Internet DRAFT - draft-aleksandrov-ip-supplement

draft-aleksandrov-ip-supplement





Over-GROUND Ltd.                                          D. Aleksandrov
Internet Draft: IP Supplement for a Real Time Service          July 2004
Document: draft-aleksandrov-ip-supplement-01.txt


       Internet Protocol (IP) Supplement for a Real Time Service


Status of this Memo

   This document is an Internet-Draft and is subject to 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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

   This document expires 12 January 2005.

Abstract

   The Real Time Network Service (RTNS) is a process of data transfer 
   (with real time characteristics) between two end systems. It is part 
   of the OSI model of the Network layer. It is not a separate protocol, 
   but rather an additional service, of which applications, exchanging 
   data in real time, can take advantage. In the current document this 
   service is defined as an option of the Internet Protocol.

Table of Contents

   1. Real Time Network Service Fundaments  . . . . . . . . . . . . .  2
   2. Packet Identification . . . . . . . . . . . . . . . . . . . . .  3
   3. Hop-by-hop Treatment of Packets Requiring RTNS  . . . . . . . .  5
      3.1. Virtual Queues . . . . . . . . . . . . . . . . . . . . . .  5
      3.2. Virtual Queuing Rules  . . . . . . . . . . . . . . . . . .  6
      3.3. Degree of the Return Connection at the 
           Destruction of an RTNS Packet. . . . . . . . . . . . . . .  6
      3.4. Function of the Transporting Module  . . . . . . . . . . .  7
      3.5. Results of the Function of the Transporting Module . . . . 10
      3.6. Common Qualities with RTP from the Standpoint 
           of the Needed Results  . . . . . . . . . . . . . . . . . . 11

D. Aleksandrov                                                  [Page 1]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   4. Requirements to Upper Layer Applications for RTNS Usage . . . . 11
   5. RTNS Format in IP . . . . . . . . . . . . . . . . . . . . . . . 13 
      5.1 Option for RTNS in IPv4 . . . . . . . . . . . . . . . . . . 14
      5.2 Option for RTNS in IPv6 . . . . . . . . . . . . . . . . . . 15
   6. Interaction of RTNS-identifying and Non-identifying hosts . . . 16
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
   8. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
   9. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   10. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
   Appendix 1
   An Example of the Implementation of RTNS in IP . . . . . . . . . . 19

1. Real Time Network Service Fundaments

   Fundamentally, RTNS is the sending of a tagged stream of data, in 
   which the data packets are characterized by varying delivery 
   priorities. Each packet's delivery priority is recorded within the 
   data body and is connected with the time of its generation as well as 
   its importance for the interpretation of the information being sent. 
   The treatment of packets is governed by the set priority index and is 
   executed hop-by-hop in the process of transportation. It is based on 
   a queuing algorithm and follows the same rules, which apply to both 
   sending and receiving end systems, as well as the transporting 
   network nodes. Priority rules affect only packets from the same 
   sequence. When two packets from the same stream enter simultaneously 
   into a certain network node (it matters little whether this is the 
   router, gateway, sender or receiver) its IP module can make a 
   decision to:

   - change their order in the queuing sequence for sending;

   - eliminate one of them (in some instances this can be followed by 
   its replacement with the other one in the queuing sequence);

   - not take any further action.

   The assigned priority can not lead to the displacement or elimination 
   of a packet from a different sequence. This algorithm has no relation 
   to the reserving of resources and does not take advantage of the said 
   process, but there is no reason why it cannot be executed 
   simultaneously with such types of transport algorithms. Both unicast 
   and multicast traffic is treated in the same way. 

   RTNS leads to unreliable delivery of a sequence of packets via 
   individual routes from a sender-host to a single receiver-host or a 
   multitude of receiver-hosts. The difference from the traditional IP 
   traffic is in the presence of an algorithm for the identification and 
   elimination of data non-relevant to the current sequence. The real 
   time of the information reaching the receiver(s) is more important 
   than its end volume. The protocol, feeding data to the IP module and 
   requiring RTNS, should not have the following expectations:

   - that sender - receiver sessions should be initiated;


D. Aleksandrov                                                  [Page 2]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   - that confirmation of data delivery should be required;

   - that delivery should be guaranteed. 
 
   Chapter 1 of the present document describes the method of 
   identification of RTNS in the packets. Chapter 2 concentrates on the 
   rules for the treatment of packets, depending on the assigned 
   priority. These rules are applied hop-by-hop in the process of packet 
   transportation. Chapter 3 contains the principles which upper-layer 
   applications utilize in order to take advantage of the type of 
   service defined. Chapter 4 suggests a proper format for the 
   designation of the service in IPv4 and IPv6. Chapter 5 examines the 
   compatibility of the RTNS - identifying and non-identifying hosts. 
   Appendix 1 gives short but not exhaustive examples of the use of this 
   service. 

