Internet Draft Dae Young Kim
Intended status: Informational Chungnam National University
Expires: October 2007 Seok Joo Koh
April 18, 2007 Kyungpook National University
Enhanced Communications Transport Protocol for One-to-Many Multicast
Applications with Unicast Reverse Data Channels
<draft-dykim-ectp-00.txt>
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.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 18, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kim and Koh Expires October 18, 2007 [Page 1]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
Abstract
This document is a part of the ITU-T Recommendation and ISO/IEC
International Standard, named the Enhanced Communications Transport
Protocol (ECTP), which is a multicast transport protocol designed to
support Internet multicast applications. This third part of ECTP
(ECTP-3) describes the protocol specification for the duplex
multicast transport. In a duplex connection, a single multicast
sender, named TC-Owner (TO), transmits multicast data to the other
group members, while some of the participating TS-users may send
unicast data to the TO over the reverse data channel.
Kim and Koh Expires October 18, 2007 [Page 2]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
Table of Contents
1. Introduction................................................4
2. Terminology.................................................5
2.1. Definitions............................................5
2.2. Abbreviations..........................................6
2.3. Conventions............................................6
3. Protocol Overview...........................................7
4. Design Considerations.......................................11
4.1. Participants..........................................11
4.2. Control Tree..........................................11
4.3. Data Channels.........................................12
4.4. Addressing............................................13
4.5. Tokens................................................15
5. Packets....................................................15
5.1. Base Header...........................................15
5.2. Extension Elements.....................................17
5.3. Packet Format.........................................19
6. Procedures.................................................21
6.1. Connection Creation....................................21
6.2. Late Join.............................................22
6.3. Forward Data Transport.................................22
6.4. Reliability Control for Reliable Transport.............24
6.5. Control Tree Maintenance...............................26
6.6. Congestion Control for Forward Data Channel............27
6.7. Token Control.........................................27
6.8. Backward Data Transport................................28
6.9. Connection Management..................................29
7. Security Considerations.....................................29
8. IANA Considerations........................................29
9. Acknowledgments............................................29
10. References................................................30
10.1. Normative References..................................30
10.2. Informative References................................30
Author's Addresses............................................30
Intellectual Property Statement................................30
Disclaimer of Validity........................................30
Kim and Koh Expires October 18, 2007 [Page 3]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
1. Introduction
This document (Recommendation | International Standard) specifies the
Enhanced Communications Transport Protocol (ECTP), which is a
transport protocol designed to support Internet multicast
applications running over multicast-capable networks. ECTP shall be
provisioned over UDP.
ECTP is designed to support tightly controlled multicast connections
in simplex, duplex and N-plex applications. This part of ECTP (part
3: ITU-T X.607 | ISO/IEC 14476-3) specifies the protocol mechanisms
for reliability control in the duplex case.
In the ECTP-3 duplex multicast connection, the participants are
classified into one TC-Owner and many TS-users. TC-Owner will be
designated among the TS-users before the connection begins. In the
duplex multicast connection, the two types of data transports are
supported: multicast data transport from TC-Owner to all the other
TS-users and unicast data transport from TS-users to TC-Owner. After
the connection is created, TC-Owner can transmit multicast data to
the group, whereas each TS-user is allowed to send unicast data to
TC-Owner just after it gets a token from the TC-Owner.
In ECTP, TC-Owner is at the heart of multicast group communications.
It is responsible for overall connection management by governing the
connection creation and termination, connection pause and resumption
and the late join and leave operations.
The duplex multicast connection specified in ECTP-3 is targeted to
the multicast applications in which the TC-Owner (a single multicast
sender) transmits the data information to all the other TS-users, and
some of the TS-users respond to the multicast sender with the unicast
feedback data. Basically, the duplex multicast transport will be well
suited to the one-to-many multicast applications that need the
unicast feedback channels from some TS-users (e.g., remote education,
Internet broadcasting, etc). For example, in a remote education
application, the multicast sender (lecturer) transmits the data such
as voice, text and image to the student group, whereas some of the
students may respond to the lecturer with the unicast data like
questions for confirmation.
It is noted that this duplex multicast connection can also be used
for the some-to-many multicast applications (e.g., a panel
conferencing) in which a few of TS-users want to send multicast data
to the group. In this scenario, the multicast data from the TS-users
may first be delivered to the TC-Owner by unicast, and then TC-Owner
will transmit the received unicast data to the group by multicast.
Kim and Koh Expires October 18, 2007 [Page 4]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
2. Terminology
2.1. Definitions
This document also applies the following definitions:
TO (TC-Owner)
TO can only transmit multicast data to the other TS-users, and it
manages overall operations of ECTP-3;
TU (TS-User)
TU can receive multicast data sent by TO;
SU (Sending TU)
A TU who gets a token from TO. Only the SU is allowed to send
unicast data to TO. In other words, before sending unicast data,
each TU must request a token to TO;
RA (Repair Agent)
It is located on the control tree of ECTP-3. One or more RAs
could be designated for scalable error recovery and status
monitoring in ECTP-3. An RA is also a TU, that is, it receives
multicast data from TO. RAs will be configured as a parent of the
local groups through the control tree configuration in ECTP-3;
Token
It represents the right for a TU to transmit data. The TU who has
a token is called SU. The tokens are managed by TC-Owner;
Forward Data Channel
It represents the multicast data channel from TO to the TUs. TO
sends multicast data to all the other group members over IP
multicast address.
Backward Data Channel
It represents the unicast data channel from a TU (SU) to TO. An
SU who has a token can send unicast data to TO over IP unicast
address.
Kim and Koh Expires October 18, 2007 [Page 5]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
2.2. Abbreviations
The following acronyms for ECTP protocols are used in this document:
ECTP-1 ECTP part 1 (ITU-T X.606 | ISO/IEC 14476-1)
ECTP-2 ECTP part 2 (ITU-T X.606.1 | ISO/IEC 14476-2)
ECTP-3 ECTP part 3 (ITU-T X.607 | ISO/IEC 14476-3)
ECTP-4 ECTP part 4 (ITU-T X.607.1 | ISO/IEC 14476-4)
ECTP-5 ECTP part 5 (ITU-T X.608 | ISO/IEC 14476-5)
ECTP-6 ECTP part 6 (ITU-T X.608.1 | ISO/IEC 14476-6)
The following acronyms for ECTP-3 packets are used in this document:
CCR Connection Creation Request
CCC Connection Creation Confirm
TJR Tree Join Request
TJC Tree Join Confirm
DATA Data
NDATA Null Data
RDATA Retransmission Data
ACK Acknowledgment
HB Heartbeat
HBACK Heartbeat Acknowledgment
LJR Late Join Request
LJC Late Join Confirm
ULR User Leave Request
CTR Connection Termination Request
TGR Token Get Request
TGC Token Get Confirm
TRR Token Return Request
TRC Token Return Confirm
2.3. Conventions
In this document, the capital characters are used to represent a
packet of ECTP-3 (e.g., CCR for Connection Creation Request packet),
and the capital and italic characters are used for timers or
variables used in ECTP-3 (e.g., CCT for Connection Creation Timer,
and AGN for ACK Generation Number).
Kim and Koh Expires October 18, 2007 [Page 6]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
3. Protocol Overview
The Enhanced Communications Transport Protocol (ECTP) is a transport
protocol designed to support Internet multicast applications. ECTP
operates over IPv4/IPv6 networks that have the IP multicast
forwarding capability with the help of IGMP and IP multicast routing
protocols.
As shown in Figure 1, the ECTP shall be provisioned over UDP.
+-------------------------+
| Multicast Applications |
+-------------------------+
| ECTP |
+-------------------------+
| UDP |
+-------------------------+
| IP |
+-------------------------+
Figure 1. ECTP Protocol Model
Figure 1 illustrates an example of the use of mobile SCTP for
seamless handover in IPv4 networks. Based on this figure, the
handover procedures are described in the succeeding sections.
This document describes the protocol specification of the ECTP part 3
(ECTP-3) for the duplex multicast connection. The duplex multicast
connection is used for supporting multicast data transport between
the participants that are classified into a single TC-Owner (TO) and
many TS-users. A duplex multicast connection supports the two types
of data channels between the participants: multicast data channel
(sent by TO toward all the other TS-users) and unicast data channel
(sent by a TS-user to TO). Such a TS-user is called Sending User (SU).
Figure 2 illustrates these two types of data transport channels used
in the duplex multicast connection. As shown in the figure, TO can
transmit multicast data to the other TS-users over IP multicast
(group) address. Some SUs may send unicast data to TO. The SU must
first get a token from the TO before sending the unicast data.
Kim and Koh Expires October 18, 2007 [Page 7]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
/-----------------------------------\
| |
v /=============> TU (SU)
|
TO ==============================> TU
|
^ \=============> TU (SU)
| |
\-----------------------------------/
Figure 2. Data Flows in ECTP Duplex Connection
To establish a duplex multicast connection, TO transmits a CCR packet
to the group. The CCR packet contains the connection information
including general characteristics of the connection. In particular,
the CCR packet must indicate that the connection type is the duplex
multicast transport. Each TU who wants to participate in the
connection will respond to the TO with a CCC packet. The connection
creation operation will be completed when a pre-determined CCT timer
expires.
During the connection creation phase, a logical control tree is
configured between TO and TUs, or between TUs for providing the
scalable reliability control. With the root of the TO, the control
tree defines a parent-child relationship between any pair of two TUs.
The parent TU is called Repair Agent (RA). Based on the control tree,
the error recovery will be performed. To configure a control tree,
each TU sends a TJR message to a candidate parent node that has
already been connected to the tree. The parent node will respond to
the promising child TU with the TJC message. In this way, the control
tree will gradually be expanded from the root toward the leaf nodes.
Some of the prospective TUs may join the connection as late-joiners.
The late-joining TU participates in the connection by sending an LJR
message to TO. In response to the LJR message, TO sends an LJC
message to the TU. The late-joiner TU will also join the control tree
by using the TJR and TJC messages. For this purpose, the LJC message
of TO may include the information about the prospective parent RA
node for the late-joiner. The late-joining TU may try to connect to
the prospective RA node so as to configure the control tree.
After the connection is established, the data transmission phase
starts. ECTP-3 protocol supports two types of data channels: the
forward multicast channel from TO to the group and the backward
unicast channel from the TU to TO.
Kim and Koh Expires October 18, 2007 [Page 8]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
ECTP-3 also provides three kinds of reliability options: reliable
(error recovery), semi-reliable (partial error recovery), and
unreliable (no error recovery). In the reliable option, all the DATA
packets will be recovered by the parent on the tree. In the semi-
reliable option, the retransmissions of the lost packets are limited
by the buffer status of the parent node. That is, the parent node
will retransmit only the DATA packets that are at present being
contained in the buffer. In the unreliable option, the RDATA packets
are not used. It is also noted that each ACK packet does not mean any
retransmission request to the parent. The ACK packets are instead
used for monitor the receiving status of the receivers.
In the forward multicast data transmission, TO can begin the
multicast data transmission to the group by using the IP multicast
address and group port number. The multicast data packets sent by TO
will be sequentially segmented and transmitted by DATA packets to the
receiving TUs. The TS-users will deliver the received DATA packets to
the upper-layer application in the order transmitted by TO.
For the forward multicast data channel of TO, the error control will
be performed based on the local group defined by the ECTP control
tree. If a child TU detects a data loss, it sends a retransmission
request to its parent via ACK packets. Each child generates an ACK
packet every ACK Generation Number (AGN) data packets. That is, an
ACK packet is generated for the AGN data packets of TO. An ACK
message contains a Bitmap to indicate which data packets have been
received or not. In response to an ACK packet, each parent RA may
retransmit the RDATA packets to its children.
In the forward multicast data transport, the HB and HBACK packets are
used between a parent and children for the control tree maintenance.
A parent transmits HB packets to the children every HB Generation
Time (HGT). The HB contains which child must respond to this HB
packet with the HBACK packet. The corresponding child will send a
HBACK packet to the parent. The HB packet may also be used by the
parent to calculate the local RTT for the group. For this purpose,
the HB and HBACK packets contain a timestamp. The TO uses this RTT
information for the rate-based congestion control that is based on
the well-known TCP-Friendly Multicast Congestion Control (TFMCC)
equation. The transmission rate of TO will be adjusted based on the
RTT and the packet loss rate.
For the backward unicast data transport, a certain TU in the
connection may get a token from TO by sending a TGR message. The TO
will then respond to the TU with the TGC message that contains a
Token ID. Accordingly, the total number of tokens in the connection
Kim and Koh Expires October 18, 2007 [Page 9]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
is controlled by TO. The Token ID is used to identify the sender of
the unicast DATA packets at the TO side. The TU who has a token is
called Sending TU (SU).
The SU can send unicast DATA packets to TO. For the error recovery
and congestion control, the HB and HBACK packets are exchanged
between SU and TO. The SU sends an HB message to TO. The TO then
responds with the HBACK packet that contains the acknowledgement
information, as done in ACK packets in the forward multicast channel.
It is noted that the HBACK is used for retransmission request in the
backward channel. The SU performs the rate-based congestion control,
as done in the forward data channel, which is based on the RTT and
packet loss rate.
After completing the unicast data transmission, the SU will return
the token to the TO by sending a TRR message. TO will respond to the
SU with a TRC message.
The connection management operations are taken in the connection;
user leave, the connection pause and resumption, and connection
termination. In the User Leave operation, a participating TU may
leave the connection by sending a ULR message to the parent. In a
certain case, the parent may enforce a specific child TU to leave the
connection by sending the ULR message, which is called the
troublemaker ejection. The TO may temporarily pause and resume the
connection. In the connection pause period, the TO will send NDATA
packets to the group.
After the TO has completed the data transport, it may terminate the
duplex connection by sending a CTR message to the group.
Kim and Koh Expires October 18, 2007 [Page 10]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
4. Design Considerations
This section describes some considerations for the design of ECTP-3.
4.1. Participants
The participants to an ECTP-3 connection can be classified into one
of the following nodes:
TO (TC-Owner)
ECTP-3 connection has a single TO. The TO is responsible for the
overall operations required for connection management including
connection creation and termination, control tree creation, late join,
and connection maintenance. TO is also a single sender of the forward
multicast data channel. Only the TO is allowed for sending the
original multicast data to the other participants.
TU (TS-User)
An ECTP-3 connection has one or more TUs. Each of them receives
multicast data from TO.
RA (Repair Agent)
In the ECTP-3 connection, an RA is a TU who is responsible for error
recovery to the local group by retransmission of data. On the control
tree hierarchy of ECTP-3, an RA is a parent node and has its children
nodes. Note that an RA is also a TU. That is, an RA also receives
multicast data from TO. In ECTP-3, a TU may act as an RA in the
connection, or some designated RAs may be used for the error recovery
in the connection. It depends on the deployment of ECTP-3.
SU (Sending TS-User)
An SU is a TU who can send unicast data to TO. In ECTP-3 connection,
a TU becomes an SU when it has a token and it can thus transmit
unicast data to TO.
4.2. Control Tree
An ECTP-3 connection may configure a control tree for scalable
reliability control as follows.
Kim and Koh Expires October 18, 2007 [Page 11]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
TO
^^^
/ | \
ACKs / | \
/ | \
/ | \
/ | \
/ | \
RA RA RA
^^ ^^^ ^^
/ | / | \ | \
/ | / | \ | \
/ | / | \ | \
TU TU TU TU TU TU TU
Figure 3. ECTP-3 Control Tree
In the ECTP-3 control tree, TO is on the top of the tree, which is in
the Tree Level 0. RA is a parent node on the tree and has one or more
children. The TU nodes, not designated as RA, cannot have its
children. Such a control tree will be configured in the connection
creation phase.
Error recovery in ECTP-3 will be performed within each local group
defined by the control tree. A child can request retransmission to
its parent RA. In response to the request, the parent RA will
retransmit the data packets to the children, if it has them in the
buffer. An RA is also a TU, and it thus receives the multicast data
from the TO. The control tree is applied only for forward multicast
data channel. The control tree does not apply to the backward unicast
data channel.
4.3. Data Channels
In ECTP-3, the two types of data channels are used: forward and
backward data channels.
Forward Data Channel
The forward data channel is used for TO to send multicast data to the
other TUs. The forward data channel can also be used for an RA to
send Retransmission Data to its children TUs.
Kim and Koh Expires October 18, 2007 [Page 12]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
The forward data channel address consists of the group (multicast) IP
address and the group port. TO sends multicast data via DATA packets
by using the forward data channel address. TO and RAs can also
retransmit multicast data via RDATA packets by using the forward data
channel address.
The following figure illustrates the use of the forward multicast
data channels in ECTP-3.
Backward Data Channel
The backward data channel is used by an SU to send unicast datat to
TO. The backward channel address consists of the IP address of TO and
the group port.
The following figure illustrates the use of the backward unicast data
channels in ECTP-3.
Each SU must send unicast data via DATA and RDATA packets to TO by
using this backward data channel address as the destination address.
On the other hand, TO must bind its backward data channel address to
receive the unicast data from any SU in the connection.
4.4. Addressing
In ECTP-3, each packet uses the following types of IP addresses and
port number for its source and destination address:
- Group IP address and Local IP address;
- Group port and Local port.
Group and Local IP Addresses
The group IP address is the IP multicast address (e.g., Class D
address for IPv4), whereas a local IP address represents the unicast
IP address for each of the ECTP participants: TO, RAs and TUs.
The group IP address is used as the destination address of the
packets that need to be multicast by TO and RAs. For example, the CCR
and DATA packets of TO will use the group IP address as the
destination address of the associated IP packets. Each RA also uses
the group IP address as the destination address of the RDATA and HB
packets.
The local IP address of each participant is used as the source and
destination IP address for the unicast packets, and also the source
address for the multicast packets.
Kim and Koh Expires October 18, 2007 [Page 13]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
It is noted that the group IP address and the local IP address of TO
must be announced to all the prospective participants via an out-of-
band signaling such as Web announcement.
Group and Local Ports
The group port represents the port number that has been announced to
all of the ECTP-3 participants before the connection. In ECTP-3, the
group port will typically be used as the destination port of the
ECTP-3 multicast packets transmitted by TO or RAs, such as CCR and
DATA. That is, each TU should bind to the group IP address and port
so as to receive the relevant ECTP-3 multicast packets.
The group port number is also used by SU to send unicast data to TO.
That is, TO will bind to the local port with its local IP address so
as to receive the unicast data from any SU. In particular, the group
port is also used as the destination port of the packet that requests
a certain action, such as LJR.
On the other hand, in the other cases that are not described above,
the ECTP-3 packet will use the local port number as source and/or
destination ports. For example, in response to the Late Join Request
from a TU, the TO will respond with the Late Join Confirm message
that use the local port of the TU as the destination port.
The detailed use of the local IP address and port will be specified
for each of the ECTP-3 packets in the later section.
Addresses of Data Channels
In ECTP-3, all the data packets use the group port number as the
destination port. Accordingly, before the connection creation, the
following information must be announced to all of the ECTP-3
participants via an out-of-band signaling such as Web announcement.
- Group IP address and Group port;
- Local IP address of TO.
The following figure describes the use of IP address and port for the
forward and backward data channels. The forward multicast data
packets use the group IP address and port number as the destination
address of the data packets, whereas the backward data packets use
the local IP address of TO and the group port number as the
destination address.
Kim and Koh Expires October 18, 2007 [Page 14]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
4.5. Tokens
In ECTP-3, a token represents the right for a TU to send a unicast
data to TO. Before transmitting the data, each TS-user must get a
token from the TO, as per the Token Control procedures of ECTP-3.
Each token is represented as a 1-byte non-negative integer in ECTP-3.
Such a token number (or Token ID) will be assigned by TO when a TU
requests a token in the connection. Token ID is ranged between 1 and
255. The Token ID of 0 is reserved for use of TO. At the TO side,
the Token ID can be used to identify who is sending the unicast data.
5. Packets
An ECTP packet contains a 16-byte base header together with either
extension elements or user data. It is noted that the data packets do
not include any extension elements.
In this section, we give a brief sketch of the ECTP-3 packet format.
More detailed description on the packet format is given in [6].
5.1. Base Header
The 16-byte base header contains the information helpful to all the
protocol operations, in particular for the data packets.
The base header contains the following information:
Next Element (4 bits)
This specifies the type of the extension element immediately
following the base header. The encoding values of the extension
elements will be described later. The extension element value of
0000 means that the next part of this packet contains the user data,
if any.
Version (2 bits)
This defines the version of the ECTP-3 protocol. Its current version
is encoded as 00.
CT (Connection Type): (2 bits)
Kim and Koh Expires October 18, 2007 [Page 15]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
This specifies the type of the ECTP connection. The encoding value
for the connection type is as follows:
01 simplex multicast connection (for ECTP-1 and ECTP-2);
10 duplex multicast connection (for ECTP-3 and ECTP-4);
11 N-lex multicast connection (for ECTP-5 and ECTP-6);
The value 00 is reserved for future use. In this ECTP-3 specification,
the CT must be set as 10. It is noted that this definition is
compatible with the specifications of ECTP-1 and ECTP-2.
Packet Type (8 bits)
It indicates the type of this ECTP-3 packet. The encoding values of
the ECTP-3 packets will be described later.
Checksum (16 bits)
This is used to check the validity of the ECTP-3 packet that includes
the base header, extension header and/or user data. The ECTP-3
checksum is calculated by using the conventional complement
arithmetic operation, as done in TCP and UDP.
Connection ID (32 bits)
The Connection ID is used to identify an ECTP connection by the ECTP
host. It may also be used to verify the connection. In the connection
setup phase, this information must first be informed by TO to the
other participants via the CCR or LJC packets. All the otherECTP-3
packets must set this field to be the value announced by TO.
PSN (32 bits)
This value represents the sequence number of the data packet for the
ECTP-3 DATA or RDATA packets. For some control packets such as NDATA
or HB packets, this value has a different semantic, which will be
described later. For the other control packets, it is ignored. This
sequence number is a 32-bit unsigned number that starts with the
initial sequence number and increases by 1, and wraps back around to
1 after reaching 232-1.
Payload Length (16 bits)
This value indicates the total length of the extension headers or
user data in byte, following the base header.
Kim and Koh Expires October 18, 2007 [Page 16]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
F (1 bit)
It is a flag bit. The use of this flag depends on the packet types:
For the LJC (Late Join Confirm), TJC (Tree Join Confirm), Token
Get Confirm (TGC), Token Return Confirm (TRC) packets, the F = 1
indicates that each of the corresponding join request is accepted.
F is set to 0, otherwise;
For the ULR (User Leave Request) packet, F is set to 1 for the
user-invoked leave, or set to 0 for the troublemaker ejection;
For the CTR (Connection Termination Request) packet, F is set to
1 for an abnormal termination, or set to 0 for the normal
termination after all the data have been transmitted;
For the token control operations, TGR and TRR request messages
use this flag so as to indicate whether this is the TO-initiated
or TU-initiated token control.
For the other packets, the detailed description is given in the
protocol procedure section. Otherwise, if any usage is not specified,
this field will be ignored.
Reserved (7 bit)
This field is reserved for future use.
Token ID (8 bit)
The Token ID is valid only for data packets: DATA and RDATA packets.
This represents who is the source of the data packets. The Token ID
value is ranged between 0 and 255. Each SU receives a Token ID from
TO via the token get procedure and sets this field to be the number
assigned by TO. The forward multicast data packets of TO set this
field to be 0.
5.2. Extension Elements
The ECTP packets used for control may contain one or more extension
elements along with the base header. The based header and each
extension element has the field of Next Element that points to the
immediately succeeding extension element, if any.
The Next Element field is encoded as shown in the following table. It
is noted that the 0000 means No Element. Accordingly, the last
extension element of an ECTP packet must set its Next Element field
to 0000.
Kim and Koh Expires October 18, 2007 [Page 17]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
Table 1. Extension Elements
+-------------------+---------+-----------------+
| Extension Element | Encoding| Length (bytes) |
+-------------------+---------+-----------------+
| End of Element | 0000 | 0 |
+-------------------+---------+-----------------+
| Connection | 0001 | 4 |
+-------------------+---------+-----------------+
| Acknowledgement | 0010 | Variable |
+-------------------+---------+-----------------+
| Membership | 0011 | 4 |
+-------------------+---------+-----------------+
| Timestamp Report | 0100 | 12 |
+-------------------+---------+-----------------+
| IP Address | 0101 | 8 or 20 |
+-------------------+---------+-----------------+
It is noted that all the extension elements other than Address
element have already been defined in ECTP-1 and ECTP-2. Accordingly,
the encoding values of those extension elements will be reused in
ECTP-3. It is noted that the encoding value of 0101 is reserved for
the QoS extension element, which is not used in ECTP-3, and may be
defined for the QoS management in ECTP-4.
All the extension elements described in the table will be defined in
this section by encompassing the requirements for the ECTP-3 protocol.
Connection Element
The connection extension element contains overall information on the
ECTP-3 transport connection. It is encoded as 0001 in the Next
Element field of the preceding element or based header. This
extension element must be included in the CCR, LJC and TGR packets.
Acknowledgement Element
This extension element provides information on the status of the
packet reception at the child node, which will be referred to by the
parent node for the error, flow and congestion control. This
extension header is attached to the ACK packet. It is encoded as
0010 in the Next Element field of the preceding element or based
header.
Membership Element
Kim and Koh Expires October 18, 2007 [Page 18]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
This 4-byte extension element contains information on the tree
membership. It is encoded as 0011 in the Next Element field of the
preceding element or based header.
Timestamp Element
The Timestamp element is encoded as 0100 in the Next Element field of
the preceding element or based header. The ECTP-3 uses the 8-byte
timestamp so as to calculate Round Trip Time (RTT).
Address Element
The Address extension element is encoded as 0110 in the Next Element
field of the preceding element or based header. This element is
attached to the packet when the protocol needs to specify the IPv4 or
IPv6 address of the participant concerned. For example, the LJC
packet of TO may include this element so as to inform a late-joining
TU about the IP address of the promising RA that the TU may connect.
5.3. Packet Format
ECTP-3 defines the total 18 packet types: 3 types of data packets and
15 types of control packets. The following table summarizes the
packets used in ECTP-3.
Table 2. ECTP-3 Packets
+----------------------------+-------+----------+-----------+---+
| Full Name |Acronym| From | To |M/U|
+----------------------------+-------+----------+-----------+---+
|Connection Creation Request | CCR | TO | TUs | M |
+----------------------------+-------+----------+-----------+---+
|Connection Creation Confirm | CCC | TU | TO | U |
+----------------------------+-------+----------+-----------+---+
| Tree Join Request | TJR | Child | Parent | U |
+----------------------------+-------+----------+-----------+---+
| Tree Join Confirm | TJC | Parent | Child | U |
+----------------------------+-------+----------+-----------+---+
| Data | DATA | TO/SU | TUs/TO |M/U|
+----------------------------+-------+----------+-----------+---+
| Null Data | NDATA | TO | TUs | M |
+----------------------------+-------+----------+-----------+---+
| Retransmission Data | RDATA |Parent/SU |Children/TO|M/U|
+----------------------------+-------+----------+-----------+---+
| Acknowledgement | ACK | Child | Parent | U |
+----------------------------+-------+----------+-----------+---+
Kim and Koh Expires October 18, 2007 [Page 19]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
| Heartbeat | HB |Parent/SU |Children/TO|M/U|
+----------------------------+-------+----------+-----------+---+
| Heartbeat ACK | HBACK | Child/TO | Parent/SU | U |
+----------------------------+-------+----------+-----------+---+
| Late Join Request | LJR | TU | TO | U |
+----------------------------+-------+----------+-----------+---+
| Late Join Confirm | LJC | TO | TU | U |
+----------------------------+-------+----------+-----------+---+
| User Leave Request | ULR |Child/Par.|Par./Child | U |
+----------------------------+-------+----------+-----------+---+
| Connection Term. Request | CTR | TO | TUs | M |
+----------------------------+-------+----------+-----------+---+
| Token Get Request | TGR | SU | TO | U |
+----------------------------+-------+----------+-----------+---+
| Token Get Confirm | TGC | TO | SU | U |
+----------------------------+-------+----------+-----------+---+
| Token Return Request | TRR | SU | TO | U |
+----------------------------+-------+----------+-----------+---+
| Token Return Confirm | TRC | TO | SU | U |
+----------------------------+-------+----------+-----------+---+
(*) In the table, M/U means Multicast and Unicast.
In the table, the parent node represents TO or RA, and the packets
used for token control can be initiated by SU as well as TO. As also
shown in the table, all of the ECTP-3 packets are exchanged between
the participants in the request-and-conform manner. For example, the
CCR request expects to receive the corresponding CCC confirm message.
The ACK messages will be used to confirm the DATA and RDATA messages.
On the other hand, ULR and CTR messages do not require any responding
confirm messages.
Kim and Koh Expires October 18, 2007 [Page 20]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
6. Procedures
This section describes the protocol procedures of ECTP-3. Before an
ECTP-3 connection is created, the following address information
should be announced to the prospective participants: TU and RA.
- Multicast IP address of the group
- Group port number
- IP address of TO
This information may be announced to the prospective participants via
an out-of-band signaling mechanism such as Web announcement.
Accordingly, the prospective TU should be able to bind the group IP
address and port so as to receive the CCR packet from the TO. A
prospective late-joiner TU should also send a LJR packet to the TO.
6.1. Connection Creation
An ECTP-3 connection will begin when TO sends the first ECTP-packet,
CCR, to the group over the multicast group IP address and port. An
ECTP-3 control tree is also configured in the connection creation
phase.
TO begins the connection creation operation by sending the CCR packet
to the group. The CCR packet contains the generic information on the
connection element such as TCO (Tree Configuration Option), RO
(Reliability Option), and MSS (Maximum Segment Size).
After sending the CCR packet, TO starts the CCT (Connection Creation
Timer). Only the CCC packets will be allowed during the CCT timer.
Each TU should join the control tree before responding with a CCC
packet. In the connection creation phase, each TU can join only the
TO as the parent.
To join the control tree, each TU sends a TJR packet to TO. TO then
responds to the TU with the TJC packet. The TJC packet should
indicate whether the tree join request is accepted or not by using
the F flag of the base header.
The TJC packet should also contain the Child ID and Tree Level in the
membership element. The TJC packet may optionally contain the address
element to represent a promising parent RA for the TU. It needs to
ensure that the parent RA has already been on the tree.
Kim and Koh Expires October 18, 2007 [Page 21]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
6.2. Late Join
Some of the prospective participants may join the ECTP-3 connection
as a late joiner. In particular, any TU is allowed to join the
connection as a late joiner, after the CCT timer expires.
The late joiner TU sends an LJR packet to TO. In response to the LJR
packet, the TO sends an LJC packet to the TU, which should indicate
that the request is accepted or not by using the F flag of the base
header.
The LJC packet should contain the connection element. It may also
contain the address element so as to recommend the promising parent
RA for the TU. If no address element is indicated the TU may try to
join the TO in the control tree configuration.
If the LJC packet does not arrive within the RXT (Retransmission
Timeout), the late joiner may try to send the LJR packet again.
To join the control tree, the TU should send a TJR packet to the
promising parent RA, as indicated by TO via the LJC packet, or to the
parent TO. The TO then responds with the TJC packet to the TU.
If the TJC packet does not arrive within the RXT, the late joiner may
try to send the TJR packet again.
In this way, the ECTP-3 control tree will be configured in the
hierarchical manner.
6.3. Forward Data Transport
In the ECTP-3 forward data channel, the TO sends multicast DATA
packets to the group. When a data packet loss is detected by the
receiving TU, the retransmission for error recovery will be performed
within a local group that is defined by the control tree.
On the other hand, ECTP-3 provides three kinds of Reliability Option
(RO) for error control operations: reliable, semi-reliable, and
unreliable. The semantics of the RO are as follows:
1) Reliable Transport (error recovery)
In the reliable option, all the DATA packets will be recovered by
the parent on the tree. Each child requests the retransmission
via ACK packet, and the parent sends the corresponding RDATA
packet over the multicast address.
Kim and Koh Expires October 18, 2007 [Page 22]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
2) Semi-reliable Transport (partial error recovery)
In the semi-reliable option, the retransmissions of the lost
packets are limited by the buffer status of the parent node. That
is, the parent node will retransmit only the DATA packets that
are at present being contained in the buffer. It is noted that
the parent node need not keep all the DATA packets in the buffer.
The parent will rather delete the old DATA packets from the
buffer, which have not been acknowledged by the children.
It is noted in the semi-reliable option that the parent should
announce its children about which DATA packets could be recovered
in the error recovery. For this purpose, the parent node will use
the periodic HB packets. Specifically, the PSN filed of the base
header of the HB packet will indicate the lowest sequence number
of DATA packets that are contained in the buffer.
3) Unreliable Transport (no error recovery)
In the unreliable option, the RDATA packets are not used. It is
also noted that each ACK packet does not mean any retransmission
request to the parent. The ACK packets are instead used by the
parent to monitor the status of the connection such as ADN.
After the connection creation, the TO can send multicast DATA packets
to the group members.
TO will generate DATA packets by the segmentation procedure. To do
this, TO splits a multicast data stream of application into multiple
DATA packets. Each DATA packet has its own sequence number. When TO
has no data to transmit, TO may transmit the periodic NDATA packets
in the connection pause period.
Each TU delivers all the data packets received to the application in
the order sent by TO. Each receiver reassembles the received packets.
Corrupted and lost packets are detected by using a checksum and
sequence number. A corrupted packet is also considered as a loss. The
lost DATA packets are recovered in the error control function.
ECTP-3 uses the flow control based on a fixed-size window. The window
size represents the number of unacknowledged data packets in the
sending buffer. TO can maximally transmit the window size of data
packets at the configured data transmission rate. In ECTP-3, the
transmission rate of multicast data is controlled by the rate-based
congestion control mechanisms.
Kim and Koh Expires October 18, 2007 [Page 23]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
A new DATA packet is sequentially numbered by TO. The sequence number
of the DATA packet starts from Initial PSN and increases by 1. The
sequence number is used to detect lost data packets by receivers. The
Initial PSN is randomly generated other than 0. The sequence number
of 0 is reserved. The packet sequence number is increased for each
new DATA packet. Modulo 232 arithmetic is used and the sequence
number wraps back around to 1 after reaching <232 1>. The Initial
PSN number will be informed to the TUs by way of CCR or LJC packet.
6.4. Reliability Control for Reliable Transport
When the reliability option for the connection indicates Reliable (RO
= 10), all the DATA packets should be recovered in the error recovery
operations.
Error Detection
The checksum field of the base header is used for detection of packet
corruption, and the PSN field is for detection of a packet loss. When
a data packet is received, each receiver examines the checksum. If
the checksum field is invalid, the packet is regarded as a corruption
and shall be discarded. A corruption is treated as a loss. The loss
can be detected as a gap of two consecutive sequence numbers for DATA
packets. The loss information is recorded into the ACK bitmap, which
is attached to the subsequent ACK packets.
ACK packets are used for the retransmission requests. When a receiver
detects a gap in the sequence numbers of received packets, it sets to
zero the bit of the ACK bitmap that corresponds to the lost DATA
packet. The ACK bitmap is included into the acknowledgement element,
which is attached to the subsequent ACK packet and delivered to the
parent by the ACK generation mechanisms.
For a local group, a parent and its children maintain the Lowest
Sequence Number (LSN) variables to determine the status of DATA
packets. For a child, the LSN represents the sequence number of the
lowest numbered DATA packet that the child has not received. For a
parent, the LSN represents the sequence number of the lowest numbered
DT packet that has not been acknowledged by its children.
To request the retransmissions of lost data, each child makes an
acknowledgement element containing the LSN, Valid Bitmap Length and
ACK Bitmap. The ACK Bitmap specifies a success or a failure of a
packet delivery for each DATA packet; 1 for success and 0 for failure.
Suppose Bitmap = 01101111, LSN = 15. Then the DATA packets with the
sequence number 15 and 18 are lost.
Kim and Koh Expires October 18, 2007 [Page 24]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
Retransmission Request by ACK Generation
Each child generates an ACK packet by ACK Generation Number (AGN).
Each child sends an ACK packet to its parent every AGN number of
packets. To do this, a child receives a Child ID from its parent in
tree configuration, which is contained in the tree membership element
of the TJC packet.
Each child sends an ACK packet to its parent, if the PSN number of a
DATA packet modulo AGN equals Child ID modulo AGN, i.e., if
PSN % AGN = Child ID % AGN.
Suppose AGN = 8 and Child ID = 2. The child generates an ACK packet
for the DT packets whose sequence numbers are 2, 10, 18, 26, etc.
This ACK generation rule is applied when the corresponding DT packet
is received or detected as a loss by the child.
Retransmissions and ACK Aggregation by RA
Each parent uses ACK packets to gather status information for the
error recovery. Each time a parent receives an ACK packet from any of
its children, it records and updates the status information on which
packets have been successfully received by its children.
A DATA packet is defined as a stable packet if all of the children
have received it. The stable DATA packets are released out of the
buffer memory of the parent. When a parent receives an ACK packet
from one of its children, if one or more packet losses are indicated,
the parent transmits the corresponding RDATA packets to all of its
children over its multicast control address.
After a parent retransmits an RDATA packet, it will ignore any
subsequent retransmission requests for the same packet during the RXT
period.
An ACK packet contains information on the number of active
descendants (ADN). The parent aggregates the ADN variables for all of
its children, and sends the aggregated information to its parent
(when it sends an ACK to the parent.
Kim and Koh Expires October 18, 2007 [Page 25]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
6.5. Control Tree Maintenance
The ECTP-3 control tree is maintained using the HB and HBACK packets.
Each parent RA advertises periodic HB packets using Heartbeat
Generation Time (HGT), after it becomes an on-tree node. The default
HGT is 3 second. The HB packet contains the information (Child ID of
the membership element) about which child should respond to this HB
packet. The corresponding child should respond with the HBACK packet.
In ECTP-3, the exchange of HB and HBACK packets between a parent and
children is done with the following three purposes:
1) Check whether the tree node is still alive
A child detects the failure of its parent, if it cannot receive
any packets such as HB and RDATA packets from the parent during
the time interval of FDN (Failure Detection Number) x Heartbeat
Generation Time (HGT). Then the child begins to find an alternate
parent. The default FDN is 3.
A parent detects the failure of a child, if it cannot hear any
HBACK packets from the child for the FDN consecutive HB packets.
If a child is detected as a failure, the parent sends an ULR
packet (for troublemaker ejection) to the failed child, and
clears the child out of its children list.
2) Information on DATA packets that can be recovered
The HB packet of the parent contains the information in the PSN
field of the header, which represents the lowest sequence number
of DATA packet that is contained in the buffer. This information
will be referred to by the children in the ACK generation.
3) Calculation of local RTT
On the other hand, the HB and HBACK can also be used for
calculate the Round Trip Time (RTT) for a local group. A parent
RA sends a HB packet containing a timestamp element to its
children every HGT interval. The corresponding child will also
contain the timestamp element as it is in the HBACK packet.
Receiving an HBACK packet from a child, the parent RA calculates
the RTT by subtracting Timestamp from the current time. The RTT
is recorded into the children list. The parent determines the
Local RTT by the maxim RTT value for its children.
Kim and Koh Expires October 18, 2007 [Page 26]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
6.6. Congestion Control for Forward Data Channel
For the forward multicast data transport, the congestion control will
be done by TO to adjust the data transmission rate. The adjustment of
transmission rate of TO is controlled based on the packet loss rate
and the RTT for the local group. The RTT for the local group may be
calculated using the HB and HBACK packets.
The congestion control algorithm (i.e., the algorithm for
transmission rate adjustment of TO) follows the well-known TCP-
Friendly Multicast Congestion Control (TFMCC) algorithm, which has
been developed in the IETF RMT WG. The TFMCC algorithm is featured
by:
TFMCC is a congestion control mechanism for multicast
transmissions in a best-effort Internet environment. It is a
single-rate congestion control scheme, where the sending rate is
adapted to the receiver experiencing the worst network conditions.
TFMCC is reasonably fair when competing for bandwidth with TCP
flows and has a relatively low variation of throughput over time,
making it suitable for applications such as streaming media where a
relatively smooth sending rate is of importance.
In ECTP-3, the TO will calculate the sending rate X, which is based
on the s (MSS), R (local RTT), and p (packet loss rate). It is noted
that the packet loss rate will be determined by TO as the number of
loss events as a fraction of the number of packets transmitted. The
RTT will also be calculated in the Control Tree Maintenance operation.
TO will take the maximum value of the RTTs and packet loss rate that
have been reported from its children.
6.7. Token Control
In ECTP-3, a token represents the right to send a data to the TO in
the backward unicast data channel. Each TU who wants to transmit a
data to TO must get a token from the TO. The TU will be an SU after
getting a token from TO. In this way, TO can control the maximum
number of tokens simultaneously active for the connection.
An SU returns the token after completing the unicast data
transmission to TO.
Kim and Koh Expires October 18, 2007 [Page 27]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
The TU can get a token from TO. In this Token Get operation, the TU
first requests a token to TO. The following figure shows the
operations for Token Get.
To get a token in the Token Get operation, a TU sends a TGR message
to TO, and then waits for the corresponding TGC message. In response
to the TGR packet, the TO should send a TGC message to the TU. The
TGC message should indicate whether the request is accepted or not by
using the F flag of the base header. In case of the acceptance, the
message will also contain a valid Token ID and Initial PSN in the
base header. If the responding TGC message has not arrived until the
RTO timer expires, the TU may send the TGR message again.
The TU (i.e., SU) should respond with the TGC message that sets the F
flag to 0 (acceptance). If the responding TGC message has not
arrived from the SU until the RTO timer expires, the TO may send the
TGR message to SU again.
When completing data transmission, the SU may return the token to TO.
The SU can return its token to TO. In this Token Return operation,
the TU sends the TRR packet to TO.
In the Token Return case, the SU sends a TRR message to TO. The TO
then responds with the TRC message. On the other hand, in the Token
Withdrawal case, the TO may enforce the concerned SU to return the
token by sending a TRR message. If the responding TRC message has not
arrived until the RTO timer expires, the TRR message may be sent
again.
6.8. Backward Data Transport
After getting a token from TO, an SU can transmit unicast DATA
packets to TO.
In the backward unicast data channel, the initial sequence number
(ISN) of SU is indicated in the PSN field of the header of the TGR
(in the Token Get case) or TGC (in the Token Give case). The ISN is
randomly generated other than 0, as done in the forward data
channel.
The DATA packets transmitted by SU must indicate the Token ID that is
allocated by TO.
The reliability control for the unicast data channel will be done
between SU and TO. In the data transmission phase, the SU sends a HB
packet to the TO every HGT time interval. The TO should respond with
the HBACK packet to the SU. The HBACK packet may indicate the
Kim and Koh Expires October 18, 2007 [Page 28]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
retransmission request in the Acknowledgement element. In this case,
the SU sends the corresponding RDATA packet.
The HB and HBACK packet will also be used to calculate the RTT
between SU and TO.
The congestion control (sending rate adjustment) of SU is performed,
as done in the forward data channel. Based on the packet loss rate
and RTT, the SU calculate the transmission rate.
6.9. Connection Management
In the User Leave case, the child node will send a ULR message to its
parent (RA or TO). In the Troublemaker Ejection case, the parent will
request the concerned child to leave the connection. In both cases,
the ULR message does not require the corresponding confirm message.
It is noted that the User Leave operation is performed between a
parent and a child over the control tree, rather than between TO and
TU. The troublemaker ejection may be applied to the child that has
not been responding during a certain time interval in the HB and
HBACK operation for tree maintenance. It is not recommended to apply
the troublemaker ejection to an RA node that has one or more children.
In ECTP-3, the TO may pause the connection temporarily for a certain
reason. For example, when it has no user data to transmit, the TO may
pause the connection. The connection may also resume. During the
connection pause period, the TO may send NDATA packet. The TO may
also terminate the connection when it has completed the data
transmission. The TO performs the connection termination by sending a
CTR message to the group.
7. Security Considerations
TBD
8. IANA Considerations
TBD
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Kim and Koh Expires October 18, 2007 [Page 29]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[1] ITU-T Recommendation X.601 (2000), Multi-Peer Communications
Framework
[2] ITU-T Recommendation X.602 (2004) | ISO/IEC 16511: 2005,
Information Technology Group Management Protocol (GMP)
[3] ITU-T Recommendation X.605 (1998) | ISO/IEC 13252: 1999,
Information Technology Enhanced Communications Transport
Service Definition
[4] ITU-T Recommendation X.606 (2001) | ISO/IEC 14476-1: 2002,
Information Technology Enhanced Communications Transport
Protocol: Specification of simplex multicast transport (ECTP-1)
[5] ITU-T Recommendation X.606.1 (2002) | ISO/IEC 14476-2: 2003,
Information Technology Enhanced Communications Transport
Protocol: Specification of QoS Management for Simplex Multicast
Transport (ECTP-2)
[6] ITU-T Recommendation X.607 (2007) | ISO/IEC 14476-3:2007,
Information Technology Enhanced Communications Transport
Protocol: Specification of Duplex Multicast Transport (ECTP-3)
Author's Addresses
Seok Joo Koh
Kyungpook National University, KOREA
sjkoh@knu.ac.kr
Dae Young Kim
Chungnam National University, KOREA
dykim@cnu.ac.kr
Kim and Koh Expires October 18, 2007 [Page 30]
Internet-Draft ECTP for Duplex Multicast Transport April 2007
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed 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.
Disclaimer of Validity
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, THE IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim and Koh Expires October 18, 2007 [Page 31]