idnits 2.17.1 draft-deng-alto-p2p-ext-07.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 46 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3083 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) == Missing Reference: 'RFC5693' is mentioned on line 115, but not defined == Missing Reference: 'RFC4627' is mentioned on line 251, but not defined ** Obsolete undefined reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Missing Reference: 'RFC 7285' is mentioned on line 298, but not defined == Unused Reference: 'I-D.draft-wu-alto-te-metrics' is defined on line 711, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-roome-alto-pid-properties-01 == Outdated reference: A later version (-09) exists of draft-wu-alto-te-metrics-03 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO Working Group L. Deng 3 INTERNET-DRAFT China Mobile 4 Intended Status: Standard Track H. Song 5 Expires: April 20, 2016 Huawei 6 S. Kiesel 7 University of Stuttgart 8 R. Yang 9 Yale 10 Q. Wu 11 Huawei 12 October 19, 2015 14 Extended End Point Properties for Application-Layer Traffic Optimization 15 draft-deng-alto-p2p-ext-07 17 Abstract 19 The purpose of the Application-Layer Traffic Optimization (ALTO) 20 protocol is to provide better-than-random peer selection for P2P 21 networks. The base ALTO protocol focuses, only on providing network 22 topological location information (i.e., network maps and cost maps). 23 However, the peer selection method of an endpoint may also use other 24 properties, such as geographic location. This document defines a 25 framework and an extended set of End Point properties (EP properties) 26 to extend the base ALTO protocol. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Guidelines and Methodology . . . . . . . . . . . . . . . . 4 70 3.2. Information flow . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Privacy considerations . . . . . . . . . . . . . . . . . . 6 72 3.3.1. Privacy-Preserving Information Mapping . . . . . . . . 6 73 3.2.2. Access Control . . . . . . . . . . . . . . . . . . . . 7 74 3.4. Relation with other properties . . . . . . . . . . . . . . 7 75 4. Endpoint Extensions . . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Location-Related Properties . . . . . . . . . . . . . . . . 8 77 4.1.1. Endpoint Property Type: geolocation . . . . . . . . . . 8 78 4.2. Node-related properties . . . . . . . . . . . . . . . . . . 9 79 4.2.1. End Point Property Type: participating-role . . . . . . 9 80 4.2.2. End Point Property Type: battery-limited . . . . . . . 10 81 4.2.3. End Point Property Type: local-capacity . . . . . . . . 11 82 4.3. Network-Related Properties . . . . . . . . . . . . . . . . 11 83 4.3.1. End Point Property Type: network-access . . . . . . . . 11 84 4.3.2. End Point Property Type: forwarding-class . . . . . . . 13 85 4.4. Subscription-Related Properties . . . . . . . . . . . . . . 14 86 4.4.1. End Point Property Type: volume-limited . . . . . . . . 14 87 4.4.2. End Point Property Type: provisioned-bandwidth . . . . 15 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 92 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 93 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 The initial purpose for Application Layer Traffic Optimization (ALTO) 99 protocol [RFC7285] is to provide better than random peer selection 100 for Peer-to-Peer (P2P) networks. It is expected that ALTO can be used 101 in serving a variety of applications and therefore it should be able 102 to provide richer information in terms of End Point properties. 104 In this document, more EP property extensions are defined to provide 105 guidance for both P2P and other applications in terms of end point 106 selection. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 This document makes use of the ALTO terminology defined in RFC 5693 115 [RFC5693]. 117 TBA. 119 3. Overview 121 It is expected that EP properties reflecting the following list of 122 information can be useful for an ALTO client to provide better user 123 experience or avoid performance degradation: 125 o location-related information, the information about the geographic 126 location of the end point. 128 o node-related information, the information about the end point's 129 local features, such as software/hardware configuration and the 130 participating role of the end point (e.g. as a end user, or a CDN 131 server, or a P2P cache, etc.). 133 o network-related information, the information about the attached 134 network of the end point, such as the type or configuration of the 135 access network (e.g. 2G/3G/4G, WLAN, DSL, etc.) and the information 136 about the network topology (e.g. ASN, Rack-id, etc.). 138 o subscription-related information, the information about the service 139 provision agreement between the end point's owner (i.e. the 140 subscriber) and the network provider. 142 3.1. Guidelines and Methodology 143 The most basic principle would be to maintain the EP property set to 144 a minimum, which in turn implies two guidelines: non-redundancy and 145 generality. 147 o Non-redundancy, refers to the guideline that there is no complete 148 coverage between any two properties. 150 o Generality, refers to the guideline that each property should be 151 generally applicable to a group of settings. It is not economic to 152 define a property which is bounded to a single type of application or 153 a single deployment scenario. 155 In order to make sure that the properties as defined in this document 156 fulfill the above principle and guidelines, we intend to justify each 157 property's definition using the following methodology: 159 o Usefulness: there should be a clear motivation and application 160 scenarios that justify the necessity and value for providing such 161 information via EP property enquiry. 163 o Non-redundancy: avoid adding a property whose value can be implied 164 by an already defined property or any combination of them. It may be 165 of interest to keep the discussion and suggestions on how to acquire 166 such information via from other already defined EP properties in the 167 document. 169 o Case-independency: when designing the concrete information model 170 for the properties, it is suggested to group application/deployment 171 specific information into more general property definitions (with 172 different value for different applications/scenarios) whenever 173 possible. 175 3.2. Information flow 177 On the one hand, the same piece of information about a group of 178 candidate endpoints may be acquired by an application in two ways: 179 directly through one-to-many communication of application-specific 180 message exchange with each candidate for flexibility, or indirectly 181 via one-to-one transaction with the ALTO server for efficiency. 183 On the other hand, EP properties as defined in this document may as 184 well be retrieved and aggregated into the ALTO server in two ways. 185 One is from the endpoint itself, and the other is from the service 186 provider which provides network service to the end point. 188 Note: There is currently no standardized mechanism by which a peer 189 could publish information about itself into an ALTO server. 191 Therefore, it is to be decided whether or not if we should include EP 192 properties in this document if their acquisition requires an 193 extension to the base protocol for an endpoint to publish its 194 information directly to the ALTO server. 196 An endpoint can discover the ALTO server with ALTO discovery 197 mechanisms, and then setup a communication channel with its ALTO 198 server. After that the endpoint property from the endpoint itself can 199 be reported. 201 The ALTO server can also be configured to access the Network 202 Management System server or other similar servers provided by the 203 network service provider for information about end points, such as 204 subscription related information. 206 3.3. Privacy considerations 208 Privacy considerations is a general concern for almost all EP 209 properties, as they are by definition more stationary information 210 regarding a specific end point. 212 However, each end point may have different concerns or sensitive 213 preference over a specific EP property. For example, endpoint 214 property regarding the service role of the endpoint, serving nodes 215 deployed by the ISP or third party service provider, such like P2P 216 caching server, or CDN node, may have different considerations over 217 whether a piece of information is private or not. Therefore, it may 218 be necessary to provide a mechanism to accommodate this type of 219 individual customization by providing a channel for an end point to 220 explicitly indicate this information based on its own preference. 222 More general, it is expected that the privacy level of a specific EP 223 property is dependent on the nature of the information (i.e. the EP 224 property), the type of the subscriber (i.e. the user who owns the end 225 point in question), the type of the application (i.e. the ALTO client 226 who is requesting the EP property) and the policy of the ISP (i.e. 227 the owner of the ALTO server who is able to do information collection 228 from the end points and determine how the the information is exposed 229 to the requesting application). 231 Fortunately, there are generally applicable schemes to be used to 232 address the privacy protection concerns, which may be applicable to a 233 group of EP properties and can be configured by the ISP or the EP 234 subscriber. In this section, several general schemes are introduced, 235 whose application to each EP property is elaborated later in 236 following sections. 238 3.3.1. Privacy-Preserving Information Mapping 239 On the one hand, the privacy concern is unnecessary if the specific 240 endpoint property can also be measured/disclosed in another way. The 241 privacy concern regarding to the accurate information of the endpoint 242 would be alleviated if using relative numbers to rank them. For 243 deployment considerations, it is also possible for each endpoint to 244 make the choice whether to disclose the relative information or not, 245 but an incentive could be used to encourage the disclosure when it is 246 beneficial to the application. 248 In other words, in order to preserve the privacy of a piece of 249 information, different data types can be defined via information 250 mapping. In particular, in this document, each property is defined as 251 a JSON object [RFC4627], which contains a dynamic typing attribute 252 "content" as well as two deterministic attributes, "name" and 253 "precision". 255 The "name" attribute is a string, whose value is the name of the 256 property. The "precision" attribute is also a string, whose value 257 comes from an attribute-dependent set. Depending on the value of the 258 property's "precision" attribute, its "content" attribute can be a 259 string, number, boolean or another object. 261 In this document, in order to define an EP property as a JSON object, 262 we specify: 264 o the string value of its "name" attribute; 265 o the value set of its "precision" attribute; and 266 o the definitions of its "content" attribute for each "precision". 268 A special string value "" for "precision" attribute is used to 269 indicate that an EP property, which is not privacy sensitive or using 270 information mapping, has no precision-dynamic "content" definition. 272 3.2.2. Access Control 274 On the other hand, access control to sensitive property information 275 may also be used to mitigate the privacy concern of a defined 276 property. Even greater flexibility can be delivered by access control 277 at the discretion of both the network operator and the individual 278 subscriber, which is deployment specific and out of scope for the 279 general discussion within this document. 281 3.4. Relation with other properties 283 Endpoint information can be extremely dynamic or relatively static. 284 Currently, this specification does not intend to provide any real- 285 time properties such as the available bandwidth from the endpoint [I- 286 D.draft-wu-alto-te-metrics], whose value is subject to frequent 287 changes and hence requires a measurement-based exposure scheme. 289 The basic end point properties as defined in this document, serves as 290 a basis for the property namespace to be used to derive PID 291 properties [I-D.draft-roome-alto-pid-properties] for the 292 corresponding peer group, when the direct enquiry for the information 293 per end point is not efficient or economic for the ALTO client. 295 4. Endpoint Extensions 297 This document defines new endpoint property types for the ALTO 298 protocol [RFC 7285]. 300 4.1. Location-Related Properties 302 4.1.1. Endpoint Property Type: geolocation 304 It is believed that the information about an individual endpoint's 305 geo-location is of value to a variety of applications. However, it is 306 also well accepted that geolocation of an endpoint is likely to be 307 considered as a private piece of information to the subscriber, and 308 therefore should be protected against undesirable privacy intrusion. 310 Moreover, in a data-center, the relative location of a serving node 311 may be of interest to an ALTO client, where much finer-grained 312 information (e.g. the hosting physical server or rack number) are 313 relevant and can be dynamically updated by either a live migration of 314 a serving node contained in a virtualization container or a traffic 315 handover between active and standby instances during an HA/LB switch- 316 off. 318 To this end, an EP property is defined as a JSON object, with the 319 name "geolocation", whose "content" definition is actually dependent 320 on the "precision" attribute, which in turn is a JSON string whose 321 value belongs to the following JSON array: 323 geolocation_precision-set = ["countrycode", "boundingbox", "circle", 324 "dc"] 326 If the "precision" attribute of the "geolocation" property of an 327 endpoint is "countrycode", the following "content" attribute is 328 defined as the ISO 3166 two-letter country codes of the region the 329 endpoint resides in, as a JSON string. 331 If the "precision" attribute of the "geolocation" property of an 332 endpoint is "boundingbox", the following "content" attribute is 333 defined as a four-element JSON object "bounding-box": 335 bounding-box = { 336 "latul" : number, 337 "longul" : number, 338 "latbr": number, 339 "longbr" : number 340 } 342 If the "precision" attribute of the "geolocation" property of an 343 endpoint is "circle", the following "content" attribute is defined as 344 a three-element JSON object "circle_location": 346 circle-location = { 347 "latc" : number, 348 "longc" : number, 349 "radius": number 350 } 352 If the "precision" attribute of the "geolocation" property of an 353 endpoint is "dc-location", the following "content" attribute is 354 defined as a four-element JSON object "dc-location": 356 dc-location = { "rack-id" : number, 357 "server-id" : number } 359 4.2. Node-related properties 361 4.2.1. End Point Property Type: participating-role 363 Different types of end points have different roles or participating 364 policies for a given application, which can be explored in making a 365 better decision when choosing a serving node. For example, as 366 described in [I-D.draft-deng-alto-p2pcache], P2P caching node can 367 also act as p2p peers in a p2p network. If a p2p caching peer is 368 located near the edge of the network, it will reduce the backbone 369 traffic, as well as the uploading traffic. [RFC7069] provides one 370 example of such caching nodes. P2P caching peers are usually 371 expected to be given higher priority than the ordinary peers for 372 serving a content request so as to optimize the network traffic. So 373 it's necessary for the End Point property to support this indication. 375 In general, the end points which belong to different participating 376 parties (subscriber, ISP, or ICP) within an application's service 377 transaction demonstrate different role/policies. 379 It is straightforward for an ISP to acquire the information of an end 380 point's participation role from its local record for its subscribers, 381 its local or third party infrastructure for a given application. 383 To this end, an EP property is defined as a JSON object, with the 384 name "participating-role", whose "precision" attribute is set to "" 385 and its "content" attribute is defined as a JSON string, whose value 386 belongs to the following array: 388 participating-role-set=["user", "cache", "super-node"] 390 In other words, the "participating-role" property is defined as 391 follows: 393 participating-role : { 394 "precision": "", 395 "content": ["user", "cache", "super-node"] 396 } 398 4.2.2. End Point Property Type: battery-limited 400 Another important End Point property that will impact peer selection 401 is what kind of power supply the peer has. It can be either the 402 electric power or the battery supply. 404 And for most of the time, it is safe to bet that electric power 405 supplied nodes would stay online longer than those battery supplied 406 nodes, while battery powered devices are usually less willing to act 407 as super peer, relay, etc. 409 And most of the nowadays intelligent equipments are aware of their 410 power supply type. But it is necessary that the power supply of a 411 peer can be queried through some method no matter whether or not it 412 is limited by its battery. 414 To this end, an EP property is defined as a JSON object, with the 415 name "battery-limited", whose "precision" attribute is set to "" and 416 its "content" attribute is defined as a boolean, is either "true" or 417 "false". 419 If the peer in question is actually battery-limited, the value of 420 this property with respect to the peer is set to "true". 422 In other words, the "content" attribute of the "battery-limited" 423 property is defined as a JSON boolean, "true" for a battery supplied 424 end point, or "false" for an electricity supplied end point or for an 425 end point with an unknown power supply type. 427 "battery-limited": { 428 "precision": "", 429 "content": true/false 430 } 432 4.2.3. End Point Property Type: local-capacity 434 For resource-consuming applications, it would be helpful to know the 435 local capacity (e.g., in terms of computing, storage, and networking) 436 of an end point before it is selected. 438 In other words, the "local-capacity" property is defined as a JSON 439 object, as follows: 441 "local-capacity": { 442 "precision": "", 443 "content":{ 444 "CPU": { 445 "volume": integer, 446 "meter": string 447 }, 448 "memory":{ 449 "volume": integer, 450 "meter": string 451 }, 452 "storage": { 453 "volume": integer, 454 "meter": string 455 } 456 } 457 } 459 4.3. Network-Related Properties 461 4.3.1. End Point Property Type: network-access 463 One important End Point property that will impact peer selection is 464 the type of the node's access network. 466 Note: There is remaining doubt on whether or not this property is 467 needed, since at least part of the information it reflects, for 468 instance, the end point's provisioned bandwidth, is defined and 469 exposed by other properties. 471 For instance, a mobile subscriber's access network can be cellular 472 (2G, 3G, or 4G). Take another example of a node owned by a home 473 subscriber, the type of its access network can be DSL, FTTB, or 474 FTTH. 476 Different type of access network gives a clear indication on both the 477 amount and the technology of the provisioned resources (e.g. the 478 shared/guaranteed bandwidth, the interval for physical channel 479 scheduling, etc.) 481 Moreover, one may prefer to specify a special access type for a node 482 deployed in a data center too, because it is likely to be more 483 robust, and have more network resources than either mobile or home 484 users. 486 Hence application may have its own algorithm for peer selection or 487 traffic rendering if the node access type information can be provided 488 via an End Point property. The value for this property can be 489 enumerated as "adsl", "ftth", "fttb", "dc", and etc. 491 In case that the end point has its own privacy concerns in revealing 492 its access network type directly to potentially distrusted 493 applications through ALTO, another indirect way of exposing the 494 similar information can be used by "access-preference" as per ISP's 495 judgement. 497 In essence, an ISP assigned "access-preference" property for the end 498 points gives the network operator a chance to say which end point's 499 link is "better" without having to tell what the actual criterion 500 is. 502 The value for this property (defined as integer) can be set by the 503 ISP of the ALTO server, based on its own relative preference to 504 different network access types. A peer with the higher value is more 505 preferable than another peer with the lower value. 507 For example, an ISP could use the following setting for now: 509 1 = DSL; 10 = FTTB; 12 = FTTH; 50 = DC; 511 and add "100=new-technology", when some new technology better than 512 FTTH appears later. 514 To this end, an EP property is defined as a JSON object with the name 515 "network-access", with two different values for "precision" 517 network-precision-set=["technology", "rank"] 518 In other words, the "content" of the "network-access" property is 519 dependent on the value of its "precision" attribute. 521 If the value of "precision" is "technology", the following "content" 522 attribute is defined as a JSON string, whose value belongs to the 523 following array: 525 network-access-set = ["adsl", "ftth", "fttb", "dc", "cellular"] 527 If the value of "precision" is "rank", the following "content" 528 attribute is defined as a JSON number, whose value indicates the 529 relative preference over the end point in question, in terms of its 530 access network. The end point with a higher number is more preferable 531 to another end point with a lower number. 533 In summary, the "network-access" property is defined as a JSON 534 object, as follows: 536 "network-access": { 537 "precision": "technology", 538 "content":["adsl", "ftth", "fttb", "dc", "cellular"] 539 } 541 "network-access": { 542 "precision": "ranking", 543 "content": number 544 } 546 Note: There is concern about undesirable privacy leakage via network- 547 access properties to distrusted ALTO clients. In such cases, 548 according to the definitions above, either the endpoint itself or the 549 ISP who is running the ALTO server can either specify an access 550 control policy to prevent undesirable exposure to specific ALTO 551 clients or use a privacy preserving mapping from the raw description 552 of access technologies to a number of abstract relative ranking 553 information instead. Moreover, the endpoint or the ISP might choose 554 to use another subscription related property "provisioned-bandwidth" 555 (defined later in Section 4.4.2) instead of "network-access". 557 4.3.2. End Point Property Type: forwarding-class 559 As suggested for the NFV use-case, the End Point property 560 "forwarding-class" is meant to indicate the type of forwarding class 561 the end point or network supports. 563 Forwarding classes can be thought of as output queues. For a 564 classifier to assign an output queue to a packet, it must associate 565 the packet with one of the following forwarding classes: 567 o Expedited forwarding (EF), provides a low-loss, low-latency, 568 low- jitter, assured bandwidth, end-to-end service. 570 o Assured forwarding (AF), provides a group of values you can 571 define and includes four subclasses: AF1, AF2, AF3, and AF4, each 572 with three drop probabilities: low, medium, and high. 574 o Best effort (BE), provides no service profile. For the best 575 effort forwarding class, loss priority is typically not carried in 576 a class-of-service (CoS) value. 578 o Network control (NC), is typically high priority because it 579 supports protocol control. 581 Hence, the "content" of the "forwarding-class" property is defined as 582 a JSON string, whose value belongs to the following array: 584 forwarding-class-set = ["expedited", "assured", "network control", 585 "best effort"] 587 In summary, the "forwarding-class" property is defined as a JSON 588 object, as follows: 590 "forwarding-class": { 591 "precision": "", 592 "content": ["expedited", "assured", "network control", "best effort"] 593 } 595 4.4. Subscription-Related Properties 597 4.4.1. End Point Property Type: volume-limited 599 Many wireless operators offer low-cost plans, which limit the amount 600 of data to be transmitted within a month to some gigabytes. After 601 that they will throttle the subscriber's bandwidth or charge extra 602 money. Hosts with such a tariff, could be tagged by another End Point 603 property "volume-limited" and should be avoided for peer selection to 604 serve other peers. 606 The "content" value for this property (defined as a boolean) is 607 either "true" or "false". If a peer is constrained by such a 608 subscription plan, the value of this property with respect to the 609 peer is set to "true". 611 In other words, the "volume-limited" property is defined as a JSON 612 object with a boolean "content", "true"for an end point with such a 613 limited data plan, or "false" for an point with unlimited or unknown 614 data plan. 616 "volume-limited": { 617 "precision": "", 618 "content": true/false 619 } 621 4.4.2. End Point Property Type: provisioned-bandwidth 623 For applications seeking for a candidate peer for uploading services, 624 the end point's uploading bandwidth is essential for the selection. 626 While it is straightforward for one to expose the accurate 627 information over an end point's bandwidth capability, the subscriber 628 of the end point might consider it a piece of private information. 630 On the other hand, it is suggested that the ISP can also choose to 631 expose its relative preference in terms of the end point's 632 provisioned bandwidth; this ensures better load balancing within the 633 network by avoiding undesirable hot spots caused by competition from 634 applications for the handful most provisioned end points. 636 Therefore, the "provisioned-bandwidth" property is defined as a JSON 637 object, whose "content" definition is actually dependent on the 638 "precision" attribute, which in turn is a JSON string whose values 639 belong to the following JSON array: 641 provisioned-bandwidth-precision-set = ["raw", "ranking"] 643 If the "precision" attribute of the "provisioned-bandwidth" property 644 of an end point is "raw", the following "content" is filled with the 645 accurate value of the provisioned bandwidth, as a JSON object 646 "provisioned-bandwidth-value" with two elements: 648 provisioned-bandwidth-value = { 649 "value" : number, 650 "metric" : ["GB", "MB", "KB", "Gb", "Mb", "Kb"] 651 } 653 If the "precision" attributed of the "provisioned-bandwidth" property 654 of an end point is "ranking", the following "content" is filled with 655 the relative ranking of the end point's provisioned bandwidth 656 assigned by the ISP, which in turn is a JSON number where higher 657 number indicating more preference. 659 In summary, the "provisioned-bandwidth" property is defined as a JSON 660 object as follows: 662 "provisioned-bandwidth": { 663 "precision": "raw", 664 "content": { 665 "value": number, 666 "metric": ["GB", "MB", "KB", "Gb", "Mb", "Kb"] 667 } 668 } 670 "provisioned-bandwidth": { 671 "precision": "ranking", 672 "content": number, 673 } 675 5. Security Considerations 677 TBA. 679 6. IANA Considerations 681 This document adds the following new End Point property types to the 682 existing registry created by ALTO protocol [RFC7285]. 684 TBA. 686 7. References 688 7.1. Normative References 690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 691 Requirement Levels", BCP 14, RFC 2119, March 1997. 693 [RFC7285] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 694 RFC7285, March 2014. 696 7.2. Informative References 698 [I-D.draft-deng-alto-p2pcache] Deng, L., Chen, W., and Q. Yi, 699 "Considerations for ALTO with network-deployed P2P 700 caches", draft-deng-alto-p2pcache-03 (work in progress), 701 February 2014. 703 [RFC7069] Alimi, R., Rahman, A., Kutscher, D., Yang, Y., Song, H., 704 and K. Pentikousis, "DECoupled Application Data Enroute 705 (DECADE)", RFC 7069, November 2013. 707 [I-D.draft-roome-alto-pid-properties] Roome, W. and Yang, R., "PID 708 Property Extension for ALTO Protocol", draft-roome-alto- 709 pid-properties-01 (work in progress), February 2014. 711 [I-D.draft-wu-alto-te-metrics] Wu, Q., Yang, R., Lee, Y., and 712 Randriamasy, S., "ALTO Traffic Engineering Cost Metrics", 713 draft-wu-alto-te-metrics-03 (work-in-progress), June 2014. 715 Acknowledgements 717 The authors would like to thank, Michael Scarf, Vijay 718 Gurbani, Reinaldo Penno, Sabine Randriamsy and Qiao Fu for 719 their review and valuable comments. 721 Authors' Addresses 723 Lingli Deng 724 China Mobile 725 China 727 Email: denglingli@chinamobile.com 729 Haibin Song 730 Huawei 731 China 733 Email: haibin.song@huawei.com 735 Sebastian Kiesel 736 University of Stuttgart, Computing Center 737 Germany 739 Email: ietf-alto@skiesel.de 741 Richard Yang 742 Y. Richard Yang 743 Yale University 745 Email: yry@cs.yale.edu 747 Qin Wu 748 Huawei 749 China 751 Email: sunseawq@huawei.com