Internet DRAFT - draft-aleksandrov-ip-extension
draft-aleksandrov-ip-extension
Over-GROUND Ltd. D. Aleksandrov
Internet Draft: IP Extension for a Real Time Service
Document: draft-aleksandrov-ip-extension-00.txt
Internet Draft
Internet Protocol (IP) Extension for a Real Time Service
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 11 January 2006.
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
D. Aleksandrov Expires January 2006 [Page 1]
Internet Draft IP Extension for a Real Time Service July 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, the Internet layer ot the DoD
model respectively. 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. . . . . . . . . . . . . . . 7
3.4. Function of the Transporting Module . . . . . . . . . . . 8
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
4. Requirements to Upper Layer Applications for RTNS Usage . . . . 12
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
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19
Appendix 1
An Example of the Implementation of RTNS in IP . . . . . . . . . . 20
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 routers. 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 an end system or a router) its IP
module can make a decision to:
- change their order in the queuing sequence for sending;
D. Aleksandrov Expires January 2006 [Page 2]
Internet Draft IP Extension for a Real Time Service July 2005
- 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 doesn't bother resource reservation, too. There is no
reason why RTNS cannot be combined (applied simultaneously) together
with some resource reservation 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 take note of the following:
- the delivery should be connectionless;
- that confirmation of data delivery should not be required;
- that there should not be a reliable delivery.
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 (layers) with increasing levels of
importance.
Let us consider the case when the data containing the whole
information about a fixed by duration epoch is coded in k increasing
layers. If the receiver disposes of all k layers, the transmitted
information will be received in full. Because of the fact that the
data in layers 1 to k is supplementing, if the data of layers from 1
to n is received (where n can have any value from 1 to k), the data
can still be interpreted but with a different (always lower) quality.
D. Aleksandrov Expires January 2006 [Page 3]
Internet Draft IP Extension for a Real Time Service July 2005
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 epochs in which the
transmission is divided.
The bounds of the increasing 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
of certain encoding techniques and the end of the transmission.
The packets, sent within a certain epoch, 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 epoch and the encoding layers
is given below:
Layer Packet 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 should be present:
- tags signifying the sequence within the epoch;
- the order of the epochs themselves.
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 "epoch
number". 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 epoch numbers and no clear
chronology.
D. Aleksandrov Expires January 2006 [Page 4]
Internet Draft IP Extension for a Real Time Service July 2005
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;
- Epoch number - value from 1 to q with cyclic recurrence;
- Internal Number - number of the packet within the epoch. 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
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 epoch as well as the
quantity of skipped epochs.
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. The queue itself will be referred to as "SFL queue".
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
D. Aleksandrov Expires January 2006 [Page 5]
Internet Draft IP Extension for a Real Time Service July 2005
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 3.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 pointing them indicators.
When a packet requesting RTNS is received by the IP module for
forwarding, it chooses the most suitable interface to whose queue the
packet should be added. 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 pointing 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;
- the connection to an application from an upper layer receiver.
When an indicator pointing a virtual queue reaches the exit of a real
queue the transporting module sends forward the packet which is
located at the exit of the virtual (SFL) queue. In section 3.5. 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 (epoch number, internal
number) showing that it has been generated more than one epoch 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 (epoch number, internal number)
show that it has been generated more than one epoch 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.
D. Aleksandrov Expires January 2006 [Page 6]
Internet Draft IP Extension for a Real Time Service July 2005
Rule 3) With each new addition of a packet to a virtual queue it
is reordered according to the chronology of the indexes (epoch
number, 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
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, epoch, 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 epochs cycled.
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
D. Aleksandrov Expires January 2006 [Page 7]
Internet Draft IP Extension for a Real Time Service July 2005
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:
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. An element
here is an indicator pointing SFL queue or just a packet not
requiring RTNS handling:
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 = Extract_outgoing_packet (SFL);
if (Positive_number_of_packets_in_virtual_queue (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
D. Aleksandrov Expires January 2006 [Page 8]
Internet Draft IP Extension for a Real Time Service July 2005
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 pointing a 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 pointing the
virtual 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: SFL combination) - 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 it 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 (epoch number, 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
D. Aleksandrov Expires January 2006 [Page 9]
Internet Draft IP Extension for a Real Time Service July 2005
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;
Extract_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;
Positive_number_of_packets_in_virtual_queue (Argument: virtual
queue) - returns "true" if the number of packets in the virtual
queue, identified with the Argument is positive, "false" - if the SFL
queue consists of zero packets;
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 pointing 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 new 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;
- the quantity of transferred data in case of network congestion and
narrow band connections is managed effectively.
The real time is ensured by the dropping of packets which are late by
at least one epoch from the transmission. The encoding algorithm
which chooses the duration of the epoch 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
D. Aleksandrov Expires January 2006 [Page 10]
Internet Draft IP Extension for a Real Time Service July 2005
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.
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 extension.
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.
D. Aleksandrov Expires January 2006 [Page 11]
Internet Draft IP Extension for a Real Time Service July 2005
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:
- connectionless data dalivery;
- lack of confirmation for the data delivery;
- unreliable delivery.
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 be notified 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 value of the epoch number index. 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 be notified 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
D. Aleksandrov Expires January 2006 [Page 12]
Internet Draft IP Extension for a Real Time Service July 2005
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 epoch.
It is necessary because the data generating application is the only
one which knows the epoch duration that will be used. The IP module
could always use values from one to the maximum because when
numbering the sequent epochs, 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 epoch number, which creates a
certain quantity of extra traffic in those cases when the duration of
the epoch 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 epoch 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 lower than the current
one, leads to the assignment of "1" as a epoch number at the next
request for a change of the epoch;
- to change the epoch.
It is initiated separately and precedes the first data transferal
from the new epoch. After the epoch 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: epoch
and interval numbers. They accompany each data portion. It is
the responsibility of the upper layer application to buffer and order
the data within each of the epochs.
5. RTNS Format in IP
The flagging of packets requesting RTNS is achieved through a hop-by-
D. Aleksandrov Expires January 2006 [Page 13]
Internet Draft IP Extension for a Real Time Service July 2005
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;
- 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 recorded in the Options field of
the IP header.
The data contained in it is: flow identifier, epoch number, 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 | ENL | INL | Epoch Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Number | Internal Number |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
D. Aleksandrov Expires January 2006 [Page 14]
Internet Draft IP Extension for a Real Time Service July 2005
control options (value x00xxxxx).
It is proposed that IANA assigns an option number for RTNS starting
with 100 [IANAv4].
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:
Epoch Number Length (ENL) - field length in octets, in which
the number of the epoch is recorded. This number is an unsigned
integer.
Internal Number Length (INL) - field length in octets, in which the
internal number is recorded. It is an unsigned integer.
Epoch Number - number of the epoch. It is a field of varying length
- 1 to 15 octets, an unsigned integer.
Internal Number - 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 (epoch number, 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 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 epoch number,
D. Aleksandrov Expires January 2006 [Page 15]
Internet Draft IP Extension for a Real Time Service July 2005
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 | ENL | INL | Epoch Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch Number | Internal Number |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).
It is proposed that IANA assigns an option number for RTNS in IPv6
starting with 000 [IANAv6].
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: Epoch Number
Length (ENL), Internal Number Length (INL), Epoch Number, Internal
Number 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.
The term "network node" is used in this chapter as common for both
"router" and "end system".
Each packet flagged for RTNS could pass through a succession of
routers (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.
D. Aleksandrov Expires January 2006 [Page 16]
Internet Draft IP Extension for a Real Time Service July 2005
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 routers
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.
At each border, between an RTNS-identifying host and a rest of the
network (where the RTNS non-identifying nodes 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.
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
D. Aleksandrov Expires January 2006 [Page 17]
Internet Draft IP Extension for a Real Time Service July 2005
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.
7. IANA Considerations
This document proposes IANA assigned a new value among the IP Option
Numbers [IANAv4] - Real-time Network Service Option.
This document proposes IANA assigned a new value 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.,
D. Aleksandrov Expires January 2006 [Page 18]
Internet Draft IP Extension for a Real Time Service July 2005
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
[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 89 7904009
E-mail: rtns@over-ground.net
11. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
D. Aleksandrov Expires January 2006 [Page 19]
Internet Draft IP Extension for a Real Time Service July 2005
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
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 routers.
What follows is an example for the structuring of increasing layers
of encoding for the TV program:
Layer 1 Transmission topic - information about the current
D. Aleksandrov Expires January 2006 [Page 20]
Internet Draft IP Extension for a Real Time Service July 2005
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 11 January 2006.
D. Aleksandrov Expires January 2006 [Page 21]