2. Packet Identification  

   RTNS, as described in the present document, is based on the 
   assumption that the information being transferred has been digitally 
   coded as a sequence of data blocks with supplementing levels of 
   importance.  

   Let us consider the case when the data containing the whole 
   information about a fixed time interval is coded in k supplementing 
   levels. If the receiver disposes of all k blocks, the transmitted 
   information will be received in full. Because of the fact that the 
   data in layers 1 to k is supplementing, if the blocks from 1 to n are 
   received (where n can have any value from 1 to k), the data can still 
   be interpreted but with a different quality. 

   The data should be encoded in such a manner that the following 
   correlation is valid: 

           Layer            Quality
          -------           -------
          Layer 1           Very low
          Layer 2           Low
          ...........................
          Layer k           Maximum

   The methods of proper information encoding are entirely beyond the 
   scope of this document. 

   When the data is in real time, the cascade encoding is done 
   separately for each of the consequent time intervals in which the 
   transmission is divided. 

   The bounds of the supplementing layers of encoding are a matter of 
   communication between the sending and receiving applications. Neither 
   the rules of this communication, nor the ways for the initiation and 
   discontinuation of the transmission are discussed in the present 
   document. It is taken for granted that applications have their ways 
   to initiate the transmission of data as well as to signal the usage 

D. Aleksandrov                                                  [Page 3]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   of certain encoding techniques and the end of the transmission. 

   The packets, sent within a certain time interval, are given numbers 
   from 1 to m, where m is the maximum number of packets expected under 
   the used algorithm for encoding. The correlation between the 
   numeration of the packets within the limits of a certain time 
   interval and the encoding layers is given below: 

          Layer               Layer number
         -------           ----------------
          Layer 1           1       to  m[1]
          Layer 2           m[1]+1  to  m[2]
         ..................................
          Layer k           m[k-1]+1  to  m

   These numbers will be referred to as "internal". 

   It should be noted that both: tags signifying the sequence within the 
   time interval and the order of the time intervals should be present. 
   The order is given by means of a number changing in a pattern of 
   cycling recurrence from 1 to q. It will be referred to as "number of 
   the time interval" or just "time interval". The time for the 
   completion of the whole cycle should be longer than the maximum 
   period for which the packet can be present in the network. Otherwise, 
   there is always the risk of having two packets with the same internal 
   and time interval numbers and no clear chronology. 

   The assignment of two numbers in the packets sent leads to a sequence 
   indexed in the following manner:  

   (1, 1), (1, 2), ......(1, m), (2, 1), (2, 2)..........(2, m), (3, 1) 
   ............. (q-1, m), (q, 1), (q, 2) ........(q, m), (1, 1)......

   The sender should be properly identified. This is achieved by means 
   of a combination of two values: the address of the sender and a flow 
   label. The sender must choose a locally unique identifier for each 
   data flow. In case of a restoration from a crash, it must be able to 
   assign such identifiers to the flows so that confusion is avoided.  

   All in all, the packets which require RTNS have three different 
   numbers:

   - Flow Identifier - in combination with the sender's address it 
   distinguishes between the different packet sequences;

   - Time Interval Identifier  - value from 1 to q with cyclic 
   recurrence;

   - Number of the packet within the time interval (internal number) - 
   takes consequent  values from 1 to m for each value of q.

   It should not be expected that the sender will generate packets with 
   all the values of m and q. If the encoding algorithm allows that, 
   part of them can be occasionally skipped (provided that this would 

D. Aleksandrov                                                  [Page 4]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   decrease the quantity of outgoing data without leading to information 
   getting lost). To avoid confusion, however, the application sending 
   the data must inform the transporting module of the sender about the 
   quantity of skipped numbers within an assigned time interval as well 
   as the quantity of skipped time intervals. 

3. Hop-by-hop Treatment of Packets Requiring RTNS 

   On each hop-by-hop stage of the transportation, the packets with 
   assigned RTNS are treated in accordance with the rules set forward in 
   this chapter. We do not consider the case when the routing host 
   cannot properly identify the type of service required. This case is 
   discussed in Chapter 6. 

   The transporting algorithm is based on the separation of the packets, 
   which have asked for the specific service in the virtual queues, and 
   a number of particular rules for their ordering.  

3.1 Virtual Queues 

   Each packet belonging to the combination sender - flow label (SFL) is 
   added to the virtual queue, in which the same combination is valid 
   for all packets. 

   Within the network module there are as many virtual queues as there 
   are different SFL combinations of packets requiring RTNS, waiting to 
   be transferred. A virtual queue is initiated when an RTNS packet is 
   received, which cannot be added to any of the existing ones, and the 
   queue is not terminated as long as there is at least one packet left 
   in it. 

   The virtual queue does not have an outgoing interface. When a request
   from a random interface is received the queue sends forward the 
   packet located at its exit. 

   The virtual queue treats its packets following a set of specific 
   rules. The latter are described in section 2.2. 

   Because of the fact, that the virtual queues are not related to a 
   particular interface, the requests for the delivery of one of their 
   packets are executed with the assistance of indicators.

   When a packet requesting RTNS is received by the IP module for 
   resending, it chooses the most suitable interface to whose queue the 
   packet should be added for resending. RTNS does not change the rules 
   for the selection of the most suitable interface. The difference with 
   the ordinary packets is that instead of the packet itself an 
   indicator is added to the outgoing queue of SFL packets. In the 
   present document the term "interface" should be understood in its 
   broadest sense. It can signify both: the connection to another host, 
   as well as the connection to an application from an upper layer 
   receiver.    

   When an indicator from a virtual queue reaches the exit of a real 

D. Aleksandrov                                                  [Page 5]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   queue the transporting module sends forward the packet which is 
   located at the exit of the SFL queue corresponding to the value of 
   the indicator. In section 2.2. is explained that it is possible for 
   an indicator to reach the end of a real queue at the moment of time 
   when  a corresponding virtual queue does no longer exists. In this 
   case the transporting module simply ignores the indicator and 
   continues with the treatment of the packets and indicators, which 
   come after it.  
 
