INTERNET-DRAFT L. Roberts
Transport Area Working Group Anagran Inc.
Intended status: Informational Nov 14, 2010
Expires: May 17 2011
Flow State Aware Signaling
draft-roberts-fsasignaling-01
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 17, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Roberts Expires May 17, 2011 [Page 1]
Internet-Draft Flow State Aware Signaling Nov 2010
Abstract
The concepts in this document are based on work on
Q.Flowstatesig in the ITU SG11/Q5. Flow State Aware Signaling
has been worked on in the ITU for the past 13 years. However,
this document stands on its own since no IETF compatible format
has yet been adopted. The goal of this protocol is to provide
(1) a technique to have network nodes provide available rate
flows (like TCP) rapid and periodic feedback to the sender as to
the maximum rate they should send and (2) to provide network
feedback to fixed rate flows (like UDP voice) if the peak rate
they require can be statistically assured. Network traffic using
this protocol should experience reduced response time, less
queuing delay and less packet discards. The use of this protocol
is limited to bounded subnets at the network edge and is to be
converted to and from standard IP flows at the subnet
boundaries.
Table of Contents
1. Introduction...................................................4
2. Conventions, Definitions and General Principles................5
2.1. Conventions used in this document.........................5
2.2. Definitions...............................................5
2.3. General Principles........................................7
3. FSA Protocol...................................................9
3.1. Sender Process............................................9
3.1.1. Signaling Requests...................................9
3.1.2. Data Transfer and Signaling Renegotiates............10
3.2. Receiver Process.........................................11
3.3. Termination of the Flow..................................12
3.4. Net-Node Process.........................................12
3.4.1. Net-Node Recognition of Flows.......................12
3.4.2. Net-Node Processing of Signaling Packets............13
4. Data Structures...............................................14
4.1. Data Packet Structure....................................14
4.1.1. GRE-FSA Header......................................14
4.2. Signaling packets........................................15
4.3. QoS Structure............................................15
4.4. Floating Point Rates.....................................17
4.5. FSA Sender Depth (FSD)...................................17
5. Security Considerations.......................................18
6. IANA Considerations...........................................19
7. Conclusions...................................................19
Roberts Expires May 17, 2011 [Page 2]
Internet-Draft Flow State Aware Signaling Nov 2010
8. References....................................................19
8.1. Normative References.....................................19
9. Acknowledgments...............................................20
Roberts Expires May 17, 2011 [Page 3]
Internet-Draft Flow State Aware Signaling Nov 2010
1. Introduction
Today many of the applications on the Internet would operate
better if there were no discards, delay, or rate variation for
the packet flow. Overcapacity is one way to achieve this but at
the network edge this is often much too expensive since TCP will
expand to fill most any link bandwidth. At that edge each TCP
flow is normally controlled by adding delay and random discards,
generally using RED or simple tail drop. With current technology
the network cannot provide feedback to the sending process as to
what rate each individual flow can operate at to achieve its
desired QoS with minimal delay and no packet discards. That is
the goal of this protocol.
This document describes a Flow State Aware (FSA) protocol that
allows network nodes along the path of a data flow provide
feedback to the Sender as to the transmission rate the network
can support. There are two rates negotiated between the Sender
and all the network nodes in the flow path; an available rate
(AR) updated periodically and a guaranteed peek rate (GR) which
is good for the duration of the flow. These rates are used to
define four services. To determine these rates and the related
QoS parameters, the Sender sends a signaling packet requesting
the rates and QoS desired for a flow. Each network node on the
path can reduce the rates and other QoS parameters to rates and
QoS that node can support. When the signaling packet arrives at
the destination, it is returned to the Sender. The Sender can
then send the data flow at the signaled rates. The Sender also
must send additional requests periodically so that the rates can
be updated as the network load changes or if path failures
occur. An example is in Figure 1 below where the Sender requests
the maximum rate his computer can send, the first Net-Node marks
that down to 10 Mbps and the next Net-Node marks that down to 5
Mbps. When the QoS Structure arrives at the Receiver it returns
it to the Sender (not necessarily on the same path). Upon
receiving the 5 Mbps rate in a response, the Sender can jump to
that rate for the delivery of the flow.
Request Request Request
100Mbps 10 Mbps 5 Mbps
+------+ +---------+ +---------+ +--------+
| |----->| |----->| |----->| |
|Sender|<-----|Net-Node1|<-----|Net-Node2|<-----|Receiver|
+------+ +---------+ +---------+ +--------+
Response Response Response
5 Mbps 5 Mbps 5 Mbps
Figure 1: Determining a Sending Rate
Roberts Expires May 17, 2011 [Page 4]
Internet-Draft Flow State Aware Signaling Nov 2010
This process requires that signaling packets follow the same
path as the data flow packets so that the feedback is from the
nodes on the path. Thus, the requirement is to use inband
signaling, not out-of-band signaling.
Although this process requires a new function at each network
node, it need not be integrated into the routers; it can be
added as separate inline traffic management card or system. The
task of examining about 7% of the packets and marking them if
necessary is easily accomplished today at 10 Gbps line rates.
Since the process would be far more difficult at 100 Gbps today
it should not be expected to be supported in the core, rather it
is being specified to be restricted to bounded subnets at the
network edge.
2. Conventions, Definitions and General Principles
2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [RFC2119].
In this document, these words will appear with that
interpretation only when in ALL CAPS. Lower case uses of these
words are not to be interpreted as carrying RFC-2119
significance.
2.2. Definitions
1. Sender: A Sender is the process where data flows are
encapsulated to transit a bounded subnet. The Sender process
accepts standard IP as input and encapsulates each TCP or UDP
flow with a GRE-FSA header and inserts Flow State Aware (FSA)
signaling messages as necessary into the encapsulated stream.
It also manages the sending rate as indicated by the FSA
signaling feedback. All other IP traffic is forwarded without
encapsulation.
2. Receiver: A Receiver is the process which receives traffic
from the bounded subnet, interprets the signaling messages,
returns encapsulated signaling responses, and de-encapsulates
Roberts Expires May 17, 2011 [Page 5]
Internet-Draft Flow State Aware Signaling Nov 2010
the data flows. It then outputs standard IP to the network or
computer on the outside of the bounded subnet.
3. Proxy: A Proxy is a process or system which contains both a
Sender and a Receiver. It is used to separate a bounded subnet
from standard IP networks. On the side toward the bounded
subnet (the FSA side)it sends and receives encapsulated TCP
and UDP flows. On the side away from the bounded subnet (the
IP side), it sends and receives standard IP.
4. End-system: A End-system is either a user's computing device
or a server which incorporates the Sender and Receiver
functions.
5. Net-Node process: A Net-Node process is the network process
that examines all GRE-FSA Encapsulated packets and, if they
are marked as containing signaling, the signaling is processed
and, if necessary, modified to lower the rates or QoS such
that the flow can be supported with minimal delay and no
discards at that network node.
6. Bounded Subnet: A section of IP network totally bounded by
proxies or End-systems and where all the network nodes support
Net-Node processes.
7. QoS Structure: A 16 byte block, used in packets marked as
signaling packets that contains the rates and QoS parameters
which are to be negotiated with the Net-Nodes.
8. Available Rate Service (ARS): A transport service primarily
for applications that can flexibly adapt to the current
available capacity and can quickly adjust their sending rate
as the available capacity changes.
9. Variable Rate Service (VRS): A transport service for
applications that want an AR service and can flexibly take
advantage of additional available capacity, but requires a
minimum capacity.
10. Maximum Rate Service (MRS): A transport service for streaming
applications that internally control their peak rate and need
a fixed maximum rate path where they will experience minimal
discards or delays.
Roberts Expires May 17, 2011 [Page 6]
Internet-Draft Flow State Aware Signaling Nov 2010
11. Guaranteed Rate Service (GRS): A transport service for
applications that require guaranteed bandwidth for the
duration of the flow.
12. State Timeout Timer (STT): STT is the maximum time that is
allowed between two packets before the flow state should be
dropped. The STT default value is 2 seconds.
13. Response Timeout period (RTO): RTO is the time to wait for a
Response to a Request or Close packet before retransmitting
the Request or Close. The RTO default value is 1 second.
14. Response Timeout Count (RTC) is a counter that is decremented
every time a response time out (RTO) occurs. The default RTC
is 3.
15. Flow Sender Depth (FSD): When there are FSA subnets like a
satellite link inside a FSA subnet it is important to not
double encapsulate the packets. Therefore each QoS Structure
contains a Flow Sender Depth (FSD) which is incremented by one
when encountering the IP side of a Proxy and decremented by 1
when encountering the FSA side of a proxy. When FSD>1 no
encapsulation or de-encapsulation should occur.
16. Error Rate Threshold (ERT): ERT is a parameter in a Sender
which, if exceeded, causes the Sender to drop out of the FSA
protocol and send the remainder of the flow as standard IP.
The default ERT is 2% packet loss but can be set higher if
there is a known noisy link in the forward path.
17. NormPriority: NormPriority is the highest priority value that can
be authorized without sender authentication. The priority field is
8 bits with the highest value being the leftmost bit. The default
value of NormPriority is 0010000 or 1/8 of the range which with 5
bit priorities allows 4 values for the average user.
2.3. General Principles
The Internet has progressed today to support much higher speeds
and volumes of traffic but it still it suffers from delay, delay
jitter and packet discards at the edges where the rates must be
controlled. This has little effect on bulk file transfers but
for interactive applications it would be valuable to eliminate
these artifacts. This protocol allows these problems to be
virtually eliminated as traffic transits the edge. The
Roberts Expires May 17, 2011 [Page 7]
Internet-Draft Flow State Aware Signaling Nov 2010
technology to support this protocol was not economic a decade
ago but with today's low cost of memory and processing it is
quite economic to support the required functions. It is to be
expected that the introduction of FSA technology will be slowly
adopted as the needs dictate. Therefore, it should be carefully
limited to bounded subnets and support simple interworking with
IP networks that do not support FSA signaling.
For example, one application of FSA technology could be to
include Proxy software in DSL or Cable modems, place a Net-Node
process on the network side of the DSLAM or CMTS systems, along
with another Proxy to remove signaling just before the core
network. Thus a single POP might be upgraded to eliminate the
discards and delay introduced at the user edge, allowing smooth
managed flows to move from the core to the users modem and thus
into his LAN. Since neither the users LAN nor the core network
is likely to need to further reduce the flow rates, the
interactive response time, speed, and throughput would be
significantly improved for users within that POP.
Another possible use of FSA technology is in optimizing the
throughput, reducing delay, and eliminating discards as IP
traffic transits a long haul trunk between two higher bandwidth
networks. Examples are satellite links, trans-ocean cables, and
limited capacity international links. TCP would normally slow
down considerably when encountering the long haul delay and have
long periods to recover from discarded packets. However, with
Proxies at either end and a Net-Node system at one end, TCP
would not be impacted seriously by the added delay and would
avoid needing to recover from discards. Due to the ability to
jump to its allocated rate after one round trip it would not be
impacted by the long delay even when a packet was lost due to
noise. Also the throughput would not be limited by the WAN link
delay.
Thus the goal of this document is to introduce a protocol that
can be implemented incrementally into sections of any IP network
as economics and demand dictate. By encapsulating the traffic
within a new GRE-FSA header between Proxies or End Systems it is
intended that there would be no adverse impact on any network
equipment or end system. The reason for this Internet Draft is
to see if the IETF can see any potential problems that might
have adverse impact to the network or users.
If for any reason there is a system within a bounded subnet
which is not behind a proxy and does not have a FSA supported
End-system, the encapsulated packets would be discarded as
Roberts Expires May 17, 2011 [Page 8]
Internet-Draft Flow State Aware Signaling Nov 2010
unknown. The design is such that if the Sender does not receive
a response to his initial request, the Sender will revert to
standard IP, thereby continuing without any adverse effect
except to lose the benefits of the FSA Protocol.
3. FSA Protocol
The following is a specification of the FSA protocol. It is
intended as a short but complete specification.
3.1. Sender Process
The job of a Sender is to encapsulate TCP and UDP flows within a
GRE-FSA header, inserting where appropriate signaling packets
carrying QoS Structures. Packets which contain QoS Structures
MUST be marked as signaling packets. The Encapsulation is in a
GRE protocol packet. This packet format is a standard IP header
with GRE specified as the protocol. The first 4 byte word after
the IP header is is the GRE header which contains an Ethertype
indicating FSA protocol as obtained from the IEEE. Currently
Ethertype 0x22EF has been obtained for this protocol. The first
2 bytes in the GRE header is set to zero. The 4 byte work after
the GRE header is the FSA header and it contains a signaling bit
S, the protocol code (TCP or UDP) of the flow, and a word offset
to the first QoS Structure, if any. The S bit MUST be zero for
non-signaling packets and MUST be one for signaling packets. As
the GRE and FSA headers allways occur together, the pair will be
called the GRE-FSA header.
3.1.1. Signaling Requests
When the Sender detects a new flow (where the addresses, ports,
and protocol are not the same as any current flow), the Sender
MUST encapsulate each data packet underneath a copy of the
packets IP header but with the Protocol or Next Header set to
GRE followed by a GRE-FSA header.
The GRE-FSA header MUST be marked as a signaling packet (S=1).
Following the GRE-FSA header should be the TCP or UDP header.
Next a QoS Structure should be affixed to the end of the packet.
The QoS structure should contain the desired service type,
rates, and other QoS parameters and is marked as a Request
packet.
For TCP the first packet, marked a Request signaling packet, MAY
serve both as the data SYN and the Request. If a separate packet
is used, the SYN bit and the ACK bit in the signaling packets
TCP header MUST be set to zero to indicate that it is not to be
Roberts Expires May 17, 2011 [Page 9]
Internet-Draft Flow State Aware Signaling Nov 2010
forwarded by the Receiver. For UDP the FSA Request signaling
packet is always a separate packet.
When the Sender is sending encapsulated TCP it expects that all
the Net-Nodes along the path are adjusting the rate (AR) such
that none of the Net-Nodes will need to discard packets from the
flow due to congestion. Thus, any lost packets are expected to
be due to transmission problems. Therefore the Sender SHOULD
continue sending at the designated rate even if packets are
lost. The standard TCP retransmission of lost packets will
correct the transmission losses.
It may be possible that one network node along the flow path has
not properly implemented the Net-Node processing and starts
discarding packets. To ensure that the traffic is not harmed
excessively at that node, each Sender SHOULD monitor the packet
loss rate and if it exceeds an Error Rate Threshold (ERT), the
Sender SHOULD stop encapsulating the flow and continue with the
flow as standard IP. If the path is known to be across a known
noisy link, the ERT setting should be set slightly higher than
the known packet loss rate.
In the case of a Proxy, it is taking in IP packets and sending
forward FSA encapsulated packets and the necessary signaling
packets. However, if the incoming packets include FSA Signaling
packets, then it should increase the Flow Sender Depth (FSD) by
1 and just forward the packets without encapsulating them again.
This allows there to be FSA subnets imbedded within a larger FSA
subnet.
If no Response packet is received after a Request is made within
a Response Timeout period (RTO) from the Request time, then the
Sender MUST retry up to two more times sending Request packets.
If after three tries, no Response is received, the FSA SHOULD
send a close packet (to notify the Net-Nodes) and then send the
data flow with no encapsulation and no signaling packets.
3.1.2. Data Transfer and Signaling Renegotiates
Once a Response is received, the Sender should proceed to
encapsulate and send the packets of the data flow with S set to
zero indicating non-signaling. For UDP flows, data packets MAY
be sent between the Request and when the Response is received
but these packets are at risk of being discarded since no rate
has yet been agreed.
Roberts Expires May 17, 2011 [Page 10]
Internet-Draft Flow State Aware Signaling Nov 2010
Renegotiate Signaling packets MUST be inserted into the data
flow periodically. After sending a Request packet, the Sender
MUST send a renegotiate packet after 1 second or after 16
packets whichever is earlier. After that the Sender MUST insert
Renegotiate packets after one second or every 128 packets,
whichever is earlier. The Renegotiate packets allow the Net-
Nodes to re-determine the rate for ARS and VRS higher or lower,
depending on network load. For MRS and GRS the renegotiate acts
as a keep alive with the Net-Nodes and allows them to, in
unusual circumstances such as trunk failures, to slow the flow
or even to terminate the flow (rate=0). Since Renegotiate
signaling packets would add 24 bytes to a data packet which
might exceed the maximum size, they should be sent as separate
packets, using the IP header from one of the flows data packets
but with the protocol set to GRE followed by the IP and TCP or
UDP headers of the prior packet but with no data section. The
QoS Structure should be attached at the end. The Receiver will
delete these separate signaling packets from the output TCP or
UDP flow.
The receiver at the Sender's site will be receiving the
Responses sent from the remote Receiver. If a Response has the
protocol TCP and SYN=1 or ACK=1 in the TCP header, the rates and
QoS should be applied to the sender's parameters and the
encapsulated TCP SYN/ACK or ACK packet should be extracted and
sent to the output stream. If alternatively SYN=ACK=0 then the
rates and QoS should be applied to the sender's parameters and
the packet discarded.
3.2. Receiver Process
The Receiver is the other half of the Sender process. It
receives and responds to the FSA Signaling commands and extracts
the encapsulated data flow. The extracted data flow is then
forwarded to its output, typically the next stage of the network
or the Receivers computer.
When the Receiver process receives a Request signaling packet it
will have the rate that the Sender should send at. Unless the
FSD counter is greater than one the Receiver SHOULD pass the QoS
Structure back to the Sender by constructing a Signaling packet
marked as Response. The Response SHOULD have the QoS Structure
parameters AR, GR, PP, DP, TP, and BT exactly as received. FSD
SHOULD be set to one and CD set to Response. If the Receiver has
local limitations on the rate it can receive which are less than
the AR+GR rate specified in the QoS Structure, it SHOULD reduce
the rates to its own limit.
Roberts Expires May 17, 2011 [Page 11]
Internet-Draft Flow State Aware Signaling Nov 2010
For a Response signaling packet where the protocol is TCP, the
Receiver MAY attach a second QoS Structure to the bottom of the
packet to specify its own Forward rate and QoS request. The
Receiver should mark CH bit 2 of the first QoS structure to a 1
to indicate there is a second QoS Structure. Then the packet is
returned.
If a TCP Request or Renegotiate signaling packet has the SYN bit
set in the TCP header and the Flow Sender Depth (FSD) is one,
the GRE delivery IP header, the GRE-FSA header, and the QoS
Structure(s) SHOULD be removed and the remaining TCP SYN packet
sent forward as a data packet. Similarly, if a receiver receives
a TCP Response packet with the ACK bit set and FSD=1 it should
strip the encapsulation and QoS Structure and forward the TCP
SYN/ACK or ACK packet as a data packet.
If a Signaling packet has FSD>1, the receiver should decrease
FSD by 1 and forward the packet without de-encapsulating it,
to the output data stream.
All encapsulated data packets (S=0) SHOULD be de-encapsulated
(removing the GRE-FSA header and moving the flow protocol to
the IP header) and forwarded to the output data stream except
when the first Signaling packet has had FSD>1.
3.3. Termination of the Flow
When a Sender receives no more data packets as part of a flow
for the State Timeout Timer period (STT) then the Sender should
consider this flow terminated and close out its state.
3.4. Net-Node Process
Each network node within a bounded subnet where branching occurs
needs to have a Net-Node process. The Net-Node should police all
flows to ensure they do not violate the rules they have agreed
to. It also needs to keep track of the total traffic which is on
the trunk or trunks it is managing. This is typical operation
for a traffic manager.
3.4.1. Net-Node Recognition of Flows
When a GRE-FSA packet is received, the Net-Node needs to collect
the two addresses from the encapsulated IP header, the protocol
from the FSA header, and the two port fields from the first 4
bytes of the TCP or UDP header. These 5 fields uniquely identify
Roberts Expires May 17, 2011 [Page 12]
Internet-Draft Flow State Aware Signaling Nov 2010
the flow. They can be hashed to aid in the flow lookup. This
process will identify the signaling packets and the datapackets
as the same flow.
3.4.2. Net-Node Processing of Signaling Packets
The new task is to watch for FSA Signaling packets. They will be
GRE packets with Ethertype FSA and have the S field in the FSA
header set to 1. For these packets it needs to examine the QoS
Structure and see if they are on the forward path which is true
if the CD field is odd (CD=1,5,7). For CD=even (2) they should
just be forwarded. For CD=1 or 5 the rates and QoS requests
should be examined to see if the rates can be supported given
the QoS request. If they can be supported within the available
capacity on their path then the packet should be forwarded
untouched. If the rates must be reduced to fit within the
available capacity, the rates should be reduced as needed. Also
if the QoS must be changed for this path, the relevant QoS
parameter should be reduced. If either change is made, the
Modify bit (M) should be set to one. For forward signaling
packets, changed or not, the rates agreed to should be saved for
policing the flow. For CD=7 (Close) the FSA state SHOULD be
deleted.
For all FSA flows, if there is a gap between packets of STT
seconds then the Net-Nodes MAY drop the flow state for that
flow.
It might seem that all Net-Nodes would need to know the final
rates and QoS agreed to but this is unnecessary. The Net-Nodes
are not reserving capacity as wasted bandwidth, they are only
policing and adjusting flow rates dynamically to ensure a modest
safety margin. If node 1 has passed a request which asked for 10
Mbps and node 2 reduced the rate to 5 Mbps, node 2 will be
policing the flow to 5 Mbps if necessary. Actually the Sender
will be sending at <=5 Mbps unless miss-configured. If the flow
is sent at 7 Mbps, node 1 will not police the flow, but Node 2
will police it. The same concept is true for closing flow state,
since all systems (Sender, Receiver, and Net-Nodes) will drop
the flow state 2 seconds after the final packet.
Roberts Expires May 17, 2011 [Page 13]
Internet-Draft Flow State Aware Signaling Nov 2010
4. Data Structures
4.1. Data Packet Structure
The data structure for a non-signaling encapsulated packet
follows: The delivery Header is a GRE IP header which is an
exact copy of the encapsulated packets IP header except that the
IPv4 protocol or IPv6 Next Header is changed to GRE. The GRE-FSA
header follows the Delivery header. The data packet less the IP
header follows the GRE-FSA header.
--------------------------------------
| Delivery Header |
--------------------------------------
| GRE-FSA Header |
--------------------------------------
| |
| TCP or UDP header and data |
| |
--------------------------------------
Figure 2: Encapsulated Data Packet
4.1.1. GRE-FSA Header
The GRE-FSA header length is 8 bytes. The GRE-FSA header has the
form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserverd0 | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved1 | Flow Protocol | QoS Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GRE-FSA header
The first two bytes are GRE defined flags and a 3 bit Version
field. They should all be set to zero, completing the GRE
defined header. Following this is the FSA header, starting with
the S (Signaling) bit. The 6th byte is the protocol of the flow,
originally in the IP header. It should be TCP or UDP. The 7th
and 8th bytes is the number of 4 byte words before the first
QoS structure, if a signaling packet, set to zero for data
packets. This allows quick access to the QoS information.
Roberts Expires May 17, 2011 [Page 14]
Internet-Draft Flow State Aware Signaling Nov 2010
4.2. Signaling packets
A Signaling packet consists of an IP delivery header which is a
copy of the data packets IP header but with the protocol or Next
Header set to GRE (47). It is followed by a GRE-FSA header with
S=1. After the GRE-FSA header comes the TCP or UDP headers of
the data packet. At the end the 16 byte QoS Structure is
affixed.
--------------------------------------
| Delivery Header |
--------------------------------------
| GRE-FSA Header |
--------------------------------------
| TCP or UDP header |
| |
--------------------------------------
| QoS Structure |
--------------------------------------
Figure 4: Signaling Packet with QoS Structure
4.3. QoS Structure
The QoS Structure is 16 bytes as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Rate (AR) | Guaranteed Rate (GR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PP | DP | CD | TP | BT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Version | M | Reserved3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: QoS Structure
Roberts Expires May 17, 2011 [Page 15]
Internet-Draft Flow State Aware Signaling Nov 2010
The QoS Fields in a QoS Structure are as follows:
Reserved2: (32 bits) Reserved and set to 0.
AR: (16 bits) Available Rate - floating point rate as described
in section 4.4 for network assigned rates e.g. as used for TCP
traffic.
GR: (16 bits) Guaranteed Rate - floating point rate as described
in section 4.4 for user specified fixed rate traffic (GRS, MGS,
and the minimum rate of VRS) - this is the peak rate allowed.
PP: (8 bits) Preference Priority - indicates a relative rate
priority for AR and VR and an acceptance priority for MR and GR
flows - 64 levels - 0=lowest, 63=highest in the high order 6
bits (bits 0-5). The two low order bits are reserved and should
be set to 0.
DP: (8 bits) Delay Priority in 64 levels. - 0=lowest priority,
63=highest priority. The highest level gets priority in
transmission reducing delay and delay variation.
CD: (4 bits) Change/Direction field - Bit 0: set to zero, Bits
1-3: 0= No action required, 1=Request at the start of a flow to
negotiate the QoS parameters, 2= Response returning agreed
parameters to the Sender, 3=Reserved, 4=Reserved, 5=Renegotiate,
a sender request to renegotiate rates on the continuation of a
flow. 6=Reserved, 7=Close, sent by Sender to close out Net-Nodes
state.
TP: (4 bits) Bits 0-1: Reserved and set to zero; Bits 2-3: Type
of flow - 0=Available Rate Service (ARS), 1=Variable Rate
Service (VRS) composite rate where GR is requested as a fixed
minimum and AR is additional bandwidth assigned by the network,
2=Maximum Rate Service (MRS), 3=Guaranteed Rate Service (GRS).
CH: (4 bits) Bit 2: Second QoS Attached, 0 = single QoS
Structure, 1 = Second QoS Structure follows; Bit 3: Security
Structure attached, 0 = No Security Structure follows, 1 =
Security Structure follows.
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 - set to 1.
Roberts Expires May 17, 2011 [Page 16]
Internet-Draft Flow State Aware Signaling Nov 2010
M: (4 bits) Bit 3: Modified marker. Set to 0 by Sender on
Request or Renegotiate. Set to 1 by Net-Nodes if any field
changed during a request or renegotiate; Bits 0-2: Flow Sender
Depth (FSD) - Set to 1 by Sender, increased by one entering a
proxy and decremented by one when leaving a proxy.
Reserved3: (16 bits) Reserved and set to 0
4.4. Floating Point Rates
The AR and GR rates are passed as 16 bit floating point
numbers.
. 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.
. Rates are in kilobits per second.
. Since E can be as large as 31 and M 511, the maximum rate is
4.291 Tbps. The lowest rate would be 1 Kbps since 0 is zero.
. Rates are to be measured based on averaging over the Burst
Tolerance time. The default Burst Tolerance is 1/2 second which
means the rate may peak higher momentarily but policing will
occur only if the 1/2 second average exceeds the rate agreed
to.
. The rate is measured using all the bytes in the IP packet
including the delivery header and GRE header.
4.5. FSA Sender Depth (FSD)
In some cases, there may be bounded subnets inside bounded
subnets. To protect against errors which would otherwise occur
in this case, any Sender that receives signaling packets on its
IP input side, would assume it is an inner subnet and should
only add 1 to FSD rather than creating signal packets and
setting FSD to 1. It should remember that the flow has FSD>1
and pass GRE-FSA data packets without encapsulating them.
Receivers who receive a signaling packet on the FSA side with
FSD >1 should reduce FSD by 1 and not de-encapsulate the packets
or delete the signaling packets. If instead, FSD=1 when
received, the Receiver should remove all the encapsulation, drop
stand alone signaling packets, and delete all QoS Structures.
Roberts Expires May 17, 2011 [Page 17]
Internet-Draft Flow State Aware Signaling Nov 2010
5. Security Considerations
This protocol might be attacked in many ways. Taking them one at
a time:
. An attacker might attempt to use a priority that was higher
than others were using. Therefore, all priorities higher than
NormPriority should be reduced to NormPriority by the Net-
Nodes until such time that the Security Structure process is
in place. There is a flag in the QoS Structure, bit 3 of CH,
that indicates that a security structure follows the QoS
Structure(s). The security Structure is intended to include
encrypted information that conveys to the network and to the
receiver a code assigned for a period of time by a AAA server
which identifies the person and/or system which is sending the
flow. The Net-Node equipment can then query the AAA server to
find out this user's maximum priority authorization if they
are registered. The network can then allow higher priority to
Emergency Service workers in the public network, military
officials in a military network, or corporate officials or
processes in a corporate network. The bottom levels of
priority would allow all users to prioritize background tasks,
interactive tasks and critical tasks as they choose. The
network would not however have the authority to find the users
name or other details from the AAA servers since they are only
authorized to obtain priority. The receiver may have other
characteristics it is authorized to request like the users
name if the receiver is a bank. The user would then have
authorized the AAA server convey their name to that bank. All
the details of the security structure are currently incomplete
thus the security authorization process will need to be
submitted later.
. Denial of Service attacks could be launched to try an overload
the Net-Node processes with Signaling packets. However, Net-
Nodes should always limit the frequency of Signaling Packets
to the agreed frequency of 1 per second per flow or 1 per 128
packets, so as to avoid this attack. If a sender exceeds this
rate, then that source address can be blacklisted or reduced
to a very low raate. Also, standard subscriber equalization
(which ensures all active subscribers receive nearly equal
capacity) eliminates most other overload type of attacks.
Roberts Expires May 17, 2011 [Page 18]
Internet-Draft Flow State Aware Signaling Nov 2010
. Requests for large fixed bandwidths could attempt to block
others from obtaining capacity. However, the suggested method
for the Net-Nodes is to not reserve any bandwidth, but to
continuously measure the total usage and to keep say 8%
headroom for rapid changes. This way for anyone to try and
block others can only be done by using the capacity. Again,
subscriber equalization can assure that no individual could
block others.
. There are many other areas where security could become an
issue. When the security structure is added, these will be
considered.
6. IANA Considerations
IANA should add the FSA Ethertype to its approved list of
Ethertypes. This is desirable so that IP equipment knows what
the FSA Ethertype means; however, they could always look at the
IEEE list.
7. Conclusions
Pursuant to RFC 4775 [RFC 4775], this Internet Draft sets forth the
FSA protocol that the ITU has been working on for many years. In
its liaison to the ITU, the IESG has suggested that new protocols
might be a viable way to identify signaling packets. Rather than
use up protocol codes, this proposal uses the already defined
and well understood technique of encapsulating using the GRE
protocol with a IEEE issued Ethertype. The purpose is to inform
the IETF on the proposed protocol so that they can advise the
ITU if they see any interoperability issues that the FSA
protocol might have with the IETF standards.
8. References
8.1. Normative References
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC 2784] T. Farinacci, T. Li,S. Hanks, D. Meyer, and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000
[RFC 4775] S. Bradner, "Procedures for Protocol Extensions
and Variations", RFC 4775, December 2006
Roberts Expires May 17, 2011 [Page 19]
Internet-Draft Flow State Aware Signaling Nov 2010
9. Acknowledgments
ITU SG11 Question 5; Q.Flowstatesig.
This document was prepared using 2-Word-v2.0.template.dot.
Roberts Expires May 17, 2011 [Page 20]
Internet-Draft Flow State Aware Signaling Nov 2010
Authors' Addresses
Lawrence Roberts
Anagran Inc.
580 N Pastoria Ave
Sunnyvale, CA 94062
Phone: 408-7801-0880 x6134
Email: lroberts@anagran.com
Roberts Expires May 17, 2011 [Page 21]