Internet DRAFT - draft-heckmann-tdp

draft-heckmann-tdp




                                                               O. Heckmann
                                                           V. Darlagiannis
                                                                M. Karsten
                                                              R. Steinmetz
                                                                  KOM, TU-
                                                                 Darmstadt
      Internet Draft                                           Bob Briscoe
      Document: draft-heckmann-tdp-00.txt                  British Telecom
     Expires: August 2002                                       March 2002
   
   
                         Tariff Distribution Protocol  
                                    (TDP) 
   
   
  Status of this Memo 
   
      This document is an Internet-Draft and is in full conformance 
      with all provisions of Section 10 of RFC2026. 
       
       
      Internet-Drafts are working documents of the Internet Engineering 
      Task Force (IETF), its areas, and its working groups.  Note that      
      other groups may also distribute working documents as Internet-
      Drafts. 
       
      Internet-Drafts are draft documents valid for a maximum of six 
      months and may be updated, replaced, or obsoleted by other 
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as "work 
      in progress." 
       
      The list of current Internet-Drafts can be accessed at 
           http://www.ietf.org/ietf/1id-abstracts.txt 
      The list of Internet-Draft Shadow Directories can be accessed at 
           http://www.ietf.org/shadow.html. 
       
       
  Abstract 
       
      This draft describes a very flexible and efficient protocol for 
      distributing price information (tariffs) inside an Internet 
      Service Provider's management system and to its customers. It is 
      designed to work with multiple QoS architectures, for example 
      Intserv [2] and Diffserv [4]. It can also be used for dynamic 
      pricing. It can use a number of different transport mechanisms, 
      e.g. embedding tariff messages as policy objects in RSVP [9] 
      messages. As tariffs can get very complex, it is possible but not 
      necessary to send tariffs as code (e.g. Java).  
      The draft also contains clear definitions of tariff and related 
      terms.  
   
   
  Table of Contents 

       
        Tariff Distribution Protocol  March 2002 
         
   
       
       
     Status of this Memo ..............................................1 
     Abstract .........................................................1 
     1 Background .....................................................2 
   1.1  Structure of this Draft .......................................3
     2 Definitions ....................................................3 
     2.1 Service ......................................................3 
     2.2 Session ......................................................3 
     2.3 Session Characterization .....................................3 
     2.4 Charge and Charge Advice .....................................3 
     2.5 Price Coefficient ............................................3 
     2.6 Price ........................................................3 
     2.7 Tariff .......................................................4 
     2   Application scenarios ........................................4 
     4 The General Structure of TDP ...................................6 
     5 Representation sublayer ........................................6 
   5.1 Representation of Tariffs ......................................6
   5.2 TDP Message Types and Interaction ..............................7
   5.3 Specification of the Tariff Message ............................8
   5.4 Request Message ...............................................11
   6 Transfer Sublayer ...............................................11
   6.1 TCP ...........................................................12
   6.2 UDP multicast .................................................12
   6.3 HTTP ..........................................................13
   6.4 RSVP Policy Objects ...........................................13
     7 Related Work ..................................................14 
   7.1 Open Settlement Protocol ......................................14
   7.2 Internet Open Trading Protocol ................................14
     References ......................................................15 
     Appendix A. Example Tariff components ...........................16 
     Appendix B. Tariff example ......................................16 
     Appendix C. Example of tariff message ...........................16 
     Appendix D. Definition of TariffMessage using XML Schema ........18 
     Author's Addresses ..............................................20 

    
   
       
  1 Background 
      One important aspect of market managed networking is pricing. In 
      a competitive, market managed, multi-service Internet, a vast 
      variety of different tariffs will exist, many of them might be 
      updated regularly. TDP is a protocol for the flexible and 
      efficient distribution of even the most complex tariffs.  


        
      Heckmann et al  Experimental - Expires August 2002  Page 2 

        Tariff Distribution Protocol  March 2002 
         
   
       
  1.1  Structure of this Draft 
      This draft is structured as follows: After this background 
      information, a clear definition of pricing related terms like 
      tariff, price and charge is given. Then the general structure of 
      the Tariff Distribution Protocol (TDP) itself is presented. It 
      consists of two layers that are presented afterwards. In the 
      seventh section related protocols and their relationship to TDP 
      are discussed. The document closes with the references, authors 
      addresses and a copyright statement. 
       
  2 Definitions 
  2.1 Service 
      In the following context the word _service_ is used for a low-
      level network service that an ISP offers to its customers, e.g. 
      the Intserv [2] Guaranteed Service [3] or a service build on the 
      Diffserv [4] AF/EF PHB [5], [16].  
  2.2 Session 
      The term session is used to describe the actual invocation and 
      usage of one clearly specified service. 
  2.3 Session Characterization 
      Charging if typically done per session, so sessions have to be 
      characterized quantitatively. The term _session characterization_ 
      is used for a set of well defined quantitative parameters (the 
      session characterization parameters) that describes all aspects 
      of a session that are relevant for a tariff.  
      Example parameters are duration, number of bytes or packets sent 
      or received, guaranteed service parameters (rate, peak rate, 
      bucket depth, etc.), number of received ECN marked packets, etc. 
  2.4 Charge and Charge Advice 
      The amount of money the provider charges for a session is the 
      _charge_, which is equal to the customer's costs for that 
      session. A _charge advice_ is used for the amount of money that 
      the customer must pay for a (fictional or real) session. The 
      differences between charge and charge advice are subtle but 
      important. The charge advice is the output of the tariff while 
      the charge is the output of the provider's charging and 
      accounting system and is passed on (eventually in aggregated 
      form) to the billing system.  
      An example from phone tariffs will clearify that:  
      A customer can find out the costs for a one minute call (the 
      session) he plans to make by looking at his mobile phone 
      provider's tariff. That is the charge advice. Once he makes that 
      call his provider's charging and accounting system (CAS) stores 
      that the customer owes the provider a certain amount of money, 
      that is the charge. 
  2.5 Price Coefficient 
      A price coefficient is the partial derivative of charge advice 
      with respect to one session characterization parameter.  
  2.6 Price 
      If a session is characterized by only one parameter, there is 
      only one price coefficient and this coefficient is what people 
        
      Heckmann et al  Experimental - Expires August 2002  Page 3 

        Tariff Distribution Protocol  March 2002 
         
   
       
      often intuitively call price (money per minute, per kilo etc.). 
      But following Encyclopedia Britannica [6], a price is _the amount 
      of money that has to be paid to acquire a given product_, 
      therefore equal to the charge advice. To avoid confusion the word 
      price is used in this context only as a general term. 
  2.7 Tariff 
      A tariff is a set of rules for calculating the charge advices for 
      sessions of one service. Thus, the input of a tariff is a session 
      characterization and the output is a charge advice. 
      One might think that a tariff is the same as the set of price 
      coefficients but this only holds true for the simplest cases 
      (linear tariff algorithms) as the examples below will show.  
      It is useful to distinguish inside the tariff between the tariff 
      algorithm and the tariff parameters, (see Table 1). The algorithm 
      describes how the session characterization parameters are 
      combined with the tariff parameters in order to obtain the charge 
      advice CA.  
       
      +----------------------------+-------------------------------+ 
      |Session characterization    |t, u                           | 
      |parameters                  |                               | 
      |----------------------------+-------------------------------+ 
      |Tariff parameters           |a, b, c                        | 
      |----------------------------+-------------------------------+ 
      |Tariff algorithm            |CA(t, u) = a*t+b*u^c           | 
      |----------------------------+-------------------------------+ 
      |Price coefficients of t     |d(CA(t, u))/dt = a             | 
      |----------------------------+-------------------------------+ 
      |Price coefficients of u     |d(CA(t, u))/du = b*c*u^(c-1)   | 
      +----------------------------+-------------------------------+ 
       
                        Table 1: Example Tariff 

       
      An example is given in [22]. The example also shows 
      that the tariff parameters are not necessarily the same as the 
      price coefficients. If a tariff algorithm is non-linear, the 
      price coefficients are no longer constant (see the price 
      coefficient for u). 
       
      It makes sense to distinguish between the tariff algorithm and 
      the tariff parameters. In a good implementation this has to be 
      done anyway to separate data and methods. It is also efficient, 
      because typically the algorithm will not be changed as often as 
      the tariff parameters and TDP allows to send updates of the 
      tariff parameters only, thus reducing message size. 
       
  2  Application scenarios 
      One application scenario is to use TDP to distribute tariff 
      related information inside a provider's management plane. Figure 

        
      Heckmann et al  Experimental - Expires August 2002  Page 4 

        Tariff Distribution Protocol  March 2002 
         
   
       
      1 shows the modules of an ISP's management plane that are 
      typically involved in tariff distribution. 
       
                     Provider                      |    Customer 
      M   +-----------+       +---------+          |  +---------+ 
      a   |Enterprise |       |Tariff   |          |  |Price    | 
      n   |Policy     |------>|Directory|------------>|Reaction | 
      a   |Control    |  / \  +---------+   |      |  +---------+ 
      g   +-----------+   |        |        |      | 
      e                   |        |       \ /     | 
      m   +-----------+   |        |  +----------+ | 
      e   |Price      |---         |  |Charging &| | 
      n   |Calculation|............|..|Accounting| | 
      t   +-----------+            |  +----------+ | 
               / \                 |               | 
                |                  |               | 
          +-----------+            |               | 
      ---------------------------------------------|--------------- 
      D P |Mediation  |            |               | 
      a a +-----------+            |               | 
      t t                          |               | 
      a h /----------------------------------------|-----------\ 
          \----------------------------------------|-----------/ 
                                   |               | 
      ---------------------------------------------|--------------- 
      S S                          |               | 
      e i                         \ /              | 
      r g                   +-----------+          | 
      v n                   |Bandwidth  |          | 
      i a                   |Broker     |          | 
      c l                   +-----------+          | 
      e i                                          | 
        n                                          | 
        g                                          | 
   
                  Figure 1: Architecture 
   

      Another application scenario is to use TDP to distribute price 
      information from a provider to its customers. In both scenarios 
      the instance that possesses the tariff information is called the 
      tariff sender and the instance that receives the tariff 
      information is called the tariff receiver. 
      A tariff can be set manually with the enterprise policy control 
      module (EPC). In a dynamically priced Internet tariff changes are 
      automated and then originate the price calculation module. This 
      module uses several data sources as input for it's decisions, for 
      example the CAS and the mediation module (which aggregates and 
      correlates data from the network infrastructure).  


        
      Heckmann et al  Experimental - Expires August 2002  Page 5 

        Tariff Distribution Protocol  March 2002 
         
   
       
      The tariff directory stores all tariffs and forwards them towards 
      the CAS and - if it exists - the bandwidth broker (BB). Note that 
      the CAS and the BB might be distributed systems consisting of a 
      number of boxes.  
      The customers can be end-users or other providers. They can be 
      informed about the tariffs via a push mechanism (tariff directory 
      sends tariffs and tariff updates) and/or a pull mechanism (end-
      system requests a certain tariff). If the customer is a provider, 
      it can use the pricing information as a further input source for 
      its own price calculation module. 
       
  4 The General Structure of TDP 
      TDP can be divided into two sublayers. The highest sublayer 
      (representation sublayer) describes the two basic message types 
      of TDP, the tariff and the tariff request message. XML is used as 
      representation format and to specify how tariffs and related 
      metainformation are encoded. A compact binary version of the 
      tariff message is also specified (see Figure 2). 
       
                  +--------------------------+ 
                  |    XML     |   Binary    | Representation 
                  |--------------------------+ 
                  | TCP | UDP | RSVP | HTTP  | Transfer 
                  +--------------------------+ 
       
                          Figure 2: TDP Layers 

   
      The transfer sublayer offers a variety of transfer mechanisms 
      that can be used to transport the messages. In this draft four 
      different transfer mechanisms are specified but TDP is open to 
      more transfer mechanisms. 
  5 Representation sublayer 
  5.1 Representation of Tariffs 
      Some current mobile phone tariffs show that tariffs can be very 
      complex. They can include special discounts (for example 10% 
      discount after the 10th minute) and often depend on the time of 
      the day and the day of the week (weekend...). It is unrealistic 
      to expect that all future multi-service Internet tariffs will fit 
      into a standardized scheme.  
      The protocol accounts for this with flexibility. It can include 
      any description of a tariff and it's parameters. It can use any 
      tariff definition language but also allows the use of other 
      programming languages, like Java, instead. As the distributed 
      tariffs should also be human-readable, a textual description of 
      the algorithm and the parameters can also be included as plain 
      text, HTML [10] and/or XML [11].  
      TDP also reflects the possibility that there might also be a 
      number of _standardized_ tariffs, that is tariffs where the 
      algorithm is known to all parties involved in the communication 

        
      Heckmann et al  Experimental - Expires August 2002  Page 6 

        Tariff Distribution Protocol  March 2002 
         
   
       
      and therefore no code has ever to be sent around but the 
      algorithm has to be identified in a globally unique way.  
       
  5.2 TDP Message Types and Interaction 
      The protocol uses two basic kinds of messages: the tariff message 
      that contains either a complete tariff (consisting of tariff 
      algorithm plus tariff parameters) or a tariff update (consisting 
      of new tariff parameters only) and the request message that is 
      used to request a certain tariff (see Figure 1).  
       
        +---------------+-----+ Request Message +-----+---------------+ 
        |               |     |<----------------|     |               | 
        | Tariff Sender | TDP | Tariff Message  | TDP |Tariff Receiver| 
        |               |     |---------------->|     |               | 
        +---------------+-----+                 +-----+---------------+ 
   
                          Figure 3: TDP Message Types 

       
      The protocol can be used in two different modes, the pull and the 
      push mode, both modes can also be combined (mixed mode). Sender 
      and receiver agree upon the mode used by means outside the 
      protocol. Tariff and request messages can be sent with different 
      transfer mechansisms (see section 6). 
       
      5.2.1 Push mode 
      In push mode only tariff messages are sent, the order and time 
      interval is completely up to the sender. No tariff request 
      messages are used. The user has to find out the tariffs by 
      listening to the stream of tariff messages. 
       
      5.2.2 Pull mode 
      In pull mode the tariff receiver requests a specific tariff or 
      the tariff for a specific service by sending a request message 
      that is answered by the tariff sender with a tariff message. A 
      single tariff message can answer more than one request. 
      Pull mode uses an asynchronous request/reply mechanism. A tariff 
      receiver can send any number of requests directly one after the 
      other while the answering tariff messages can be send in a 
      different order, with a different transport mechanism and with 
      different delays.  
       
      5.2.3 Mixed mode 
      The protocol can also be used in mixed mode which is equal to 
      pull mode but the tariff sender can also send tariff information 
      that was not requested. 
       




        
      Heckmann et al  Experimental - Expires August 2002  Page 7 

        Tariff Distribution Protocol  March 2002 
         
   
       
  5.3 Specification of the Tariff Message 
      TDP uses a XML message format to describe its messages, allowing 
      the reuse of existing code like XML parsers and validators, e.g. 
      Apache [11].  
      An example tariff message is included in the Appendix B. The XML 
      Schema [17] specification of a tariff message is also included in 
      the Appendix D. 
       
      5.3.1 Provider Tag 
      The provider is identified globally by using his domain name (2nd
      level domain) in the provider tag. There must be exactly one 
      provider tag in each tariff message identifying the provider 
      offering this tariff. 
      With the optional name tag one or more human readable names can 
      be included, this information should not be used instead of the 
      domain name above, it can be used by applications with user 
      interfaces. 
       
      5.3.2 Tariff Tag 
      Each tariff has one unique tariff ID. The ID must be unique only 
      inside the provider space, the provider is responsible for 
      managing the IDs. The tariff ID is not the same as the service ID 
      because one tariff could be used for more than one service and 
      the other way around. The ID can be any string up to a length of 
      255 bytes. 
      The tariff tag must include exactly one ID tag and can also 
      include any number of optional name tags with human readable 
      information that must not be relied on to identify the tariff 
      uniquely. 
      Each tariff message must include exactly one tariff tag. 
       
      5.3.3 Service Tag 
      Each service the provider offers has one unique service ID. The 
      ID must be unique only inside the provider space, the provider is 
      responsible for managing the IDs. The ID can be any string up to 
      a length of 255 bytes. 
      The service tag must include exactly one ID tag and can also 
      include any number of optional name tags with human readable 
      information that must not be relied on to identify the service 
      uniquely. 
      Each tariff message must include one or more service tags. If 
      more than one service tags are included the tariff described by 
      the message must be able to calculate charge advices for all the 
      listed services. 
       
      5.3.4 Algorithm Tag 
      The algorithm tag describes the tariff algorithm. Each tariff 
      message includes zero or one algorithm tags. If no algorithm tag 
      is included, then the information in the message is usable only 
      by senders that know the algorithm by other means (because the 
      algorithm is standardized and known by everyone or because the 
        
      Heckmann et al  Experimental - Expires August 2002  Page 8 

        Tariff Distribution Protocol  March 2002 
         
   
       
      algorithm was sent before and has not changed yet). This is 
      called a tariff update. 
      The algorithm tag includes exactly one version tag that contains 
      a version number (integer). It can contain any number of valid 
      tags that describe the time intervals in which the tariff is 
      valid.  
      The algorithm tag contains any number of description tags that 
      describe the algorithm. The description tag has two attributes: 
      content and referenced. The default value for content is 
      _text/plain_ and for referenced is _true_.  
      The description tag includes the algorithm itself in a form that 
      is specified by the content attribute. The content attribute uses 
      MIME-Types [20] [21]. If the referenced attribute is set to _true_ 
      then the content of the description tag is a url that points to a 
      remote document with the algorithm description. If referenced is 
      set to _false_ then the algorithm description is included 
      directly in the description tag body. 
      The algorithm description is now specified for several content 
      types, the protocol is open for more content types. 
       
      5.3.4.1 Algorithm Description for content-type _text/plain_ 
      The algorithm description is included in a _text_ tag. At least 
      one text tag has to be included, but more than one is possible. 
      Every text tag must include the complete algorithm description, 
      the content of the text tags - which can differ in the language 
      used, etc. The attributes of the text tag are not further 
      specified in this version of the draft. 
      The content of the text tag must be plain text as specified in 
      [20] [21]. 
       
      5.3.4.2 Algorithm Description for content-type _text/html_ 
      The algorithm description is included in a _html_ tag. At least 
      one html tag has to be included, but more than one is possible. 
      Every html tag must include the complete algorithm description, 
      the content of the html tags _ which can differ in the language 
      used, html version used, etc. The attributes of the html tag are 
      not further specified in this version of the draft. 
      The content of the html tag must be HTML as specified in [10]. 
       
      5.3.4.3 Algorithm Description for content-type _text/xml_ 
      The algorithm description is included in a _xml_ tag. At least 
      one xml tag has to be included, but more than one is possible. 
      Every xml tag must include the complete algorithm description, 
      the content of the xml tags - which can differ in the language 
      used, xml version used, etc. The attributes of the xml tag are 
      not further specified in this version of the draft. 
      The content of the xml tag must be XML as specified in [18]. 
       
      5.3.4.4 Algorithm Description for content-type _binary/java_ 
      The algorithm description consists of any number of class tags, 
      each  including one java class needed for the tariff algorithm. 
        
      Heckmann et al  Experimental - Expires August 2002  Page 9 

        Tariff Distribution Protocol  March 2002 
         
   
       
      Alternatively one jar (Java archive) tag can be used that 
      contains a number of classes. The body of the description must 
      include the name of the classes included that is the tariff 
      algorithm and that will be executed. 
      Each class tag has an obligatory name attribute that describes 
      the name of the java class that is included. The attribute 
      encoding describes how the class is encoded, for which the 
      default value is _base64_ [20]. The optional compression 
      attribute can be used to describe the compression algorithm used 
      to compress the class before it was encoded with the method 
      specified by the encoding attribute. The default is to use no 
      compression, the default value for the compression attribute is 
      therefore _NO_. 
       
      5.3.5 Parameters Tag 
      The parameters tag includes the tariff parameters and related 
      metainformation. 
      The parameters tag must include exactly one version tag, the same 
      rules as for the version tag, part of the algorithm tag, apply. 
      The parameters tag can also include any number of valid tags, the 
      same rules as for the valid tag, part of the algorithm tag, 
      apply. 
      The parameters tag includes any number of description tags, at 
      least one description tag must be included. The description tags 
      have a content attribute with the default value _text/plain_ and 
      a referenced attribute with the default value _true_.  
      The description tag includes the tariff parameters in a form that 
      is specified by the content attribute. The content attribute uses 
      MIME-Types [20] [21]. If the referenced attribute is set to _true_, 
      then the content of the description tag is a url that points to a 
      remote document with the tariff parameters description. If 
      referenced is set to _false_ then the tariff parameters 
      description is included directly in the description tag body. 
      The tariff parameters description is now specified for several 
      content types, the protocol is open for more content types. 
       
      5.3.5.1 Parameters Description for content-type _text/plain_ 
      The tariff parameters description is included in a _text_ tag. At 
      least one text tag has to be included, but more than one is 
      possible. Every text tag must include the complete parameters 
      description, the content of the text tags _ which can differ in 
      the language used, etc. The attributes of the text tag are not 
      further specified in this version of the draft. The content of 
      the text tag must be plain text as specified in [20] [21]. 
       
      5.3.5.2 Parameters Description for content-type _binary_ 
      The tariff parameters description is included in a _binary_ tag. 
      At least one binary tag has to be included, but more than one is 
      possible. Every binary tag must include the complete parameters, 
      the content of the binary tags _ which can differ in the encoding 
      used, etc. Each binary tag has an encoding attribute that 
        
      Heckmann et al  Experimental - Expires August 2002  Page 10 

        Tariff Distribution Protocol  March 2002 
         
   
       
      describes the way the binary information is encoded in the xml 
      message. The default value is _base64_ [20]. 
      The content of the binary tag is a byte array that can be read by 
      the algorithm code. The specification of this byte array is done 
      by the author of the tariff algorithm. 
       
      5.3.6 Reference Tag 
      If a tariff message is a direct answer to a request message it 
      references this request message with one reference tag. Any 
      number of reference tags can be included in a tariff message. The 
      reference tag must include two tags, the sender tag that contains 
      the IP address of the originator of the request message and the 
      num tag that contains an integer that identifies the request 
      message (as there might be more than one request messages from 
      one IP address). The content from the reference tag must be 
      exactly identical to the content of the reference tag in the 
      according request message. 
       
  5.4 Request Message 
      The second message type is the request message. It allows 
      requesting either a special tariff or - in case that tariff 
      receivers do not yet know, what tariff they are interested in - 
      allows requesting tariffs for one service. Service discovery is 
      outside the scope of TDP. 
      The XML Schema specification for the request message and an 
      example are in the Appendix D. 
       
      5.4.1 Reference Tag 
      There must be exactly one reference tag in a request message. The 
      reference tag identifies the request message and is repeated in 
      the tariff message that answers this request message. The 
      reference tag must include two tags, the sender tag that contains 
      the IP address of the originator of the request message and the 
      num tag that contains an integer that identifies the request 
      message (as there might be more than one request messages from 
      one IP address). 
       
      5.4.2 Request Tag 
      There must be exactly one request tag in a request message. It 
      specifies either the tariff that is requested or the service for 
      which a tariff is requested. It includes either one tariff or one 
      service tag. The tariff and the service tag include one further 
      tag which can be an ID tag or a name tag. In the ID tag the 
      tariff or service ID is entered and in the name tag the human 
      readable name would be entered (see 5.3.2 and 5.3.3). 
   
  6 Transfer Sublayer 
      Different transfer mechanisms can be used to send the messages of 
      the representation sublayer (see section 5). Which ones are used 
      by actual instances of the protocol are decided upon by means 
      outside of the protocol (e.g. by an SLA). 
        
      Heckmann et al  Experimental - Expires August 2002  Page 11 

        Tariff Distribution Protocol  March 2002 
         
   
       
       
  6.1 TCP 
      Plain TCP connections offer a minimalistic reliable transport 
      mechanism for the TDP messages.  
      A small header is added to the tariff and request message: 
       
                            0                   1            
                            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                           |          Length Field         | 
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                           |                               | 
                           |            Payload            | 
                           |                               | 
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                          Figure 4: PDU for TCP transport 

       
      The Payload consists of exactly one tariff or request message. 
      The length field describes the number of bytes in the payload.  
       
  6.2 UDP multicast 
      In case UDP multicast is used the PDU takes the following format: 
       
       0                   1                   2                   3    
       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  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             ID                | Segm. Number  | Total Segments|       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      //                  Payload (or part thereof)                   | 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
  Figure 5: PDU for UDP transport 

       
      The Payload consists of the tariff or request message. The sender 
      can divide the message into segments. This is necessary if the 
      message is bigger than the maximum allowed message size of UDP 
      [19] but the sender is free to fragment a message also for 
      smaller message sizes. All segments get the same ID, they get a 
      sequential segment number starting with 0. The _total segments_ 
      field in the header is set to the total number of segments for 
      that message (so a minimum of one is entered here). 
      The sender has to make sure that two different tariff messages 
      get two different IDs. An ID number can be reused after a timeout 
      period of 2 times the maximum segment lifetime of TCP. 
       

        
      Heckmann et al  Experimental - Expires August 2002  Page 12 

        Tariff Distribution Protocol  March 2002 
         
   
       
  6.3 HTTP 
      The TDP request messages are sent as an HTTP [10] request message 
      and the TDP tariff messages are sent as HTTP response messages. 
      The message body carries the TDP request or the tariff message.  
       
  6.4 RSVP Policy Objects 
       
       
             +-------------+-------------+-------------+-------------+ 
             |  Length                   | POLICY_DATA |      1      | 
             +---------------------------+-------------+-------------+ 
             |  Data Offset              | 0 (reserved)              | 
             +---------------------------+-------------+-------------+ 
             |                                                       | 
             // Option List                                         // 
             |                                                       | 
             +-------------------------------------------------------+ 
             |                                                       | 
             // Policy Element List                                 // 
             |                                                       | 
             +-------------------------------------------------------+ 
       
                      Figure 6: RSVP POLICY_DATA object 

       
       
             +-------------+-------------+-------------+-------------+ 
             |  Length                   |   P-Type                  | 
             +---------------------------+---------------------------+ 
             |                                                       | 
             // Policy information  (Opaque to RSVP)                // 
             |                                                       | 
             +-------------------------------------------------------+ 
       
                          Figure 7: Policy Element 

       
       0                   1                   2                   3    
       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  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |             ID                | Segm. Number  | Total Segments|       
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                                                               | 
      //               TDP Message (or part thereof)                 // 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                          Figure 8: Policy Information 

   

        
      Heckmann et al  Experimental - Expires August 2002  Page 13 

        Tariff Distribution Protocol  March 2002 
         
   
       
      The POLICY_DATA object as specified in [8] is listed in Figure 6. 
      The TDP Message is embedded as policy information (Figure 7) in a 
      policy element (Figure 8) as part of the policy element list of 
      the RSVP POLICY DATA object. 
      The Payload of the policy information consists of the tariff or 
      request message. The sender can divide the message into segments. 
      This is necessary if the message is bigger than the maximum 
      allowed message size for policy information [8] but the sender is 
      free to fragment a message also for smaller message sizes. All 
      segments get the same ID, they get a sequential segment number 
      starting with 0. The _total segments_ field in the header is set 
      to the total number of segments for that message (so a minimum of 
      one is entered here). 
      The sender has to make sure that two different tariff messages 
      get two different IDs. An ID number can be reused after a timeout 
      period of 2 times the maximum segment lifetime of TCP. 
       
  7 Related Work 
      We now describe two other related protocols and compare them with 
      the Tariff Distribution Protocol presented in this paper. 
       
  7.1 Open Settlement Protocol 
      The Open Settlement Protocol (OSP, [13]) is an ETSI TIPHON 
      specification that describes a set of protocols to permit the 
      exchange of inter-domain pricing, authorization and settlement 
      information between Internet telephony operators. The pricing 
      part overlaps with the Tariff Distribution Protocol presented in 
      this paper, yet, there are a lot of differences. 
      Both protocols are XML-based and both allow a binary format. 
      While OSP uses HTTP only as underlying protocol, the Tariff 
      Distribution Protocol allows different transport mechanisms.  
      OSP can be used to exchange prices (OSP terminology) - expressed 
      in the terminology of this work, OSP is restricted to very simple 
      tariffs with one price coefficient (like the per-minute prices 
      for phone calls). As OSP is more intended as settlement protocol 
      between providers, it offers an explicit mechanism to accept or 
      decline prices (pricing confirmation). It offers no mechanism to 
      request a special tariff or a tariff for a given service. 
      Summarizing, OSP offers broader capabilities but is far less 
      powerful in the area of price communication and it is specialized 
      for the IP telephony use case. 
       
  7.2 Internet Open Trading Protocol 
      The IETF Internet Open Trading Protocol (IOTP) specification [14] 
      describes a framework for payment protocols and uses XML over 
      HTTP. This work is complementary to the Tariff Distribution 
      Protocol as it is mostly concerned with the settlement, while the 
      Tariff Distribution Protocol determines how the individual 
      charges the bill consists of are calculated. 
   

        
      Heckmann et al  Experimental - Expires August 2002  Page 14 

        Tariff Distribution Protocol  March 2002 
         
   
       
  References:

  [1]  M3I Project, http://www.m3i.org/. 

  [2]  Braden R., Clark D., Shenker S., "Integrated Services in the 
  Internet Architecture: an Overview", RFC 1633, June 1994. 

  [3]  Partridge, C. and  R. Guerin, "Specification of Guaranteed 
  Quality of Service", RFC 2212, September 1997. 

  [4]  S. Blake, D. L. Black, M. A. Carlson, E. Davies, Z. Wang, and W. 
  Experimental RFC, December 1998.  Weiss, "RFC 2475 - An Architecture 
  for Differentiated Services".

  [5]  J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, "RFC 2597 - 
  Assured Forwarding PHB Group". Request for Comments, June 1999. 

  [6]  Encyclopaedia Britannica, http://www.britannica.com/. 

  [7]  Merriam Webster, http://www.m-w.com/. 

  [8]  S. Herzog, "RFC 2750 - RSVP Extensions for Policy Control",
  Standards Track, January 2000.                                  

  [9]  R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. RFC 
  2205 - Resource ReSerVation Protocol (RSVP) _ version 1 functional 
  specification. Standards Track RFC, September 1997. 

  [10] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 
  "RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1", Standards 
  Track, January 1997.

  [11] Apache XML Project, Apache Organisation, http://xml.apache.org/. 

  [12] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah 
  Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, Dave Winer, 
  "Simple Object Access Protocol (SOAP) 1.1", W3C Note 08, May 2000. 

  [13] European Telecommunications Standards Institute (ETSI), 

  "Telecommunications and Internet Protocol Harmonization Over Networks 
  (TIPHON); Open Settlement Protocol (OSP) for Inter-Domain pricing, 
  authorization, and usage exchange", ETSI TS 101 321 V2.1.1, August 
  2000

  [14] Burdett, D., "Internet Open Trading Protocol - IOTP Version  
  1.0", RFC 2801, April 2000.



        
      Heckmann et al  Experimental - Expires August 2002  Page 15 

        Tariff Distribution Protocol  March 2002 
         
   
       
  [15] X. Wang and H. Schulzrinne, "RNAP: A resource negotiation and 
  pricing protocol", In International Workshop on Network and Operating 
  Systems Support for Digital Audio and Video (NOSSDAV'99), pages 77-- 
  93, Basking Ridge, New Jersey, June 1999.

  [16] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding 
  PHB", RFC 2598, June 1999. 

  [17] David C. Fallside, " XML Schema Part 0: Primer", W3C 
  Recommendation, 2 May 2001 

  [18] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 
  "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 
  Recommendation 6, October 2000

  [19] J. Postel, "User Datagram Protocol", RFC 768, August 1980 

  [20] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail 
  Extensions) Part One: Format of Internet Message Bodies", RFC 2045, 
  November 1996

  [21] N. Freed, N. Borenstein, "MIME (Multipurpose Internet Mail 
  Extensions) Part Two: Media Types", RFC 2046, November 1996 

  [22] Oliver Heckmann, Vasilios Darlagiannis, Martin Karsten, and 
  Ralf Steinmetz. A Price Communication Protocol for a Multi-Service 
  Internet. In Informatik 2001 - Wirtschaft und Wissenschaft in der 
  Network Economy - Visionen und Wirklichkeit (GI/OCG 2001), September 
  2001.
   
  Appendix A. Example Tariff components 
      Session characterization parameters: t, u 
      Tariff parameters:   a, b, c 
      Tariff algorithm:        
      Price coefficient of t:        
      Price coefficient of u:  
       
  Appendix B. Tariff example 
      Session characterization parameters: t, u 
      Tariff parameters:                   a, b, c 
      Tariff algorithm:                   CA(t, u)= a * t + b * u^c 
      Price coefficient of t:             d/dt(CA(t, u)) = a 
      Price coefficient of u:             d/du(CA(t, u)) = b * c * 
      u^(c-1) 
       
       
  Appendix C. Example of tariff message 
       
       
        
      Heckmann et al  Experimental - Expires August 2002  Page 16 

        Tariff Distribution Protocol  March 2002 
         
   
      
      <?xml version="1.0" encoding="UTF-8" ?>
      <tariffMessage>
        <provider>
          bt.com
          <name> British Telecom </name>
        <authentication> ... </authentication> 
      </provider> 
       
      <tariff> 
            <ID> 131 </ID> 
      </tariff> 
       
      <service> 
          <ID> 40 </ID> 
          <name> IntServ GS <name> 
      </service> 
       
      <algorithm> 
          <version> 3 </version> 
          <valid> 
              <from> <date> 20.01.00 </date>  
                   <time zone=_MEZ_> 00:00 </time> 
           </from> 
          </valid> 
       
          <description content="binary/java"  
                     referenced="false"> 
              <class name="com.bt.intserv.gs.t3"            
      encoding="base64_ 
                 compression="ZIP"> 
                  ... 
              </class> 
            ... 
          </description> 
        <description content="text/plain"  
                     referenced="false"> 
              <text> 
              ... 
              </text> 
          </description> 
       
      </algorithm> 
       
       
      <parameters> 
          <version> 305 </version> 
          <valid> 
              <from>  20000</from> 
          </valid> 
       
          <description content="binary"  
                     referenced="false"> 
        
      Heckmann et al  Experimental - Expires August 2002  Page 17 

        Tariff Distribution Protocol  March 2002 
         
   
      
            ...
          </description>
          <description content="text/plain" 
                     referenced="true"> 
                http://www.bt.com/... 
          </description> 
      </parameters> 
       
      <reference> 
          <sender> 162.154.20.41 </sender> 
          <num> 12 </num> 
      </reference> 
       
      <authentication> ... </authentication> 
       
      </tariffMessage> 
    