3.2. Virtual Queuing Rules 

      Rule 1) Each packet is added to the corresponding queue only if 
   there is no other packet in it with indexes (time interval, internal 
   number) showing that it has been generated more than one time 
   interval later than the first one.  

   When, as a follow up to this rule, a packet cannot be added to its 
   corresponding queue, it is destroyed but no ICMP or other message to 
   the sender is generated.  

      Rule 2) Each added packet leads to the dropping from its virtual 
   queue of every packet whose indexes (time interval, internal number) 
   show that it has been generated more than one time interval later 
   than the one in question. 

   When, as a follow up to this rule, a packet is destroyed, no ICMP or 
   other message to the sender is generated.  

      Rule 3) With each new addition of a packet to a virtual queue it 
   is reordered according to the chronology of the indexes (time 
   interval, internal number). The oldest of the packets is always 
   located as the nearest one to its exit. The order of the fragment 
   from the same datagram in relation to each other is in accordance 
   with the chronology of their generation. 

   The three rules for the treatment of virtual queues are not equally 
   important. The first one is always executed. Once the packet has been 
   added, the second rule is checked and after its execution (with or 
   without the destruction of packets), the third one takes effect. 

3.3. Degree of the Return Connection at the Destruction of an RTNS Packet  


   Rules 1 and 2 presuppose that no ICMP messages will be sent after the 
   destruction of a packet. This does not mean that such a message 
   cannot be sent when it concerns an RTNS packet. When such a packet is 
   not part of a virtual queue it obeys all rules pertinent to any other 
   packet (rules for the generation of ICMP messages are also included). 
   For example, if it proves not possible to choose a proper interface 
   (there is no delivery route), the decision for the generation of an 
   ICMP message is taken as it would have been for any other packet. 

   The rule that no message should be sent after the destruction of a 
   packet (part of a virtual queue) is introduced with the clear notion 

D. Aleksandrov                                                  [Page 6]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   that it will probably be modified later on. When an unicast traffic 
   is present, it is comprehendible that the IP module should require 
   information concerning data loss in the process of transferal, 
   especially when a fixed route option is activated - LSRR (IPv4 
   [RFC791]) or routing header (IPv6 [RFC2460]). 

   The destruction of a packet in a virtual queue is a sign of network 
   congestion - apparently not all packets can be transferred in time. 
   Therefore, the sending of an ICMP message for each destroyed packet 
   is unjustified because it further congests the already congested 
   network. 

   If in a future modification of RTNS such notification is introduced, 
   it is conceivable that single messages, signifying a multitude of 
   destructed packets, will be used. For example, after one hundred 
   received (for transportation) packets from the same data flow, a 
   single message can be sent for the loss of packets (if any), 
   containing their number and indexes (flow, time interval, internal
   number) with the newest packet. This will allow the sender's IP
   module to maintain a continually updated map of the network locations
   where losses occur.  

   It is possible to define and use messages containing information 
   about data loss not only after a certain number of packets but also 
   after a certain period of time or a certain number of time intervals. 

   Because the optimum variant for a return connection is not clear to 
   the author himself, the usage of ICMP for the treatment of virtual 
   queues is forbidden. But a certain field, subject to a future 
   definition, is taken into consideration, so that the required type of 
   messages concerning data loss is presupposed (see Chapter 4). In this 
   way the sender can control whether to receive return information 
   about data loss. If he chooses to be informed he will have at his 
   disposal the freedom to define and use different types of ICMP 
   messages for the RTNS packets.  

3.4. Function of the Transporting Module 

   In algorithmic code, the appearance of a new packet in the host's 
   transporting module (with RTNS identification capabilities) is 
   represented as follows:














D. Aleksandrov                                                  [Page 7]

Internet Draft     IP Supplement for a Real Time Service       July 2004

	
   Interface = Choose_the_most_appr_interface (newly_arrived_packet);
   if (Packet_with_RTNS (Newly_arrived_packet)) {
    SFL = Specify_SFL (Newly_arrived_packet);
     if (! Existing_virtual_queue (SFL))
       Create_virtual_queue (SFL);
     if (Rule_1 (SFL, Newly_arrived_packet)) {
       Add_packet_to_virtual_queue (SFL, Newly_arrived_packet);
       Add_indicator_to_outgoing_queue (SFL, Interface);
       if (Rule_2 (SFL, Newly_arrived_packet))
         Drop_out-of-date_packets (SFL, Newly_arrived_packet);
       else
         Do_Nothing;
       Sort_virtual_queue (SFL);
     } else 
       Do_Nothing;
   } else
     Add_packet_to_outgoing_queue (Newly_arrived_packet, Interface);

   The instance, when an element reaches the end of the outgoing queue 
   from a specific interface, is represented as follows:

   if (Packet_for_sending (Element_at_the_exit)) 
     Transfer_packet (Element_at_the_exit);
   else {
     SFL = Specify_ SFL (Element_at_the_exit);
     if (Existing_virtual_queue (SFL)) {
       Packet_with_RTNS = Take_outgoing_packet (SFL);
       if (Number_of_packets (SFL))
         Do_Nothing;
       else
         Destroy_virtual_queue (SFL);
       Transfer_packet (packet_with_RTNS); 
     } else
       Do_Nothing;
   }

   The functions used accomplish the following:

     Choose_the_most_appr_interface (Argument: IP packet) - chooses and 
   returns an identifier for an outgoing interface depending on the 
   argument. In the instance when the delivery is not possible through 
   any of the interfaces present, it applies the rules for the 
   generation of ICMP messages;

     Packet_with_RTNS (Argument: IP packet) - checks whether the 
   argument is a packet requiring RTNS. Returns the logical result of 
   the check;

     Specify_SFL (Argument: IP packet or indicator to the virtual queue) 
   - returns the SFL combination of the argument;

     Add_indicator_to_outgoing_queue (Argument 1: virtual queue, 
   Argument 2: outgoing interface) - adds an indicator to the virtual 

