+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: HELLO Control Message
o R (bit 8) is used for the Restarted-bit.
o HelloTimer represents the time in millisecond since the agent was
restarted, modulo the precision of the field. It is used to detect
duplicate or delayed HELLO messages.
10.4.8 JOIN
JOIN (OpCode = 8) is used as part of the ST steam joining mechanism,
see Section 4.6.3.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 8 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: JOIN Control Message
o Reference contains a number assigned by the ST agent sending JOIN
for use in the acknowledging ACK.
o GeneratorIPAddress is the 32-bit IP address of the host that
generated the JOIN message.
o TargetList is the information associated with the target to be added
to the stream.
10.4.9 JOIN-REJECT
JOIN-REJECT (OpCode = 9) is used as part of the ST steam joining
mechanism, see Section 4.6.3.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 9 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: JOIN-REJECT Control Message
o Reference contains a number assigned by the ST agent sending the
REFUSE for use in the acknowledging ACK.
o LnkReference is the Reference number from the corresponding JOIN
message.
o ReasonCode reflects the reason why the JOIN request was rejected.
o GeneratorIPAddress is the 32-bit IP address of the host that first
generated the JOIN-REJECT message.
10.4.10 NOTIFY
NOTIFY (OpCode = 10) is issued by an ST agent to inform other ST
agents of events that may be significant. NOTIFY may be propagated
beyond the previous-hop or next-hop ST agent depending on the
ReasonCode, see Section 10.5.3; NOTIFY must be acknowledged with an
ACK.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 10 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: NOTIFY Control Message
o Reference contains a number assigned by the ST agent sending the
NOTIFY for use in the acknowledging ACK.
o ReasonCode identifies the reason for the notification.
o DetectorIPAddress is the 32-bit IP address of the ST agent that
detects the event.
o MaxMsgSize is set when the MTU of the listed targets has changed
(e.g., due to recovery), or when the notification is generated after
a successful JOIN. Otherwise it is set to zero (0).
o RecoveryTimeout is set when the notification is generated after a
successful JOIN. Otherwise it is set to zero (0).
o FlowSpec is present when the notification is generated after a
successful JOIN.
o TargetList is present when the notification is related to one or
more targets, or when MaxMsgSize is set
o UserData is present if the notification is generated after a
successful JOIN and the UserData parameter was set in the ACCEPT
message.
10.4.11 REFUSE
REFUSE (OpCode = 11) is issued by a target that either does not wish
to accept a CONNECT message or wishes to remove itself from an
established stream. It might also be issued by an intermediate ST
agent in response to a CONNECT or CHANGE either to terminate a
routing loop, or when a satisfactory next-hop to a target cannot be
found. It may also be a separate command when an existing stream has
been preempted by a higher precedence stream or an ST agent detects
the failure of a previous-hop, next-hop, or the network between them.
In all cases, the TargetList specifies the targets that are affected
by the condition. Each REFUSE must be acknowledged by an ACK.
The REFUSE is relayed back by the ST agents to the origin (or
intermediate ST agent that created the CONNECT or CHANGE) along the
path traced by the CONNECT. The ST agent receiving the REFUSE will
process it differently depending on the condition that caused it, as
specified in the ReasonCode field. No special effort is made to
combine multiple REFUSE messages since it is considered most unlikely
that separate REFUSEs will happen to both pass through an ST agent at
the same time and be easily combined, e.g., have identical
ReasonCodes and parameters.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 11 |G|E|N| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ValidTargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: REFUSE Control Message
o G (bit 8) is used to indicate that all targets down stream from the
sender are refusing. It is expected that this will be set most
commonly due to network failures. The TargetList parameter is
ignored or not present when this bit is set, and must be included
when not set.
o E (bit 9) is set by an ST agent to indicate that the request failed
and that the pre-change stream attributes, including resources, and
the stream itself still exist.
o N (bit 10) is used to indicate that no further attempts to recover
the stream should be made. This bit must be set when stream recovery
should not be attempted, even in the case where the target
application has shut down normally (ApplDisconnect).
o Reference contains a number assigned by the ST agent sending the
REFUSE for use in the acknowledging ACK.
o LnkReference is either the Reference number from the corresponding
CONNECT or CHANGE, if it is the result of such a message, or zero
when the REFUSE was originated as a separate command.
o DetectorIPAddress is the 32-bit IP address of the host that first
generated the REFUSE message.
o ValidTargetIPAddress is the 32-bit IP address of a host that is
properly connected as part of the stream. This parameter is only
used when recovering from stream convergence, otherwise it is set to
zero (0).
10.4.12 STATUS
STATUS (OpCode = 12) is used to inquire about the existence of a
particular stream identified by the SID. Use of STATUS is intended
for collecting information from an neighbor ST agent, including
general and specific stream information, and round trip time
estimation. The use of this message type is described in Section 8.4.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 12 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: STATUS Control Message
o Reference contains a number assigned by the ST agent sending STATUS
for use in the replying STATUS-RESPONSE.
o TargetList is an optional parameter that when present indicates that
only information related to the specific targets should be relayed
in the STATUS-RESPONSE.
10.4.13 STATUS-RESPONSE
STATUS-RESPONSE (OpCode = 13) is the reply to a STATUS message. If
the stream specified in the STATUS message is not known, the STATUS-
RESPONSE will contain the specified SID but no other parameters. It
will otherwise contain the current SID, FlowSpec, TargetList, and
possibly Groups of the stream. It the full target list can not fit in
a single message, only those targets that can be included in one
message will be included. As mentioned in Section 10.4.12, it is
possible to request information on a specific target.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 13 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Groups :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: STATUS-RESPONSE Control Message
o Reference contains a number assigned by the ST agent sending the
STATUS.
10.5 Suggested Protocol Constants
The ST Protocol uses several fields that must have specific values
for the protocol to work, and also several values that an
implementation must select. This section specifies the required
values and suggests initial values for others. It is recommended that
the latter be implemented as variables so that they may be easily
changed when experience indicates better values. Eventually, they
should be managed via the normal network management facilities.
ST uses IP Version Number 5.
When encapsulated in IP, ST uses IP Protocol Number 5.
10.5.1 SCMP Messages
1) ACCEPT
2) ACK
3) CHANGE
4) CONNECT
5) DISCONNECT
6) ERROR
7) HELLO
8) JOIN
9) JOIN-REJECT
10) NOTIFY
11) REFUSE
12) STATUS
13) STATUS-RESPONSE
10.5.2 SCMP Parameters
1) FlowSpec
2) Group
3) MulticastAddress
4) Origin
5) RecordRoute
6) TargetList
7) UserData
10.5.3 ReasonCode
Several errors may occur during protocol processing. All ST error
codes are taken from a single number space. The currently defined
values and their meaning is presented in the list below. Note that
new error codes may be defined from time to time. All implementations
are expected to handle new codes in a graceful manner. If an unknown
ReasonCode is encountered, it should be assumed to be fatal. The
ReasonCode is an 8-bit field. Following values are defined:
1 NoError No error has occurred.
2 ErrorUnknown An error not contained in this list has been
detected.
3 AccessDenied Access denied.
4 AckUnexpected An unexpected ACK was received.
5 ApplAbort The application aborted the stream abnormally.
6 ApplDisconnect The application closed the stream normally.
7 ApplRefused Applications refused requested connection or
change.
8 AuthentFailed The authentication function failed.
9 BadMcastAddress IP Multicast address is unacceptable in CONNECT
10 CantGetResrc Unable to acquire (additional) resources.
11 CantRelResrc Unable to release excess resources.
12 CantRecover Unable to recover failed stream.
13 CksumBadCtl Control PDU has a bad message checksum.
14 CksumBadST PDU has a bad ST Header checksum.
15 DuplicateIgn Control PDU is a duplicate and is being
acknowledged.
16 DuplicateTarget Control PDU contains a duplicate target, or an
attempt to add an existing target.
17 FlowSpecMismatch FlowSpec in request does not match
existing FlowSpec.
18 FlowSpecError An error occurred while processing the FlowSpec
19 FlowVerUnknown Control PDU has a FlowSpec Version Number that
is not supported.
20 GroupUnknown Control PDU contains an unknown Group Name.
21 InconsistGroup An inconsistency has been detected with the
streams forming a group.
22 IntfcFailure A network interface failure has been detected.
23 InvalidSender Control PDU has an invalid SenderIPAddress
field.
24 InvalidTotByt Control PDU has an invalid TotalBytes field.
25 JoinAuthFailure Join failed due to stream authorization level.
26 LnkRefUnknown Control PDU contains an unknown LnkReference.
27 NetworkFailure A network failure has been detected.
28 NoRouteToAgent Cannot find a route to an ST agent.
29 NoRouteToHost Cannot find a route to a host.
30 NoRouteToNet Cannot find a route to a network.
31 OpCodeUnknown Control PDU has an invalid OpCode field.
32 PCodeUnknown Control PDU has a parameter with an invalid
PCode.
33 ParmValueBad Control PDU contains an invalid parameter value.
34 PathConvergence Two branches of the stream join during the
CONNECT setup.
35 ProtocolUnknown Control PDU contains an unknown next-higher
layer protocol identifier.
36 RecordRouteSize RecordRoute parameter is too long to permit
message to fit a network's MTU.
37 RefUnknown Control PDU contains an unknown Reference.
38 ResponseTimeout Control message has been acknowledged but not
answered by an appropriate control message.
39 RestartLocal The local ST agent has recently restarted.
40 RestartRemote The remote ST agent has recently restarted.
41 RetransTimeout An acknowledgment has not been received after
several retransmissions.
42 RouteBack Route to next-hop through same interface as
previous-hop and is not previous-hop.
43 RouteInconsist A routing inconsistency has been detected.
44 RouteLoop A routing loop has been detected.
45 SAPUnknown Control PDU contains an unknown next-higher
layer SAP (port).
46 SIDUnknown Control PDU contains an unknown SID.
47 STAgentFailure An ST agent failure has been detected.
48 STVer3Bad A received PDU is not ST Version 3.
49 StreamExists A stream with the given SID already exists.
50 StreamPreempted The stream has been preempted by one with a
higher precedence.
51 TargetExists A CONNECT was received that specified an
existing target.
52 TargetUnknown A target is not a member of the specified
stream.
53 TargetMissing A target parameter was expected and is not
included, or is empty.
54 TruncatedCtl Control PDU is shorter than expected.
55 TruncatedPDU A received ST PDU is shorter than the ST Header
indicates.
56 UserDataSize UserData parameter too large to permit a
message to fit into a network's MTU.
10.5.4 Timeouts and Other Constants
SCMP uses retransmission to effect reliability and thus has several
"retransmission timers". Each "timer" is modeled by an initial time
interval (ToXxx), which may get updated dynamically through
measurement of control traffic, and a number of times (NXxx) to
retransmit a message before declaring a failure. All time intervals
are in units of milliseconds. Note that the variables are described
for reference purposes only, different implementations may not
include the identical variables.
Value Timeout Name Meaning
------------------------------------------------------------------------
500 ToAccept Initial hop-by-hop timeout for acknowledgment of
ACCEPT
3 NAccept ACCEPT retries before failure
500 ToChange Initial hop-by-hop timeout for acknowledgment of
CHANGE
3 NChange CHANGE retries before failure
5000 ToChangeResp End-to-End CHANGE timeout for receipt of ACCEPT
or REFUSE
500 ToConnect Initial hop-by-hop timeout for acknowledgment of
CONNECT
5 NConnect CONNECT retries before failure
5000 ToConnectResp End-to-End CONNECT timeout for receipt of ACCEPT
or REFUSE from targets by origin
500 ToDisconnect Initial hop-by-hop timeout for acknowledgment of
DISCONNECT
3 NDisconnect DISCONNECT retries before failure
500 ToJoin Initial hop-by-hop timeout for acknowledgment of
JOIN
3 NJoin JOIN retries before failure
500 ToJoinReject Initial hop-by-hop timeout for acknowledgment of
JOIN-REJECT
3 NJoinReject JOIN-REJECT retries before failure
5000 ToJoinResp Timeout for receipt of CONNECT or JOIN-REJECT
from origin or intermediate hop
500 ToNotify Initial hop-by-hop timeout for acknowledgment of
NOTIFY
3 NNotify NOTIFY retries before failure
500 ToRefuse Initial hop-by-hop timeout for acknowledgment of
REFUSE
3 NRefuse REFUSE retries before failure
500 ToRetryRoute Timeout for receipt of ACCEPT or REFUSE from
targets during failure recovery
5 NRetryRoute CONNECT retries before failure
1000 ToStatusResp Timeout for receipt of STATUS-RESPONSE
3 NStatus STATUS retries before failure
10000 HelloTimerHoldDown Interval that Restarted bit must be set
after ST restart
5 HelloLossFactor Number of consecutively missed HELLO
messages before declaring link failure
2000 DefaultRecoveryTimeout Interval between successive HELLOs
to/from active neighbors
10.6 Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data with the most
significant octet on the left and the least significant octet on the
right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Figure 35: Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
Fields whose length is fixed and fully illustrated are shown with a
vertical bar (|) at the end; fixed fields whose contents are
abbreviated are shown with an exclamation point (!); variable fields
are shown with colons (:). Optional parameters are separated from
control messages with a blank line. The order of parameters is not
meaningful.
11. References
[RFC1071] Braden, R., Borman, D., and C. Partridge,
"Computing the Internet Checksum", RFC1071,
USC/Information Sciences Institute,
Cray Research, BBN Laboratories, September 1988.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC1112, Stanford University, August 1989.
[WoHD95] L. Wolf, R. G. Herrtwich, L. Delgrossi: Filtering
Multimedia Data in Reservation-based Networks,
Kommunikation in Verteilten Systemen 1995 (KiVS),
Chemnitz-Zwickau, Germany, February 1995.
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC1122,
USC/Information Sciences Institute, October 1989.
[Jaco88] Jacobson, V.: Congestion Avoidance and Control, ACM
SIGCOMM-88, August 1988.
[KaPa87] Karn, P. and C. Partridge: Round Trip Time Estimation,
ACM SIGCOMM-87, August 1987.
[RFC1141] Mallory, T., and A. Kullberg, "Incremental Updating
of the Internet Checksum", RFC1141, BBN, January 1990.
[RFC1363] Partridge, C., "A Proposal Flow Specification",
RFC1363, BBN, September 1992.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC791,
DARPA, September 1981.
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers",
STD 2, RFC1700, USC/Information Sciences Institute,
October 1994.
[RFC1190] Topolcic C., "Internet Stream Protocol Version 2
(ST-II)", RFC1190, CIP Working Group, October 1990.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC1633, USC/Information Sciences Institute,
MIT, Xerox PARC, June 1994.
[VoHN93] C. Vogt, R. G. Herrtwich, R. Nagarajan: HeiRAT: the
Heidelberg Resource Administration Technique - Design
Philosophy and Goals, Kommunikation In Verteilten
Systemen, Munich, Informatik Aktuell, Springer-Verlag,
Heidelberg, 1993.
[Cohe81] D. Cohen: A Network Voice Protocol NVP-II, University of
Southern California, Los Angeles, 1981.
[Cole81] R. Cole: PVP - A Packet Video Protocol, University of
Southern California, Los Angeles, 1981.
[DeAl92] L. Delgrossi (Ed.) The BERKOM-II Multimedia Transport
System, Version 1, BERKOM Working Document, October,
1992.
[DHHS92] L. Delgrossi, C. Halstrick, R. G. Herrtwich, H.
Stuettgen: HeiTP: a Transport Protocol for ST-II,
GLOBECOM'92, Orlando (Florida), December 1992.
[Schu94] H. Schulzrinne: RTP: A Transport Protocol for Real-Time
Applications. Work in Progress, 1994.
12. Security Considerations
Security issues are not discussed in this memo.
13. Acknowledgments and Authors' Addresses
Many individuals have contributed to the work described in this memo.
We thank the participants in the ST Working Group for their input,
review, and constructive comments. George Mason University C3I Center
for hosting an interim meeting. Murali Rajagopal for his efforts on
ST2+ state machines. Special thanks are due to Steve DeJarnett, who
served as working group co-chair until summer 1993.
We would also like to acknowledge the authors of [RFC1190]. All
authors of [RFC1190] should be considered authors of this document
since this document contains much of their text and ideas.
Louis Berger
BBN Systems and Technologies
1300 North 17th Street, Suite 1200
Arlington, VA 22209
Phone: 703-284-4651
EMail: lberger@bbn.com
Luca Delgrossi
Andersen Consulting Technology Park
449, Route des Cretes
06902 Sophia Antipolis, France
Phone: +33.92.94.80.92
EMail: luca@andersen.fr
Dat Duong
BBN Systems and Technologies
1300 North 17th Street, Suite 1200
Arlington, VA 22209
Phone: 703-284-4760
EMail: dat@bbn.com
Steve Jackowski
Syzygy Communications Incorporated
269 Mt. Hermon Road
Scotts Valley, CA 95066
Phone: 408-439-6834
EMail: stevej@syzygycomm.com
Sibylle Schaller
IBM ENC
Broadband Multimedia Communications
Vangerowstr. 18
D69020 Heidelberg, Germany
Phone: +49-6221-5944553