idnits 2.17.00 (12 Aug 2021) /tmp/idnits13531/draft-heckmann-tdp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([2], [4], [9]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 436 has weird spacing: '... each inclu...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 7372 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 section? '2' on line 687 looks like a reference -- Missing reference section? '4' on line 693 looks like a reference -- Missing reference section? '9' on line 707 looks like a reference -- Missing reference section? '3' on line 690 looks like a reference -- Missing reference section? '5' on line 697 looks like a reference -- Missing reference section? '16' on line 736 looks like a reference -- Missing reference section? '6' on line 700 looks like a reference -- Missing reference section? '22' on line 755 looks like a reference -- Missing reference section? '10' on line 711 looks like a reference -- Missing reference section? '11' on line 715 looks like a reference -- Missing reference section? '17' on line 739 looks like a reference -- Missing reference section? '20' on line 748 looks like a reference -- Missing reference section? '21' on line 752 looks like a reference -- Missing reference section? '18' on line 742 looks like a reference -- Missing reference section? '19' on line 746 looks like a reference -- Missing reference section? '8' on line 704 looks like a reference -- Missing reference section? '13' on line 721 looks like a reference -- Missing reference section? '14' on line 728 looks like a reference -- Missing reference section? '1' on line 685 looks like a reference -- Missing reference section? '7' on line 702 looks like a reference -- Missing reference section? '12' on line 717 looks like a reference -- Missing reference section? '15' on line 731 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 O. Heckmann 2 V. Darlagiannis 3 M. Karsten 4 R. Steinmetz 5 KOM, TU- 6 Darmstadt 7 Internet Draft Bob Briscoe 8 Document: draft-heckmann-tdp-00.txt British Telecom 9 Expires: August 2002 March 2002 11 Tariff Distribution Protocol 12 (TDP) 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance 17 with all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as "work 28 in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This draft describes a very flexible and efficient protocol for 38 distributing price information (tariffs) inside an Internet 39 Service Provider's management system and to its customers. It is 40 designed to work with multiple QoS architectures, for example 41 Intserv [2] and Diffserv [4]. It can also be used for dynamic 42 pricing. It can use a number of different transport mechanisms, 43 e.g. embedding tariff messages as policy objects in RSVP [9] 44 messages. As tariffs can get very complex, it is possible but not 45 necessary to send tariffs as code (e.g. Java). 46 The draft also contains clear definitions of tariff and related 47 terms. 49 Table of Contents 50 Status of this Memo ..............................................1 51 Abstract .........................................................1 52 1 Background .....................................................2 53 1.1 Structure of this Draft .......................................3 54 2 Definitions ....................................................3 55 2.1 Service ......................................................3 56 2.2 Session ......................................................3 57 2.3 Session Characterization .....................................3 58 2.4 Charge and Charge Advice .....................................3 59 2.5 Price Coefficient ............................................3 60 2.6 Price ........................................................3 61 2.7 Tariff .......................................................4 62 2 Application scenarios ........................................4 63 4 The General Structure of TDP ...................................6 64 5 Representation sublayer ........................................6 65 5.1 Representation of Tariffs ......................................6 66 5.2 TDP Message Types and Interaction ..............................7 67 5.3 Specification of the Tariff Message ............................8 68 5.4 Request Message ...............................................11 69 6 Transfer Sublayer ...............................................11 70 6.1 TCP ...........................................................12 71 6.2 UDP multicast .................................................12 72 6.3 HTTP ..........................................................13 73 6.4 RSVP Policy Objects ...........................................13 74 7 Related Work ..................................................14 75 7.1 Open Settlement Protocol ......................................14 76 7.2 Internet Open Trading Protocol ................................14 77 References ......................................................15 78 Appendix A. Example Tariff components ...........................16 79 Appendix B. Tariff example ......................................16 80 Appendix C. Example of tariff message ...........................16 81 Appendix D. Definition of TariffMessage using XML Schema ........18 82 Author's Addresses ..............................................20 84 1 Background 85 One important aspect of market managed networking is pricing. In 86 a competitive, market managed, multi-service Internet, a vast 87 variety of different tariffs will exist, many of them might be 88 updated regularly. TDP is a protocol for the flexible and 89 efficient distribution of even the most complex tariffs. 91 1.1 Structure of this Draft 92 This draft is structured as follows: After this background 93 information, a clear definition of pricing related terms like 94 tariff, price and charge is given. Then the general structure of 95 the Tariff Distribution Protocol (TDP) itself is presented. It 96 consists of two layers that are presented afterwards. In the 97 seventh section related protocols and their relationship to TDP 98 are discussed. The document closes with the references, authors 99 addresses and a copyright statement. 101 2 Definitions 102 2.1 Service 103 In the following context the word _service_ is used for a low- 104 level network service that an ISP offers to its customers, e.g. 105 the Intserv [2] Guaranteed Service [3] or a service build on the 106 Diffserv [4] AF/EF PHB [5], [16]. 107 2.2 Session 108 The term session is used to describe the actual invocation and 109 usage of one clearly specified service. 110 2.3 Session Characterization 111 Charging if typically done per session, so sessions have to be 112 characterized quantitatively. The term _session characterization_ 113 is used for a set of well defined quantitative parameters (the 114 session characterization parameters) that describes all aspects 115 of a session that are relevant for a tariff. 116 Example parameters are duration, number of bytes or packets sent 117 or received, guaranteed service parameters (rate, peak rate, 118 bucket depth, etc.), number of received ECN marked packets, etc. 119 2.4 Charge and Charge Advice 120 The amount of money the provider charges for a session is the 121 _charge_, which is equal to the customer's costs for that 122 session. A _charge advice_ is used for the amount of money that 123 the customer must pay for a (fictional or real) session. The 124 differences between charge and charge advice are subtle but 125 important. The charge advice is the output of the tariff while 126 the charge is the output of the provider's charging and 127 accounting system and is passed on (eventually in aggregated 128 form) to the billing system. 129 An example from phone tariffs will clearify that: 130 A customer can find out the costs for a one minute call (the 131 session) he plans to make by looking at his mobile phone 132 provider's tariff. That is the charge advice. Once he makes that 133 call his provider's charging and accounting system (CAS) stores 134 that the customer owes the provider a certain amount of money, 135 that is the charge. 136 2.5 Price Coefficient 137 A price coefficient is the partial derivative of charge advice 138 with respect to one session characterization parameter. 139 2.6 Price 140 If a session is characterized by only one parameter, there is 141 only one price coefficient and this coefficient is what people 142 often intuitively call price (money per minute, per kilo etc.). 143 But following Encyclopedia Britannica [6], a price is _the amount 144 of money that has to be paid to acquire a given product_, 145 therefore equal to the charge advice. To avoid confusion the word 146 price is used in this context only as a general term. 147 2.7 Tariff 148 A tariff is a set of rules for calculating the charge advices for 149 sessions of one service. Thus, the input of a tariff is a session 150 characterization and the output is a charge advice. 151 One might think that a tariff is the same as the set of price 152 coefficients but this only holds true for the simplest cases 153 (linear tariff algorithms) as the examples below will show. 154 It is useful to distinguish inside the tariff between the tariff 155 algorithm and the tariff parameters, (see Table 1). The algorithm 156 describes how the session characterization parameters are 157 combined with the tariff parameters in order to obtain the charge 158 advice CA. 160 +----------------------------+-------------------------------+ 161 |Session characterization |t, u | 162 |parameters | | 163 |----------------------------+-------------------------------+ 164 |Tariff parameters |a, b, c | 165 |----------------------------+-------------------------------+ 166 |Tariff algorithm |CA(t, u) = a*t+b*u^c | 167 |----------------------------+-------------------------------+ 168 |Price coefficients of t |d(CA(t, u))/dt = a | 169 |----------------------------+-------------------------------+ 170 |Price coefficients of u |d(CA(t, u))/du = b*c*u^(c-1) | 171 +----------------------------+-------------------------------+ 173 Table 1: Example Tariff 175 An example is given in [22]. The example also shows 176 that the tariff parameters are not necessarily the same as the 177 price coefficients. If a tariff algorithm is non-linear, the 178 price coefficients are no longer constant (see the price 179 coefficient for u). 181 It makes sense to distinguish between the tariff algorithm and 182 the tariff parameters. In a good implementation this has to be 183 done anyway to separate data and methods. It is also efficient, 184 because typically the algorithm will not be changed as often as 185 the tariff parameters and TDP allows to send updates of the 186 tariff parameters only, thus reducing message size. 188 2 Application scenarios 189 One application scenario is to use TDP to distribute tariff 190 related information inside a provider's management plane. Figure 191 1 shows the modules of an ISP's management plane that are 192 typically involved in tariff distribution. 194 Provider | Customer 195 M +-----------+ +---------+ | +---------+ 196 a |Enterprise | |Tariff | | |Price | 197 n |Policy |------>|Directory|------------>|Reaction | 198 a |Control | / \ +---------+ | | +---------+ 199 g +-----------+ | | | | 200 e | | \ / | 201 m +-----------+ | | +----------+ | 202 e |Price |--- | |Charging &| | 203 n |Calculation|............|..|Accounting| | 204 t +-----------+ | +----------+ | 205 / \ | | 206 | | | 207 +-----------+ | | 208 ---------------------------------------------|--------------- 209 D P |Mediation | | | 210 a a +-----------+ | | 211 t t | | 212 a h /----------------------------------------|-----------\ 213 \----------------------------------------|-----------/ 214 | | 215 ---------------------------------------------|--------------- 216 S S | | 217 e i \ / | 218 r g +-----------+ | 219 v n |Bandwidth | | 220 i a |Broker | | 221 c l +-----------+ | 222 e i | 223 n | 224 g | 226 Figure 1: Architecture 228 Another application scenario is to use TDP to distribute price 229 information from a provider to its customers. In both scenarios 230 the instance that possesses the tariff information is called the 231 tariff sender and the instance that receives the tariff 232 information is called the tariff receiver. 233 A tariff can be set manually with the enterprise policy control 234 module (EPC). In a dynamically priced Internet tariff changes are 235 automated and then originate the price calculation module. This 236 module uses several data sources as input for it's decisions, for 237 example the CAS and the mediation module (which aggregates and 238 correlates data from the network infrastructure). 240 The tariff directory stores all tariffs and forwards them towards 241 the CAS and - if it exists - the bandwidth broker (BB). Note that 242 the CAS and the BB might be distributed systems consisting of a 243 number of boxes. 244 The customers can be end-users or other providers. They can be 245 informed about the tariffs via a push mechanism (tariff directory 246 sends tariffs and tariff updates) and/or a pull mechanism (end- 247 system requests a certain tariff). If the customer is a provider, 248 it can use the pricing information as a further input source for 249 its own price calculation module. 251 4 The General Structure of TDP 252 TDP can be divided into two sublayers. The highest sublayer 253 (representation sublayer) describes the two basic message types 254 of TDP, the tariff and the tariff request message. XML is used as 255 representation format and to specify how tariffs and related 256 metainformation are encoded. A compact binary version of the 257 tariff message is also specified (see Figure 2). 259 +--------------------------+ 260 | XML | Binary | Representation 261 |--------------------------+ 262 | TCP | UDP | RSVP | HTTP | Transfer 263 +--------------------------+ 265 Figure 2: TDP Layers 267 The transfer sublayer offers a variety of transfer mechanisms 268 that can be used to transport the messages. In this draft four 269 different transfer mechanisms are specified but TDP is open to 270 more transfer mechanisms. 271 5 Representation sublayer 272 5.1 Representation of Tariffs 273 Some current mobile phone tariffs show that tariffs can be very 274 complex. They can include special discounts (for example 10% 275 discount after the 10th minute) and often depend on the time of 276 the day and the day of the week (weekend...). It is unrealistic 277 to expect that all future multi-service Internet tariffs will fit 278 into a standardized scheme. 279 The protocol accounts for this with flexibility. It can include 280 any description of a tariff and it's parameters. It can use any 281 tariff definition language but also allows the use of other 282 programming languages, like Java, instead. As the distributed 283 tariffs should also be human-readable, a textual description of 284 the algorithm and the parameters can also be included as plain 285 text, HTML [10] and/or XML [11]. 286 TDP also reflects the possibility that there might also be a 287 number of _standardized_ tariffs, that is tariffs where the 288 algorithm is known to all parties involved in the communication 289 and therefore no code has ever to be sent around but the 290 algorithm has to be identified in a globally unique way. 292 5.2 TDP Message Types and Interaction 293 The protocol uses two basic kinds of messages: the tariff message 294 that contains either a complete tariff (consisting of tariff 295 algorithm plus tariff parameters) or a tariff update (consisting 296 of new tariff parameters only) and the request message that is 297 used to request a certain tariff (see Figure 1). 299 +---------------+-----+ Request Message +-----+---------------+ 300 | | |<----------------| | | 301 | Tariff Sender | TDP | Tariff Message | TDP |Tariff Receiver| 302 | | |---------------->| | | 303 +---------------+-----+ +-----+---------------+ 305 Figure 3: TDP Message Types 307 The protocol can be used in two different modes, the pull and the 308 push mode, both modes can also be combined (mixed mode). Sender 309 and receiver agree upon the mode used by means outside the 310 protocol. Tariff and request messages can be sent with different 311 transfer mechansisms (see section 6). 313 5.2.1 Push mode 314 In push mode only tariff messages are sent, the order and time 315 interval is completely up to the sender. No tariff request 316 messages are used. The user has to find out the tariffs by 317 listening to the stream of tariff messages. 319 5.2.2 Pull mode 320 In pull mode the tariff receiver requests a specific tariff or 321 the tariff for a specific service by sending a request message 322 that is answered by the tariff sender with a tariff message. A 323 single tariff message can answer more than one request. 324 Pull mode uses an asynchronous request/reply mechanism. A tariff 325 receiver can send any number of requests directly one after the 326 other while the answering tariff messages can be send in a 327 different order, with a different transport mechanism and with 328 different delays. 330 5.2.3 Mixed mode 331 The protocol can also be used in mixed mode which is equal to 332 pull mode but the tariff sender can also send tariff information 333 that was not requested. 335 5.3 Specification of the Tariff Message 336 TDP uses a XML message format to describe its messages, allowing 337 the reuse of existing code like XML parsers and validators, e.g. 338 Apache [11]. 339 An example tariff message is included in the Appendix B. The XML 340 Schema [17] specification of a tariff message is also included in 341 the Appendix D. 343 5.3.1 Provider Tag 344 The provider is identified globally by using his domain name (2nd 345 level domain) in the provider tag. There must be exactly one 346 provider tag in each tariff message identifying the provider 347 offering this tariff. 348 With the optional name tag one or more human readable names can 349 be included, this information should not be used instead of the 350 domain name above, it can be used by applications with user 351 interfaces. 353 5.3.2 Tariff Tag 354 Each tariff has one unique tariff ID. The ID must be unique only 355 inside the provider space, the provider is responsible for 356 managing the IDs. The tariff ID is not the same as the service ID 357 because one tariff could be used for more than one service and 358 the other way around. The ID can be any string up to a length of 359 255 bytes. 360 The tariff tag must include exactly one ID tag and can also 361 include any number of optional name tags with human readable 362 information that must not be relied on to identify the tariff 363 uniquely. 364 Each tariff message must include exactly one tariff tag. 366 5.3.3 Service Tag 367 Each service the provider offers has one unique service ID. The 368 ID must be unique only inside the provider space, the provider is 369 responsible for managing the IDs. The ID can be any string up to 370 a length of 255 bytes. 371 The service tag must include exactly one ID tag and can also 372 include any number of optional name tags with human readable 373 information that must not be relied on to identify the service 374 uniquely. 375 Each tariff message must include one or more service tags. If 376 more than one service tags are included the tariff described by 377 the message must be able to calculate charge advices for all the 378 listed services. 380 5.3.4 Algorithm Tag 381 The algorithm tag describes the tariff algorithm. Each tariff 382 message includes zero or one algorithm tags. If no algorithm tag 383 is included, then the information in the message is usable only 384 by senders that know the algorithm by other means (because the 385 algorithm is standardized and known by everyone or because the 386 algorithm was sent before and has not changed yet). This is 387 called a tariff update. 388 The algorithm tag includes exactly one version tag that contains 389 a version number (integer). It can contain any number of valid 390 tags that describe the time intervals in which the tariff is 391 valid. 392 The algorithm tag contains any number of description tags that 393 describe the algorithm. The description tag has two attributes: 394 content and referenced. The default value for content is 395 _text/plain_ and for referenced is _true_. 396 The description tag includes the algorithm itself in a form that 397 is specified by the content attribute. The content attribute uses 398 MIME-Types [20] [21]. If the referenced attribute is set to _true_ 399 then the content of the description tag is a url that points to a 400 remote document with the algorithm description. If referenced is 401 set to _false_ then the algorithm description is included 402 directly in the description tag body. 403 The algorithm description is now specified for several content 404 types, the protocol is open for more content types. 406 5.3.4.1 Algorithm Description for content-type _text/plain_ 407 The algorithm description is included in a _text_ tag. At least 408 one text tag has to be included, but more than one is possible. 409 Every text tag must include the complete algorithm description, 410 the content of the text tags - which can differ in the language 411 used, etc. The attributes of the text tag are not further 412 specified in this version of the draft. 413 The content of the text tag must be plain text as specified in 414 [20] [21]. 416 5.3.4.2 Algorithm Description for content-type _text/html_ 417 The algorithm description is included in a _html_ tag. At least 418 one html tag has to be included, but more than one is possible. 419 Every html tag must include the complete algorithm description, 420 the content of the html tags _ which can differ in the language 421 used, html version used, etc. The attributes of the html tag are 422 not further specified in this version of the draft. 423 The content of the html tag must be HTML as specified in [10]. 425 5.3.4.3 Algorithm Description for content-type _text/xml_ 426 The algorithm description is included in a _xml_ tag. At least 427 one xml tag has to be included, but more than one is possible. 428 Every xml tag must include the complete algorithm description, 429 the content of the xml tags - which can differ in the language 430 used, xml version used, etc. The attributes of the xml tag are 431 not further specified in this version of the draft. 432 The content of the xml tag must be XML as specified in [18]. 434 5.3.4.4 Algorithm Description for content-type _binary/java_ 435 The algorithm description consists of any number of class tags, 436 each including one java class needed for the tariff algorithm. 438 Alternatively one jar (Java archive) tag can be used that 439 contains a number of classes. The body of the description must 440 include the name of the classes included that is the tariff 441 algorithm and that will be executed. 442 Each class tag has an obligatory name attribute that describes 443 the name of the java class that is included. The attribute 444 encoding describes how the class is encoded, for which the 445 default value is _base64_ [20]. The optional compression 446 attribute can be used to describe the compression algorithm used 447 to compress the class before it was encoded with the method 448 specified by the encoding attribute. The default is to use no 449 compression, the default value for the compression attribute is 450 therefore _NO_. 452 5.3.5 Parameters Tag 453 The parameters tag includes the tariff parameters and related 454 metainformation. 455 The parameters tag must include exactly one version tag, the same 456 rules as for the version tag, part of the algorithm tag, apply. 457 The parameters tag can also include any number of valid tags, the 458 same rules as for the valid tag, part of the algorithm tag, 459 apply. 460 The parameters tag includes any number of description tags, at 461 least one description tag must be included. The description tags 462 have a content attribute with the default value _text/plain_ and 463 a referenced attribute with the default value _true_. 464 The description tag includes the tariff parameters in a form that 465 is specified by the content attribute. The content attribute uses 466 MIME-Types [20] [21]. If the referenced attribute is set to _true_, 467 then the content of the description tag is a url that points to a 468 remote document with the tariff parameters description. If 469 referenced is set to _false_ then the tariff parameters 470 description is included directly in the description tag body. 471 The tariff parameters description is now specified for several 472 content types, the protocol is open for more content types. 474 5.3.5.1 Parameters Description for content-type _text/plain_ 475 The tariff parameters description is included in a _text_ tag. At 476 least one text tag has to be included, but more than one is 477 possible. Every text tag must include the complete parameters 478 description, the content of the text tags _ which can differ in 479 the language used, etc. The attributes of the text tag are not 480 further specified in this version of the draft. The content of 481 the text tag must be plain text as specified in [20] [21]. 483 5.3.5.2 Parameters Description for content-type _binary_ 484 The tariff parameters description is included in a _binary_ tag. 485 At least one binary tag has to be included, but more than one is 486 possible. Every binary tag must include the complete parameters, 487 the content of the binary tags _ which can differ in the encoding 488 used, etc. Each binary tag has an encoding attribute that 489 describes the way the binary information is encoded in the xml 490 message. The default value is _base64_ [20]. 491 The content of the binary tag is a byte array that can be read by 492 the algorithm code. The specification of this byte array is done 493 by the author of the tariff algorithm. 495 5.3.6 Reference Tag 496 If a tariff message is a direct answer to a request message it 497 references this request message with one reference tag. Any 498 number of reference tags can be included in a tariff message. The 499 reference tag must include two tags, the sender tag that contains 500 the IP address of the originator of the request message and the 501 num tag that contains an integer that identifies the request 502 message (as there might be more than one request messages from 503 one IP address). The content from the reference tag must be 504 exactly identical to the content of the reference tag in the 505 according request message. 507 5.4 Request Message 508 The second message type is the request message. It allows 509 requesting either a special tariff or - in case that tariff 510 receivers do not yet know, what tariff they are interested in - 511 allows requesting tariffs for one service. Service discovery is 512 outside the scope of TDP. 513 The XML Schema specification for the request message and an 514 example are in the Appendix D. 516 5.4.1 Reference Tag 517 There must be exactly one reference tag in a request message. The 518 reference tag identifies the request message and is repeated in 519 the tariff message that answers this request message. The 520 reference tag must include two tags, the sender tag that contains 521 the IP address of the originator of the request message and the 522 num tag that contains an integer that identifies the request 523 message (as there might be more than one request messages from 524 one IP address). 526 5.4.2 Request Tag 527 There must be exactly one request tag in a request message. It 528 specifies either the tariff that is requested or the service for 529 which a tariff is requested. It includes either one tariff or one 530 service tag. The tariff and the service tag include one further 531 tag which can be an ID tag or a name tag. In the ID tag the 532 tariff or service ID is entered and in the name tag the human 533 readable name would be entered (see 5.3.2 and 5.3.3). 535 6 Transfer Sublayer 536 Different transfer mechanisms can be used to send the messages of 537 the representation sublayer (see section 5). Which ones are used 538 by actual instances of the protocol are decided upon by means 539 outside of the protocol (e.g. by an SLA). 541 6.1 TCP 542 Plain TCP connections offer a minimalistic reliable transport 543 mechanism for the TDP messages. 544 A small header is added to the tariff and request message: 546 0 1 547 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Length Field | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | 552 | Payload | 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 4: PDU for TCP transport 558 The Payload consists of exactly one tariff or request message. 559 The length field describes the number of bytes in the payload. 561 6.2 UDP multicast 562 In case UDP multicast is used the PDU takes the following format: 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | ID | Segm. Number | Total Segments| 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 // Payload (or part thereof) | 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 5: PDU for UDP transport 576 The Payload consists of the tariff or request message. The sender 577 can divide the message into segments. This is necessary if the 578 message is bigger than the maximum allowed message size of UDP 579 [19] but the sender is free to fragment a message also for 580 smaller message sizes. All segments get the same ID, they get a 581 sequential segment number starting with 0. The _total segments_ 582 field in the header is set to the total number of segments for 583 that message (so a minimum of one is entered here). 584 The sender has to make sure that two different tariff messages 585 get two different IDs. An ID number can be reused after a timeout 586 period of 2 times the maximum segment lifetime of TCP. 588 6.3 HTTP 589 The TDP request messages are sent as an HTTP [10] request message 590 and the TDP tariff messages are sent as HTTP response messages. 591 The message body carries the TDP request or the tariff message. 593 6.4 RSVP Policy Objects 595 +-------------+-------------+-------------+-------------+ 596 | Length | POLICY_DATA | 1 | 597 +---------------------------+-------------+-------------+ 598 | Data Offset | 0 (reserved) | 599 +---------------------------+-------------+-------------+ 600 | | 601 // Option List // 602 | | 603 +-------------------------------------------------------+ 604 | | 605 // Policy Element List // 606 | | 607 +-------------------------------------------------------+ 609 Figure 6: RSVP POLICY_DATA object 611 +-------------+-------------+-------------+-------------+ 612 | Length | P-Type | 613 +---------------------------+---------------------------+ 614 | | 615 // Policy information (Opaque to RSVP) // 616 | | 617 +-------------------------------------------------------+ 619 Figure 7: Policy Element 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | ID | Segm. Number | Total Segments| 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | 627 // TDP Message (or part thereof) // 628 | | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Figure 8: Policy Information 633 The POLICY_DATA object as specified in [8] is listed in Figure 6. 634 The TDP Message is embedded as policy information (Figure 7) in a 635 policy element (Figure 8) as part of the policy element list of 636 the RSVP POLICY DATA object. 637 The Payload of the policy information consists of the tariff or 638 request message. The sender can divide the message into segments. 639 This is necessary if the message is bigger than the maximum 640 allowed message size for policy information [8] but the sender is 641 free to fragment a message also for smaller message sizes. All 642 segments get the same ID, they get a sequential segment number 643 starting with 0. The _total segments_ field in the header is set 644 to the total number of segments for that message (so a minimum of 645 one is entered here). 646 The sender has to make sure that two different tariff messages 647 get two different IDs. An ID number can be reused after a timeout 648 period of 2 times the maximum segment lifetime of TCP. 650 7 Related Work 651 We now describe two other related protocols and compare them with 652 the Tariff Distribution Protocol presented in this paper. 654 7.1 Open Settlement Protocol 655 The Open Settlement Protocol (OSP, [13]) is an ETSI TIPHON 656 specification that describes a set of protocols to permit the 657 exchange of inter-domain pricing, authorization and settlement 658 information between Internet telephony operators. The pricing 659 part overlaps with the Tariff Distribution Protocol presented in 660 this paper, yet, there are a lot of differences. 661 Both protocols are XML-based and both allow a binary format. 662 While OSP uses HTTP only as underlying protocol, the Tariff 663 Distribution Protocol allows different transport mechanisms. 664 OSP can be used to exchange prices (OSP terminology) - expressed 665 in the terminology of this work, OSP is restricted to very simple 666 tariffs with one price coefficient (like the per-minute prices 667 for phone calls). As OSP is more intended as settlement protocol 668 between providers, it offers an explicit mechanism to accept or 669 decline prices (pricing confirmation). It offers no mechanism to 670 request a special tariff or a tariff for a given service. 671 Summarizing, OSP offers broader capabilities but is far less 672 powerful in the area of price communication and it is specialized 673 for the IP telephony use case. 675 7.2 Internet Open Trading Protocol 676 The IETF Internet Open Trading Protocol (IOTP) specification [14] 677 describes a framework for payment protocols and uses XML over 678 HTTP. This work is complementary to the Tariff Distribution 679 Protocol as it is mostly concerned with the settlement, while the 680 Tariff Distribution Protocol determines how the individual 681 charges the bill consists of are calculated. 683 References: 685 [1] M3I Project, http://www.m3i.org/. 687 [2] Braden R., Clark D., Shenker S., "Integrated Services in the 688 Internet Architecture: an Overview", RFC 1633, June 1994. 690 [3] Partridge, C. and R. Guerin, "Specification of Guaranteed 691 Quality of Service", RFC 2212, September 1997. 693 [4] S. Blake, D. L. Black, M. A. Carlson, E. Davies, Z. Wang, and W. 694 Experimental RFC, December 1998. Weiss, "RFC 2475 - An Architecture 695 for Differentiated Services". 697 [5] J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, "RFC 2597 - 698 Assured Forwarding PHB Group". Request for Comments, June 1999. 700 [6] Encyclopaedia Britannica, http://www.britannica.com/. 702 [7] Merriam Webster, http://www.m-w.com/. 704 [8] S. Herzog, "RFC 2750 - RSVP Extensions for Policy Control", 705 Standards Track, January 2000. 707 [9] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. RFC 708 2205 - Resource ReSerVation Protocol (RSVP) _ version 1 functional 709 specification. Standards Track RFC, September 1997. 711 [10] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 712 "RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1", Standards 713 Track, January 1997. 715 [11] Apache XML Project, Apache Organisation, http://xml.apache.org/. 717 [12] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah 718 Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, Dave Winer, 719 "Simple Object Access Protocol (SOAP) 1.1", W3C Note 08, May 2000. 721 [13] European Telecommunications Standards Institute (ETSI), 723 "Telecommunications and Internet Protocol Harmonization Over Networks 724 (TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, 725 authorization, and usage exchange", ETSI TS 101 321 V2.1.1, August 726 2000 728 [14] Burdett, D., "Internet Open Trading Protocol - IOTP Version 729 1.0", RFC 2801, April 2000. 731 [15] X. Wang and H. Schulzrinne, "RNAP: A resource negotiation and 732 pricing protocol", In International Workshop on Network and Operating 733 Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77-- 734 93, Basking Ridge, New Jersey, June 1999. 736 [16] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 737 PHB", RFC 2598, June 1999. 739 [17] David C. Fallside, " XML Schema Part 0: Primer", W3C 740 Recommendation, 2 May 2001 742 [18] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 743 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 744 Recommendation 6, October 2000 746 [19] J. Postel, "User Datagram Protocol", RFC 768, August 1980 748 [20] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail 749 Extensions) Part One: Format of Internet Message Bodies", RFC 2045, 750 November 1996 752 [21] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail 753 Extensions) Part Two: Media Types", RFC 2046, November 1996 755 [22] Oliver Heckmann, Vasilios Darlagiannis, Martin Karsten, and 756 Ralf Steinmetz. A Price Communication Protocol for a Multi-Service 757 Internet. In Informatik 2001 - Wirtschaft und Wissenschaft in der 758 Network Economy - Visionen und Wirklichkeit (GI/OCG 2001), September 759 2001. 761 Appendix A. Example Tariff components 762 Session characterization parameters: t, u 763 Tariff parameters: a, b, c 764 Tariff algorithm: 765 Price coefficient of t: 766 Price coefficient of u: 768 Appendix B. Tariff example 769 Session characterization parameters: t, u 770 Tariff parameters: a, b, c 771 Tariff algorithm: CA(t, u)= a * t + b * u^c 772 Price coefficient of t: d/dt(CA(t, u)) = a 773 Price coefficient of u: d/du(CA(t, u)) = b * c * 774 u^(c-1) 776 Appendix C. Example of tariff message 777 778 779 780 bt.com 781 British Telecom 782 ... 783 785 786 131 787 789 790 40 791 IntServ GS 792 794 795 3 796 797 20.01.00 798 799 800 802 804 807 ... 808 809 ... 810 811 813 814 ... 815 816 818 820 821 305 822 823 20000 824 826 829 ... 830 831 833 http://www.bt.com/... 834 835 837 838 162.154.20.41 839 12 840 842 ... 844 846 Appendix D. Definition of TariffMessage using XML Schema 848 849 851 852 853 This is the root element of the 854 schema 855 856 857 858 859 860 861 862 864 865 866 867 868 869 870 871 872 873 874 875 877 878 879 880 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 927 928 929 930 931 932 934 935 936 937 938 939 940 Global ID 941 942 943 945 Author's Addresses 947 Oliver Hechmann 948 Vasilios Darlagiannis 949 Martin Karsten 950 Ralf Steimetz 951 KOM, TU-Darmstadt 952 Merch str. 9 Phone: +49-6151-166150 953 Darmstadt, Germany Email: heckmann@kom.tu-darmstadt.de 955 Bob Briscoe 956 B54/74, BT Labs 957 Martlesham Heath 958 Ipswich, IP5 3RE Phone: +44 1473 645196 959 England Email: bob.briscoe@bt.com 961 Full Copyright Statement 963 Copyright (C) The Internet Society (2002). All Rights Reserved. 965 This document and translations of it may be copied and furnished to 966 others, and derivative works that comment on or otherwise explain it 967 or assist in its implementation may be prepared, copied, published 968 and distributed, in whole or in part, without restriction of any 969 kind, provided that the above copyright notice and this paragraph 970 are included on all such copies and derivative works. However, this 971 document itself may not be modified in any way, such as by removing 972 the copyright notice or references to the Internet Society or other 973 Internet organizations, except as needed for the purpose of 974 developing Internet standards in which case the procedures for 975 copyrights defined in the Internet Standards process must be 976 followed, or as required to translate it into languages other than 977 English. 979 The limited permissions granted above are perpetual and will not be 980 revoked by the Internet Society or its successors or assigns. 982 This document and the information contained herein is provided on an 983 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 984 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 985 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 986 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 987 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.