D. Aleksandrov                                                  [Page 8]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   queue of the first argument in the interface's queue, assigned by 
   means of the second argument;

     Existing_virtual_queue (Argument: virtual queue) - checks for the 
   existence of a virtual queue, corresponding to the argument and 
   returns the result of the check;

     Create_virtual_queue (Argument: virtual queue) - creates a virtual 
   queue, corresponding to the Argument;

     Rule_1 (Argument1: virtual queue, Argument2: IP packet) - returns 
   the logical answer whether the packet represented as a second 
   Argument meets the conditions for adding a packet to the virtual 
   queue, identified with the first Argument;

     Add_packet_to_virtual_queue (Argument1: virtual queue, Argument2: 
   IP packet) - adds the packet, represented as a second Argument in the 
   virtual queue, identified with the first Argument;

     Rule_2 (Argument1: virtual queue, Argument2: IP packet) - returns 
   the logical answer whether the packet, represented as a second 
   Argument, initiates the dropping of packets from the virtual queue, 
   identified with the first Argument;

     Drop_out-of-date_packets (Argument1: virtual queue, Argument2: IP 
   packet) - drops packets from the virtual queue, indicated in the 
   first Argument, according to the indexes (time interval, internal 
   number) of the packet, represented as a second Argument;

     Do_Nothing - no action is taken;

     Sort_virtual_queue (Argument: virtual queue) - sorts the virtual 
   queue indicated in the Argument according to the chronology of the 
   packets, contained in it; 

     Add_packet_to_outgoing_queue (Argument1: IP packet, Argument2: 
   outgoing interface) - adds the packet, represented as a first 
   Argument, in the queue of the interface, assigned with the second 
   Argument.
 
     Packet_for_sending (Argument: element of queue) - returns "true" as 
   an answer, if the Argument is a packet; "false" -  if it is an 
   indicator;

     Transfer_packet (Argument: IP packet) - transfers the packet, 
   represented as an Argument of the interface;

     Take_outgoing_packet (Argument: virtual queue) - the IP packet, 
   located at the exit of the virtual queue, identified with the 
   Argument, leaves it and is given as a result of the function's 
   execution;

     Number_of _packets (Argument: virtual queue) - returns the number 
   of packets in the virtual queue, identified with the Argument;

D. Aleksandrov                                                  [Page 9]

Internet Draft     IP Supplement for a Real Time Service       July 2004


     Destroy_virtual_queue (Argument: virtual queue) - destroys the 
   virtual queue, identified with the Argument.

3.5. Results of the Function of the Transporting Module 

   The most prominent result from the usage of virtual queues is that 
   RTNS packets can reorder themselves but only in places which have 
   already been occupied by their own data flow. The rest of the traffic 
   is not discriminated against. In real queues indicators are added 
   only in the instances when the packet itself would have been added, 
   provided that the specific service had not been required. 

   A small advantage over the rest of the traffic is the retaining of 
   all indicators assigned to a certain queue, when as a result of the 
   execution of Rule 2, packets are dropped out of it. The total number 
   of indicators to a virtual queue is always equal or bigger than the 
   number of packets in it.  When a virtual queue is destroyed, its 
   indicators are left behind. When a second virtual queue is created 
   for the same data flow and if some of the old indicators are still 
   present, then a certain number of packets will be sent shortly. In 
   order for the old indicators to be usable, when the same SFL 
   combination is present, the algorithm must be structured in such a 
   way that it will generate the same identifier of the virtual queue.

   The virtual queues ensure that the real time service is executed 
   properly. They also manage effectively the quantity of transferred 
   data in case of network congestion and narrow band connections. 

   The real time is ensured by the dropping of packets which are late by 
   at least one time interval from the transmission. The encoding 
   algorithm which chooses the duration of the time interval should take 
   this characteristic into account. 

   The effective management of the quantity of transferred data is 
   ensured by special ordering rules which place the packets with the 
   smallest internal numbers at the head of the transmission (Rule 1). 
   The cascade encoding, discussed in chapter 1, in combination with 
   this rule decrease the quality of receiving but retain to the maximum 
   the receiver's freedom to interpret the data. 

   The hop-by-hop treatment of packets by the network allows it to act 
   as a homogeneous environment, which controls the data flow processes 
   between the sender and the receiver. In this way it ensures that the 
   best quality of service is achieved without the need to reserve 
   resources (discrimination against the rest of the network traffic). 
   The quantity of transferred data (respectively the quality of 
   receiving) is self-adjusting and continually improves the utilization 
   of the available resources. A great advantage is that we will no 
   longer need to install and engage intermediate hosts, aiming at re-
   encoding the data in case of an unsatisfactory network resource, so 
   that the data will be received after all. 



D. Aleksandrov                                                 [Page 10]

Internet Draft     IP Supplement for a Real Time Service       July 2004

