Internet Draft: RMTP-II Specification B. Whetten, M. Basavaiah
draft-whetten-rmtp-ii-app-00.txt GlobalCast Communications, Inc.
Expires: Six months S. Paul
Lucent Technologies, Bell Labs
T. Montgomery
West Virginia University
N. Rastogi, J. Conlan, T. Yeh
GlobalCast Communications, Inc.
April 8, 1998
THE RMTP-II PROTOCOL APPENDICES
Status of this Memo
This document is 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 not appropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Abstract
These appendices furnish supplementary information for the RMTP-II
protocol draft. The appendices contain information on design
rationale, congestion control algorithms, SNMP MIBs, forward error
correction, time bounded reliability, and work in progress
RMTP-II APPENDICES [Page 1]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX A - DESIGN RATIONALE
It is widely recognized that no single reliable multicast protocol
can meet the needs of all applications over all network types.
RMTP-II targets a specific subset of application and network types.
Targeted Network Types
RMTP-II is designed to work over a controlled network, which
typically has a single administrative domain. These networks have
the fewest barriers to IP multicast and the greatest need for
reliable multicast services.
There is no current standard for bridging IP multicast over multiple
administrative domains and heterogeneous routing protocols, although
work is continuing in this area. In addition, internet service
providers have concerns about peering and settlement for IP multicast
traffic which spans multiple domains. These issues are delaying the
deployment of widespread native IP multicast in the Internet. In
contrast, a number of private companies, satellite operators, and
ISPs have turned on, or are in the process of turning on, IP
multicast for use strictly within their networks.
In a conrolled intranet environment, a single network management
organization typically controls each of the networks in which RMTP-II
will be deployed. In order to promote the adoption of RMTP-II the
following are required:
- Network managers require tools for the monitoring and control of the
reliable multicast traffic.
- Network managers can provide manual configuration of the protocol,
although requirements for this should be minimized.
- Network managers can provide additional control over network
congestion in addition to automatic end-to-end congestion control.
- Network managers can have direct control over multicast senders.
RMTP-II takes these requirements into account by providing the
following features:
- RMTP-II provides SNMP management of the control nodes.
- RMTP-II segments node operations into trusted nodes (control nodes),
and user nodes (sender and receiver nodes).
- RMTP-II allows manual or automatic tree configuration.
RMTP-II APPENDICES [Page 2]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
- RMTP-II provides the top node as a centralized point through which
network managers control the rate parameters and congestion
algorithms of the senders.
- RMTP-II provides access control of multicast senders.
While the majority of controlled networks are symmetrical and support
many-to-many multicast, a significant percentage are asymmetrical and
support few-to-many multicast. RMTP-II takes this into account by
not requiring any many-to-many multicast services, and by dividing
the communication paths of the protocol into two pieces - the data
channel and the control channel. The use of a separately defined
data channel, which is not assumed to overlap with the control
channel, allows RMTP-II to support asymmetrical networks, such as a
one way satellite data feed with a terrestrial return path, and ADSL.
A number of extensions to IP multicast, such as subtree multicast,
ACK accumulation, and PGM, have been proposed which can run in the
routers. This would make tree based reliable multicast protocols
easier to configure and to scale more readily. To date, none of
these mechanisms have been standardized or released by a major
commercial vendor. RMTP-II is designed with these mechanisms,
especially subtree multicast, in mind. However, since the current
goal of RMTP-II is to provide an immediate, graceful deployment path,
these features will only be supported as options.
Targeted Application Types
Multicast applications can be divided into two classes, few-to-many
and many-to-many. Many-to-many applications include server
replication, multi-user games, small group conferencing, and computer
supported collaborative work. These applications typically treat all
members in a group as peers, require special semantics such as total
ordering of messages from multiple senders, and rarely require
scalability beyond 100 receivers. Other protocols, such as RMP
[WMK94], have been designed to support these many-many applications.
RMTP-II focuses on few-to-many applications, such as multicast file
transfer, electronic software distribution, real time news and
financial distribution, "push" applications, audio/video/data
broadcasts, distance learning, and some types of server replication.
These applications typically require at most 50 simultaneous senders,
10,000 or more receivers, have different roles for senders and
receivers, and do not require total ordering of messages between
senders. These applications may require strong guarantees on
delivery, streaming of data in real time, or support for synchronous
streaming. RMTP-II is designed to meet all of these requirements.
RMTP-II APPENDICES [Page 3]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
RMTP-II provides a strong, but fully distributed membership protocol
which supports scaling to 10,000 or more simultaneous receivers while
providing strong guarantees on message delivery. RMTP-II is a
streaming protocol and provides support for real time applications.
RMTP-II meets the requirement of synchronous streaming applications
with a new quality of service level called Time Bounded Reliability.
Time Bounded Reliability restricts recovery of packets to a limited
time interval. This keeps dropped packets from blocking the rest of
a synchronous data stream and prevents a failed receiver from
affecting other receivers.
RMTP-II takes the application semantics into account by dividing the
nodes' roles into senders, receivers, and control nodes.
Other Design Considerations
In addition to the requirements imposed by the targeted network and
application types, RMTP-II takes into account the following factors
and design goals:
- ACK and NACK implosion must be prevented.
- Control traffic, retransmission traffic, and retransmission latency
must be minimized.
- End-to-end congestion control algorithms must be strongly supported
as they become mature.
- Simplicity of design is required for ease of use and development.
- Extensibility must be supported for future development.
RMTP-II APPENDICES [Page 4]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX B - CONGESTION CONTROL ALGORITHMS
Work in progress.
RMTP-II APPENDICES [Page 5]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX C - SNMP MIBS FOR RMTP-II
This appendix defines the SNMP MIB for the RMTP-II protocol and its
entities. The MIBS are grouped according to the functionality of the
RMTP-II nodes.
RMTP DEFINITIONS ::= BEGIN
IMPORTS
enterprises, Counter, Gauge, IpAddress
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
TRAP-TYPE
FROM RFC-1215
PhysAddress
FROM RFC1213-MIB;
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
globalcast OBJECT IDENTIFIER ::= { enterprises 2751 }
rmtp OBJECT IDENTIFIER ::= { globalcast 1 }
ln OBJECT IDENTIFIER ::= { rmtp 1 }
sd OBJECT IDENTIFIER ::= { rmtp 2 }
ag OBJECT IDENTIFIER ::= { rmtp 3 }
dr OBJECT IDENTIFIER ::= { rmtp 4 }
tn OBJECT IDENTIFIER ::= { rmtp 5 }
common OBJECT IDENTIFIER ::= { rmtp 6 }
------------------
-- Group common --
------------------
inPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of packets received, unicast and multicast"
::= {common 1}
outPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
RMTP-II APPENDICES [Page 6]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
DESCRIPTION "The number of packets sent"
::= {common 2}
inMcastPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of multicast packets received"
::= {common 3}
outMcastPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of multicast packets sent"
::= {common 4}
--------------
-- Group ln --
--------------
lnParentAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the parent node in the RMTP tree"
::= {ln 1}
lnParentPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "UDP port of the parent node in the RMTP tree"
::= {ln 2}
lnHbPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of Heartbeat packets received"
::= {ln 3}
lnNumRejoin OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of Rejoin requests made internally"
::= {ln 4}
RMTP-II APPENDICES [Page 7]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
lnStreamTable OBJECT-TYPE
SYNTAX SEQUENCE OF StreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Stream table - basic information."
::= {ln 5 }
lnStreamEntry OBJECT-TYPE
SYNTAX LnStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one stream."
INDEX {lnStreamId}
::= {lnStreamTable 1}
LnStreamEntry ::= SEQUENCE {
lnstreamId INTEGER,
lnInDataPkts Counter,
lnInRxPkts Counter,
lnInNullDataPkts Counter,
lnOuthackPkts Counter,
lnDroppedPkts Counter,
lnQos INTEGER,
lnState INTEGER,
lnSataChannel OCTET STRING
}
lnStreamId OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the stream"
::= {lnStreamEntry 1}
lnInDataPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of data packets received"
::= {lnStreamEntry 2}
lnInRxPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of retransmission packets received"
::= {lnStreamEntry 3}
RMTP-II APPENDICES [Page 8]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
lnInNullDataPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of null data packets received"
::= {lnStreamEntry 4}
lnOutHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets sent to the parent node"
::= {lnStreamEntry 5}
lnDroppedPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of packets missed or dropped"
::= {lnStreamEntry 6}
lnQos OBJECT-TYPE
SYNTAX INTEGER {
unordered(1),
ordered(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "The current QoS for the stream"
::= {lnStreamEntry 7}
lnState OBJECT-TYPE
SYNTAX INTEGER {
joining(1),
joinAck(2),
started(3),
completed(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "Current state of the stream"
::= {lnStreamEntry 8}
lnDataChannel OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION "Data channel used for this stream"
RMTP-II APPENDICES [Page 9]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
::= {lnStreamEntry 9}
--------------
-- Group sd --
--------------
sdAdmitRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "Admit rate specified by the sender application to
control
the bandwidth utilization"
::= {sd 1}
sdDataQSize OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "Current data queue size for the sender. It can be
changed
at run-time"
::= {sd 2}
sdState OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "State of the stream"
::= {sd 3}
sdInHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets received"
::= {sd 4}
sdInHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION ""
::= {sd 5}
sdOutDataPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
RMTP-II APPENDICES [Page 10]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
STATUS mandatory
DESCRIPTION "The number of data packets sent"
::= {sd 6}
sdOutNullDataPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of null data packets sent"
::= {sd 7}
sdQos OBJECT-TYPE
SYNTAX INTEGER {
unordered(1),
ordered(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "The QoS quality of service set for this stream"
::= {sd 8}
sdQFullCounter OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of times the data queue was full. If this
number is higher than data queue size should be
increased to get better performance."
::= {sd 9}
sdTopNode OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION "An ascii string for top node's address and port
in the format xxx.xxx.xxx.xxx:nnnnn"
::= {sd 10}
lowAdmitRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The lowest Admit rate provided by the sender
application.
In case of congestion, sender can lower the Admit Rate
to
lowAdmitRate."
::= {sd 11}
RMTP-II APPENDICES [Page 11]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
highAdmitRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The highest Admit rate provided by the sender
application. "
::= {sd 12}
--------------
-- Group ag --
--------------
agParentAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the parent node in the RMTP tree"
::= {ag 1}
agParentPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "UDP port of the parent node in the RMTP tree"
::= {ag 2}
agMaxChildren OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION "The maximum number of children at any time"
::= {ag 3}
agChildRejectCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of children rejected by the node"
::= {ag 4}
agChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF ChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Child table - basic information."
::= {ag 5 }
RMTP-II APPENDICES [Page 12]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
agChildEntry OBJECT-TYPE
SYNTAX AgChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one Child."
INDEX { agMod }
::= {agChildTable 1}
AgChildEntry ::= SEQUENCE {
agMod INTEGER,
agStreamCount INTEGER
}
agMod OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The mod number assigned by the parent node"
::= {agChildEntry 1}
agStreamCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of streams received by the node"
::= {agChildEntry 2}
agStreamTable OBJECT-TYPE
SYNTAX SEQUENCE OF AgStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Stream table - basic information."
::= {ag 6 }
agStreamEntry OBJECT-TYPE
SYNTAX AgStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one stream."
INDEX {agStreamId}
::= {agStreamTable 1}
AgStreamEntry ::= SEQUENCE {
agStreamId INTEGER,
agInHackPkts Counter,
agOuthackPkts Counter,
agChildCount INTEGER,
agState INTEGER,
RMTP-II APPENDICES [Page 13]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
agMaxLossRate INTEGER,
agMaxLossRateAddress IpAddress
}
agStreamId OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the stream"
::= {agStreamEntry 1}
agInHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets received"
::= {agStreamEntry 2}
agOutHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets sent"
::= {agStreamEntry 3}
agChildCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of children receiving this stream"
::= {agStreamEntry 4}
agState OBJECT-TYPE
SYNTAX INTEGER {
joining(1),
joinAck(2),
started(3),
completed(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "Current state of the stream"
::= {agStreamEntry 5}
agMaxLossRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
RMTP-II APPENDICES [Page 14]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
DESCRIPTION "Maximum loss rate of all the child nodes"
::= {agStreamEntry 6}
agMaxLossRateAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the node having maximum loss"
::= {agStreamEntry 7}
--------------
-- Group tn --
--------------
tnMaxChildren OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION "The maximum number of children at any time"
::= {tn 1}
tnChildRejectCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of children rejected by the node"
::= {tn 2}
--------------------------------------------------
-- Global Parameters maintained at the top node --
--------------------------------------------------
branchFactor OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The maximum number of children for any node in the
tree"
::= {tn 3}
thackConstant OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The scaling coefficient for thack"
::= {tn 4}
overHead OBJECT-TYPE
SYNTAX INTEGER
RMTP-II APPENDICES [Page 15]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
ACCESS read-write
STATUS mandatory
DESCRIPTION "The maximum number of HACKs should be received,
for each data packet, at control nodes"
::= {tn 5}
tJoinResponse OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "Maximum time to wait for a response to a JoinStream
request"
::= {tn 6}
rJoin OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The number of retries of the JoinRequest befor
declaring
the parent unreachable"
::= {tn 7}
tHB OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The time interval at which control nodes multicast
heartbeat
packets"
::= {tn 8}
failureConstant OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The threshold time for failure detection"
::= {tn 9}
tNulldataMax OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "Maximum time interval between NullData packets"
::= {tn 10}
thackMax OBJECT-TYPE
SYNTAX INTEGER
RMTP-II APPENDICES [Page 16]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
ACCESS read-write
STATUS mandatory
DESCRIPTION "Maximum time allowed between HACK transmission for
each node"
::= {tn 11}
rxMax OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "Maximum number of retransmissions for a data packet"
::= {tn 12}
optimistic OBJECT-TYPE
SYNTAX INTEGER {
pessimistic(0)
optimistic(1),
}
ACCESS read-write
STATUS mandatory
DESCRIPTION "Defines the stability property for the RMTP-II tree"
::= {tn 13}
tnChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF TnChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Child table - basic information."
::= {tn 14 }
tnChildEntry OBJECT-TYPE
SYNTAX TnChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one Child."
INDEX { tnMod }
::= {tnChildTable 1}
TnChildEntry ::= SEQUENCE {
tnMod INTEGER,
tnStreamCount INTEGER
}
tnMod OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The mod number assigned by the parent node"
RMTP-II APPENDICES [Page 17]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
::= {tnChildEntry 1}
tnStreamCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of streams received by the node"
::= {tnChildEntry 2}
tnStreamTable OBJECT-TYPE
SYNTAX SEQUENCE OF TnStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Stream table - basic information."
::= {tn 4 }
tnStreamEntry OBJECT-TYPE
SYNTAX TnStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one stream."
INDEX {tnStreamId}
::= {tnStreamTable 1}
TnStreamEntry ::= SEQUENCE {
tnStreamId INTEGER,
tnInHackPkts Counter,
tnOuthackPkts Counter,
tnChildCount INTEGER,
tnState INTEGER,
tnMaxLossRate INTEGER,
tnMaxLossRateAddress IpAddress
}
tnStreamId OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the stream"
::= {tnStreamEntry 1}
tnInHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets received"
::= {tnStreamEntry 2}
RMTP-II APPENDICES [Page 18]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
tnOutHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets sent"
::= {tnStreamEntry 3}
tnChildCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of children receiving this stream"
::= {tnStreamEntry 4}
tnState OBJECT-TYPE
SYNTAX INTEGER {
joining(1),
joinAck(2),
started(3),
completed(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "Current state of the stream"
::= {tnStreamEntry 5}
tnMaxLossRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Maximum loss rate of all the child nodes"
::= {tnStreamEntry 6}
tnMaxLossRateAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the node having maximum loss"
::= {tnStreamEntry 7}
tnSenderTable OBJECT-TYPE
SYNTAX SEQUENCE OF SenderEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The sender table - basic information."
::= {tn 5 }
RMTP-II APPENDICES [Page 19]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
tnSenderEntry OBJECT-TYPE
SYNTAX SenderEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one sender."
INDEX {tnStreamId}
::= {tnSenderTable 1}
SenderEntry ::= SEQUENCE {
tnSdstreamId INTEGER,
tnSdAddress IpAddress,
tnSdPort INTEGER
}
tnSdStreamId OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the stream"
::= {tnSenderEntry 1}
tnSdAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the sender node"
::= {tnSenderEntry 2}
tnSdPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "UDP Port of the sender node"
::= {tnSenderEntry 3}
----------------------------------------------------
-- The configuration table for each of the sender --
-- each entry gives the current, minimum and --
-- maximum admit rate for the sender. --
----------------------------------------------------
tnSdConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF SenderConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The sender Config table - Rate information."
::= {tn 6 }
RMTP-II APPENDICES [Page 20]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
tnSenderConfigEntry OBJECT-TYPE
SYNTAX SenderConfigEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one sender, sender index is
used as the INDEX for this table"
INDEX {tnSdIndex}
::= {tnSenderConfigTable 1}
SenderConfigEntry::= SEQUENCE {
tnSdIndex INTEGER,
sdCurrentRate INTEGER,
sdMaxRate INTEGER,
sdMinRate INTEGER,
sdCommand INTEGER
}
tnSdIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the sender"
::= {tnSenderConfigEntry 1}
sdCurrentRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The current admit rate for the sender node"
::= {tnSenderConfigEntry 2}
sdMaxRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The maximum admit rate for the sender node"
::= {tnSenderConfigEntry 3}
sdMinRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION "The minimum admit rate for the sender node"
::= {tnSenderConfigEntry 4}
sdCommand OBJECT-TYPE
SYNTAX INTEGER
ACCESS write-only
RMTP-II APPENDICES [Page 21]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
STATUS mandatory
DESCRIPTION "The commands that can be passed to the sender node"
::= {tnSenderConfigEntry 5}
--------------
-- Group dr --
--------------
drParentAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the parent node in the RMTP tree"
::= {dr 1}
drParentPort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "UDP port of the parent node in the RMTP tree"
::= {dr 2}
drMaxChildren OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION "The maximum number of children at any time"
::= {dr 3}
drChildRejectCount OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of children rejected by the node"
::= {dr 4}
drChildTable OBJECT-TYPE
SYNTAX SEQUENCE OF ChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Child table - basic information."
::= {dr 5 }
drChildEntry OBJECT-TYPE
SYNTAX DrChildEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one Child."
RMTP-II APPENDICES [Page 22]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
INDEX { drMod }
::= {drChildTable 1}
DrChildEntry ::= SEQUENCE {
drMod INTEGER,
drStreamCount INTEGER
}
drMod OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The mod number assigned by the parent node"
::= {drChildEntry 1}
drStreamCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The number of streams received by the node"
::= {drChildEntry 2}
drStreamTable OBJECT-TYPE
SYNTAX SEQUENCE OF DrStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "The Stream table - basic information."
::= {dr 6 }
drStreamEntry OBJECT-TYPE
SYNTAX DrStreamEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION "Each entry corresponds to one stream."
INDEX {drStreamId}
::= {drStreamTable 1}
DrStreamEntry ::= SEQUENCE {
drStreamId INTEGER,
drInHackPkts Counter,
drOuthackPkts Counter,
drChildCount INTEGER,
drState INTEGER,
drMaxLossRate INTEGER,
drMaxLossRateAddress IpAddress
}
drStreamId OBJECT-TYPE
RMTP-II APPENDICES [Page 23]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "The unique identifier for the stream"
::= {drStreamEntry 1}
drInHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets received"
::= {drStreamEntry 2}
drOutHackPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of HACK packets sent"
::= {drStreamEntry 3}
drChildCount OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Number of children receiving this stream"
::= {drStreamEntry 4}
drState OBJECT-TYPE
SYNTAX INTEGER {
joining(1),
joinAck(2),
started(3),
completed(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION "Current state of the stream"
::= {drStreamEntry 5}
drMaxLossRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION "Maximum loss rate of all the child nodes"
::= {drStreamEntry 6}
drMaxLossRateAddress OBJECT-TYPE
SYNTAX IpAddress
RMTP-II APPENDICES [Page 24]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
ACCESS read-only
STATUS mandatory
DESCRIPTION "IP Address of the node having maximum loss"
::= {drStreamEntry 7}
END
RMTP-II APPENDICES [Page 25]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX D - FORWARD ERROR CORRECTION
Recent work [NB96, NBT97, Rizzo97] has shown the benefits of
incorporating forward error correction (FEC) into reliable multicast
protocols. RMTP-II supports two modes of FEC: Proactive and
Reactive.
Proactive FEC is a mechanism by which parity packets are sent along
with the data packets. The receivers use the parity packets to
recover the missing data packets. This is used in environments where
there is no back channel to get feedback from the receivers to the
sender, and to support real time applications.
Reactive FEC is a mechanism by which the sender encodes and sends
parity packets only if it gets notification about missed data
packets. The sender sends parity packets instead of retransmitting
the data packets. The receivers are able to repair different lost
packets with these parity packets. This is used in environments
where receivers face independent loss. For example, if receivers are
connected to the network by modem, the losses at the various
receivers may be independent. If each receiver looses a different
packet then there may be much transmission. Each receiver may be
able to recover its missed data when a parity packet is transmitted.
Algorithm
Parity packets are sent using the reserved sequence number zero and
the FEC option. The FEC option has three fields:
BeginSeq:
This is the beginning data packet sequence number for the FEC
block.
EndSeq:
This is the end data packet sequence number for the FEC block.
Index:
This is the index number used for the parity packet.
All data packets within a block need to be of fixed size to calculate
parity. When transmitting, the sender must find the max size, Smax,
from all the packets in the FEC block. All bytes in the block
between the actual packet length and Smax are set to zero. This is
only done for FEC calculation.
Proactive FEC
The following parameters are required:
RMTP-II APPENDICES [Page 26]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
Bmax:
This is the maximum block size (number of packets in a block).
P:
This is the number of parity packets per block.
Tmax:
This is the maximum time interval, after which a parity packet is
forced out.
When the sender sends the first packet of a block, it schedules a
timer for time Tmax. After it sends Bmax packets, the sender computes
P parity packets for Bmax packets and then sends the parity packets
with sequence number zero. If the timer expires, then compute P
parity packets just for the number of packets that have been sent.
If the receiver receives a parity packet, it determines whether it
has missed any data packets within the FEC block. The FEC option in
the parity packet has the block information. If no data packets are
missing within the FEC block it ignores the parity packets.
If a receiver determines that one or more data packets are missed
within a FEC block, it waits to receive that many parity packets.
When it receives the required parity packets, the receiver passes the
received data packets and parity packets to the FEC decoder to
recover the missed data packets.
If the parity packets received are less than the missed data packets
within a FEC block, the FEC decoder cannot generate the missed data
packets. In such a situation, it waits to recover the missed data
packets from the data retransmissions done by the sender.
Reactive FEC
The following parameters are required:
Bmax:
This is the maximum block size (the number of packets in a block.
P:
The number of parity packets per block.
When the sender receives a HACK, it creates FEC blocks from Lowest
Sequence Number to Highest Sequence Number. It computes parity
packets for each block and sends the parity packets instead of
retransmitting the data packets.
The receivers use these parity packets to compute the missed data
packets. If the receiver cannot compute the missed data packets from
RMTP-II APPENDICES [Page 27]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
the parity packets, it uses the FEC option in the HACK packet to
notify the sender to retransmit the data packet instead of sending
parity packets. The control node propagates this FEC option to the
sender.
If the sender receives a HACK with the FEC option to retransmit the
data packets set, it will retransmit the data packets and not send
parity packets.
FEC option for HACK packet
This option allows the receivers to request retransmission of data
instead of parity packets.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | OTYPE | LENGTH | SendData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A: set to 00 skip option, process packet
OTYPE: set to 11 Gcast FEC
LENGTH: set to 1
SendData: If set, then all the control nodes, propagate this option
to the sender. The sender retransmits the data packets instead of
sending parity packets.
FEC option for data packet This option allows the sender to send FEC
parity packets to receivers.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | OTYPE | LENGTH | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BeginSeq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EndSeq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ParityIndex |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A: set to 00 - skip option, process packet
RMTP-II APPENDICES [Page 28]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
OTYPE: set to 11 - Gcast FEC
LENGTH: set to 4
BeginSeq: This is the beginning data packet sequence number for the
FEC block.
EndSeq: This is the end data packet sequence number for the FEC
block.
ParityIndex: This is the index number used for the parity packet.
References [NB96] J. Nonnenmacher and E.W. Biersack, "Reliable
Multicast: Where to use Forward Error Correction", Proc. 5th.
Workshop on Protocols for High Speed Networks, Sophia Antipolis,
France, Oct. 1996.
[NBT97] J. Nonnenmacher, E. W. Biersack, and Don Towsley. "Parity-
Based Loss Recovery for Reliable Multicast Transmission", In Proc. of
ACM SIGCOMM '97, Cannes, France, September 1997.
[Rizzo97] L. Rizzo, "Effective erasure codes for reliable computer
communications protocols", DEIT Technical Report LR-970115.
RMTP-II APPENDICES [Page 29]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX E - TIME BOUNDED RELIABILITY
RMTP includes a new quality of service level called Time Bounded
Reliability. This QoS is designed to support synchronous streaming
data types, such as streaming audio and video, and real time
financial data. Packets with this QoS level are assigned a maximum
latency Bound, and the receiver attempts to deliver the packets with
a QoS of Source Ordered for up to Bound seconds. After that time
elapses, the receiver stops requesting retransmission of the missing
packets and "delivers" them to the application as an error code.
This allows packets which have been blocking on the missing packets
(because they have higher sequence numbers than the missing ones) to
be delivered within a fixed amount of time after they are sent. Each
stream can have only a single QoS and Bound associated with it, and
this is fixed for the duration of the stream.
We define the following variables for a given packet.
Tsent: The time at the sender when the packet was generated (based
on sender's clock).
Treceived: The time at the receiver when the packet was received
(based on receiver's clock).
Lmin: The minimum physical latency for a packet to be delivered from
the sender to the receiver.
Bound: The maximum time allowed for recovery of a packet.
Cdiff: The difference in clocks between the sender and the reciever.
Tdrop: The time at the receiver when the packet should be declared
dropped (based on receiver's clock).
In order to be scalable, the protocol can not rely on any true clock
synchronization algorithms for determining Cdiff. Instead, Lmin is
defined as the minimum observed latency between the two computers,
which occurs when (Treceived-Tsent) is the smallest. When each
packet is received, the receiver calculates this Diff=Treceived-
Tsent, and compares it to Cdiff. If it is smaller than Cdiff (which
is initially set to positive infinity), then Cdiff is set to Diff.
Tdrop for a given packet is then defined as Bound - Tsent + Cdiff.
Given this, the algorithm may not give accurate results when: Bound
is smaller than the sum of Lmin plus the timer resolution on the
receivers' machines. During the initial packets sent in a data
stream, when Cdiff has not yet been measured accurately.
When a packet is sent, Tsent is included in the packet's header.
RMTP-II APPENDICES [Page 30]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
Tsent is the time at which the sender's transport received the
packet, not adjusted for daylight savings time. All clock
measurements are not adjusted for daylight savings time, to avoid any
discontinuities in operation when a computer adjusts its internal
clock for this time change. When the packet is received, the current
clock at the receiver is measured as Treceived, and Cdiff is updated
if necessary.
The packets in each receiver's incoming data queue are sorted by
sequence number, using sequence number arithmetic. For the packet in
the queue with the lowest sequence number, the current time at the
receiver is regularly compared against Tdrop, as calculated with
Tsent for that packet and the current values of Cdiff and Bound. If
the current time is larger than Tdrop, then all of the missing
packets with smaller sequence numbers are "delivered" to the
application as error codes, and the tested packet is delivered as
well. When this occurs, the receivers will stop requesting
retransmission for the "delivered" missing packets, and will consider
them to have gone stable.
RMTP-II APPENDICES [Page 31]
Internet Draft The RMTP-II PROTOCOL 8 April 1998
APPENDIX F - WORK IN PROGRESS
Work is currently in progress for the following areas:
1) Security considerations
2) Analysis of protocol performance
3) Proof of protocol correctness
4) Integration with generic router assist mechanisms
5) Definition of automatic tree configuration algorithms for use in
the session manager
6) Analysis of congestion control algorithms relative to TCP traffic
7) Header compression, including HACK bitfield compression
The authors welcome any and all feedback on this draft, as well as
offers to collaborate on any of these work in progress areas.
RMTP-II APPENDICES [Page 32]