Appendix D. Definition of TariffMessage using XML Schema 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   elementFormDefault="qualified" attributeFormDefault="unqualified"> 
     <xs:element name="tariffMessage"> 
       <xs:annotation> 
         <xs:documentation>This is the root element of the 
   schema</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="provider"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element ref="ID"/> 
                 <xs:element name="ProviderName" type="xs:string" 
   maxOccurs="unbounded"/> 
                 <xs:element name="authentication"/> 
               </xs:sequence> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="tariff"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element ref="ID"/> 
               </xs:sequence> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="service" minOccurs="0" 
   maxOccurs="unbounded"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element ref="ID"/> 
                 <xs:element name="serviceName" type="xs:string" 
        
      Heckmann et al  Experimental - Expires August 2002  Page 18 

     Tariff Distribution Protocol  March 2002 
      

 
   maxOccurs="unbounded"/>
               </xs:sequence> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="Algorithm" minOccurs="0"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="version" type="xs:integer"/> 
                 <xs:element name="valid"> 
                   <xs:complexType> 
                     <xs:sequence> 
                       <xs:element name="date" type="xs:date"/> 
                       <xs:element name="timeZone"/> 
                     </xs:sequence> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="description" maxOccurs="unbounded"> 
                   <xs:complexType> 
                     <xs:choice> 
                       <xs:element name="code"/> 
                       <xs:element name="text"/> 
                     </xs:choice> 
                   </xs:complexType> 
                 </xs:element> 
               </xs:sequence> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="parameters"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="version" type="xs:integer"/> 
                 <xs:element name="valid"> 
                   <xs:complexType> 
                     <xs:sequence> 
                       <xs:element name="date" type="xs:date"/> 
                       <xs:element name="timeZone"/> 
                     </xs:sequence> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="description" maxOccurs="unbounded"/> 
               </xs:sequence> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="reference" minOccurs="0" 
   maxOccurs="unbounded"> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="senderIP"/> 
                 <xs:element name="num" type="xs:integer"/> 
               </xs:sequence> 
             </xs:complexType> 
     
   Heckmann et al  Experimental - Expires August 2002  Page 19 

     Tariff Distribution Protocol  March 2002 
      
 
    
           </xs:element>
         </xs:sequence>
       </xs:complexType> 
     </xs:element> 
     <xs:element name="ID" type="xs:string"> 
       <xs:annotation> 
         <xs:documentation>Global ID</xs:documentation> 
       </xs:annotation> 
     </xs:element> 
   </xs:schema> 
    
    
Author's Addresses 
    
   Oliver Hechmann 
   Vasilios Darlagiannis 
   Martin Karsten 
   Ralf Steimetz 
   KOM, TU-Darmstadt 
   Merch str. 9                 Phone:  +49-6151-166150 
   Darmstadt, Germany           Email:  heckmann@kom.tu-darmstadt.de 
    
   Bob Briscoe 
   B54/74, BT Labs 
   Martlesham Heath  
   Ipswich, IP5 3RE             Phone:  +44 1473 645196 
   England                      Email:  bob.briscoe@bt.com 
    
   Full Copyright Statement 
    
   Copyright (C) The Internet Society (2002). All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
     
   Heckmann et al  Experimental - Expires August 2002  Page 20 

     Tariff Distribution Protocol  March 2002 
      
 
    
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

















































   Heckmann et al  Experimental - Expires August 2002  Page 21