3.6. Common Qualities with RTP from the Standpoint of the Needed Results 

   RTP [RFC3550] is the protocol for data transferal with real-time 
   characteristics, which currently concentrates most of the efforts in 
   this direction. RTNS of IP does not try to underestimate RTP. The 
   utilization of the mechanisms, available to a network layer protocol 
   of the OSI [OST] model, gives us an additional opportunity for the 
   development of services in real time. RTP is a higher layer protocol 
   with a high level of specificity while RTNS is just an IP supplement. 
   Therefore we do not try to exhaustively compare the two technologies, 
   but rather point our attention in the direction of some results which 
   can be achieved by using each one of them. RTP does not ensure the 
   real time of the delivery because it is a higher layer protocol. It 
   only creates an opportunity for the inclusion within the packets of 
   information about the data in real time.

   Information of the same kind is recorded by RTNS too, but it also 
   offers a real-time service. RTP uses mixers for the servicing of 
   clients using narrow band connections to the network. Layered 
   encoding is also part of RTP's specifications. It should be noted 
   that different addresses are used to signify the different layers, 
   especially when multicast transmission is used.  

   RTNS achieves both aims following the guidelines for the destruction 
   of packets which congest the network. An IP module identifying RTNS, 
   reacts without delay if congestion occurs. When RTP is used the 
   reaction time is longer because the sending application is managing 
   the process.

   RTCP allows the initiation of a return connection informing about the 
   quality of transmission, but it also allows the user to turn this 
   function off. On the contrary, IP's RTNS has no provisions for a 
   return connection, but still the possibility for the initiation of 
   one is left open.  

   One of RTNS's advantages is that end systems are not expected to 
   monitor and react in case of network congestion. The end result is a 
   reduced transfer for receivers using narrow band connections and a 
   full range of data for users of broadband connections. The same 
   result is aimed at and provided for in the specifications of RTP. 

4. Requirements to Upper Layer Applications for RTNS Usage 

   Upper layer applications must be able to exchange specific messages 
   with the IP module in order to make use of RTNS. It is very likely 
   that upper layer applications utilize UDP [RFC768] as an intermediate 
   protocol, used for the transferal of data to the network layer. 
   Because RTNS is implemented in the IP module, it is not committed to 
   a specific upper layer protocol. 

   The recommendation for the usage of UDP is determined by its 
   characteristics: 

   - non-initiation of sender - receiver sessions; 

D. Aleksandrov                                                 [Page 11]

Internet Draft     IP Supplement for a Real Time Service       July 2004


   - lack of confirmation for the data delivery;

   - the delivery is not guaranteed.

   UDP also has ports for the identification of sending and receiving 
   applications. The data flow identifier is sufficient for that purpose 
   but it is unrecognizable for the hosts which do not use RTNS. The 
   usage of ports is a specific application problem (if they plan to use 
   RTNS), rather than a problem of the service itself. And therefore it 
   is not discussed in the present document.  

   The sending application must be able not only to transfer data but 
   also to request the execution of the following functions from the 
   transport module: 

   -  to notify about the duration of a packet's life in the network. 
   The upper layer application requests and should be given the maximum 
   duration for a packet's life in the network, which will be used for 
   the transferal.  This value (in seconds) is used to determine the 
   maximum index number (time interval).  The upper layer application is 
   solely responsible for the correct assignment of this number. The 
   algorithm, used to calculate the maximum packet life, is beyond the 
   scope of this document. Because of the fact that IP only counts the 
   number of hops, not seconds, the maximum packet life can only be 
   calculated approximately. In order to avoid any confusion, it is 
   better for the inquiring application to get a value, which has been 
   increased on purpose by a certain percentage; 

   - to notify about the maximum value of the transmission unit. The 
   upper layer application should be able to request and receive 
   information about the maximum transmission unit (MTU) so that it can 
   adjust its encoding algorithm. This adjustment is not obligatory. By 
   considering the value of MTU, the data generator can require the 
   increase of the index (internal number), so that the fragmentation of 
   packets is avoided;

   - to assign a maximum number for the time interval. It is necessary 
   because the data generating application is the only one which knows 
   the duration of the time interval that will be used. The IP module 
   could always use values from one to the maximum because when 
   numbering the time intervals, the only thing that really matters is 
   their change and order. This leads to the transferal of packets with 
   recorded long-in-bits values of the time intervals, which creates a 
   certain quantity of extra traffic in those cases when the duration of 
   the time interval is such that for the standard duration of packet 
   life short-in-bits maximum value would be enough. 

   It would be best if this function is used at the initiation of the 
   transmission. Its execution is not obligatory. If it is never 
   initiated, the transport module will assign to the time intervals' 
   numbers from 1 to the maximum admissible value. The upper layer 
   application is free to choose how many times to use this function 
   during the time of the transmission. Its initiation, with a value 

D. Aleksandrov                                                 [Page 12]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   lower than the current one, leads to the assignment of "1" as a time 
   interval number at the next request for a change of the time 
   interval;

   - to change the time interval - it is initiated separately and 
   precedes the first data transferal from the new time interval. After 
   the time interval is changed, the value of the internal number is set 
   to 1;

   - to increase the internal number - it is fed in with each portion of 
    data (in particular - UDP packets), which the IP module receives. 
   Its minimum value is 0 and the maximum is defined as a result of the 
   subtraction of the current internal number from the maximum 
   admissible value for this index. Value 0 means no increase. When the 
   upper layer application requests that the internal number is 
   increased and tries to assign a number bigger than its maximum value, 
   the transport module records the maximum admissible value in the 
   packets and returns the message "requested internal number greater 
   than the maximum admissible value". It is the responsibility of the 
   upper layer application to take into consideration this message and 
   to adjust its requests accordingly. 

   The application, which receives the data, needs two indexes: time 
   interval and internal number. They accompany each data portion. It is 
   the responsibility of the upper layer application to buffer and order 
   the data within each of the time intervals. 

