rfc1819.txt
字号:
|JOIN.reject-ind| join reject indication | T |
|DATA.req | send data | O |
|DATA.ind | receive data indication | T |
|CHG.req | change stream QoS | O |
|CHG.ind | change request indication | T |
|CHG.accept | accept change | T |
|CHG.refuse | refuse change | T |
|CHG.accept-ind | change accept indication | O |
|CHG.refuse-ind | change refuse indication | O |
|DROP.req | drop targets | O |
|DROP.ind | disconnect indication | T |
|LEAVE.req | leave stream | T |
|LEAVE.ind | leave stream indication | O |
|CLOSE.req | close stream | O |
|CLOSE.ind | close stream indication | T |
+---------------------------------------------------+
Table 1: ST Primitives
2.2 State Diagrams
It is not sufficient to define the set of ST stream operations. It is
also necessary to specify when the operations can be legally
executed. For this reason, a set of states is now introduced and the
transitions from one state to the others are specified. States are
defined with respect to a single stream. The previously defined
Delgrossi & Berger, Editors Experimental [Page 21]
RFC 1819 ST2+ Protocol Specification August 1995
stream operations can be legally executed only from an appropriate
state.
An ST agent may, with respect to an ST stream, be in one of the
following states:
o IDLE: the stream has not been created yet.
o PENDING: the stream is in the process of being established.
o ACTIVE: the stream is established and active.
o ADDING: the stream is established. A stream expansion is underway.
o CHGING: the stream is established. A stream change is underway.
Previous experience with ST has lead to limits on stream operations
that can be executed simultaneously. These restrictions are:
1. A single ADD or CHG operation can be processed at one time. If
an ADD or CHG is already underway, further requests are queued
by the ST agent and handled only after the previous operation
has been completed. This also applies to two subsequent
requests of the same kind, e.g., two ADD or two CHG operations.
The second operation is not executed until the first one has
been completed.
2. Deleting a stream, leaving a stream, or dropping targets from a
stream is possible only after stream establishment has been
completed. A stream is considered to be established when all
the next-hops of the origin have either accepted or refused the
stream. Note that stream refuse is automatically forced after
timeout if no reply comes from a next-hop.
3. An ST agent forwards data only along already established paths
to the targets, see also Section 3.1. A path is considered to
be established when the next-hop on the path has explicitly
accepted the stream. This implies that the target and all other
intermediate ST agents are ready to handle the incoming data
packets. In no cases an ST agent will forward data to a
next-hop ST agent that has not explicitly accepted the stream.
To be sure that all targets receive the data, an application
should send the data only after all paths have been
established, i.e., the stream is established.
Delgrossi & Berger, Editors Experimental [Page 22]
RFC 1819 ST2+ Protocol Specification August 1995
4. It is allowed to send data from the CHGING and ADDING states.
While sending data from the CHGING state, the quality of
service to the targets affected by the change should be assumed
to be the more restrictive quality of service. When sending
data from the ADDING state, the targets that receive the data
include at least all the targets that were already part of the
stream at the time the ADD operation was invoked.
The rules introduced above require ST agents to queue incoming
requests when the current state does not allow to process them
immediately. In order to preserve the semantics, ST agents have to
maintain the order of the requests, i.e., implement FIFO queuing.
Exceptionally, the CLOSE request at the origin and the LEAVE request
at the target may be immediately processed: in these cases, the queue
is deleted and it is possible that requests in the queue are not
processed.
The following state diagrams define the ST service. Separate diagrams
are presented for the origin and the targets.
The symbol (a/r)* indicates that all targets in the target list have
explicitly accepted or refused the stream, or refuse has been forced
after timeout. If the target list is empty, i.e., it contains no
targets, the (a/r)* condition is immediately satisfied, so the empty
stream is created and state ESTBL is entered.
The separate OPEN and ADD primitives at the target are for conceptual
purposes only. The target is actually unable to distinguish between
an OPEN and an ADD. This is reflected in Figure 7 and Table 3 through
the notation OPEN/ADD.
Delgrossi & Berger, Editors Experimental [Page 23]
RFC 1819 ST2+ Protocol Specification August 1995
+------------+
| |<-------------------+
+---------->| IDLE |-------------+ |
| | | OPEN.req | |
| +------------+ | |
CLOSE.req | CLOSE.req ^ ^ CLOSE.req V | CLOSE.req
| | | +---------+ |
| | | | PENDING |-|-+ JOIN.reject
| | -------------| |<|-+
| JOIN.reject | +---------+ |
| DROP.req +----------+ | |
| +-----| | | |
| | | ESTDL | OPEN.(a/r)* | |
| +---->| |<------------+ |
| +----------+ |
| | ^ | ^ |
| | | | | |
+----------+ CHG.req| | | | Add.(a/r)* +----------+
| |<-------+ | | +-------------- | |
| CHGING | | | | ADDING |
| |-----------+ +----------------->| |
+----------+ CHG.(a/r)* JOIN.ind +----------+
| ^ ADD.req | ^
| | | |
+---+ +---+
DROP.req DROP.req
JOIN.reject JOIN.reject
Figure 6: ST Service at the Origin
+--------+
| |-----------------------+
| IDLE | |
| |<---+ | OPEN/ADD.ind
+--------+ | CLOSE.ind | JOIN.req
^ | OPEN/ADD.refuse |
| | JOIN.refect-ind |
CLOSE.ind | | V
DROP.ind | | +---------+
LEAVE.req | +-------------| |
| | PENDING |
+-------+ | |
| | +---------+
| ESTBL | OPEN/ADD.accept |
| |<-----------------------+
+-------+
Figure 7: ST Service at the Target
Delgrossi & Berger, Editors Experimental [Page 24]
RFC 1819 ST2+ Protocol Specification August 1995
2.3 State Transition Tables
Table 2 and Table 3 define which primitives can be processed from
which states and the possible state transitions.
+======================================================================+
|Primitive |IDLE| PENDING | ESTBL | CHGING | ADDING |
|======================================================================|
|OPEN.req | ok | - | - | - | - |
|OPEN.accept-ind| - |if(a,r)*->ESTBL| - | - | - |
|OPEN.refuse-ind| - |if(a,r)*->ESTBL| - | - | - |
|ADD.req | - | queued |->ADDING| queued | queued |
|ADD.accept-ind | - | - | - | - |if(a,r)* |
| | - | - | - | - |->ESTBL |
|ADD.refuse-ind | - | - | - | - |if(a,r)* |
| | - | - | - | - |->ESTBL |
|JOIN.ind | - | queued |->ADDING| queued |queued |
|JOIN.reject | - | OK | ok | ok | ok |
|DATA.req | - | - | ok | ok | ok |
|CHG.req | - | queued |->CHGING| queued |queued |
|CHG.accept-ind | - | - | - |if(a,r)* | - |
| | - | - | - |->ESTBL | - |
|CHG.refuse.ind | - | - | - |if(a,r)* | - |
| | - | - | - |->ESTBL | - |
|DROP.req | - | - | ok | ok | ok |
|LEAVE.ind | - | OK | ok | ok | ok |
|CLOSE.req | - | OK | ok | ok | ok |
+----------------------------------------------------------------------+
Table 2: Primitives and States at the Origin
+======================================================+
| Primitive | IDLE | PENDING | ESTBL |
|======================================================|
| OPEN/ADD.ind | ->PENDING | - | - |
| OPEN/ADD.accept | - | ->ESTBL | - |
| OPEN/ADD.refuse | - | ->IDLE | - |
| JOIN.req | ->PENDING | - | - |
| JOIN.reject-ind |- | ->IDLE | - |
| DATA.ind | - | - | ok |
| CHG.ind | - | - | ok |
| CHG.accept | - | - | ok |
| DROP.ind | - | ok | ok |
| LEAVE.req | - | ok | ok |
| CLOSE.ind | - | ok | ok |
| CHG.ind | - | - | ok |
+------------------------------------------------------+
Table 3: Primitives and States at the Target
Delgrossi & Berger, Editors Experimental [Page 25]
RFC 1819 ST2+ Protocol Specification August 1995
3. The ST2 Data Transfer Protocol
This section presents the ST2 data transfer protocol, ST. First, data
transfer is described in Section 3.1, then, the data transfer
protocol functions are illustrated in Section 3.2.
3.1 Data Transfer with ST
Data transmission with ST is unreliable. An application is not
guaranteed that the data reaches its destinations and ST makes no
attempts to recover from packet loss, e.g., due to the underlying
network. However, if the data reaches its destination, it should do
so according to the quality of service associated with the stream.
Additionally, ST may deliver data corrupted in transmission. Many
types of real-time data, such as digital audio and video, require
partially correct delivery only. In many cases, retransmitted packets
would arrive too late to meet their real-time delivery requirements.
On the other hand, depending on the data encoding and the particular
application, a small number of errors in stream data are acceptable.
In any case, reliability can be provided by layers on top of ST2 if
needed.
Also, no data fragmentation is supported during the data transfer
phase. The application is expected to segme⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -