idnits 2.17.00 (12 Aug 2021) /tmp/idnits30846/draft-eckert-intarea-flow-metadata-framework-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-mmusic-traffic-class-for-sdp-04 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Eckert, Ed. 3 Internet-Draft R. Penno 4 Intended status: Informational A. Choukir 5 Expires: April 24, 2014 C. Eckel 6 Cisco Systems, Inc. 7 October 21, 2013 9 A Framework for Signaling Flow Characteristics between Applications and 10 the Network 11 draft-eckert-intarea-flow-metadata-framework-02 13 Abstract 15 This document provides a framework for communicating information 16 elements (a.k.a. metadata) in a consistent manner between 17 applications and the network to provide better visibility of 18 application flows, thereby enabling differentiated treatment of those 19 flows. These information elements can be conveyed using various 20 signaling protocols, including PCP, RSVP, and STUN. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 24, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Deep packet inspection . . . . . . . . . . . . . . . . . 4 59 2.1.1. Benefits . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Limitation . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Explicit signaling methods . . . . . . . . . . . . . . . 5 62 3. Proposed framework . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1.1. Common, application independent, IPFIX registered, 65 information elements . . . . . . . . . . . . . . . . 7 66 3.1.2. Cross-protocol information element encoding rules . . 7 67 3.1.3. Anticipated Usage Models . . . . . . . . . . . . . . 8 68 3.1.3.1. Informational . . . . . . . . . . . . . . . . . . 8 69 3.1.3.2. Advisory . . . . . . . . . . . . . . . . . . . . 8 70 3.1.3.3. Service Request . . . . . . . . . . . . . . . . . 9 71 3.1.4. Considerations for signaling of common information 72 elements . . . . . . . . . . . . . . . . . . . . . . 9 73 3.1.4.1. Proxy originated information . . . . . . . . . . 9 74 3.1.4.2. Authentication . . . . . . . . . . . . . . . . . 9 75 3.1.4.3. Common encoding . . . . . . . . . . . . . . . . . 10 76 3.1.4.4. Usage Model to Protocol integration . . . . . . . 10 77 3.2. Proposed common information elements . . . . . . . . . . 11 78 3.2.1. Bandwidth Attributes . . . . . . . . . . . . . . . . 12 79 3.2.1.1. Maximum Bandwidth . . . . . . . . . . . . . . . . 12 80 3.2.1.2. Minimum Bandwidth . . . . . . . . . . . . . . . . 12 81 3.2.1.3. Bandwidth Pool . . . . . . . . . . . . . . . . . 12 82 3.2.2. Traffic Class Attributes . . . . . . . . . . . . . . 12 83 3.2.2.1. RFC4594-DSCP . . . . . . . . . . . . . . . . . . 12 84 3.2.2.2. Traffic Class Label (TCL) . . . . . . . . . . . . 12 85 3.2.3. Acceptable Path Attributes . . . . . . . . . . . . . 13 86 3.2.3.1. Delay Tolerance . . . . . . . . . . . . . . . . . 13 87 3.2.3.2. Loss Tolerance . . . . . . . . . . . . . . . . . 14 88 3.2.3.3. Jitter Tolerance . . . . . . . . . . . . . . . . 14 89 3.2.4. Application Identification . . . . . . . . . . . . . 15 90 3.2.4.1. RFC 6759 style application identification . . . . 15 91 3.2.4.2. URL style application identification . . . . . . 15 92 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 93 5. Informative References . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 This document provides a framework for communicating information 99 elements (a.k.a. metadata) in a consistent manner between 100 applications and the network to provide better visibility of 101 application flows, thereby enabling differentiated treatment of those 102 flows. These information elements can be conveyed using various 103 signaling protocols, including PCP, RSVP, and STUN. 105 The framework is built around the definition of four key components: 107 1. A set of application independent information elements (IEs) 109 2. An encoding of these IEs that is independent of the signaling 110 protocol used as transport 112 3. Usages of these IEs to support various transactional semantics 114 4. A mapping of one of more to these usages to an initial set of 115 signaling protocols, including PCP, RSVP, and STUN 117 This document defines an initial set of IEs, a set of encoding rules, 118 and initial usage model. The actual encoding is defined in 119 [I-D.choukir-tsvwg-flow-metadata-encoding]. Additional documents 120 define the mapping to specific signaling protocols (e.g. RSVP 121 [I-D.zamfir-tsvwg-flow-metadata-rsvp], STUN 122 [I-D.martinsen-mmusic-malice], and PCP [I-D.wing-pcp-flowdata]) 124 2. Background 126 This section provides background on the motivation for the framework. 128 Identification and treatment of application flows are critical for 129 the successful deployment and operation of applications based on a 130 wide range of signaling protocols. Historically, this functionality 131 has been accomplished to the extent possible using heuristics, which 132 inspect and infer flow characteristics. 134 Heuristics may be based on port ranges, IP subnetting, or deep packet 135 inspection (DPI), e.g. application level gateway (ALG). Port based 136 solutions suffer from port overloading and inconsistent port usage. 137 IP subnetting solutions are error prone and result in network 138 management hassle. DPI is computationally expensive and becomes a 139 challenge with the wider adoption of encrypted signaling and secured 140 traffic. An additional drawback of DPI is that the resulting 141 insights are not available, or need to be recomputed, at network 142 nodes further down the application flow path. 144 The proposed solution allows applications to explicitly signal their 145 flow characteristics to the network. It also provides network nodes 146 with visibility of the application flow characteristics and enables 147 them to contribute to the flow description. The resulting flow 148 description may be communicated as feedback from the network to 149 applications. 151 The proposed solution does not enhance existing heuristic based 152 mechanisms, nor does it preclude the use of such mechansims. Rather, 153 it proposes a new mechanism that does not suffer the drawbacks of 154 heuristic based mechanisms. 156 2.1. Deep packet inspection 158 2.1.1. Benefits 160 Deep Packet Inspection (DPI) and other traffic observation methods 161 (such as performance monitoring) are successfully being used for two 162 type of workflows: 164 1. Provide network operators with visibility into traffic for 165 troubleshooting, capacity planning, accounting and billing and 166 other off network workflows. This is done by exporting observed 167 traffic analysis via protocol such as IPFIX and SNMP. 169 2. Provide differentiated network services for the traffic according 170 to network operator defined rule sets, including policing and 171 shaping of traffic, providing admission control, impacting 172 routing, permitting passage of traffic (e.g. firewall functions), 173 etc. 175 Note: For the context of this document, we consider that DPI starts 176 as early into packets as using ACLs with UDP/TCP port numbers to 177 classify traffic. 179 2.1.2. Limitation 181 These two workflows, visibility and differentiated network services, 182 are critical in many networks. However, their reliance on inspection 183 and observation limits the ability to enable these workflows more 184 widely. 186 o Simple observation based classification, especially ones relying 187 on TCP/UDP, ports often result in incorrect results due to port 188 overloading (i.e. ports used by applications other than those 189 claiming the port with IANA). 191 o More and more traffic is encrypted, rendering deep packet 192 inspection impossible or much more complex (e.g. needing to share 193 encryption keys with network equipment). 195 o Observation generally requires inspecting the control and 196 signaling traffic of applications. This traffic may flow through 197 a different network path than the actual application data traffic. 198 Impacting the traffic behavior is ineffective in those scenarios. 200 o Observation of control, signaling and data traffic with DPI will 201 in general result in less insight into the applications intent 202 than if the application was explicitly signaling its intent to the 203 network. 205 o Without explicit desire by the application to signal its intent to 206 the network, it will also not consider to explicitly provide 207 authentication to the network. DPI mechanism have a more 208 difficult job in analyzing application traffic when authentication 209 mechanisms are in use (if they even can) 211 o Without explicit involvement of the application, network services 212 leveraging DPI traffic classification impact the application 213 behavior by impacting its traffic, but cannot provide explicit 214 feedback to the application in the form of signaling. 216 2.2. Explicit signaling methods 218 There are a variety of existing and evolving signaling options that 219 can provide explicit application to network signaling and serve the 220 visibility and differentiated network services workflows where DPI is 221 currently being used. It seems clear that there will be no single 222 one-protocol-fits-all solution. Every protocol is currently defined 223 in its own silo, creating duplicate or inconsistent information 224 models. This results in duplicate work, more operational complexity 225 and an inability to easily convert information between protocols to 226 easily leverage the best protocol option for each specific use case. 227 Examples of existing signaling options include the following: 229 o RSVP is the original on path signaling protocol standardized by 230 the IETF. It operates on path out-of-band and could support any 231 transport protocol traffic (it currently supports TCP and UDP). 232 Its original goal was to provide admission control. Arguably, its 233 success was impacted by its reliance on router-alert because this 234 often leads to RSVP packets being filtered by intervening 235 networks. To date, more lightweight signaling workflows utilizing 236 RSVP have not been standardized within the IETF. 238 o NSIS (next Steps in Signaling) is the next iteration of RSVP-like 239 signaling defined by the IETF. Because it focused on the same 240 fundamental workflow as RSVP admission control as its main driver, 241 and because it did not provide significant enough use-case 242 benefits over RSVP, it has seen even less adoption than RSVP. 244 o STUN is an on path, in-band signaling protocol that could easily 245 be extended to provide signaling to on path network devices 246 because it provides an easily inspected packet signature, at least 247 for transport protocols such as UDP and SCTP. Through its 248 extensions TURN and ICE, it is becoming quite popular in 249 application signaling driven by the initial use-case of 250 automatically opening up firewall pinholes and determining the 251 best local and remote addresses for peer-to-peer connectivity 252 (ICE). 254 o PCP is a protocol designed to support use cases similar to UPnP 255 firewall traversal. It also can easily be extended to provide 256 more generic application to network signaling for traffic flows. 257 Unlike the prior protocols, it is not meant to be used on path 258 end-to-end but rather independently on one "edge" of a traffic 259 flow. It is therefore an attractive alternative (albeit with 260 challenges under path redundancy) because it allows the 261 introduction of application to network signaling without relying 262 on the remote peer. This is especially useful in multi-domain 263 communications. 265 o In addition to these, depending on the devices where it is 266 performed, different degrees of DPI may be used to achieve 267 explicit signaling. For example, inspection of HTTP connections 268 is often viable in high-touch network devices. Such inspection 269 may provide explicit signaling if the application purposely keeps 270 or inserts information elements that are meant to be signaled to 271 the network in the clear, or knowingly uses an encryption scheme 272 shared with the network. 274 Rather than encourage independent, protocol specific solutions to 275 this problem, this document provides a protocol and application 276 independent framework that can be applied in a consistent fashion 277 across the various protocols. 279 3. Proposed framework 280 3.1. Overview 282 The proposed framework includes the following elements: 284 3.1.1. Common, application independent, IPFIX registered, information 285 elements 287 An application media flow may be expressed as a set of information 288 elements that are defined and registered like observation-based IPFIX 289 attributes. We propose leveraging IPFIX as the information model 290 (not necessarily as the transport signaling) for the following 291 reasons: 293 o As outlined above, export of traffic information is one of the two 294 big workflows. IPFIX is arguably the most flexible, extensible 295 and best defined option for this. Leveraging the same information 296 model for flow characteristics facilitates export of this 297 information via IPFIX. 299 o IPFIX allows for IETF/IANA standardized information elements, but 300 also for unambiguous vendor-defined attributes by including the 301 so-called PEN (Private Enterprise Number) into the information 302 element type. Note that IPFIX has ongoing work to better 303 disseminate vendor specific registration of attributes. The 304 framework defined here expects to be able to leverage the output 305 of that work. 307 3.1.2. Cross-protocol information element encoding rules 309 The majority of the protocols listed previously (RSVP, NSIS, STUN/ 310 ICE, PCP) require (or favor) compact binary encoding of information 311 elements. This is natively supported by the information element 312 registration of IPFIX. 314 The IPFIX registry defines each information element's data-type, and 315 there is a native binary network encoding for each of these types. 316 At a minimum, every protocol leveraging common information elements 317 would need to use an encoding that identifies the information 318 element's PEN and IE-ID, and that leverages network standard binary 319 encoding of the value including the length of the value. Including 320 the length of the value into the encoding is required for 321 extensibility because otherwise new information elements could not be 322 introduced without first having all network devices know the data- 323 type, and therefore the length, of the information element. 324 Leveraging network standard binary encoding is equally important to 325 permit network elements to propagate information elements from one 326 protocol to another protocol without understanding the information 327 elements data-type. 329 In protocols that are not constrained to binary encoding, it is 330 nevertheless highly desirable to include the equivalent information 331 and therefore permit propagation between binary and non-binary 332 transport of information elements without having to understand all 333 information elements. 335 3.1.3. Anticipated Usage Models 337 The signaling of information elements may be from application to the 338 network or from network to application. When signaled within a given 339 protocol, the information elements may be interpreted independently 340 of that protocol, or it may be used in combination with the given 341 protocol. 343 3.1.3.1. Informational 345 The most simplistic usage model is one in which applications signal 346 information elements describing their anticipated or existing flows 347 into the network along the path of those flows without expecting or 348 requiring anything back from the network. Network elements along the 349 flow path may or may not do something with this information. 351 This "informational" usage model enables network elements along the 352 path to support the workflows traditionally performed via DPI 353 mechanisms, as described previously. 355 3.1.3.2. Advisory 357 This usage model extends the "informational" usage in that the 358 application expects or requests some information back from the 359 network. With this usage, the same information elements apply and 360 may be communicated by the application into the network, but the 361 application indicates its interest in receiving some feedback. 363 Default values are defined for each information element to 364 unambiguously support cases in which an application does not have a 365 valid value to communicate with the network; rather, it wants the 366 network to provide a value back to it in response. In essence, this 367 allows an application to ask a question and receive an answer from 368 the network. Of course, a network element may provide similar 369 feedback for cases in which an application communicated a non-default 370 value as well. Network elements may also provide unsolicited 371 advisory feedback. 373 In all cases, applications are not guaranteed to receive an answer or 374 any specific service from the network. In the event an answer is 375 provided, that answer is similarly not a guarantee of any specific 376 service or treatment by the network. It is to be interpreted as 377 advisory only. 379 As mentioned previously, the same information elements are used in 380 the signaling from the application to the network as well as from the 381 network to the application. The underlying transport protocol used 382 to carry the information elements is expected to provide the 383 necessary request/response semantics or some other mechanism by which 384 the communication in both directions can be tied together. 386 3.1.3.3. Service Request 388 This usage model extends the "advisory" usage to operate as an 389 explicit service request. Unlike the advisory usage, information 390 elements signalled by the application are interpreted by network 391 elements within the context of a service request, and information 392 elements signalled by the network back to the application are 393 interpreted within the context of a response to that request. 395 As with the advisory usage, the same information elements are used in 396 the signaling from the application to the network as well as from the 397 network to the application. The underlying transport protocol used 398 to carry the information elements is expected to provide the 399 necessary service request/response semantics. 401 3.1.4. Considerations for signaling of common information elements 403 3.1.4.1. Proxy originated information 405 The goal of this framework is to enable applications to explicitly 406 signal common information elements about their traffic flows and 407 optionally receive common information elements from the network as 408 feedback. Nevertheless, it is clear that broad adoption of such 409 technology is improved by enabling the use of proxies. The proxies 410 can provide or amend the flow description information in the absence 411 of Flow Metadata support by the application itself. 413 3.1.4.2. Authentication 415 Common information elements should provide for cryptographic 416 authentication by the sender. In general the authentication provides 417 some form of identification of the sender and proves that the common 418 information elements covered by the authentication were originated 419 from, or approved by, that identity. 421 3.1.4.3. Common encoding 423 A companion document [I-D.choukir-tsvwg-flow-metadata-encoding] 424 covers recommended encoding rules that take the following aspects 425 into account: 427 o Compact binary encoding rules 429 o Signaling for both sent and received traffic flows 431 o Signaling of standard and vendor specific information elements 433 o Minimizes protocol specific definition required to add 434 informational or advisory common information elements into 435 existing transactions 437 o Signaling of feedback from the network 439 o Identification of originator to support proxies and facilitate 440 mitigation between common information elements from different 441 originators 443 o Signaling of authenticators 445 3.1.4.4. Usage Model to Protocol integration 447 There is a range of options for how this framework is integrated with 448 a particular transport protocol. We describe two examples we 449 consider useful: 451 3.1.4.4.1. Common transport informative integration 453 1. A transport protocol signaling method is defined to carry the 454 common encoded information elements at least in signaling from 455 application to network. 457 2. If the transport by itself does not already have a mechanism to 458 indicate a purely informative protocol transaction, then a 459 protocol specific indication for this is added. 461 In result, this integration achieves two option: 463 1. Informative common information elements can be sent from 464 application to network by using the protocol's method to indicate 465 the purely informational protocol transaction. This option 466 effectively leverages the protocol as transport for additional 467 informative attribute based services without impacting the 468 services and transactions of the protocol otherwise. 470 2. Informative common information elements can be sent alongside an 471 existing protocol transaction. In this case they may either be 472 ships in the night (triggering informative attribute based 473 services), or they may additionally be used by the policy rules 474 of the protocol transaction itself which could be advisory or 475 service request. All feedback of the transaction would still 476 rely on protocol specific information element (common information 477 elements only used from host to network). 479 This integration is for example defined in [I-D.wing-pcp-flowdata], 480 [I-D.zamfir-tsvwg-flow-metadata-rsvp], and 481 [I-D.martinsen-mmusic-malice]. 483 3.1.4.4.2. Common transport advisory integration 485 In addition to the common transport informative integration, the 486 transport encoding is extended to carry the common transport 487 information element in feedback messages from the network to the host 488 /application. The method to indicate informative only transaction, 489 when sending to the network is used to indicate advisory only 490 transaction when signaling from the network. 492 This option primarily enables informative and advisory usage models, 493 but it can equally interact with pre-existing service-request options 494 of the transport protocol and impact advisory feedback or the service 495 request itself based on that interaction. 497 3.2. Proposed common information elements 499 The section defines an initial set of common information elements. 500 These information elements are intended to be added to the set of 501 IANA standardized information elements either by this or associated 502 documents. Additional documents are expected to define additional 503 attributes that can use either IANA or other vendor-PEN. 505 All information element definition must include the following: 507 1. Default value to be provided by an application when it does not 508 have an informative value to provide to the network, but is 509 interested in receiving an advisory value of the attribute from 510 the network. If no advisory feedback is requested, and no 511 informative value is known, the attribute may simply not be sent. 513 2. Conflict resolution in the presence of different values for the 514 same information element (e.g. two peers signaling information 515 elements for both the upstream and downstream direction of a flow 516 include different values for the information element) 518 3.2.1. Bandwidth Attributes 520 3.2.1.1. Maximum Bandwidth 522 This attribute is used to convey the maximum sustained bandwidth for 523 the flow. It is an unsigned 64 bit value and is specified in bits 524 per second. 526 Default Value: 0 528 Conflict Resolution: Minimum for the set of non-default values 530 3.2.1.2. Minimum Bandwidth 532 This attribute is used to convey the minimum sustained bandwidth for 533 the flow. It is an unsigned 64 bit value and is specified in bits 534 per second. Not sending the Minimum Bandwidth is equivalent to 535 sending the same value as for Maximum Bandwidth. 537 Default Value: 0 539 Conflict Resolution: Minimum of the set of non-default values 541 3.2.1.3. Bandwidth Pool 543 This attribute is used to convey that the traffic dynamically shares 544 bandwidth with other traffic using the same Bandwidth Pool. Variable 545 length GUID (Global Unique ID) of at least 48 bits. The Maximum 546 Bandwidth used by the pool is the largest Maximum Bandwidth indicated 547 by any member, the Minimum Bandwidth of the Pool is the largest 548 Minimum Bandwidth indicated by any member. 550 3.2.2. Traffic Class Attributes 552 3.2.2.1. RFC4594-DSCP 554 This attribute is used to convey the DSCP value appropriate for the 555 flow. It is an unsigned 8 bit value. Values signaled are assumed to 556 be in compliance with [RFC4594] or backward compatible extensions 557 thereof. Other values are undefined. 559 Default Value: 0xff 561 Conflict Resolution: tbd 563 3.2.2.2. Traffic Class Label (TCL) 564 The data type of this information element is a string. It carries 565 the Traffic Class Label defined in 566 [I-D.ietf-mmusic-traffic-class-for-sdp]. Depending on the outcome of 567 that drafts standardization, the version carried as an information 568 element may be slightly expanded over the its definition for SDP. 569 The TCL is a structured string of the form: 571 .(.adjective)(.adjective) 573 category and application provide a base categorization of the traffic 574 class that attempts to provide a simplified and extensible, framework 575 for the traffic class definitions in [RFC4594]. These base 576 classifications can be refined with zero or more adjectives. 577 Examples of a TCL is "conversational.video.avconf". 579 Default Value: Empty string 581 Conflict Resolution: tbd 583 3.2.3. Acceptable Path Attributes 585 The following set of attributes deal with tolerance to various path 586 impairments. A discrete and ordered set of values is defined for 587 each. This way the values are applicable on a per hop basis as well 588 as end to end. The values may be mapped to relevant metrics within a 589 given network, such as the mapping of delay tolerance and loss 590 tolerance to QCI values as defined in [I-D.penno-pcp-mobile-qos] 592 3.2.3.1. Delay Tolerance 594 This attribute is used to convey the delay tolerance of an 595 application with respect to the associated flow. When provided by a 596 network element, it indicates the delay tolerance expected of the 597 application with respect to the associated flow. It is a 3 bit field 598 for which values are assigned as follows: 600 0 = no information available 602 1 = very low 604 2 = low 606 3 = medium 608 4 = high 610 5-7: reserved 611 Default Value: 0 613 Conflict Resolution: For application to network, the most strict of 614 non-default values. For network to application, the least strict of 615 the set of non-default values. 617 3.2.3.2. Loss Tolerance 619 This attribute is used to convey the loss tolerance of an application 620 with respect to the associated flow. When provided by a network 621 element, it indicates the loss tolerance expected of the application 622 with respect to the associated flow. It is a 3 bit field for which 623 values are assigned as follows: 625 0 = no information available 627 1 = very low 629 2 = low 631 3 = medium 633 4 = high 635 5-7: reserved 637 Default Value: 0 639 Conflict Resolution: For application to network, the most strict of 640 non-default values. For network to application, the least strict of 641 the set of non-default values. 643 3.2.3.3. Jitter Tolerance 645 This attribute is used to convey the jitter tolerance of an 646 application with respect to the associated flow. When provided by a 647 network element, it indicates the jitter tolerance expected of the 648 application with respect to the associated flow. It is a 3 bit field 649 for which values are assigned as follows: 651 0 = no information available 653 1 = very low 655 2 = low 657 3 = medium 658 4 = high 660 5-7: reserved 662 Default Value: 0 664 Conflict Resolution: For application to network, the most strict of 665 non-default values. For network to application, the least strict of 666 the set of non-default values. 668 3.2.4. Application Identification 670 Application identification is clearly one of the more difficult 671 classification goals. The proposals included here are as of yet not 672 widely vetted: 674 3.2.4.1. RFC 6759 style application identification 676 [RFC6759] defines the IPFIX IE-IDs that permit both IANA and vendor 677 specific application identification. Though defined for observation 678 (a.k.a.: DPI), it could also be used with explicit signaling from 679 applications. 681 Applications that use one of the protocols for which there is an IANA 682 port allocation could explicitly indicate this port via the IANA-L4 683 engine-id in their application to network signaling. This would 684 identify the application even if the application is not using the 685 IANA assigned port for it. This covers cases in which applications 686 use ports other than registered, such as HTTP servers running on 687 other than 80, or when ports get mapped due to PAT. 689 To avoid collision with DPI exported IANA-L4 classification, it is 690 necessary to assign a new engine-id for application-self assigned 691 IANA-L4 classification (e.g. new engine-id for IANA-L4-SELF- 692 ASSIGNED). If an application vendor has a PEN, the application can 693 use a PANA-L7-PEN classification with the PEN of the originating 694 application vendor. Likewise, if applications are in general made 695 available via "market" type reseller mechanism (common in mobile 696 device applications), then the application vendor could request an 697 application identification from the market owner and leverage the 698 market owners PEN. 700 3.2.4.2. URL style application identification 702 One problem with [RFC6759] style application identification 703 especially non-IANA registered ones is the complexity in making all 704 network elements learn the semantic of the numeric encoding of e.g. 705 the PANA-L7-PEN information element in signaling protocols that only 706 use the numeric encoding of information elements. The second problem 707 may be to determine what PEN to use, because not every developer of 708 an application may be a company that has a PEN or otherwise would 709 intend to apply for one. Application identification via a URL 710 encoded string information element is a way to overcome both issues. 711 Today, almost all applications have some DNS domain associated with 712 them through which they are being marketed or that belongs to the 713 company developing the application. Therefore, one simple form of 714 self assigned application identification is a new IPFIX information 715 element: UrlAppId. The value of this information element is an 716 abbreviated URL of the following form: 718 / /[ | ] 720 The idea is that the owner of (fully qualified domain name) is 721 assigning an , and by signaling both and 722 , this information element provides a self-identifying, 723 unambiguous application identification. 725 Example: 727 example.com/network-lemmings/sdn-edition 729 A game publishing house or application market operator with the 730 domain name example.com is initially allocating the UrlAppId 731 example.com/network-lemmings to that application. After 35 years, a 732 new variant of the game is released, the SDN edition, and the app- 733 developer decides that it would best like to distinguish this 734 application variant by the above UrlAppId example.com/network- 735 lemmings/sdn-edition. 737 In general, different traffic flows within a single application 738 should best not be distinguished via the UrlAppId, but instead rely 739 on attributes more specifically targeted for that purpose (such as 740 the TrafficClassLabel). If there is no adequate better attribute 741 defined, application developers may choose to use the other-details 742 section of the UrlAppId to distinguish flows within the same 743 application. 745 Formally, the only requirement against the UrlAppId is that the fqdn 746 part is a DNS domain owned by the assigner, and that the rest of the 747 string after the first / is as self explanatory as possible. 749 It should be noted that in the context of DPI, classification of web- 750 based application traffic is very often performed by URL inspection 751 of HTTP traffic. This proposed intent based information element 752 leverages that model and makes it usable where it can not be 753 currently used with just DPI: encrypted HTTP, non-HTTP applications, 754 HTTP applications with non-descriptive URLs, etc. 756 4. Acknowledgements 758 The authors would like to thank Dan Wing, Anca Zamfir, Paul Jones, 759 and Tirumaleswar Reddy for their valuable contributions to this 760 document. 762 5. Informative References 764 [I-D.choukir-tsvwg-flow-metadata-encoding] 765 Eckert, T., Zamfir, A., Choukir, A., and C. Eckel, 766 "Protocol Independent Encoding for Signaling Flow 767 Characteristics", draft-choukir-tsvwg-flow-metadata- 768 encoding-01 (work in progress), July 2013. 770 [I-D.ietf-mmusic-traffic-class-for-sdp] 771 Polk, J., Dhesikan, S., and P. Jones, "The Session 772 Description Protocol (SDP) 'trafficclass' Attribute", 773 draft-ietf-mmusic-traffic-class-for-sdp-04 (work in 774 progress), July 2013. 776 [I-D.martinsen-mmusic-malice] 777 Penno, R., Martinsen, P., Wing, D., and A. Zamfir, "Meta- 778 data Attribute signaLling with ICE", draft-martinsen- 779 mmusic-malice-00 (work in progress), July 2013. 781 [I-D.penno-pcp-mobile-qos] 782 Penno, R., Reddy, T., Wing, D., Steeg, B., and M. 783 Boucadair, "PCP Usage for Quality of Service (QoS) in 784 Mobile Networks", draft-penno-pcp-mobile-qos-00 (work in 785 progress), July 2013. 787 [I-D.wing-pcp-flowdata] 788 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 789 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 791 [I-D.zamfir-tsvwg-flow-metadata-rsvp] 792 Eckert, T., Zamfir, A., and A. Choukir, "Flow Metadata 793 Signaling with RSVP", draft-zamfir-tsvwg-flow-metadata- 794 rsvp-00 (work in progress), July 2013. 796 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 797 Guidelines for DiffServ Service Classes", RFC 4594, August 798 2006. 800 [RFC6759] Claise, B., Aitken, P., and N. Ben-Dvora, "Cisco Systems 801 Export of Application Information in IP Flow Information 802 Export (IPFIX)", RFC 6759, November 2012. 804 Authors' Addresses 806 Toerless Eckert (editor) 807 Cisco Systems, Inc. 808 San Jose 809 US 811 Email: eckert@cisco.com 813 Reinaldo Penno 814 Cisco Systems, Inc. 815 170 West Tasman Drive 816 San Jose 95134 817 USA 819 Email: repenno@cisco.com 821 Amine Choukir 822 Cisco Systems, Inc. 823 Lausanne 824 CH 826 Email: amchouki@cisco.com 828 Charles Eckel 829 Cisco Systems, Inc. 830 170 West Tasman Drive 831 San Jose, CA 95134 832 US 834 Email: eckelcu@cisco.com