5. RTNS Format in IP

   The flagging of packets requesting RTNS is achieved through a hop-by-
   hop option. A special IP module, responsible for the management of 
   the service, must check the passing packets for this option. It is 
   understandable to expect that this service should be described as a 
   differentiated one, making use of the DS field defined in accordance 
   with [RFC2474]. The definition of per-hop behavior out of DS's scope 
   defies the recommendation of [RFC2475], where it is specifically 
   stated that in such instances differentiated service encoding must be 
   used. 

   The reasons to reject such definition are listed below:

   - [RFC2474] determines that just one kind of differentiated service 
   can be recorded and applied to a certain packet. The service that is 
   being described in the current document can be used together with 
   other kinds of differentiated services. Fundamentally, it can be 
   described as a type of differentiated treatment but only of the 
   packets belonging to the same data flow. A differentiated service can 
   also be requested for the whole data flow and at that instance - in 
   the exact sense this term is used in [RFC2474];

   - [RFC2481] and [RFC3168] (which later substituted it) proposes the 
   taking up of the two least significant bits in the DS field. As a 
   result the IP packet is left with no empty fields. Therefore we can 
   deduct that there is no other way to define RTNS;

D. Aleksandrov                                                 [Page 13]

Internet Draft     IP Supplement for a Real Time Service       July 2004


   - inclusion of an RTNS option in the packet is the same as its 
   flagging for the type of service requested from the standpoint of any 
   IP module identifying this option. For a module, which cannot offer 
   the service requested, the result is zero, even when the request is 
   recorded in the packet's DS field.

5.1 Option for RTNS in IPv4

   In IPv4 RTNS is defined as an option of type 10011001 (153 
   decimally), recorded in the Options field of the IP header. 

   The data contained in it is: flow identifier, number of the time 
   interval, internal number and the type of return connection. 

   RTNS option format for IPv4:

     1               2               3               4   
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Option Type  | Option Length |0|0|0|0|      FLOW LABEL       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | FLOW LABEL    | TIDL  |  IIDL |      Time identifier          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Time Identifier|    Internal Identifier        |ICMP Parameter |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Option Type - the first 8 bits define the type of the option as put 
   forward in [RFC791]. An option for real time must be present in each 
   of the fragments (value 1xxxxxxx). It can be described as one of the 
   control options (value x00xxxxx) and use the first vacant value in 
   the sub-field Option Number - 25 decimally (value xxx11001) [IANAv4]. 
   As a result the RTNS option is defined by type 10011001 - 153 
   decimally. 

     Option Length - is located in the second octet as required by 
   [RFC791]. The correct decimal values are between 9 and 37 (binary 
   values form 00001001 to 00100101).

     Flow Label - a 20-bit field for the data flow identifier. It takes 
   up octets 3, 4 and 5, whose starting four bits are filled up with 
   zeros. The flow identifier is 20 bits long in order to be compatible 
   with the length of the flow label field in the IPv6 header, which is 
   of the same size.  

     Octet 6 of this option is divided into two 4-bit fields: 

     Time Identifier Length (TIDL) - field length in octets, in which 
   the number of the time interval is recorded. This number is an 
   unsigned integer. 

     Internal Identifier Length (IIDL) - field length in octets, in 
   which the internal number is recorded. It is an unsigned integer.


D. Aleksandrov                                                 [Page 14]

Internet Draft     IP Supplement for a Real Time Service       July 2004

     Time Identifier - number of the time interval. It is a field of 
   varying length -  1 to 15 octets, an unsigned integer.

     Internal Identifier - an internal number. It is a field of varying 
   length -  1 to 15 octets, an unsigned integer.

     ICMP Parameter - defines the type of return connection for the 
   undelivered packets. It is filled with zeros by the sender, which is 
   to signify that there is no need for return connection, in other 
   words no ICMP message should be generated even if in a virtual queue 
   packets are destroyed. If, in a future revision of RTNS, the usage of 
   ICMP is provided for, at the occurrence of the situation described in 
   2.3, it should generate values different from zero for each type of 
   return connection and these values should be recorded in the field in 
   question. 

   The indexes (time interval, internal number) are recorded in fields 
   of varying length so that the encoding application exercises the 
   freedom to choose from among them and also to decrease the size of 
   the real time options when their value is small. 

   The minimum length of the option is  9 octets (72 bits). Its maximum 
   length is 296 bits (37 octets). 

