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]