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]