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]