5.2 Option for RTNS in IPv6

   RTNS is defined in IPv6 as an option of type 00000111 (7 decimally), 
   recorded in an additional hop-by-hop options header. Each packet 
   requiring RTNS has to have this additional options header.  

   The data contained in this option is: number of the time interval, 
   internal number and type of the return connection.  

   The data flow identifier is defined in a 20-bit Flow Label field, 
   located in the packet's IPv6 header. 

   The type of the option is the following:

     1               2               3               4   
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Option Type  | Option Length | TIDL  | IIDL  |Time Identifier|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Time Identifier|    Internal Identifier        |ICMP Parameter |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Option Type - the first 8 bits define the type of the option as 
   required by [RFC2460]. In the case when the IP module cannot 
   interpret the option, it must be skipped with no further consequence 
   (value 00xxxxxx) - the packet is treated as any other packet would 
   be. The option for RTNS does not change en-route (value xx0xxxxx) and 
   uses a free value for bits 3 - 7 of the field [IANAv6]. The value 
   chosen here is xxx00111. As a result the RTNS option is defined by 
   type 00000111 - 7 decimally.

D. Aleksandrov                                                 [Page 15]

Internet Draft     IP Supplement for a Real Time Service       J-ne 2004


     Option Length (Option Data Length) - an 8-bit unsigned integer, 
   which - in accordance with [RFC2460] defines the length of the 
   option's data (the next 4 fields) in octets. The correct decimal 
   values are from 4 to 32. (binary form 0000100 to 00100000). 

     Here are the rest of the fields in the option's data: Time 
   Identifier Length (TIDL), Internal Identifier Length (TIDL), Time 
   Identifier, Internal Identifier and ICMP Parameter have comparable 
   lengths, values and interpretations with the corresponding IPv4 
   fields. 

   The difference in the options' data between IPv4 and IPv6 is that the 
   IPv4 data flow identifier should be present as a field in the RTNS 
   option, where as in IPv6 the special field in IP header is used 
   instead. 

   The minimum length of the option's data is 4 octets (32 bits), and of 
   the whole option - 6 octets (48 bits). The maximum length of the 
   option's data is 32 octets (256 bits), and of the whole option  - 34 
   octets (272 bits).

6. Interaction of RTNS-identifying and Non-identifying hosts.

   Each packet flagged for RTNS could pass through a succession of 
   network nodes (identifying or non-identifying the type of service 
   requested), at the time of its transferal.  The difference between 
   the two types of hosts shows itself when the network resources are 
   limited. 

   If the data transferal were quick enough and broadband, the packets 
   of each data flow would arrive at their final location in the same 
   order and quantity as generated. They would also pass each hop in the 
   same manner. When there is no slowing down the conduct of the network 
   nodes identifying RTNS is the same as the conduct of those, which do 
   not identify RTNS. Therefore we must describe the case when there is 
   not enough network resource for the data flow requesting RTNS and the 
   rest of the traffic. 

   We can be sure that the packets from a certain data flow will sooner 
   or later reach a node identifying RTNS. At least the receiver host 
   should be of this kind because to install the application (which 
   counts on receiving the data) otherwise, would have been useless. 
   When the packets reach such a node, they will be partially sorted and 
   the data, which is not current, will be dropped from the flow. 

   We can also be sure that by the time they reach a node, non-
   identifying RTNS, the packets have at least once been through a node 
   identifying the requested service. At least the sender host should be 
   of this kind or otherwise to install the application (which generates 
   the data) would have been useless. The outgoing packets (part of an 
   RTNS flow) from such a host are always sorted. If all cannot be sent, 
   then they are reduced. 


D. Aleksandrov                                                 [Page 16]

Internet Draft     IP Supplement for a Real Time Service       July 2004

   At each border, between an RTNS-identifying host and a rest of the 
   network (where the RTNS non-identifying hosts are), the packets, 
   which cannot be properly treated by the network infrastructure, are 
   dropped. To be precise, the latter are destroyed in the virtual queue 
   of the RTNS-identifying host. The most important thing here is that 
   this process is executed in accordance with the service requirements. 
   If we allow for a certain approximation, each part of the network, 
   which does not identify RTNS and is located between two RTNS-
   identifying hosts, can be considered a direct connection (virtual 
   link) with insufficient capacity. The capacity of a virtual link is a 
   host whose resources are used to the maximum. This host identifies 
   RTNS and sends data through it. 

   Because of the fact that the virtual link does not have the 
   capability to drop the packets, whose data is not current, it lessens 
   the quality of the data flow requiring RTNS. A point can be reached 
   when there is a practical incapability for the receiving of data - 
   when almost all RTNS-requiring packets are dropped within a host 
   whose exit interfaces are connected to network nodes, which do not 
   work with RTNS. On the other hand, the dropping of such packets will 
   have a good effect on the rest of the network traffic from whose 
   standpoint both types of hosts are identical. The dropping of packets 
   regulates the network load, discriminating against the RTNS-requiring
   data but not against the rest of it. 

   According to the formal definition of "congestion", given in 
   [RFC2914] and [RFC2309], RTNS may cause a congestion collapse. That 
   is because "bandwidth is wasted by delivering packets through the 
   network that are dropped before reaching their ultimate destination." 
   Dropping a packet in a virtual queue always happens in an edge node 
   connecting a congested link to a non-congested one. This node could 
   be the sender host. In this case, the free link is to the Upper Layer 
   Application generating data, and the congested link is (one of) 
   host's network interface(s). Yes, there are dropped packets, but they 
   are delivered to their drop-point over uncongested link(s). It is the 
   same, as relying on end systems to back-off the size of the flow, 
   with the advantage, that an RTNS flow is self back-offing. It is a 
   TCP-compatible, not a more aggressive flow. When using multicast, 
   every branch of the multicast tree is able to back-off its rate to a 
   different level. 

   Another doubt provoking aspect of RTNS functionality is the fact, 
   that its queuing algorithm is only efficient when packets, requiring 
   the service, remain for a comparatively long time in virtual queues. 
   And also, wouldn't the RTNS algorithm slow down routers too much? As 
   computer capabilities are constantly growing, just like network 
   speeds are, even if RTNS is nowadays unworkable, it could soon be 
   applicable.

   There is no necessity for the simultaneous recognition of RTNS by all 
   IP modules from the very beginning. This makes it possible to 
   implement the service in limited parts of the Internet and then 
   gradually "take over" new territories. 


