idnits 2.17.1 draft-adams-tsvwg-flow-signaling-identification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2009) is 5327 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group J. Adams 3 Internet-Draft Razoom, Inc 4 Intended status: Informational 5 Expires: March 1st, 2010 6 September 15, 2009 8 Flow State Aware signalling standardisation, and a proposal for 9 alerting nodes or end-systems on data related to a flow 10 draft-adams-tsvwg-flow-signaling-identification-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 1st, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes the motivation for Flow State Aware signalling 49 and proposes a method of enabling Flow State Aware signalling packets 50 to be identified. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Motivation and Early Deployment Scenarios for FSA QoS . . . . 5 56 3. Architectural considerations . . . . . . . . . . . . . . . . . 7 57 4. Evolution considerations . . . . . . . . . . . . . . . . . . . 8 58 5. FSA Signalling Standards Development . . . . . . . . . . . . . 9 59 6. Signal Packet Identification . . . . . . . . . . . . . . . 10 60 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 61 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 62 9. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 10. Informative References . . . . . . . . . . . . . . . . . . . 12 65 1. Introduction 67 This internet draft informs on the benefits of Flow State Aware (FSA) 68 signalling, both as an ehancement of flow classification and, longer- 69 term, as the engine to create new network capabilities. 71 This internet draft also informs on an existing proposal for Flow State 72 Aware signal packet identification, and calls for further evaluation 73 of such proposals and a recommendation of the best solution by the 74 IETF. 76 2. Motivation and Early Deployment Scenarios for FSA QoS 78 Flow State Aware (FSA) technology operates at the per-flow level and 79 provides functions to manage the QoS and monitoring actions that may 80 be required on a specific flow. It distinguishes itself from Deep 81 Packet Inspection and WAN Optimisation functions in that it supports 82 FSA Transport Classes, i.e. 83 - the Maximim Rate (MR) class. Allowing a flow to start with no 84 admission control and protecting other flows from any disturbance 85 to their QoS experience through "remembering" and directing 86 discard actions on this flow (until conditions change). 87 - the Guaranteed Rate (GR) class. A class of flows that are protected 88 from discard actions under normal operating conditions. 89 - the Available Rate (AR) class. A class of flows that are supported 90 by signalling tests of the current fastest end-to-end available 91 rate 92 - the Variable Rate (VR) class. A class of flows with a minimum rate 93 (in the same sense as an MR-level of guarantee) plus an additional 94 available-rate "top-up". 96 FSA associates flow state with every flow (potentially) in any aggregate 97 of flows and/or the aggregate itself. It uses this state information to 98 perform the following: 99 2.1 QoS actions on any flow. In particular 100 2.1.1 Admission-based actions - allowing a flow to start but 101 promoting it to QoS guarantees when resources are 102 available. 103 2.1.2 Preference-based actions - controlling how soon a flow 104 is promoted to QoS guarantees 105 2.1.3 Focused packet discards. "Remembering" flows whose 106 packets are subject to some level of discard. 107 2.1.4 Guaranteed QoS. "Remembering" flows whose packets are 108 not to be subjected to any discard under normal 109 operating conditions. 110 2.1.5 Additional QoS actions if end-to-end Flow State Aware 111 signalling is operating. In particular: 112 2.1.5.1 Available Rate assignment of capacity. Based 113 on the signalling yielding the fastest end-to-end 114 available rate. 115 2.2 Measurement actions on any flow or any flow aggregate. In 116 particular: 117 2.2.1 Per-flow or per-aggregate flow policing, as required. 118 2.2.2 Per-flow or per-aggregate flow alerts, based on a 119 measured parameter, and where the alert may trigger: 120 2.2.2.1 A change of state (per flow, per aggregate) 121 2.2.2.2 A change of QoS action 122 2.2.2.3 A change of monitoring action 123 2.2.3 Per-flow or per-aggregate flow alerts, based on a 124 packet classifier parameter, and where the alert may 125 trigger: 126 2.2.3.1 A change of state (per flow, per aggregate) 127 2.2.3.2 A change of QoS action 128 2.2.3.3 A change of monitoring action 130 This internet draft focuses on signalling development associated 131 with flow state (through which the above action 2.1 and 2.2 are 132 then managed). First it may be noted that not all of the actions above 133 actually require any signalling. For example, 2.1.1 can allow a flow 134 to start immediately, regardless of whether any signalling had been 135 received related to that flow. But it would still require some actions 136 related to flow classification so that the flow was properly 137 classified as "needing QoS guarantees". Similarly, 2.1.2 could be done 138 entirely with the aid of flow classification and no signalling. 140 Furthermore performing flow classification on high speed (10 Gbit/s) 141 input links is possible (and is already being done) so no claim can be 142 made that signalling is a necessary addition to make the classifiers 143 operate at 10 Gbit/s or higher. 145 Essentially the argument for signalling is twofold: 146 A. Extending the information about what we know about a flow or what 147 we want done to a flow. 148 B. Enabling path tests, such as the Available Rate path test. 150 In the next section of this internet draft, some future possibilities 151 are listed that could extend what is being signalled and which add to 152 the argument that an FSA signalling capability can do more than a 153 classifier ever could do on its own. 155 It is clear that a richer level of information could be associated with 156 a flow if flow-based signalling accompanies that flow. This would be 157 true at any level of classifier processing power. By "accompanied" we 158 could mean either in-band or path-coupled, but in-band seems to be the 159 choice that causes the least processing hit, and opens up new 160 possibilities like high-speed transfers based on the fastest available 161 rate. 163 An investigation into the use of GIST [1] as the signal transport 164 for FSA yielded the following observations: 166 - FSA is a signal from one node to all downstream FSA nodes in 167 the path of the flow. GIST is a signal between two nodes. 168 - GIST utilises UDP encapsulation. FSA uses the same type of 169 encapsulation as is used for the data packets of the flow. 171 3. Architectural considerations 173 Reference [2] defines a Flow State Aware Signalling Edge Function. This 174 is a function that provides the origin and/ or termination of the Flow 175 State Aware end-to-end signalling path, and participates in requests 176 and responses on behalf of a user application or management action. It 177 may be located, for example, in a user end-system or at a network edge 178 node where it serves as the signalling end-point of multiple users and 179 associated applications. Alternatively, it may be located at an 180 Aggregation End-point where it supports the signalling requirements of 181 flow aggregates. 183 Figure 1 shows an overview of FSA functions 185 --------- --------- ----------- ------------ 186 | Non-FSA | | FSA | | FSA | |Aggregation | 187 | End- |---<--| End- |---<--|Signalling |---<--| End-point |--<- 188 | System |--->--|System |--->--| Edge |--->--| Function |-->- 189 |Functions| |Functions| | | | | 190 --------- --------- ----------- ------------ 192 Figure 1: FSA Functional architecture 194 In Figure 1 an FSA End-System is shown with QoS and/ or monitoring 195 capabilities but with no Signalling Edge Function. Of course, it is 196 envisaged that End-Systems may evolve so that they may have: 197 - no FSA capabilities (as is the case today) 198 - limited FSA capabilities, for example at an End-System Hub 199 - Evolved FSA capabilities, including FSA signalling 201 The Aggregation End-point is a function which attaches or deletes the 202 common Flow Aggregate Identifiers to ensure commencement of/ cessation 203 of common routing and QoS treatment of packets. This end-point also 204 initiates/ terminates in-band signalling to control Flow State 205 information retained for treatment of the flow aggregate. 207 The implication of FSA signals terminating on a FSA Signalling Edge 208 Function (including Aggregation End-point functions) is that the End 209 Systems that are receiving or sending data do not receive extra packets 210 (i.e. the signalling packets) that may otherwise cause data corruption 211 or other problems relating to TCP or UDP transmission. Instead, the only 212 packets that are forwarded further downstream from a FSA signalling Edge 213 Function are the user-data packets. 215 At the far right-hand side of Figure 1 is shown both-way multiple packet 216 flows going either downstream towards an End-System via a FSA Signalling 217 Edge Function, or upstream towards a far-end Aggregation End Point 218 function and far-end FSA Signalling Edge Function. 220 The FSA functions shown in Figure 1 may include layer 2 or layer 3 221 packet forwarding capability. Thus an example of a FSA function in 222 Figure 1 could be: 223 - an Ethernet frame-forwarding function that is "IP aware" 224 - a router 226 4. Evolution considerations 228 More insight can be gained by looking at an early FSA deployment 229 scenario and considering an evolution of this that includes FSA 230 signalling and what is then added to the value. 232 (a) First stage: Stand-alone Flow State Aware functions managing the 233 access bandwidth, QoS experience and monitoring actions associated 234 with broadband service. 236 Without signalling, such a solution could focus on 2.1.1, 2.1.2, 237 2.1.3, 2.1.4, and 2.2. 239 (b) Second stage of evolution: With signalling on some flows only. 240 Allows the support all of 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, plus 241 2.1.5 in the following limited sense: 242 - some flows are being controlled end-to-end if distributed 243 content services utilise FSA managed access bandwidth and 244 the content sources can transmit towards the users just 245 using an access network. 246 - some flows are not associated with any signalling and are 247 managed as in evolution stage (a) 248 - signalling (where used) increases the information available 249 per flow or simplifies and extends the setting of preference 250 priority or peak rate without a large number of classifier 251 rules. 253 (c) Third stage: (Could also be a second stage without signalling) 254 Access FSA functions are interconnected by fixed-bandwidth trunks 255 and: 256 - Without signalling, such a solution could focus on 2.1.1, 2.1.2, 257 2.1.3, 2.1.4, and 2.2. (but with limited information, e.g. on 258 preference priority or peak rates). 260 - With signalling, extends the number of sources that can signal 261 flow information towards an FSA QoS management function and 262 utilise signal-supported services such as AR or VR. 264 (d) Forth stage of evolution: Signalling on most flows, where some 265 sources are anywhere on the internet. Allows access to FSA signal- 266 supported QoS and monitoring capabilities for content providers who 267 have not built out content distribution to match scenario (b) or (c) 268 above. 270 (e) Fifth stage of evolution: extensions to the signalling to 271 incorporate further new capabilities (see next section). 273 Note that priority Assignment allows the sender to request the priority 274 that the sender needs for each flow. For Emergency Services, Military 275 use, and corporate use the ability for a user to assign different rate 276 priorities to each flow is critical. If the flow may be available rate, 277 the rate would then be assigned based on the priority. For maximum rate 278 flows, the priority could allow critical flows the rate they need. This 279 capability must be coupled with authorization security for the user to 280 use this priority. 282 Authorization security for a sender to use a given priority can be 283 verified with a AAA server but must be assured for each flow to insure 284 security. Per packet assurance is considered infeasible and/or 285 expensive, thus per flow security verification is the logical solution. 286 This security is critical when priorities are used but also will greatly 287 improve identifying who is sending malware or creating a DoS attack. 289 Note also that, being assigned an available rate by the network (through 290 a path test via in-band signalling) ensures that TCP type flows from a 291 FSA signalling-capable source end system can: 292 - stream at the maximum rate which is fair in the network 293 - flow at much higher rates than TCP can flow today 294 and for large distances greatly reduces the time to deliver a file. 296 5. FSA Signalling Standards Development 298 The direction of the standards work in the ITU is towards developing 299 standards that extend the range of FSA-based QoS controls through 300 explicit signalling with the inclusion of parameters indicating the 301 treatment required. The first phase of work reached consent on: 303 (a) A new transport service that provides, in effect, admission 304 control in the form of the state and packet deletion actions 305 associated with a flow. 307 (b) Requirements for FSA in a Next Generation Network. 309 These requirements are captured in ITU-T Recommendation Y.2121 [2]. The 310 ITU sent the IETF a liaison attaching Y.2121 in January 2008[3], thus 311 Y.2121 is available to the IETF. 313 The current work in the ITU is in Q5/11. Whilst many of the concepts 314 of (a) and (b) can be applied end-to-end, the focus of the ITU work is, 315 currently, only on service access scenarios. 317 More explicitly, the scope of the current standards initiative in the 318 ITU is on the application of FSA QoS in the limited capacity pathway 319 downstream from a service point of access towards an end system or 320 upstream from an end system towards a service point of access. Such a 321 pathway may cross through the core of an IP network, but any FSA signals 322 would only be visible at FSA edge functions and FSA source/ receiver 323 functions at either end (or both ends) of the access pathway. 325 FSA signals are deleted by FSA Edge functions or FSA source/ receiver 326 functions so that they do not travel beyond the access pathway. This 327 will require all FSA signal initiated at an FSA Edge (acting as the 328 virtual signal source) to be marked so that response signals associated 329 with such flows are deleted at the same Edge (even if this is separated 330 into different sending and receiving physical units). 332 Thinking further about the longer-term, there could be extensions to 333 what is conveyed in signalling packets to unlock new capabilities. So 334 far, such extensions have not been addressed, but could include: 336 (i) in-band monitor on/ monitor off commands associated with 337 monitoring a group of packets of a flow (or aggetegate) that trail 338 behind the first such command and stop at the second such command. 339 (ii) in-band monitor-and-change-state-if commands associated with a 340 group of packets that trail behind the first such command and 341 change either a QoS state or a monitoring action if a given event 342 is observed in the group of packets up until a second such command. 344 6. Signal Packet Identification 346 This internet draft is raising the solution to an issue already captured 347 in [2]. It is a requirement for a new type of in-band control packet to 348 be identifiable to any FSA node that would facilitate: 350 * The inclusion of new information obtained from (typically, but not 351 necessarily) a source function, providing rate or or other 352 data related to an individual flow or flow aggregate. 353 * The alerting of any of the following that new data is available: 354 o the receiving end system; 355 o downstream nodes with links that are affected by that flow; 356 o the source. 358 So far, Q5/11 has considered a number of alternative solutions and has 359 proposed a candidate solution to signal packet identification. This 360 solution is that all signal packets should be marked with DiffServ=an 361 EXP/LU DSCP set to "QoSSignal" 363 This is viewed, architecturally, in an analagous way to an "escape" key. 364 The DSCP = "QoSSignal" creates an escape into a new set of QoS options 365 that are conveyed in another part of the packet called the "QoS 366 Structure". 368 Because packets marked with an EXP/LU DSCP set to "QoSSignal" originate 369 and terminate on FSA Signalling Edge Functions, it is assumed that 370 this chosen solution does not change any internet protocol as currently 371 defined and operating on any network node or End-System node. 373 However, considering the evolution scenarios described in section 4 374 above, the proposed solution for FSA signal packet marking may need 375 further study if the scenarios of exploiting the FSA signal-enhanced 376 flow information and FSA QoS actions / monitoring actions extend towards 377 more general use between any two points on the internet. 379 7. Security considerations 381 An eavesdropper, which can monitor the packets that correspond to the 382 connection to be attacked could learn the IP addresses and port 383 numbers in use (and also sequence numbers etc.) and try to attack the 384 connection by generating signalling packets. 386 The protection of signalling packets with an authorization field is 387 recommended, following the principles described in [2] Annex A. 389 Furthermore, FSA monitoring functions may be used to determine the 390 frequency of signal packet arrivals and whether this frequency 391 exceeds some threshold that would signify an alert and a possible 392 DOS attack. 394 8. IANA considerations 396 This document has no actions for IANA with the existing proposal for 397 signal packet identification. But this would not be the case for some 398 alternative proposals. 400 9. Proposal 402 This internet draft indicates the background to a proposal to identify 403 a new in-band signalling packet and indicates the current candidate 404 solution that has been assumed in the ITU-T for the explicit limited 405 scope described above in section 5. Members of the IETF are 406 asked to consider this proposal and endorse the current solution for 407 the scope currently under consideration and determine the best solution 408 for extensions of this scope. 410 10. Informative References 412 [1] draft-ietf-nsis-ntlp-20 (2009), GIST: General Internet Signalling 413 Transport 414 [2] ITU-T Recommendation Y.2121 (2008), Requirements for the support 415 of flow state aware transport technology in an NGN 416 [3] ITU Liaison Statement to the IETF, Jan 2008, attachment Y.2121. 418 Authors' Address 420 Dr John Adams 421 CTO, 422 Razoom, Inc., 423 24, Keswick Close 424 Felixstowe, 425 Suffolk 426 IP11 9NZ 428 Phone: +44 1394 272713 429 email: john@razoom.com