idnits 2.17.1 draft-wing-pcp-flowdata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 03, 2013) is 3949 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-01 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group D. Wing 3 Internet-Draft R. Penno 4 Intended status: Standards Track T. Reddy 5 Expires: January 04, 2014 Cisco 6 July 03, 2013 8 PCP Flowdata Option 9 draft-wing-pcp-flowdata-00 11 Abstract 13 This document defines a mechanism for a host to signal flow 14 characteristics to the network, and the network to signal its ability 15 to accommodate that flow back to the host. The mechanism defines a 16 new PCP option for the existing MAP and PEER opcodes. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 04, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. PCP FLOWDATA Option . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Usage and Processing . . . . . . . . . . . . . . . . . . 4 56 3.2. Generating a PCP Request with FLOWDATA Option . . . . . . 5 57 3.3. Processing a Request with FLOWDATA Option . . . . . . . . 6 58 3.4. Processing a Response with FLOWDATA Option . . . . . . . 7 59 3.5. Link or State Changes on PCP Server . . . . . . . . . . . 7 60 3.6. Conflict Resolution . . . . . . . . . . . . . . . . . . . 8 61 4. PCP FLOWDATA Option Data Fields . . . . . . . . . . . . . . . 9 62 5. FLOWDATA Interaction with PCP Proxy . . . . . . . . . . . . . 14 63 6. Network Authorization . . . . . . . . . . . . . . . . . . . . 15 64 7. Scaling Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 70 11.2. Informative References . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 Access networks often have insufficient bandwidth or other 76 characteristics that prevent some applications from functioning as 77 well as desired. Although the quality of wireless and wired access 78 networks continue to improve, those access networks are often 79 constrained for various reasons. This document provides a mechanism 80 to signal the application's network requirements to the access 81 network, so that certain network flows can receive service that is 82 differentiated from other network flows. With this mechanism, a host 83 can request the network provide certain characteristics for a flow in 84 both the upstream and downstream directions. The network authorizes 85 the request and signals back to the host that it can (fully or 86 partially) accommodate the flow. This sort of signaling is useful 87 for long-lived flows such as interactive audio/video, streaming 88 video, and network control traffic (call signaling, routing 89 protocols). 91 In order to obtain such differentiated service from a network, many 92 previous mechanisms have been created for hosts to convey flow 93 information to the network. The mechanism described in this document 94 has several useful properties: 96 o Usable at the application level, without needing operating system 97 support; 99 o Abstracts layer 2 specifics, so host and applications can avoid 100 layer 2-specific signaling; 102 o Robust metadata support, to convey sufficient information to the 103 network about the flow; 105 o Differentiates service on the local network and the immediately 106 adjacent access network, which is typically bandwidth constrained; 108 o Deployable on a local network and its adjacent access link, 109 without needing support of the remote host's network or support of 110 the remote host; 112 o Provides differentiated service for both directions of a flow, 113 including flows that cross administrative boundaries (such as the 114 Internet). 116 The mechanism described in this specification defines an extension to 117 Port Control Protocol (PCP [RFC6887]). This may be surprising at 118 first because PCP is considered as a protocol for managing mappings 119 in NATs and firewalls. However, PCP does not require the network 120 implement a NAT or to implement a firewall. This is an important 121 point: this specification does not require the network operate a NAT, 122 and does not require the network operate a firewall. At a high 123 level, PCP provides bi-directional communication a flow to the 124 network. PCP can recursively communicate flow information to a 125 number of on-path devices using PCP itself 126 ([I-D.cheshire-recursive-pcp], [I-D.ietf-pcp-proxy]) or using an SDN 127 protocol. Such recursion provides the flow information to more 128 devices on the path, allowing each of them to optimize the flow over 129 their respective links. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. PCP FLOWDATA Option 139 The FLOWDATA option described in this document allows a host to 140 signal the bi-directional characteristics of a flow to its PCP 141 server. After signaling, the PCP server determines if it can 142 accommodate that flow, making configuration changes if necessary to 143 accommodate the flow, and returns information in the FLOWDATA option 144 indicating its ability to accommodate the described flow. 146 3.1. Usage and Processing 148 A host may want to indicate to the network the priority of a flow 149 after the flow has been established (typical if the host is operating 150 as a client) or before the flow has been established (typical if the 151 host is operating as a server). Both of these are supported and 152 depicted in the following diagrams. 154 The following diagram shows how a connection is first established and 155 then the flow is prioritized. This allows for the fastest connection 156 setup time with the server. 158 PCP client PCP server UDP/TCP server 159 | | | 160 |-------------TCP SYN, SYNACK, ACK----------------------->| 161 | | | 162 | (flow is not prioritized) | | 163 | | | 164 |------- PCP PEER + FLOWDATA Option ------>| | 165 |<-----------------SUCCESS-----------------| | 166 | | | 167 | (flow is prioritized) | | 168 | | | 170 Figure 1: Message diagram, client connects first 172 The following diagram shows first asking the network to prioritize a 173 flow, then establishing a flow. This is useful if the priority of 174 the flow is more important than establishing the flow quickly. 176 PCP client PCP server UDP/TCP server 177 | | | 178 | | | 179 |------- PCP PEER + FLOWDATA Option ------>| | 180 |<-----------------SUCCESS-----------------| | 181 | | | 182 | (flow is prioritized) | | 183 | | | 184 |-------------TCP SYN, SYNACK, ACK----------------------->| 185 | | | 187 Figure 2: Message diagram, client sets priority first 189 The following diagram shows a PCP client getting a PCP MAP mapping 190 for incoming flows with priority. This ensures that the PCP client 191 has a mapping and all packets associated with the incoming TCP 192 connections matching that mapping are prioritized. The PCP Client in 193 this case could be a video server in a data center. 195 PCP client PCP server UDP/TCP client 196 | | | 197 (listening on port XYZ) | | 198 | | | 199 |-------PCP MAP + FLOWDATA Option------>| | 200 |<-------------SUCCESS------------------| | 201 | | | 202 | (flow is prioritized) | | 203 ... ... ... 204 | | | 205 |<------------TCP SYN, SYNACK, ACK---------------------| 206 | | | 208 Figure 3: Message diagram, operating a server 210 The following diagram shows how two separate connections, where only 211 one is active at a time, use the same instance identifier. 213 PCP client PCP server TCP srvr 1 TCP srvr 2 214 | | | | 215 |-------------TCP SYN, SYNACK, ACK----------->| | 216 | | | | 217 | (flow to server 1 is not prioritized) | | 218 | | | | 219 |-PCP PEER+FLOWDATA instance=123-->| | | 220 |<-----------------SUCCESS---------| | | 221 | | | | 222 | (flow to server 1 is prioritized) | | 223 | | | | 224 |-------------TCP SYN, SYNACK, ACK------------------------>| 225 | | | | 226 | (flow to server 2 is not prioritized) | | 227 | | | | 228 |-PCP PEER+FLOWDATA instance=123-->| | | 229 |<-----------------SUCCESS---------| | | 230 | | | | 231 | (flow to server 2 is sharing | | 232 | characteristics with flow to server 1) | | 233 | | | | 235 Figure 4: Message diagram with Instance Identifier 237 3.2. Generating a PCP Request with FLOWDATA Option 239 The PCP client first does all the processing described in Sections 240 8.1, 11.2, and 12.3 of [RFC6887] as appropriate for generating a MAP 241 or PEER opcode request. Included in that request is a FLOWDATA 242 option formatted as described in this document. For flows 243 established by the PCP client, the MAP or PEER request with FLOWDATA 244 option can be sent before or after the PCP client has established any 245 flows. For flows terminated by the PCP client (that is, when 246 operating a server), the FLOWDATA option can be received and 247 processed by the PCP server together with a MAP request or later 248 during a MAP refresh request as shown in Figure 3. 250 3.3. Processing a Request with FLOWDATA Option 252 The PCP server performs processing in the order of the paragraphs 253 below. 255 Upon receiving a PCP Request with FLOWDATA option first does the 256 processing described in Section 8.2, 11.3, and 12.2 of [RFC6887], as 257 appropriate for processing a MAP or PEER opcode request. If the MAP 258 or PEER request contains the FLOWDATA option, the PCP server 259 determines if the flow characteristics described in the FLOWDATA 260 option can be accommodated by the network element controlled by the 261 PCP server (that is, the router, NAT, or firewall controlled by the 262 PCP server). To determine this, the PCP server might examine its 263 static configuration and do bandwidth counting, or it might 264 reconfigure the underlying network so that additional bandwidth is 265 made available for this particular flow, or might perform other 266 actions. If the PCP server determines the flow can only be partially 267 accommodated, it returns values in the FLOWDATA fields that it can 268 accommodate or returns 0 in those FLOWDATA fields where it has no 269 information. In other words if the request indicated a low tolerance 270 for delay but the PCP server and its controlled device determine that 271 only high delay is available, the FLOWDATA response indicates high 272 delay is available. The same sort of processing occurs on all of the 273 FLOWDATA fields of the response (upstream and downstream delay 274 tolerance, loss tolerance, jitter tolerance, minimum bandwidth, 275 maximum bandwidth). 277 A PCP server that processes the FLOWDATA option is likely to create 278 state for that flow (e.g., for bandwidth counting so that the 279 bandwidth is returned to the bandwidth pool when the flow lifetime 280 expires). Because Memory and other resources limit how much state 281 can be created, the PCP server MUST implement a policy limit so that 282 all state is not consumed by one host. It MAY also implement other 283 limits, such as rate limits. The PCP server can implement its own 284 policy to remove flows from its memory, such as FIFO. If a host has 285 exceeded its quota, the existing error USER_EX_QUOTA SHOULD be 286 returned. 288 If the PCP server can accommodate the flow as described in the 289 FLOWDATA option, and can create the mapping as described in the MAP 290 or PEER opcode, it sends a PCP response with the SUCCESS response 291 code, and includes the FLOWDATA option filled in according to 292 Section 4. 294 After performing the above steps, the router creates state (if 295 necessary for its implementation) and sends SUCCESS response code to 296 the client with the data fields in the FLOWDATA option properly 297 filled out. 299 3.4. Processing a Response with FLOWDATA Option 301 The PCP client performs processing in the order of the paragraphs 302 below. 304 Upon receiving a PCP response, the PCP client performs the normal 305 processing described in Section 8.3 of [RFC6887]. 307 If the PCP response was SUCCESS (0), the PCP server has created a 308 mapping. If the PCP response contains the FLOWDATA option, the 309 FLOWDATA fields indicate if the network could accommodate the 310 requested flow characteristics. The PCP client can use that 311 information to influence the traffic it sends and receives on the 312 network. For example, if the FLOWDATA response indicates the network 313 can accommodate a flow of a certain downstream bandwidth, the PCP 314 client will likely achieve the best result if it does not initiate a 315 flow that exceeds that bandwidth. 317 Note to implementers: PCP allows the server to send multiple 318 responses to a single request. This means that after sending a 319 request and receiving a (positive) response, a subsequent response 320 might be sent updating the information about the flow, should the 321 network conditions change. The response could carry a FLOWDATA 322 option where the data fields contain different values from the 323 first response. This might occur, for example, if a competing 324 high-bandwidth flow has finished, more bandwidth is available for 325 this host; the DSL line rate might have improved (or degraded); 326 the link speed may have been dynamically increased (or decreased). 327 Thus, a PCP client should expect these subsequent responses and 328 react accordingly. 330 3.5. Link or State Changes on PCP Server 332 After the PCP server has sent a SUCCESS response code including the 333 FLOWDATA option, link characteristics might change causing a flow to 334 no longer be accommodated by the network (e.g., link speed degrades) 335 or for the PCP server to flush a flow from its list of prioritized 336 flows (e.g., due to memory constraints). Whenever the network can no 337 longer accommodate a flow, the PCP server MUST inform the PCP client 338 by sending a mapping update response including an updated FLOWDATA 339 option, following the same procedure as a Mapping Update 340 (Section 14.2 of [RFC6887]). As with PCP without FLOWDATA, if the 341 PCP server loses all its state it will alert the PCP clients using 342 rapid recovery (Section 14 of [RFC6887]) which also indicates loss of 343 FLOWDATA state in the network. 345 Note: it is also possible that originally-requested flowdata could be 346 accommodated (e.g., link speed improved). We might want to signal to 347 endpoints that they should ask again for their originally-requested 348 flowdata. This is for future study. 350 3.6. Conflict Resolution 352 It is possible that two hosts send requests with different thresholds 353 for delay or jitter or different values for bandwidth in each 354 direction, and their requests arrive at the same PCP server. An 355 example is a media streamer and a television within the same home 356 where one indicates its sending bandwidth is higher than the other 357 indicates its receiving bandwidth. As another example, the indicated 358 tolerance for delay might be different. 360 If this occurs, it is RECOMMENDED that the PCP server use the smaller 361 bandwidth and stricter delay/loss tolerance (that is, the lower 362 tolerance to delay or jitter), and issue a FLOWDATA update so both 363 PCP clients receive the same information. The diagram below depicts 364 a conflict message flow. 366 media streamer PCP server television 367 | | | 368 |-7mbps, delay=med-->| | 369 |<--OK---------------| | 370 | | | 371 | |<-5mbps, delay=hi---| 372 | | | 373 | (conflict!) | 374 | | | 375 | |--OK, 5mbps, d=m--->| 376 | | | 377 | (send mapping update | 378 | with FLOWDATA option) | 379 | | | 380 |<--OK, 5mbps, d=m---| | 381 |<--OK, 5mbps, d=m---| | 382 |<--OK, 5mbps, d=m---| | 384 Figure 5: Message diagram, resolving conflict 386 It is also possible for one PCP client to think two flows should use 387 the same instance identifier but the other PCP client to use 388 different instance identifiers for those two flows. In this case, 389 the operation of the PCP server (and the device it controls) is 390 implementation specific. 392 4. PCP FLOWDATA Option Data Fields 394 The FLOWDATA option has the following characteristics: 396 Option Name: FLOWDATA 397 Number: (to be assigned by IANA) 398 Purpose: Describe flow characteristics to the network 399 Valid for Opcodes: MAP, PEER 400 Length: 24 octets 401 May appear in: request. May appear in response only if it 402 appeared in the associated request. 403 Maximum occurrences: 1 405 The FLOWDATA option request has the following format. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 |Option Code=TBA| Reserved | Option Length=24 | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 | Instance Identifier | 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | uDT | uLT | uJT | RSVD1 | dDT | dLT | dJT | RSVD2 | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Upstream Minimum Bandwidth | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Downstream Minimum Bandwidth | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Upstream Maximum Bandwidth | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Downstream Maximum Bandwidth | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 6: FLOWDATA Option 429 Description of the fields: 431 Instance Identifier: 96 bit identifier, unique to each 432 simultaneously-active flow. This is a pseudo random number that 433 MUST be generated following the procedures described in [RFC4086]. 435 uDT: Upstream Delay Tolerance, 0=no information available, 1=very 436 low, 2=low, 3=medium, 4=high. 438 uLT: Upstream Loss Tolerance, 0=no information available, 1=very 439 low, 2=low, 3=medium, 4=high. 441 uJT: Upstream Jitter Tolerance, 0=no information available, 1=very 442 low, 2=low, 3=medium, 4=high. 444 RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0 445 on transmission. 447 dDT: Downstream Delay Tolerance, 0=no information available, 1=very 448 low, 2=low, 3=medium, 4=high. 450 dLT: Downstream Loss Tolerance, 0=no information available, 1=very 451 low, 2=low, 3=medium, 4=high. 453 dJT: Downstream Jitter Tolerance, 0=no information available, 1=very 454 low, 2=low, 3=medium, 4=high. 456 RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0 457 on transmission. 459 Upstream Minimum Bandwidth Measures bandwidth sent by the PCP 460 client. Value is in octets per second. The value 0 means no 461 information is available. 463 Downstream Minimum Bandwidth Measures bandwidth sent to the PCP 464 client. Value is in octets per second. The value 0 means no 465 information is available. 467 Upstream Maximum Bandwidth: Measures bandwidth sent by the PCP 468 client. Value is in octets per second. The value 0 means no 469 information is available. 471 Downstream Maximum Bandwidth Measures bandwidth sent to the PCP 472 client. Value is in octets per second. The value 0 means no 473 information is available. 475 The instance identifier accommodates network traffic where multiple 476 5-tuples exist for a particular data flow, but the bandwidth flows 477 only over the aggregate of the multiple 5-tuples. A use-case for 478 this identifier is TCP video streaming which retrieves short pieces 479 of the movie, often over separate TCP connections for load balancing, 480 which would use the same Instance Identifier for each TCP connection. 481 An instance is considered unique if the combination of the PCP 482 client's IP address and the instance identifier are unique. 484 Discussion point: Minimum and maximum value of bandwidth is 1 byte 485 per second to 4 gigaBYTES per second. We probably need to express 486 higher bandwidth, and maybe also lower bandwidth? 488 Different applications have different needs for their flows. The 489 following table is derived from [RFC4594] to serve as a guideline for 490 tolerance to loss, delay and jitter for some sample applications. 492 ------------------------------------------------------------------- 493 |Service Class | | Tolerance to | 494 | Name | Traffic Characteristics | Loss |Delay |Jitter| 495 |===============+==============================+======+======+======| 496 | Network |Variable size packets, mostly | | | | 497 | Control |inelastic short messages, but | Low | Low | High | 498 | | traffic can also burst | | | | 499 | | (e.g., OSPF) | | | | 500 |---------------+------------------------------+------+------+------| 501 | | Fixed-size small packets, | Very | Very | Very | 502 | Telephony | constant emission rate, | Low | Low | Low | 503 | | inelastic and low-rate flows | | | | 504 | | (e.g., G.711, G.729) | | | | 505 |---------------+------------------------------+------+------+------| 506 | Signaling | Variable size packets, some | Low | Low | High | 507 | | what bursty short-lived flows| | | | 508 |---------------+------------------------------+------+------+------| 509 | Multimedia | Variable size packets, | Low | Very | | 510 | Conferencing | constant transmit interval, | - | Low | Low | 511 | |rate adaptive, reacts to loss |Medium| | | 512 |---------------+------------------------------+------+------+------| 513 | Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low | 514 | Interactive | mostly variable rate | | Low | | 515 |---------------+------------------------------+------+------+------| 516 | Multimedia | Variable size packets, |Low - |Medium| High | 517 | Streaming | elastic with variable rate |Medium| | | 518 |---------------+------------------------------+------+------+------| 519 | Broadcast | Constant and variable rate, | Very |Medium| Low | 520 | Video | inelastic, non-bursty flows | Low | | | 521 |---------------+------------------------------+------+------+------| 522 | Low-Latency | Variable rate, bursty short- | Low |Low - | High | 523 | Data | lived elastic flows | |Medium| | 524 |---------------+------------------------------+------+------+------| 525 | OAM | Variable size packets, | Low |Medium| High | 526 | | elastic & inelastic flows | | | | 527 |---------------+------------------------------+------+------+------| 528 |High-Throughput| Variable rate, bursty long- | Low |Medium| High | 529 | Data | lived elastic flows | |- High| | 530 |---------------+------------------------------+------+------+------| 531 | Standard | A bit of everything | 0 0 0 | 532 |---------------+------------------------------+------+------+------| 533 | Low-Priority | Non-real-time and elastic | High | High | High | 534 | Data | (e.g., network backup) | | | | 535 ------------------------------------------------------------------- 537 The FLOWDATA Option response has the following format. The fields 538 indicate what the network can accommodate of the request. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |Option Code=TBA| Reserved | Option Length=24 | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 | Reserved | 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | AuDT| AuLT| AuJT| RSVD1 | AdDT| AdLT| AdJT| RSVD2 | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Accommodated Upstream Minimum Bandwidth | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Accommodated Downstream Minimum Bandwidth | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Accommodated Upstream Maximum Bandwidth | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Accommodated Downstream Maximum Bandwidth | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 7: FLOWDATA Option 562 Description of the fields: 564 Reserved: 96 bits, MUST be ignored on reception and MUST be 0 on 565 transmission. 567 AuDT: Accommodated Upstream Delay Tolerance, 0=no information 568 available, 1=able to accommodate very low, 2=able to accommodate 569 low, 3=able to accommodate medium, 4=able to accommodate high. 571 AuLT: Accommodated Upstream Loss Tolerance, 0=no information 572 available, 1=able to accommodate very low, 2=able to accommodate 573 low, 3=able to accommodate medium, 4=able to accommodate high. 575 AuJT: Accommodated Upstream Jitter Tolerance, 0=no information 576 available, 1=able to accommodate very low, 2=able to accommodate 577 low, 3=able to accommodate medium, 4=able to accommodate high. 579 RSVD1: Reserved (7 bits), MUST be ignored on reception and MUST be 0 580 on transmission. 582 AdDT: Accommodated Downstream Delay Tolerance, 0=no information 583 available, 1=able to accommodate very low, 2=able to accommodate 584 low, 3=able to accommodate medium, 4=able to accommodate high.. 586 AdLT: Accommodated Downstream Loss Tolerance, 0=no information 587 available, 1=able to accommodate very low, 2=able to accommodate 588 low, 3=able to accommodate medium, 4=able to accommodate high. 590 AdJT: Accommodated Downstream Jitter Tolerance, 0=no information 591 available, 1=able to accommodate very low, 2=able to accommodate 592 low, 3=able to accommodate medium, 4=able to accommodate high. 594 RSVD2: Reserved (7 bits), MUST be ignored on reception and MUST be 0 595 on transmission. 597 Accommodated Upstream Minimum Bandwidth Bandwidth the network can 598 accommodate for this flow, sent by the PCP client. Value in bytes 599 per second. 0 means no information is available. 601 Accommodated Downstream Minimum Bandwidth Bandwidth the network can 602 accommodate for this flow, sent to the PCP client. Value in bytes 603 per second. 0 means no information is available. 605 Accommodated Upstream Maximum Bandwidth: Bandwidth the network can 606 accommodate for this flow, sent by the PCP client. Value in bytes 607 per second. 0 means no information is available. 609 Accommodated Downstream Maximum Bandwidth Bandwidth the network can 610 accommodate for this flow, sent to the PCP client. Maximum 611 Downstream bandwidth in bytes per second, 0 means no information 612 is available. 614 5. FLOWDATA Interaction with PCP Proxy 616 The FLOWDATA option is optional to process. A PCP Proxy performs the 617 functions described in [I-D.ietf-pcp-proxy], and if the PCP request 618 contains the FLOWDATA option it also performs the functions described 619 in this section. 621 The PCP request containing the FLOWDATA option SHOULD be proxied 622 normally, so that the upstream PCP server can be aware of the entire 623 request. The PCP proxy MAY have its own policies specific to the 624 FLOWDATA option which require it to modify the FLOWDATA values 625 request (e.g., reduce bandwidth for a certain PCP client). 627 After proxying the message containing FLOWDATA, when the PCP proxy 628 receives the associated PCP response, the PCP proxy MAY reduce the 629 bandwidth values or use worse (higher) values for delay, loss, or 630 jitter tolerance. It MUST NOT increase the bandwidth or use better 631 (lower) values for the delay, loss, or jitter tolerance. 633 6. Network Authorization 635 Oftentimes the endpoints themselves are not authorized to request 636 network resources, but instead authorization has to first be obtained 637 from a network element such as a call controller or policy element. 638 To accommodate such deployments, third party authorization can be 639 used with FLOWDATA . At a high level, this authorization works by the 640 PCP client first obtaining a cryptographic token from the authorizing 641 network element (e.g., call controller) and includes that token in 642 the PCP request. The PCP server in the network validates the token 643 and grants access. 645 7. Scaling Considerations 647 The network elements need only act upon those flows explicitly 648 signaled by a PCP client, instead of all possible flows that a host 649 generates. 651 Short lived flows (e.g., HTTP/1.0) or best-effort flows would receive 652 little to no benefit from the signaling described in this document. 653 As explained in Section 3.3, the PCP server will limit excessive 654 flowdata requests, so hosts are encouraged to be conservative in how 655 many flows are signaled with flowdata. 657 8. Security Considerations 659 On some networks, only certain users or certain applications are 660 authorized to signal the priority of a flow. This authorization can 661 be achieved with PCP client authentication 662 [I-D.ietf-pcp-authentication]. 664 9. IANA Considerations 666 IANA is requested to assign a new PCP option called FLOWDATA from the 667 optional to process range (128-255) in the [pcp-iana] registry. 669 10. Acknowledgements 671 Thanks to Anca Zamfir for review comments. 673 11. References 675 11.1. Normative References 677 [I-D.ietf-pcp-authentication] 678 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 679 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 680 authentication-01 (work in progress), October 2012. 682 [I-D.ietf-pcp-proxy] 683 Boucadair, M., Penno, R., and D. Wing, "Port Control 684 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03 685 (work in progress), June 2013. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 691 Requirements for Security", BCP 106, RFC 4086, June 2005. 693 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 694 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 695 2013. 697 11.2. Informative References 699 [I-D.cheshire-recursive-pcp] 700 Cheshire, S., "Recursive PCP", draft-cheshire-recursive- 701 pcp-02 (work in progress), March 2013. 703 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 704 Guidelines for DiffServ Service Classes", RFC 4594, August 705 2006. 707 [pcp-iana] 708 IANA, "Port Control Protocol (PCP) Parameters", May 2013, 709 . 712 Authors' Addresses 714 Dan Wing 715 Cisco Systems, Inc. 716 170 West Tasman Drive 717 San Jose, California 95134 718 USA 720 Email: dwing@cisco.com 722 Reinaldo Penno 723 Cisco Systems, Inc. 724 170 West Tasman Drive 725 San Jose 95134 726 USA 728 Email: repenno@cisco.com 729 Tirumaleswar Reddy 730 Cisco Systems, Inc. 731 Cessna Business Park, Varthur Hobli 732 Sarjapur Marathalli Outer Ring Road 733 Bangalore, Karnataka 560103 734 India 736 Email: tireddy@cisco.com