D. Aleksandrov                                                 [Page 17]

Internet Draft     IP Supplement for a Real Time Service       July 2004

7. IANA Considerations

   This document proposes a new value of 153 among the IP Option Numbers 
   [IANAv4] - Real-time Network Service Option. 

   This document proposes a new value of 7 among the Option Types of the 
   IP Version 6 Parameters [IANAv6] - Real-time Network Service Option.

8. Security Considerations

   Security considerations are not discussed in this memo. 

9. References

   [RFC791]   Postel, J., "Internet Protocol", RFC 791, September 1981

   [RFC2460]  Deering, S. and Hinden, R., "Internet Protocol, Version 6 
              (IPv6) Specification", RFC 2460, December 1998

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 
              "RTP: A Transport Protocol for Real-Time Applications", 
              RFC 3550, July 2003

   [OST]      Osterloh, H., "TCP/IP Primer Plus", 2002, Sams Publishing
              Bulgarian Language Edition, 2002, Softpress Ltd.

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

   [RFC2474]  Nichols, K., Blake, S., Baker, F., Black, D., "Definition
              of the Differentiated Services Field (DS Field) in the
              IPv4 and IPv6 Headers", RFC 2474, December 1998

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 
              Weiss, W., "An Architecture for Differentiated Service", 
              RFC 2475, December 1998

   [RFC2481]  Ramakrishnan, K., Floyd, S., "A Proposal to add Explicit 
              Congestion Notification (ECN) to IP", RFC 2481,
              January 1999

   [RFC3168]  Ramakrishnan, K., Floyd, S., Black, D., "The Addition of 
              Explicit Congestion Notification (ECN) to IP", RFC 3168, 
              September 2001

   [IANAv4]   "IP OPTION NUMBERS",
              The Internet Assigned Numbers Authority

   [IANAv6]   "IP VERSION 6 PARAMETERS",
              The Internet Assigned Numbers Authority

   [RFC1112]  Deering, S.E., "Host extensions for IP multicasting", 
              RFC 1112, August 1989

   [RFC2914]  Floyd, S., "Congestion Control Principles", RFC 2914, 
              September 2000


D. Aleksandrov                                                 [Page 18]

Internet Draft     IP Supplement for a Real Time Service       July 2004


   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 
              S., Wroclawski, J, Zhang, L., "Recommendations on Queue 
              Management and Congestion Avoidance in the Internet", 
              RFC 2309, April 1998

10. Author's Address

   Dimitar Aleksandrov
   Over-Ground Ltd.
   Varna, Bulgaria
   Phone: +359 88 8621125    
   E-mail: rtvp@over-ground.net

Appendix 1
An Example of the Implementation of RTNS in IP 


   A typical application of RTNS would be the transmission of radio and 
   TV programs in Internet. When the classical transmission methods are 
   used (via radio and TV stations, etc.), the fundamental 
   characteristics of the transmission are: 

   - full synchrony between the receivers and the transmitter ;

   - a possibility for the signal to be received by an unlimited number 
   of listeners / viewers (within the zone  covered by each 
   transmitter);

   - lack of feedback, concerning the number of receivers and the 
   quality of the signal received.

   The same characteristics are achievable through the usage of RTNS, 
   side by side with multicasting [RFC1112]. 

   The radio - and TV program needs a multicast address and encoding of 
   the transmitted data in accordance with the principles discussed in 
   Chapter 1. The rest is taken care by the network infrastructure. It 
   is important to point out that data encoding allows access to the 
   program from users with different network and hardware capabilities. 
   This will not create a problem neither for the data-sender, nor for 
   the intermediate hosts.

   What follows is an example for the structuring of supplementing 
   layers of encoding for the TV program: 








D. Aleksandrov                                                 [Page 19]

Internet Draft     IP Supplement for a Real Time Service       July 2004

     Layer 1        Transmission topic - information about the current 
                    program in textual form 
     Layer 2        Mono sound - phone line quality 
     Layer 3        Frames  at intervals of  1 second each 
     Layer 4        Frames at intervals of 1 second each with a 
                    difference of 1/2 second from the frames of Layer 3 
     Layer 5        Sound addition - radio quality 

     Layer 6        Frames at intervals of 1/2 a second each with a 
                    difference of 1/4 second from the frames of Layers 3 
                    and 4
     Layer 7        The rest of the frames from the video
     Layer 8        Difference between the left and the right sound 
                    channels - FM stereo radio quality

   By using RTNS we can set up unicast conference connections, in which 
   all delays are avoided but some interruptions are possible. 

   RTNS can also be used when transferring data with reserved network 
   resource. It can really save the day in those cases when the usual 
   guaranteed routes are down and unusable. Another way to deal with 
   this situation is to reserve resources equivalent to the data from 
   the first several layers of encoding. In this way more clients will 
   be able to reserve guaranteed data of minimal quality and not 
   guaranteed full receiving.




























This document expires 12 January 2005.


D. Aleksandrov                                                 [Page 20]