draft-ietf-st2-spec-01.txt   draft-ietf-st2-spec-02.txt 
ST Working Group L. Delgrossi and L. Berger
ST Working Group L. Delgrossi
Internet Stream Protocol Version 2 (ST2) Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+ Protocol Specification - Version ST2+
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 38
This memo contains a revised specification of the Internet STream This memo contains a revised specification of the Internet STream
Protocol Version 2 (ST2). ST2 is an experimental resource reservation Protocol Version 2 (ST2). ST2 is an experimental resource reservation
protocol intended to provide end-to-end real-time guarantees over an protocol intended to provide end-to-end real-time guarantees over an
internet. It allows its applications to build multi-destination internet. It allows its applications to build multi-destination
simplex data streams with a desired quality of service. The revised simplex data streams with a desired quality of service. The revised
version of ST2 specified in this memo is called ST2+. version of ST2 specified in this memo is called ST2+.
Editor's Note: Editor's Note:
This memo is available both in ASCII format (file: draft-ietf-st2- This memo is available both in ASCII format (file: draft-ietf-st2-
spec-00.txt) and in PostScript (file: draft-ietf-st2-spec-00.ps). The spec-02.txt) and in PostScript (file: draft-ietf-st2-spec-02.ps).
PostScript version contains some additional pictures that help to This draft is considered to be complete, and will be used as the
clarify the text, and it is therefore recommended. basis for an RFC once comments are integrated.
This draft is not complete. It will serve as the basis for
discussions at the December IETF ST2 sessions. The work remaining
is largely nontechnical. No major technical details are expected to
change, some minor details do need to be updated or are not yet
documented.
1 Introduction 6 1 Introduction 6
1.1 What is ST2? 6 1.1 What is ST2? 6
1.2 ST2 and IP 8
1.3 Protocol History 8
1.4 Supporting Modules for ST2 9
1.4.1 Data Transfer Protocol 9
1.4.2 Setup Protocol 10
1.4.3 Flow Specification 10
1.4.4 Routing Function 10
1.4.5 Local Resource Manager 11
1.5 ST2 Basic Concepts 12
1.5.1 Streams 12
1.5.2 Data Transmission 14
1.5.3 Flow Specification 15
1.6 Outline of This Document 16
1.2 Protocol History 7 2 ST2 User Service Description 17
2.1 Stream Operations and Primitive Functions 17
2.2 State Diagrams 19
2.3 State Transition Tables 22
1.3 Streams 7 3 The ST2 Data Transfer Protocol 23
3.1 Data Transfer with ST 23
3.2 ST Protocol Functions 24
3.2.1 Stream Identification 24
3.2.2 Packet Discarding based on Data Priority 24
1.4 Data Transmission 8 4 SCMP Functional Description 24
4.1 Types of Streams 26
4.1.1 Stream Building 26
4.1.2 Knowledge of Receivers 26
4.2 Control PDUs 27
4.3 SCMP Reliability 28
4.4 Stream Options 29
4.4.1 No Recovery 29
4.4.2 Join Authorization Level 29
4.4.3 Record Route 30
4.4.4 User Data 30
4.5 Stream Setup 30
4.5.1 Information from the Application 31
4.5.2 Initial Setup at the Origin 31
4.5.2.1 Invoking the Routing Function 31
4.5.2.2 Reserving Resources 32
4.5.3 Sending CONNECT Messages 32
4.5.3.1 Empty Target List 33
4.5.4 CONNECT Processing by an Intermediate ST agent 33
4.5.5 CONNECT Processing at the Targets 33
4.5.6 ACCEPT Processing by an Intermediate ST agent 34
4.5.7 ACCEPT Processing by the Origin 34
4.5.8 REFUSE Processing by the Intermediate ST agent 34
4.5.9 REFUSE Processing by the Origin 35
4.5.10 Other Functions during Stream Setup 35
4.6 Modifying an Existing Stream 36
4.6.1 The Origin Adding New Targets 36
4.5.4 and Section 4.5.5). 36
4.6.2 The Origin Removing a Target 36
4.6.3 A Target Joining a Stream 37
4.6.3.1 Router as Origin 38
4.6.4 A Target Deleting Itself 38
4.6.5 Changing a Stream's FlowSpec 39
4.7 Stream Tear Down 39
1.5 Flow Specifications 9 5 Exceptional Cases 40
5.1 Long ST Messages 40
5.1.1 Handling of Long Data Packets 40
5.1.2 Handling of Long Control Packets 40
5.2 Timeout Failures 41
5.2.1 Failure due to ACCEPT Acknowledgment Timeout 42
5.2.2 Failure due to CHANGE Acknowledgment Timeout 42
5.2.3 Failure due to CHANGE Response Timeout 42
5.2.4 Failure due to CONNECT Acknowledgment Timeout 42
5.2.5 Failure due to CONNECT Response Timeout 42
5.2.6 Failure due to DISCONNECT Acknowledgment Timeout 43
5.2.7 Failure due to JOIN Acknowledgment Timeout 43
5.2.8 Failure due to JOIN Response Timeout 43
5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout 43
5.2.10 Failure due to NOTIFY Acknowledgment Timeout 43
5.2.11 Failure due to REFUSE Acknowledgment Timeout 43
5.2.12 Failure due to STATUS Response Timeout 44
5.3 Setup Failures due to Routing Failures 44
5.3.1 Path Convergence 44
5.3.2 Other Cases 45
5.4 Problems due to Routing Inconsistency 46
5.5 Problems in Reserving Resources 47
5.5.1 Mismatched FlowSpecs 47
5.5.2 Unknown FlowSpec Version 47
5.5.3 LRM Unable to Process FlowSpec 47
5.5.4 Insufficient Resources 47
5.6 Problems Caused by CHANGE Messages 48
5.7 Unknown Targets in DISCONNECT and CHANGE 49
1.6 ST2 and IP 9 6 Failure Detection and Recovery 49
6.1 Failure Detection 49
6.1.1 Network Failures 50
6.1.2 Detecting ST Agents Failures 50
6.2 Failure Recovery 51
6.2.1 Problems in Stream Recovery 53
6.3 Stream Preemption 55
1.7 Outline of This Document 10 7 A Group of Streams 56
7.1 Basic Group Relationships 56
7.1.1 Bandwidth Sharing 56
7.1.2 Fate Sharing 57
7.1.3 Route Sharing 58
7.1.4 Subnet Resources Sharing 58
7.2 Relationships Orthogonality 58
2 ST User Service Description 11 8 Ancillary Functions 58
8.1 Stream ID Generation 58
8.2 Group Name Generator 59
8.3 Checksum Computation 59
8.4 Collecting Information From Neighbour ST Agent 60
8.5 Round Trip Time Estimation 61
8.6 Network MTU Discovery 61
8.7 IP Encapsulation of ST 61
8.8 IP Multicasting 62
2.1 Stream Operations and Primitive Functions 11 9 The ST2 Flow Specification 63
9.1 FlowSpec Version #0 - (Null FlowSpec) 64
9.2 FlowSpec Version #7 - ST2+ FlowSpec 64
9.2.1 QoS Classes 65
9.2.2 Precedence 65
9.2.3 Maximum Data Size 66
9.2.4 Message Rate 66
9.2.5 Delay and Delay Jitter 66
9.2.6 ST2+ FlowSpec Format 66
2.2 State Diagrams 12 10 ST2 Protocol Data Units Specification 68
10.1 Data PDU 68
10.1.1 ST Data Packets 69
10.2 Control PDUs 70
10.3 Common SCMP Elements 71
10.3.1 FlowSpec 71
10.3.2 Group 72
10.3.3 MulticastAddress 73
10.3.4 Origin 73
10.3.5 RecordRoute 74
10.3.6 Target and TargetList 75
10.3.7 UserData 76
10.3.8 Handling of Undefined Parameters 77
10.4 ST Control Message PDUs 77
10.4.1 ACCEPT 77
10.4.2 ACK 79
10.4.3 CHANGE 80
10.4.4 CONNECT 80
10.4.5 DISCONNECT 83
10.4.6 ERROR 83
10.4.7 HELLO 84
10.4.8 JOIN 85
10.4.9 JOIN-REJECT 85
10.4.10 NOTIFY 86
10.5.3; NOTIFY must be acknowledged with an ACK. 86
10.4.11 REFUSE 87
10.4.12 STATUS 89
10.4.13 STATUS-RESPONSE 89
10.5 Suggested Protocol Constants 90
10.5.1 SCMP Messages 90
10.5.2 SCMP Parameters 91
10.5.3 ReasonCode 91
10.5.4 Timeouts and Other Constants 93
10.6 Data Notations 94
2.3 State Transition Tables 15 11 Acknowledgments and Author's Addresses 95
3 SCMP Functional Description 16 12 References 96
1 Introduction
3.1 Stream Setup 17 1.1 What is ST2?
3.1.1 Initial Setup at the Origin 17 The Internet Stream Protocol, Version 2 (ST2) is an experimental
connection-oriented internetworking protocol that operates at the same layer
as connectionless IP. It has been developed to support the efficient
delivery of data streams to single or multiple destinations in applications
that require guaranteed quality of service. ST2 is part of the IP protocol
family and serves as an adjunct to, not a replacement for, IP. The main
application areas of the protocol are the real-time transport of multimedia
data, e.g. digital audio and video packet streams, and distributed
simulation/gaming, across internets.
3.1.1.1 Invoking the Routing Function 17 ST2 can be used to reserve bandwidth for real-time streams across network
routes. This reservation, together with appropriate network access and
packet scheduling mechanisms in all nodes running the protocol, guarantees a
well-defined Quality of Service (QoS) to ST2 applications. It ensures that
real-time packets are delivered within their deadlines, that is, at the time
where they need to be presented. This facilitates a smooth delivery of data
that is essential for time-critical applications, but can typically not be
provided by best-effort IP communication.
3.1.1.2 Reserving Resources 17 Just like IP, ST2 actually consists of two protocols: ST for the data
transport and SCMP, the Stream Control Message Protocol, for all control
functions. ST is simple and contains only a single PDU format that is
designed for fast and efficient data forwarding in order to achieve low
communication delays. SCMP, however, is more complex. As with ICMP and IP,
SCMP packets are transferred within ST packets as shown in Figure 1.
3.1.2 Sending CONNECT Messages 18 DATA PATH CONTROL PATH
========= ============
Upper +------------------+ +---------+
Layer | Application data | | Control |
+------------------+ +---------+
| |
| V
| +-------------------+
SCMP | | SCMP | |
| +-------------------+
| |
V V
+-----------------------+ +------------------------+
ST | ST | | | ST | | |
+-----------------------+ +------------------------+
D-bit=1 D-bit=0
3.1.2.1 Empty Target List 18 Figure 1: ST2 Data and Control Path
+--------------------+
| Conference Control |
+--------------------+
|
+-------+ +-------+ |
| Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application
| Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer
+-------+ +-------+ | +-----+ +------+ +-----+ +-----+
| | | | | | |
V V | | | | | ------------
+-----+ +-----+ | | | | |
| PVP | | NVP | | | | | |
+-----+ +-----+ + | | | |
| \ | \ \ | | | |
| +-----|--+-----+ | | | |
| Appl.|control V V V V V
| ST data | +-----+ +-------+ +-----+
| & control| | UDP | | TCP | ... | RTP | Transport
| | +-----+ +-------+ +-----+ Layer
| /| / | \ / / | / /|
|\ / | +------+--|--\-----+-/--|--- ... -+ / |
| \ / | | | \ / | / |
| \ / | | | \ +----|--- ... -+ | -----------
| \ / | | | \ / | |
| V | | | V | |
| +------+ | | | +------+ | +------+ |
| | SCMP | | | | | ICMP | | | IGMP | | Internet
| +------+ | | | +------+ | +------+ | Layer
| | | | | | | | |
V V V V V V V V V
+-----------------+ +-----------------------------------+
| STream protocol |->| Internet Protocol |
+-----------------+ +-----------------------------------+
| \ / |
| \ / |
| X | ------------
| / \ |
| / \ |
VV VV
+----------------+ +----------------+
| (Sub-) Network |...| (Sub-) Network | (Sub-)Network
| Protocol | | Protocol | Layer
+----------------+ +----------------+
3.1.2.2 Long Target Lists 19 Figure 2. Protocol Relationships
1.2 ST2 and IP
3.1.3 Processing CONNECT Messages 19 ST2 is designed to coexist with IP on each node. A typical distributed
multimedia application would use both protocols: IP for the transfer of
traditional data and control information, and ST2 for the transfer of
real-time data. Whereas IP typically will be accessed from TCP or UDP, ST2
will be accessed via new end-to-end real-time protocols. The position of ST2
with respect to the other protocols of the Internet family is represented in
Figure 2.
3.1.3.1 CONNECT Processing by an Intermediate ST agent 19 Both ST2 and IP apply the same addressing schemes to identify different
hosts. ST2 and IP packets differ in the first four bits, containing the
internetwork protocol version number: number 5 is reserved for ST2 (IP
itself has version number 4). As a network layer protocol, like IP, ST2
operates independently of its underlying subnets. Existing implementations
use ARP for address resolution, and use the same Layer 2 SAPs as IP.
3.1.3.2 Setup at the Targets 19 As a special function, ST2 messages can be encapsulated in IP packets. This
is represented in Figure 2 as a link between ST2 and IP. This link allows
ST2 messages to pass through routers which do not run ST2. Resource
management is typically not available for these IP route segments. IP
encapsulation is, therefore, suggested only for portions of the network
which do not constitute a system bottleneck.
3.1.4 Processing ACCEPT Messages 20 In Figure 2, the RTP protocol is shown as an example of transport layer on
3.1.4.1 ACCEPT Processing by an Intermediate ST agent 20 top of ST2. Alternatives include the Packet Video Protocol (PVP) [Cole81],
the Network Voice Protocol (NVP) [Cohe81], and others such as the Heidelberg
Transport Protocol (HeiTP) [DHHS92].
3.1.4.2 ACCEPT Processing by the Origin 20 1.3 Protocol History
3.1.5 Processing REFUSE Messages 20 The first version of ST was published in the late 1970's and was used
throughout the 1980's for experimental transmission of voice, video, and
distributed simulation. The experience gained in these applications led to
the development of the revised protocol version ST2. The revision extends
the original protocol to make it more complete and more applicable to
emerging multimedia environments. The specification of this protocol version
is contained in Internet RFC 1190 which was published in October 1990
[RFC1190].
3.1.5.1 REFUSE Processing by the Intermediate ST agent 20 With more and more developments of commercial distributed multimedia
applications underway and with a growing dissatisfaction at the transmission
quality for audio and video over IP in the MBONE, interest in ST2 has grown
over the last years. Companies have products available incorporating the
protocol. The BERKOM MMTS project of the German PTT [DeAl92] uses ST2 as its
core protocol for the provision of multimedia teleservices such as
conferencing and mailing. In addition, implementations of ST2 for Digital
Equipment, IBM, NeXT, Macintosh, PC, Silicon Graphics, and Sun platforms are
available.
3.1.5.2 REFUSE Processing by the Origin 21 In 1993, the IETF started a new working group on ST2 as part of ongoing
efforts to develop protocols that address resource reservation issues. The
group's mission was to clean up the existing protocol specification to
ensure better interoperability between the existing and emerging
implementations. It was also the goal to produce an updated experimental
protocol specification that reflected the experiences gained with the
existing ST2 implementations and applications. This has led to the
specification of the version of ST2, called ST2+, contained in this
document.
3.2 Stream Options 21 1.4 Supporting Modules for ST2
3.2.1 No Recovery 21 ST2 is one piece of a larger mosaic. This section presents the overall
communication architecture and clarifies the role of ST2 with respect to its
supporting modules.
3.2.2 Join Authorization Level 21 ST2 proposes a two-step communication model. In the first step, the
real-time channels for the subsequent data transfer are built. This is
called stream setup. It includes selecting the routes to the destinations
and reserving the correspondent resources. In the second step, the data is
transmitted over the previously established streams. This is called data
transfer. While stream setup does not have to be completed in real-time,
data transfer has stringent real-time requirements. The architecture used to
describe the ST2 communication model includes:
3.3 Data Transfer 22 o a data transfer protocol for the transmission of real-time data over
the established streams,
3.4 Modifying an Existing Stream 22 o a setup protocol to establish real-time streams based on the flow
specification,
3.4.1 The Origin Adding New Targets 23 o a flow specification to express user real-time requirements,
3.4.2 A Target Joining a Stream 23 o a routing function to select routes in the Internet,
3.4.2.1 ST FlowSpec 24 o a local resource manager to appropriately handle resources involved
in the communication.
3.4.2.2 Router as Origin 25 This document defines a data protocol (ST), a setup protocol (SCMP), and a
flow specification (ST2+ FlowSpec). It does not define a routing function
and a local resource manager. However, ST2 assumes their existence.
3.4.3 The Origin Removing Targets 25 Alternative architectures are possible, see [RFC1633] for an example
alternative architecture that could be used when implementing ST2.
3.4.4 A Target Deleting Itself 26 1.4.1 Data Transfer Protocol
The data transfer protocol defines the format of the data packets belonging
to the stream. Data packets are delivered to the targets along the stream
paths previously established by the setup protocol. Data packets are
delivered with the quality of service associated with the stream.
3.4.5 Changing a Stream's FlowSpec 26 Data packets contain a globally unique stream identifier that indicates
which stream they belong to. The stream identifier is also known by the
setup protocol, which uses it during stream establishment. The data transfer
protocol for ST2, known simply as ST, is completely defined by this
document.
3.5 Stream Tear Down 26 1.4.2 Setup Protocol
4 Exceptional Cases 28 The setup protocol is responsible for establishing, maintaining, and
releasing real-time streams. It relies on the routing function to select
the paths from the source to the destinations. At each host on these paths,
it presents the flow specification associated with the stream to the local
resource manager. This causes the resource managers to reserve appropriate
resources for the stream. The setup protocol for ST2 is called Stream
Control Message Protocol, or SCMP, and is completely defined by this
document.
4.1 Setup Failures 28 1.4.3 Flow Specification
4.1.1 Setup Failure due to CONNECT Timeout 28 The flow specification is a data structure including the ST2 applications'
QoS requirements. At each node, it is used by the local resource manager to
appropriately handle resources so that such requirements are met.
Distributing the flow specification to all resource managers along the
communication paths is the task of the setup protocol. However, the contents
of the flow specification are transparent to the setup protocol, which
simply carries the flow specification. Any operations on the flow
specification, including updating internal fields and comparing flow
specifications are performed by the resource managers.
4.1.2 Setup Failure due to ACCEPT Timeout 28 This document defines a specific flow specification format that allows for
interoperability among existing ST2 implementations. Implementations may
support more than one flow specification format and the means are provided
to add new formats as they are defined in the future. However, the flow
specification format has to be consistent throughout the stream, i.e. it is
not possible to use different flow specification formats for the same
stream.
4.1.3 Setup Failure due to Routing Failures 28 1.4.4 Routing Function
4.2 Further Issues 29 The routing function is an external unicast route generation capability. It
4.2.1 Problems due to Routing Inconsistency 29 provides the setup protocol with the path to reach each of the desired
destinations. Once a route is selected by the routing function, it persists
for the whole stream lifetime. The routing function may try to optimize
based on the number of targets, the requested resources, or use of local
network multicast or bandwidth capabilities. Alternatively, the routing
function may even be based on simple connectivity information.
4.2.2 Path Convergence 30 The setup protocol is not necessarily aware of the criteria used by the
routing function to select routes. It works well with any reasonable routing
function algorithm. The algorithm adopted is a local matter at each host and
different hosts may use different algorithms. The interface between setup
protocol and routing function is also a local matter and therefore it is not
specified by this document.
4.2.3 Problems in Reserving Resources 30 1.4.5 Local Resource Manager
4.2.4 Problems Caused by CHANGE Messages 31 At each host traversed by a stream, the Local Resource Manager (LRM) is
responsible for handling local resources. The LRM knows which resources are
on the system and what capacity they can provide. Resources include:
5 Failure Detection and Recovery 32 o CPUs on end systems and routers to execute the application and
protocol software,
5.1 Failure Detection 32 o main memory space for this software (as in all real-time systems,
code should be pinned in main memory, as swapping it out would have
detrimental effects on system performance),
5.1.1 Network Failures 32 o buffer space to store the data, e.g., communication packets, passing
through the nodes,
5.1.2 Detecting ST Agents Failures 32 o network adapters, and
5.2 Failure Recovery 34 o transmission networks between the nodes. Networks may be as simple
as point-to-point links or as complex as switched networks such as
Frame Relay and ATM networks.
5.2.1 Problems in Stream Recovery 35 During stream setup and modification, the LRM is presented by the setup
protocol with the flow specification associated to the stream. For each
resource it handles, the LRM is expected to perform the following functions:
5.3 Stream Preemption 36 o Stream Admission Control: it checks whether, given the flow
specification, there is sufficient capacity left to handle the new
data stream. If the available capacity is insufficient, the new
data stream must be rejected.
6 A Group of Streams 37 o QoS Computation: it calculates the best possible performance the
resource can provide for the new data stream under the current
traffic conditions, e.g. throughput and delay values are computed.
6.1 Group Name Generator 37 o Resource Reservation: it reserves the resource capacities required
to meet the desired QoS.
6.2 Basic ST Relationships 38 During data transfer, the LRM is responsible for:
6.2.1 Bandwidth Sharing 38 o QoS Enforcement: it enforces the QoS requirements by appropriate
scheduling of resource access. For instance, an application with a
short guaranteed delay must be served prior to an application with
a less strict delay bound.
6.2.2 Fate Sharing 38 The LRM may also provide the following additional functions:
6.2.3 Route Sharing 39 o Data Regulation: to smooth a stream's data traffic, e.g. as with the
leaky bucket algorithm.
6.2.4 Subnet Resources Sharing 39 o Policing: to prevent applications exceed their negotiated QoS, e.g.
to send data at a higher rate than indicated in the flow
specification.
6.3 Relationships Orthogonality 39 o Stream Preemption: to free up resources for other streams with
higher priority or importance.
7 Ancillary Functions 40 The strategies adopted by the LRMs to handle resources are
resource-dependent and may vary at every host. However, it is necessary that
all LRMs have the same understanding of the flow specification. The
interface between setup protocol and LRM is a local matter at every host and
therefore it is not specified by this document. An example of LRM is the
Heidelberg Resource Administration Technique (HeiRAT) [VoHN93].
7.1 Stream IDs Generation 40 It is also assumed that the LRM provides functions to compare flow
specifications, i.e. to decide whether a flow specification requires a
greater, equal, or smaller amount of resource capacities to be reserved.
7.2 Checksum Computation 40 1.5 ST2 Basic Concepts
7.3 SCMP Reliability 40 The following sections present at an introductory level some of the
fundamental ST2 concepts including streams, data transfer, and flow
specification.
7.4 Network MTU Discovery 40 1.5.1 Streams
7.5 Packet Discarding on Network Congestion 41
7.6 IP Encapsulation of ST 41 Streams form the core concepts of ST2. They are established between a
sending origin and one or more receiving targets in the form of a routing
tree. Streams are uni-directional from the origin to the targets. Nodes in
the tree represent so-called ST agents, entities executing the ST2 protocol;
links in the tree are called hops.
7.7 IP Multicasting 42 Figure 3 illustrates a stream from an origin to four targets, where the ST
agent on Target 2 also functions as a router. Let us use this Target
2/Router node to explain some basic ST2 terminology: the direction of the
stream from this node to Target 3 and 4 is called downstream, the direction
towards the Origin node upstream. ST agents that are one hop away from a
given node are called previous-hops in the upstream, and next-hops in the
downstream direction.
7.8 Routing 42 Hosts Connections... : ...and Streams
==================== : ==============
data Origin : Origin
packets +-----------+ : +----+
+----|Application| : | |
| |-----------| : +----+
+--->| ST Agent | : | |
+-----------+ : | |
| : | |
V : | |
+-------------+ : | |
| | : | |
+-------------| Network A | : +-------+ +--------+
| | | : | |
| +-------------+ : | |
| | Target 2 : | |
| Target 1 | and Router : | |
| +-----------+ | +-----------+ : V V
| |Application|<-+ | |Application|<-+ : +----+ +----+
| |-----------| | | |-----------| | : | | Target 2 | |
+->| ST Agent |--+ +->| ST Agent |--+ : +----+ & Router +----+
+-----------+ +-----------+ : Target 1 | |
| : | |
V : | |
+-------------+ : | |
| | : | |
+-------------| Network B | : +----------+ |
| | | : | |
| +-------------+ : | |
| Target 3 | Target 4 : | |
| +-----------+ | +-----------+ : V V
| |Application|<-+ | |Application|<-+ : +----+ +----+
| |-----------| | | |-----------| | : | | | |
+->| ST Agent |--+ +->| ST Agent |--+ : +----+ +----+
+-----------+ +-----------+ : Target 3 Target 4
:
8 FlowSpec 42 Figure 3: The Stream Concept
8.1 FlowSpec Versions 43 Streams are maintained using SCMP messages. Typical SCMP messages are
CONNECT and ACCEPT to build a stream, DISCONNECT and REFUSE to close a
stream, and CHANGE to modify the quality of service associated with a
stream.
8.2 The Null FlowSpec (#0) 43 Each ST agent maintains state information describing the streams flowing
through it. It can actively gather and distribute such information. If, for
example, an intermediate ST agent fails, the neighbouring ST agents can
recognize this via HELLO messages that are periodically exchanged between ST
agents that share streams. STATUS packets can be used to ask other ST agents
about a particular stream. These ST agents then send back a STATUS-RESPONSE
message. NOTIFY messages serve to inform ST agents of significant events.
8.3 The ST Current FlowSpec (#7) 43 ST2 offers a wealth of functionalities for stream management. Streams can be
grouped together to minimize allocated resources or to process them in the
same way in case of failures. During audio conferences, for example, only a
limited set of participants may talk at once. Using the group mechanism,
resources for only a portion of the audio streams of the group need to be
reserved. Using the same concept, an entire group of related audio and video
streams can be dropped if one of them is preempted.
8.3.1 Qos Classes 44 1.5.2 Data Transmission
8.3.2 Maximum Message Size 44 Data transfer in ST2 is simplex in the downstream direction. Data transport
through streams is very simple. ST2 puts only a small header in front of the
user data. The header contains a protocol identification that distinguishes
ST2 from IP packets, an ST2 version number, a priority field (specifying a
relative importance of streams in cases of conflict), a length counter, a
stream identification, and a checksum. These elements form an 12-byte
header.
8.3.3 Rate or Throughput 44 Efficiency is also achieved by avoiding fragmentation and reassembly on
router nodes. Stream establishment yields a maximum message size for data
packets on a stream. This maximum message size is communicated to the upper
layers, so that they provide data packets of suitable size to ST2.
8.3.4 Maximum Delay and Delay Jitter 44 Communication with multiple next-hops can be made even more efficient using
MAC Layer multicast. If a subnet supports multicast, a single multicast
packet is sufficient to reach all next-hops connected to this subnet. This
leads to a significant reduction of the bandwidth requirements of a stream.
If multicast is not provided, separate packets need to be sent to each
next-hop.
9 ST State Machines 45 As ST2 relies on reservation, it does not contain error correction
mechanisms features for data exchange such as retransmission known from TCP.
It is assumed that 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.
10 ST Protocol Data Units 46 1.5.3 Flow Specification
10.1 ST Data Packets 47 As part of establishing a connection, SCMP handles the negotiation of
quality-of-service parameters for a stream. In ST2 terminology, these
parameters form a flow specification (FlowSpec) which is associated with the
stream. Different versions of FlowSpecs exist and can be distinguished by a
version number. Typically, they contain parameters such as average and
maximum throughput, end-to-end delay, and delay variance of a stream. SCMP
itself only provides the mechanism for relaying the quality-of-service
parameters.
10.1.1 Stream ID 47 Three kinds of entities participate in the quality-of-service negotiation:
application entities on the origin and target sites as the service users, ST
agents, and local resource managers (LRM). The origin application supplies
the initial FlowSpec requesting a particular service quality. Each ST agent
which obtains the FlowSpec as part of a connection establishment message, it
presents the local resource manager with it. ST2 does not determine how
resource managers make reservations and how resources are scheduled
according to these reservations; ST2, however, assumes these mechanisms as
its basis.
10.2 ST Control Messages 47 An example of the FlowSpec negotiation procedure is illustrated in Figure 4.
Depending on the success of its local reservations, the LRM updates the
FlowSpec fields and returns the FlowSpec to the ST agent, which passes it
downstream as part of the connection message. Eventually, the FlowSpec is
communicated to the application at the target which may base its
accept/reject decision for establishing the connection on it and may finally
also modify the FlowSpec. If a target accepts the connection, the (possibly
modified) FlowSpec is propagated back to the origin which can then calculate
an overall service quality for all targets. The origin may later issue a
CHANGE request to adjust reservations.
10.3 Common SCMP Elements 48 Origin Router Target 1
+------+ 1a +------+ 1b +------+
| |-------------->| |------------->| |
+------+ +------+ +------+
^ | ^ |
| | | 2 |
| | +------------------------------------------+
+ +
+-------------+ \ \ +-------------+ +-------------+
|Max Delay: 1| \ \ |Max Delay: 12| |Max Delay: 12|
|-------------| \ \ |-------------| |-------------|
|Gua Delay: 2| \ \ |Gua Delay: 5| |Gua Delay: 9|
|-------------| \ \ |-------------| |-------------|
|Max Size:4096| + + |Max Size:2048| |Max Size:2048|
+-------------+ | | +-------------+ +-------------+
FlowSpec | | 1
| +---------------+
| |
| V
2 | +------+
+-------------->| |
+------+
Target 2
+-------------+
|Max Delay: 12|
|-------------|
|Gua Delay: 4|
|-------------|
|Max Size:4096|
+-------------+
10.3.1 ErroredPDU 49 Figure 4: Quality-of-Service Negotiation with FlowSpecs
10.3.2 FlowSpec 49 1.6 Outline of This Document
10.3.3 Group 50 This document contains the specification of the ST2+ version of the ST2
protocol. In the rest of the document, whenever the terms "ST" or "ST2" are
used, they refer to the ST2+ version of ST2.
10.3.4 MulticastAddress 50 The document is organized as follows:
10.3.5 NextHopIPAddress 51 o Section 2 describes the ST2 user service from an application point
of view.
10.3.6 Origin 51 o Section 3 illustrates the ST2 data transfer protocol, ST.
10.3.7 ReasonCode 51
10.3.8 Target and TargetList 53 o Section 4 through Section 8 specify the ST2 setup protocol, SCMP.
10.3.9 UserData 54 o the ST2 flow specification is presented in Section 9.
11 ST Control Message PDUs 55 o the formats of protocol elements and PDUs are defined in Section 10.
11.1 ACCEPT 55 2 ST2 User Service Description
11.2 ACK 56 This section describes the ST user service from the high-level point of view
of an application. It defines the ST stream operations and primitive
functions. It specifies which operations on streams can be invoked by the
applications built on top of ST and when the ST primitive functions can be
legally executed. Note that the ST primitives do not form an API. They are
used here with the only purpose of illustrating the service model for ST.
11.3 CHANGE 56 2.1 Stream Operations and Primitive Functions
11.4 CONNECT 57 An ST application at the origin may create, expand, reduce, change, send
data to, and delete a stream. When a stream is expanded, new targets are
added to the stream; when a stream is reduced, some of the current targets
are dropped from it. When a stream is changed, the associated quality of
service is modified.
11.5 DISCONNECT 58 An ST application at the target may join, receive data from, and leave a
stream. This translates into the following stream operations:
11.6 ERROR 59 o OPEN: create new stream [origin], CLOSE: delete stream [origin],
11.7 HELLO 59 o ADD: expand stream, i.e. add new targets to it [origin],
11.8 JOIN-REQUEST 60 o DROP: reduce stream, i.e. drop targets from it [origin],
11.9 NOTIFY 60 o JOIN: join a stream [target], LEAVE: leave a stream [target],
11.10 REFUSE 61 o DATA: send data through stream [origin],
11.11 STATUS 62 o CHG: change a stream's QoS [origin],
11.12 STATUS-RESPONSE 63 Each stream operation may require the execution of several primitive
functions to be completed. For instance, to open a new stream, a request is
first issued by the sender and an indication is generated at the receiver;
then, the receiver may accept or refuse the request and the correspondent
indication is generated at the sender. This is shown in Figure 5 below.
12 Suggested Protocol Constants 64 Sender Network Receiver
| | |
OPEN.req | | |
|-----------------> | |
| |-----------------> |
| | | OPEN.ind
| | | OPEN.accept
| |<----------------- |
|<----------------- | |
OPEN.accept-ind | | |
| | |
12.1 SCMP Messages 64 Figure 5: Primitives for the OPEN Stream Operation
12.2 SCMP Parameters 64 Table 1 defines the ST service primitive functions associated to each stream
operation. The column labelled "O/T" indicates whether the primitive is
executed at the origin or at the target.
13 Notation 64 +===================================================+
|Primitive | Descriptive |O/T|
|===================================================|
|OPEN.req | open a stream | O |
|OPEN.ind | connection request indication | T |
|OPEN.accept | accept stream | T |
|OPEN.refuse | refuse stream | T |
|OPEN.accept-ind| connection accept indication | O |
|OPEN.refuse-ind| connection refuse indication | O |
|ADD.req | add targets to stream | O |
|ADD.ind | add request indication | T |
|ADD.accept | accept stream | T |
|ADD.refuse | refuse stream | T |
|ADD.accept-ind | add accept indication | O |
|ADD.refuse-ind | add refuse indication | O |
|JOIN.req | join a stream | T |
|JOIN.ind | join request indication | O |
|JOIN.reject | reject a join | O |
|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 |
+---------------------------------------------------+
14 Further Study 64 Table 1: ST Primitives
15 References 65 1 Introduction 2.2 State Diagrams
1.1 What is ST2? 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 stream operations can be legally executed
only from an appropriate state.
The Internet Stream Protocol, Version 2 (ST2) is a connection- An ST agent may, with respect to an ST stream, be in one of the following
oriented internetworking protocol that operates at the same layer as states:
connectionless IP. It has been developed to support the efficient
delivery of data streams to single or multiple destinations in
applications that require guaranteed data throughput and controlled
delay characteristics. The main application area of the protocol is
the real-time transport of digital audio and video packet streams
across internets.
ST2 can be used to reserve bandwidth for multimedia streams across o IDLE: the stream has not been created yet.
network routes. This reservation, together with appropriate network
access and packet scheduling mechanisms in all nodes running the
protocol, guarantees a well-defined quality of service to ST2
applications. It ensures that each multimedia packet is delivered
within its deadline, that is, at the time where it needs to be
presented. This facilitates a smooth playout of digital audio and
video that is essential for this time-critical data, but can
typically not be provided by best-effort IP communication.
Just like IP, ST2 actually consists of two protocols: ST for the data o PENDING: the stream is in the process of being established.
transport and SCMP, the Stream Control Message Protocol, for all
control functions, mainly those for resource reservation. ST is
simple and contains only one PDU that is designed for fast and
efficient data forwarding in order to achieve low communication
delays. SCMP, however, is quite complex. As with ICMP and IP, SCMP
packets are transferred within ST packets as shown in Figure 1.
1.2 Protocol History o ACTIVE: the stream is established and active.
The first version of ST was published in the late 1970's and was used o ADDING: the stream is established. A stream expansion is underway.
throughout the 1980's for experimental voice and video transmission.
The experience gained in these applications led to the development of
the revised protocol version ST2. The revision extends the original
protocol to make it more complete and more applicable to emerging
multimedia environments. The specification of this protocol version
is contained in Internet RFC 1190 which was published in October 1990
[RFC1190].
With more and more developments of commercial distributed multimedia o CHGING: the stream is established. A stream change is underway.
applications underway and with a growing dissatisfaction at the
transmission quality for audio and video over IP in the MBONE,
interest in ST2 has grown over the last years. Companies such as BBN
have products available incorporating the protocol. The BERKOM
project of the German PTT uses ST2 as its core protocol for the
provision of multimedia teleservices such as conferencing and
mailing. Among others, Digital, HP, IBM, and Siemens-Nixdorf
participate in this project. In addition, implementations of ST2 for
Sun, Silicon Graphics, Macintosh, NeXT, and PC platforms are
available.
In 1993, the IETF has started a new working group on ST2. Its mission Previous experience with ST suggested to impose limits on the stream
is to clean up the current protocol specification to ensure better operations that can be executed at the same time. These restrictions are:
interoperability between the existing and emerging implementations.
It shall also reflect the experiences gained with the current ST2
implementations and applications. This has led to the specification
of the ST2+ version contained in this document.
1.3 Streams 1. A single ADD or CHG operation can be processed at one time. If
another ADD or CHG is already underway, further requests are queued by the
ST agent and handled only after the previous operation has been completed.
It 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.
Streams form the core concepts of ST2. They are established between a 2. Deleting a stream, leaving a stream, or dropping targets from a
sending origin and one or more receiving targets in the form of a stream is possible only after stream establishment has been completed. A
routing tree. Nodes in the tree represent so-called ST agents, stream is considered to be established when all the next-hops of the origin
entities executing the ST2 protocol; links in the tree are called have either accepted or refused the stream. Note that stream refuse is
hops. automatically forced after timeout if no reply comes from a next-hop.
Figure 2 illustrates a stream from an origin to four targets, where 3. An ST agent forwards data only along already established paths to
the ST agent on Target 2 also functions as a router. Let us use this the targets, see also Section 3.1. A path is considered to be established
Target 2/Router node to explain some basic ST2 terminology: the when the next-hop on the path has explicitly accepted the stream. This
direction of the stream from this node to Target 3 and 4 is called implies that the target and all other intermediate ST agents are ready to
downstream, the direction towards the Origin node upstream. ST agents handle the incoming data packets. In no cases an ST agent will forward data
that are one hop away from a given node are called previous-hops in to a next-hop ST agent that has not explicitly accepted the stream. To be
the upstream, and next-hops in the downstream direction. 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.
Streams are maintained using SCMP messages. Typical SCMP messages are 4. It is allowed to send data from the CHGING and ADDING states. While
CONNECT and ACCEPT to build a stream, DISCONNECT and REFUSE to close sending data from the CHGING state, the quality of service to the targets
a stream, or CHANGE to modify the quality of service associated with affected by the change should be assumed to be the more restrictive quality
a stream. 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.
Each ST agent maintains state information describing the streams The rules introduced above require ST agents to queue incoming requests when
flowing through it. It can actively gather and distribute such the current state does not allow to process them immediately. In order to
information. If, for example, an intermediate ST agent fails, the preserve the semantics, ST agents have to maintain the order of the
neighboring ST agents can recognize this via HELLO messages that are requests, i.e. implement FIFO queuing. Exceptionally, the CLOSE request at
periodically exchanged between ST agents that share streams. STATUS the origin and the LEAVE request at the target may be immediately processed:
packets can be used to ask other ST agents about a particular stream. in this cases, the queue is deleted and it is possible that requests in the
These ST agents then send back a STATUS-RESPONSE message. NOTIFY queue are not processed.
messages serve to inform ST agents of changes such as a route change.
ST2 offers a wealth of functionalities for stream management. Streams The following state diagrams define the ST service. Separate diagrams are
can be grouped together to minimize allocated resources or to process presented for the origin and the targets. To keep the figure simple, only
them in the same way in case of failures. During audio conferences, the primitives that cause state transitions are represented.
for example, only one person should speak at a time. Using the group
mechanism, resources for only one audio stream of the group need to
be reserved. Using the same concept, an entire group of related audio
and video streams can be dropped if one of them fails.
1.4 Data Transmission 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.
Data transfer in ST2 is simplex in the downstream direction. Data +------------+
transport through streams is very efficient. ST2 puts only a small | |<-------------------+
header in front of the user data. The header contains a protocol +---------->| IDLE |-------------+ |
identification that distinguishes ST2 from IP packets, an ST2 version | | | OPEN.req | |
number, a priority field (specifying a relative importance of streams | +------------+ | |
in cases of conflict), a length counter, a stream identification, and CLOSE.req | CLOSE.req ^ ^ CLOSE.req V | CLOSE.req
a checksum. These elements form an 8-byte header which can be | | | +---------+ |
extended by an optional 8-byte timestamp. | | | | 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
Efficiency is also achieved by avoiding fragmentation and reassembly Figure 6: ST Service at the Origin
on router nodes. Negotiations at stream establishment time yield a
maximum transmission unit (MTU) for data packets on a stream. This
MTU is communicated to the upper layers, so that they provide data
packets of suitable size to ST2.
Communication with multiple next-hops can be made even more efficient +--------+
using MAC Layer multicast. If a subnet supports multicast, a single | |-----------------------+
multicast packet is sufficient to reach all next- hops connected to | IDLE | |
this subnet. This leads to a significant reduction of the bandwidth | |<---+ | OPEN/ADD.ind
requirements of a stream. If multicast is not provided, separate +--------+ | CLOSE.ind | JOIN.req
packets need to be sent to each next-hop. ^ | OPEN/ADD.refuse |
| | JOIN.refect-ind |
CLOSE.ind | | V
DROP.ind | | +---------+
LEAVE.req | +-------------| |
| | PENDING |
+-------+ | |
| | +---------+
| ESTBL | OPEN/ADD.accept |
| |<-----------------------+
+-------+
As ST2 relies on reservation, it does not contain error correction Figure 7: ST Service at the Target
mechanisms features for data exchange such as retransmission known It should be noted that the separate OPEN and ADD primitives at the target
from TCP. It is assumed that digital audio and video require are for conceptual purposes only. The target is actually unable to
partially correct delivery only. In many cases, retransmitted packets distinguish between an OPEN and an ADD. This is reflected in Figure 7 and
would arrive too late to meet their real-time delivery requirements. Table 3 through the notation OPEN/ADD.
On the other hand, depending on the data encoding and the particular
application, a small number of errors in audio and video streams are
acceptable. In any case, reliability can be provided by layers on top
of ST2 if needed.
1.5 Flow Specifications 2.3 State Transition Tables
As part of establishing a connection, SCMP negotiates quality-of- Table 2 and Table 3 define which primitives can be processed from which
service parameters for a stream. In ST2 terminology, these parameters states and the possible state transitions.
form a flow specification (FlowSpec, for short) which is associated
with the stream. Different versions of FlowSpecs exist and can be
distinguished by a version number. Typically, they contain parameters
such as average and maximum throughput, end-to-end delay, and delay
variance of a stream.
Three kinds of entities participate in the quality-of-service +=============================================================================+
negotiation: application entities on the origin and target sites as |Primitive |IDLE| PENDING | ESTBL | CHGING | ADDING |
the service users, ST agents, and local resource managers (LRM). The |=============================================================================|
origin application supplies the initial FlowSpec requesting a |OPEN.req | ok | - | - | - | - |
particular service quality. Each ST agent which obtains the |OPEN.accept-ind| - |if(a,r)*->ESTBL| - | - | - |
specification as part of a connection establishment message initiates |OPEN.refuse-ind| - |if(a,r)*->ESTBL| - | - | - |
the reservation of local resources by the corresponding resource |ADD.req | - | queued |->ADDING| queued | queued |
manager. These resource managers control the usage of CPU capacity |ADD.accept-ind | - | - | - | - |if(a,r)*->ESTBL|
for protocol processing, buffer space for storing messages, and |ADD.refuse-ind | - | - | - | - |if(a,r)*->ESTBL|
bandwidth in the outgoing network. ST2 does not determine how |JOIN.ind | - | queued |->ADDING| queued |queued |
resource managers make reservations and how resources are scheduled |JOIN.reject | - | OK | ok | ok | ok |
according to these reservations; ST2, however, assumes these |DATA.req | - | - | ok | ok | ok |
mechanisms as its basis. |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
The FlowSpec negotiation procedure is illustrated in Figure 3. +======================================================+
Depending on the success of its local reservations, an ST agent | Primitive | IDLE | PENDING | ESTBL |
updates the FlowSpec while the connection establishment message |======================================================|
passes downstream (for example, keeping track of accumulated delay). | OPEN/ADD.ind | ->PENDING | - | - |
The final FlowSpec is communicated to the target application which | OPEN/ADD.accept | - | ->ESTBL | - |
may base its accept/reject decision for establishing the connection | OPEN/ADD.refuse | - | ->IDLE | - |
on it and may finally also modify the FlowSpec. If a target accepts | JOIN.req | ->PENDING | - | - |
the connection, the (possibly modified) FlowSpec is propagated back | JOIN.reject-ind |- | ->IDLE | - |
to the origin which can then calculate an overall service quality for | DATA.ind | - | - | ok |
all targets. If all targets in a particular ST2 connection need to | CHG.ind | - | - | ok |
adhere to the same FlowSpec, the origin may - during a second phase | CHG.accept | - | - | ok |
of connection establishment - issue a CHANGE request to adjust | DROP.ind | - | ok | ok |
reservations. | LEAVE.req | - | ok | ok |
| CLOSE.ind | - | ok | ok |
| CHG.ind | - | - | ok |
+------------------------------------------------------+
Table 3: Primitives and States at the Target
3 The ST2 Data Transfer Protocol
1.6 ST2 and IP 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.
ST2 is designed to coexist with IP on each node. A typical 3.1 Data Transfer with ST
distributed multimedia application would use both protocols: IP for
the transfer of traditional data and control information, and ST2 for
the transfer of digital audio and video. Whereas IP typically will be
accessed from TCP or UDP, ST2 will have new multimedia end-to-end
protocols on top of it.
Both ST2 and IP apply the same addressing schemes to identify Data transmission with ST is unreliable. An application is not guaranteed
different hosts and use ARP for address resolution. ST2 can easily be that the data reaches its destinations and no attempts are made to recover
modified to include the longer host addresses of the next generation from packet loss, e.g. due to the underlying network. However, if the data
IP. ST2 uses the same Layer 2 SAPs as IP. ST2 and IP packets differ reaches its destination, it does it accordingly to the quality of service
in the first four bits, containing the internetwork protocol version associated with the stream.
number: number 5 is reserved for ST2 (IP itself has version number
4). An ST agent receives a packet over the IP SAP using the first 4
bits of the frame to select ST2 packets.
As a special function, ST2 messages can be encapsulated in IP Additionally, ST may deliver data corrupted in transmission. It is assumed
packets. This allows them to pass through routers which do not run that real-time data, such as digital audio and video, require partially
ST2. Resource management is typically not available for these IP correct delivery only. In many cases, retransmitted packets would arrive too
route segments. IP encapsulation is, therefore, suggested only for late to meet their real-time delivery requirements. On the other hand,
portions of the network which do not constitute a system bottleneck. 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.
1.7 Outline of This Document Also, no data fragmentation is supported during the data transfer phase. The
application is expected to segment its data PDUs according to the minimum
MTU over all paths in the stream. The application receives information on
the MTUs relative to the paths to the targets as part of the ACCEPT message,
see Section 8.6. The minimum MTU over all paths can be calculated from the
MTUs relative to the single paths. ST agents silently discard too long data
packets, see also Section 5.1.1.
This document contains the specification for the ST2+ version of the An ST agent forwards the data only along already established paths to
ST2 protocol. In the rest of the document, whenever the terms "ST" or targets. A path is considered to be established once the next-hop ST agent
"ST2" are used, they refer to ST2+. on the path sends an ACCEPT message, see Section 2.2. This implies that the
target and all other intermediate ST agents on the path to the target are
ready to handle the incoming data packets. In no cases will an ST agent
forward data to a next-hop ST agent that has not explicitly accepted the
stream.
The document is organized as follows: Section 2 describes the ST user To be reasonably sure that all targets receive the data with the desired
service; Section 3.1 through Section 3.5 describe stream setup, quality of service, an application should send the data only after the whole
modification, and tear down; exceptional cases are handled in Section stream has been established. Depending on the local API, an application may
4; failure detection and groups of streams respectively in Section 5 not be prevented to send data before the completion of stream setup, but it
and Section 6; the FlowSpec is presented in Section ; finally, the should be aware that the data could be lost or not reach all intended
formats of the different protocol elements and PDUs are defined by targets. This behavior may actually be desirable to applications, such as
Section 10 through Section 15. Figure 1: ST2 Data and Control Path those application that have multiple targets which can each process data as
Figure 2: The Stream Concept Figure 3: Quality-of-Service Negotiation soon as it is available (e.g. a lecture or distributed gaming).
with FlowSpecs Figure 6: ST Service at the Target Figure 4:
Primitives for the OPEN Stream Operation Figure 5: ST Service at the
Origin 2 ST User Service Description
This section describes the ST user service from the high-level point Implementations must be able to handle networks that support multicast. If a
of view of an application. It defines the ST stream operations and network does not support multicast, or for the case where the next-hops are
primitive functions. It specifies which operations on streams can be on different networks, multiple copies of the data packet must be sent.
invoked by the applications built on top of ST and when the ST
primitive functions can be legally executed. Note that the ST
primitives do not form an API. They are used here with the only
purpose of illustrating the service model for ST.
2.1 Stream Operations and Primitive Functions 3.2 ST Protocol Functions
An ST application at the origin may create, expand, reduce, change, The ST protocol provides two functions:
send data to, and delete a stream. When a stream is expanded, new
targets are added to the stream; when a stream is reduced, some of
the current targets are dropped from it. When a stream is changed,
the associated quality of service is modified.
An ST application at the target may join, receive data from, and o stream identification
leave a stream.
This translates into the following stream operations: o data priority
o OPEN: create new stream [origin], CLOSE: delete stream 3.2.1 Stream Identification
[origin],
o ADD: expand stream, i.e. add new targets to it [origin], ST data packets are encapsulated by an ST header containing the Stream
IDentifier (SID). This SID is selected at the origin so that it is globally
unique over the Internet. The SID must be known by the setup protocol as
well. At stream establishment time, the setup protocol builds, at each host
traversed by the stream, an entry into its local database containing stream
information. The SID can be used as a reference into this database, to
obtain quickly the necessary replication and forwarding information.
o DROP: reduce stream, i.e. drop targets from it [origin], Stream IDentifiers are intended to be used to make the packet forwarding
task most efficient. The time-critical operation is an intermediate ST
agent receiving a packet from the previous-hop ST agent and forwarding it
to the next-hop ST agents.
o JOIN: join a stream [target], LEAVE: leave a stream [target], The format of data PDUs including the SID is defined in Section 10.1.
Stream IDentifier generation is discussed in Section 8.1.
o DATA: send data through stream [origin], 3.2.2 Packet Discarding based on Data Priority
o CHG: change a stream's qos [origin], ST provides a well defined quality of service to its applications. However,
Each stream operation may require the execution of several primitive there may be cases where the network is temporarily congested and the ST
functions to be completed. For instance, to open a new stream, a agents have to discard certain packets to minimize the overall impact to
request is first issued by the sender and an indication is generated other streams. The ST protocol provides a mechanism to discard data packets
at the receiver; then, the receiver may accept or refuse the request based on the Priority field in the data PDU, see Section 10.1. The
and the correspondent indication is generated at the sender. This is application assigns each data packet with a discard-priority level, carried
shown in Figure 4 below. into the Priority field. ST agents will attempt to discard lower priority
packets first during periods of network congestion.
Table 1 defines the ST service primitive functions associated to each 4 SCMP Functional Description
stream operation. The column labelled "O/T" indicates whether the
primitive is executed at the origin or at the target.
2.2 State Diagrams ST agents create and manage streams using the ST Control Message Protocol
(SCMP). Conceptually, SCMP resides immediately above ST (as does ICMP above
IP). SCMP follows a request-response model. SCMP messages are made reliable
through the use of retransmission after timeout.
It is not sufficient to define the set of ST stream operations. It is This section contains a functional description of stream management with
also necessary to specify when the operations can be legally SCMP. To help clarify the SCMP exchanges used to setup and maintain ST
executed. For this reason, a set of states is now introduced and the streams, we include an example of a simple network topology, represented in
transitions from one state to the others are specified. States are Figure 8. Using the SCMP messages described in this section it will be
defined with respect to a single stream. The previously defined possible for an ST application to:
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 o Create a stream from A to the peers at B, C and D,
following states:
o IDLE: the stream has not been created yet. o Add a peer at E,
o PENDING: the stream is in the process of being established. o Drop peers B and C, and
o ACTIVE: the stream is established and active. o Let F join the stream
o ADDING: the stream is established. A stream expansion is o Delete the stream.
underway.
o CHGING: the stream is established. A stream change is +---------+ +---+
underway. | |----| B |
+---------+ +----------+ | | +---+
| |------| Router 1 |---| Subnet2 |
| | +----------+ | |
| | | |
| | +---------+
| | |
| Subnet1 | |
| | +----------+
| | | Router 3 |
+---+ | | +----------+
| A |---| | +----------+ |
+---+ | |----| Router 2 | |
| | +----------+ |
+---------+ | |
| |
| +----------+ +---+
+----------| |----| C |
| | +---+
+---------+ | Subnet3 |
+---+ | | +---+ | | +---+
| F |---| Subnet4 |---| E |--| |----| D |
+---+ | | +---+ +----------+ +---+
+---------+
Previous experience with ST suggested to impose limits on the stream Figure 8: Sample Topology for an ST Stream
operations that can be executed at the same time. These restrictions
are:
1. A single ADD or CHG operation can be processed at one time. We first describe the possible types of stream in Section 4.1; Section 4.2
If another ADD or CHG is already underway, further requests are introduces SCMP control message types; SCMP reliability is discussed in
queued by the ST agent and handled only after the previous operation Section 4.3; stream options are covered in Section 4.4; stream setup is
has been completed. It also applies to two subsequent requests of the presented in Section 4.5; Section 4.6 illustrates stream modification
same kind, e.g. two ADD or two CHG operations. The second operation including stream expansion, reduction, changes of the quality of service
is not executed until the first one has been completed. associated to a stream. Finally, stream deletion is handled in Section 4.7.
2. Deleting a stream, leaving a stream, or dropping targets from 4.1 Types of Streams
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 SCMP allows for the setup and management of different types of streams.
paths to the targets. A path is con- sidered to be established when Streams differ in the way they are built and the information maintained on
the next-hop on the path has explicitly accepted the stream. This connected targets.
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
applica- tion should send the data only after all paths have been
established, i.e. the stream is estab- lished.
4. It is allowed to send data from the CHGING and ADDING states. 4.1.1 Stream Building
When sending data from the CHGING state the quality of service to the
targets affected by the change is undefined. 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 Streams may be built in a sender-oriented fashion, receiver-oriented
requests when the current state does not allow to process them fashion, or with a mixed approach:
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 this 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 o in the sender-oriented fashion, the application at the origin
are presented for the origin and the targets. To keep the figure provides the ST agent with the list of receivers for the stream.
simple, only the primitives that cause state transitions are New targets, if any, are also added from the origin.
represented.
The symbol (a/r)* indicates that all targets in the target list have o in the receiver-oriented approach, the application at the origin
explicitly accepted or refused the stream, or refuse has been forced creates an empty stream that contains no targets. Each target
after timeout. If the target list is empty, i.e. it contains no joins then the stream autonomously.
targets, the (a/r)* condition is immediately satisfied, so the empty
stream is created and state ESTBL is entered.
2.3 State Transition Tables o in the mixed approach, the application at the origin creates a
stream that contains some targets and other targets join then
the stream autonomously.
Table 2 and Table 3 define which primitives can be processed from ST2 provides stream options to support sender-oriented and mixed steams.
which states and the possible state transitions. Figure 7: Sample Receiver-oriented streams can be emulated through the use of mixed streams.
Topology for an ST Stream 3 SCMP Functional Description The fashion by which targets may be added to a particular stream is
ST agents create and manage streams using the ST Control Message controlled via join authorization levels. Join authorization levels are
Protocol (SCMP). Conceptually, SCMP resides immediately above ST (as described in Section 4.4.2.
does ICMP above IP). SCMP follows a request-response model. SCMP
messages are made reliable through the use of retransmission after
timeout, cf. Section 7.3.
This section contains a functional description of SCMP. To help 4.1.2 Knowledge of Receivers
clarify the SCMP exchanges used to setup and maintain ST streams, we
include an example of a simple network topology, represented in
Figure 7. The topology is used to illustrate the protocol
interactions during the execution of stream operations. For instance,
an ST application may:
o Create a stream from A to the peers at B, C and D, When streams are built in the sender-oriented fashion, all ST agents will
have full information on all targets down stream of a particular agent. In
this case, target information is relayed down stream from agent-to-agent
during stream set-up.
o Add a peer at E, When targets add themselves to mixed streams, up-stream ST agents may or may
not be informed. Propagation of information on targets that "join" a stream
is also controlled via join authorization levels. As previously mentioned,
join authorization levels are described in Section 4.4.2.
o Drop peers B and C, and This leads to two types of streams:
o Let F join the stream o full target information is propagated in a controlled stream. For
such streams, all agents are aware of all down-stream targets
connected to the stream. This results in target information
being maintained at the origin and routers. Operations on single
targets are always possible, i.e. charge a certain target, or,
drop that target from the stream. It is also always possible for
any ST agent to attempt recovery of all down-steam targets.
o Delete the stream. o in light-weight streams, it is possible that the origin and other
up-stream agents have no knowledge about some targets. This
results in less maintained state and easier stream management,
but it limits operations on specific targets. Special actions
may be required to support change and drop operations on
unknown targets, see Section 5.7. Also, stream recovery may not
be possible. Of course, generic functions such as deleting the
whole stream, are still possible. It is expected that
applications that will have a large number of targets will use
light-weight streams in order to limit state in agents and the
number of targets per control message.
We begin with a description of stream setup, see Section 3.1; stream Controlled streams serve well applications as video conferencing or
option are presented in Section 3.2; data transfer in Section 3.3; distributed gaming, where it is important to have knowledge on the connected
Section 3.4 illustrates stream modification including stream receivers, e.g. to limit who participates. Light-weight streams may be
expansion, reduction, changes of the quality of service associated to exploited by applications such as remote lecturing or playback applications
a stream. Finally, stream deletion is handled in Section 3.5. of radio and TV broadcast where the receivers do not need to be known by the
sender. Section 4.4.2 defines join authorization levels, which support two
types of controlled streams and one type of light-weight streams.
3.1 Stream Setup 4.2 Control PDUs
This section presents a description of stream setup. For simplicity, SCMP defines the following PDUs (the main purpose of each PDU is also
we assume that everything succeeds, e.g. any required resources are indicated):
available, and the routing is correct. Possible failures in the setup
phase are handled in Section 4.1.
3.1.1 Initial Setup at the Origin 1. ACCEPT to accept a new stream
2. ACK to acknowledge an incoming message
3. CHANGE to change the quality of service associated with
a stream
4. CONNECT to establish a new stream or add new targets to
an existing stream
5. DISCONNECT to remove some or all of the stream's targets
6. ERROR to indicate an error contained into an incoming
message
7. HELLO to detect failures of neighbour ST agents
8. JOIN to request stream joining from a target
9. JOIN-REJECT to reject a stream joining request from a target
10. NOTIFY to inform an ST agent of a significant event
11. REFUSE to refuse the establishment of a new stream
12. STATUS to query an ST agent on a specific stream
13. STATUS-RESPONSE to reply queries on a specific stream
Before stream setup can be started, the application has to collect SCMP follows a request-response model with all requests expecting responses.
the necessary information to determine the structure of the
communication. This includes identifying the participants and
selecting the characteristics of the data flow. Such information is
passed to the ST agent at the stream's origin. The ST agent performs
the following operations:
o allocates a stream ID (SID) for the stream, cf. Section 7.1, Retransmission after timeout is used to allow for lost or ignored messages.
Control messages do not extend across packet boundaries; if a control
message is too large for the MTU of a hop, its information is partitioned
and a control message per partition is sent, as described in Section 5.1.2.
o invokes the routing function to determine the set of next- The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY and
hops for the stream, cf. Section 3.1.1.1, REFUSE must always be explicitly acknowledged:
o invokes the Local Resource Manager (LRM), cf. Section o with an ACK message, if the message was received correctly and it
3.1.1.2, to reserve local and net- work resources was possible to parse and correctly extract and interpret its
header, fields and parameters,
o creates local database entries to store information on the o with an ERROR message, if a syntax error was detected in the header,
new stream, fields, or parameters included in the message. The errored PDU
may be optionally returned as part of the ERROR message. An
ERROR message indicates a syntax error only. If any other errors
are detected, it is necessary to first acknowledge with ACK and
then take appropriate actions. For instance, suppose a CHANGE
message contains an unknown SID: first, an ACK message has to be
sent, then a REFUSE message with ReasonCode (SIDUnknown)
follows.
o propagates the stream creation request to the next-hops If no ACK or ERROR message are received before the correspondent timer
determined by the routing function, see Section 3.1.2. expires, a timeout failure occurs. The way an ST agent should handle timeout
failures is described in Section 5.2.
3.1.1.1 Invoking the Routing Function ACK, ERROR, and STATUS-RESPONSE messages are never acknowledged.
An ST agent that is setting up a stream invokes the routing function HELLO messages are a special case. If they contain a syntax error, an ERROR
to find a path to reach each of the targets specified by the target message should be generated in response. Otherwise, no acknowledgment or
list provided by the application. This is similar to the routing response should be generated. Use of HELLO messages is discussed in Section
decision in IP. However, in this case the route is to a multitude of 6.1.2.
targets rather than to a single destination. The routing function is
not part of the ST protocol and therefore it is not specified by this
document.
The result of the routing function is a set of next-hop ST agents. STATUS messages containing a syntax error should be replied with an ERROR
The set of next-hops selected by the routing function is not message. Otherwise, a STATUS-RESPONSE message should be sent back in
necessarily the same as the set of next-hops that IP would select response. Use of STATUS and STATUS-RESPONSE are discussed in Section 8.4.
given a number of independent IP datagrams to the same destinations.
The routing algorithm may attempt to optimize parameters other than
the number of hops that the packets will take, such as delay, local
network bandwidth consumption, or total internet bandwidth
consumption.
3.1.1.2 Reserving Resources 4.3 SCMP Reliability
An ST agent helps reserving both local and network resources. Local SCMP is made reliable through the use of retransmission when response is not
resources may include CPU processing time and buffer space at the received in a timely manner. The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN,
local host. Network resources may comprise bandwidth over the JOIN-REJECT, NOTIFY, and REFUSE messages all must be answered with an ACK
outgoing links to the next-hops determined by the routing function. message, see Section 4.2. In general, when sending a SCMP message which
Resource reservation is not part of the ST protocol and therefore it requires an ACK response, the sending ST agent needs to set the Toxxxx timer
is not specified by this document. ST invokes at every host the Local (where xxxx is the SCMP message type, e.g. ToConnect). If it does not
Resource Manager (LRM) to perform the appropriate reservations. receive an ACK before the Toxxxx timer expires, the ST agent should
Functions as resource scheduling and reservation enforcement are part retransmit the SCMP message. If no ACK has been received within Nxxxx
of the LRM's tasks and not of an ST agent's. retransmissions, then a SCMP timeout condition occurs and the ST agent
enters its SCMP timeout recovery state. The actions performed by the ST
agent as the result of the SCMP timeout condition differ for different SCMP
messages and are described in Section 5.2.
The ST FlowSpec contains all the information needed to allocate the For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the sending ST
necessary resources. The information contained in the FlowSpec is agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN-REJECT)
passed to the LRM as parameter of the reservation functions. The LRM after ACK has been received. For these cases, the ST agent needs to set the
updates the FlowSpec information before it passes it back to the ST ToxxxxResp timer after it receives the ACK. (As before, xxxx is the
agent. Further information on the ST FlowSpec can be found in Section initiating SCMP message type, e.g. ToConnectResp). If it does not receive
. the appropriate response back when ToxxxxResp expires, the ST agent updates
its state and performs appropriate recovery action as described in Section
5.2.
Note that if the data has to be sent across a network to a single The timeout and retransmission algorithm is implementation dependent and it
next-hop, then only the point-to- point bandwidth needs to be is outside the scope of this document. Most existing algorithms are based on
reserved. If the data has to be sent to multiple next-hop ST agents an estimation of the Round Trip Time (RTT) between two hosts. Therefore,
across a single network and network layer multicasting is not SCMP contains a mechanism to estimate this RTT, see Section 8.5. Note that
available, the ST agent replicates the data to each next-hop ST agent the timeout related variable names described above are for reference
and therefore bandwidth has to be reserved by the LRM for all the purposes only, implementors may choose to combine certain variables.
next-hops. If network layer multicast is supported, its use reduces
the bandwidth required since one single copy of the data is received
by all next-hop ST agents. The membership of a stream in a Group may
also affect the amount of resources that have to be allocated by the
LRM, cf. Section 6.
Effects similar to reservation of the necessary resources may be 4.4 Stream Options
obtained even when the network cannot provide direct support for the
reservation. Certainly if total reservations are a small fraction of
the overall resources, such as packet switch processing bandwidth,
buffer space, or network bandwidth, then the desired performance can
be honoured if the degree of confidence is consistent with the
requirements as stated in the FlowSpec. Other solutions can be
designed for specific networks.
3.1.2 Sending CONNECT Messages An application may select among some stream options. The desired options are
indicated to the ST agent at the origin when a new stream is created.
Options apply to single streams and are valid during the whole stream's
lifetime. The options chosen by the application at the origin are included
into the initial CONNECT message, see Section 4.5.3. When a CONNECT message
reaches a target, the application at the target is notified of the stream
options that have been selected, see Section 4.5.5.
The ST agent sends a CONNECT message to each of the next-hop ST 4.4.1 No Recovery
agents identified by the routing function. Each CONNECT message
contains the SID, an updated FlowSpec, and a TargetList. In general,
the FlowSpec and TargetList depend on both the next-hop and the
intervening network. Each TargetList is a subset of the original
TargetList, identifying the targets that are to be reached through
the next-hop to which the CONNECT message is being sent.
The TargetList may be empty, see Section 3.1.2.1.; if the TargetList When a stream failure is detected, an ST agent would normally attempt stream
causes a too long CONNECT message to be generated, the CONNECT recovery, as described in Section 6.2. The NoRecovery option is used to
message is partitioned as explained in Section 3.1.2.2. If multiple indicate that ST agents should not attempt recovery for the stream. The
next-hops are to be reached through a network that supports network protocol behaviour in case the NoRecovery option has been selected is
level multicast, a different CONNECT message must nevertheless be illustrated in Section 6.2. The NoRecovery option is specified by setting
sent to each next-hop since each will have a different TargetList. the S-bit in the CONNECT message, see Section 10.4.4. The S-bit can be set
only by the origin and it is never modified by intermediate and target ST
agents.
Let us consider the network topology in Figure 7 on page 16. Suppose 4.4.2 Join Authorization Level
that the original TargetList contains targets B, C, and D. The
routing function invoked at A returns that B is reachable via Router
1 and C and D are reachable via Router 2. Thus, A generates two
CONNECT messages, one for Router 1 and one for Router 2. The CONNECT
message for Router 1 contains a TargetList including target B only;
the CONNECT message for Router 2 contains a TargetList including
targets C and D.
3.1.2.1 Empty Target List When a new stream is created, it is necessary to define the join
An application at the origin may request the local ST agent to create authorization level associated with the stream. This level determines the
empty streams. It does so by passing an empty TargetList to the local protocol behavior in case of stream joining, see Section 4.1 and Section
ST agent during the initial stream setup. When the local ST agent 4.6.3. The join authorization level for a stream is defined by the J-bit and
receives request to create an empty stream, it allocates the stream N-bit in the CONNECT message header, see Section 10.4.4. One of the
ID (SID), updates its local database entries to store information on following authorization levels has to be selected:
the new stream and notifies the application that stream setup is
complete. The local ST agent does not generate any CONNECT message
for streams with an empty TargetList.
3.1.2.2 Long Target Lists o Level 0 - Refuse Join (JN = 00): No targets are allowed to join this
stream.
Each ST agent knows the MTU of the networks to which it is connected, o Level 1 - OK, Notify Origin (JN = 01): Targets are allowed to join
and those MTUs restrict the size of the SCMP message it can send. the stream. The origin is notified that the target has joined.
SCMP messages with long TargetList can cause the size of the SCMP
message to exceed the network MTU. The ST agent which receives an
SCMP message bigger than its MTU must break the original message into
multiple fragments, each carrying part of the TargetList. The effect
of this partition is to compromise the performance but still carry
out the function of the SCMP message. If the original SCMP message
contains any Userdata parameters, these parameters are replicated in
each fragment for delivery to all targets. Applications that support
a large number of receivers may avoid using long target lists by
exploiting the stream joining functions, cf. Section 3.4.2.
3.1.3 Processing CONNECT Messages o Level 2 - OK (JN = 10): Targets are allowed to join the stream. No
notification is sent to the stream origin.
3.1.3.1 CONNECT Processing by an Intermediate ST agent Some applications may choose to maintain tight control on their streams and
will not permit any connections without the origin's permission. For such
streams, target applications may request to be added by sending an
out-of-band, i.e. via regular IP, request to the origin. The origin, if it
so chooses, can then add the target following the process described in
Section 4.6.1.
An ST agent receiving a CONNECT message, assuming no errors, responds The selected authorization level impacts stream handling and the state that
to the previous-hop with an ACK. The ACK message must identify the is maintained for the stream, as described in Section 4.1.
CONNECT to which it corresponds by including the reference number
indicated by the Reference field of the CONNECT message. The
intermediate ST agent invokes the routing function, reserves
resources via the LRM, and then propagates the CONNECT messages to
its next-hops, as described in the previous section.
3.1.3.2 Setup at the Targets 4.4.3 Record Route
An ST agent that is the target of a CONNECT message, assuming no The RecordRoute option can be used to request the route between the origin
errors, responds to the previous-hop with an ACK. The ST agent and a target be recorded and delivered to the application. This option may
reserves local resources and inquires from the specified application be used while connecting, accepting, changing, or refusing a steam. The
process whether or not it is willing to accept the connection. results of a RecordRoute option requested by the origin, i.e. as part of
the CONNECT or CHANGE messages, are delivered to the target. The results of
a RecordRoute option requested by the target, i.e. as part of the ACCEPT or
REFUSE messages, are delivered to the origin.
In particular, the application must be presented with parameters from The RecordRoute option is specified by adding the RecordRoute parameter to
the CONNECT, such as the SID, FlowSpec, Options, and Group, to be the mentioned SCMP messages. The format of the RecordRoute parameter is
used as a basis for its decision. The application is identified by a shown in Section 10.3.5. When adding this parameter, the ST agent at the
combination of the NextPcol field and the SAP field included in the origin must determine the number of entries that may be recorded as
correspondent (usually single remaining) Target of the TargetList. explained in Section 10.3.5.
The contents of the SAP field may specify the port or other local 4.4.4 User Data
identifier for use by the protocol layer above the host ST layer.
Subsequently received data packets will carry the SID, that can be
mapped into this information and be used for their delivery.
Finally, based on the application's decision, the ST agent sends to The UserData option can be used by applications to transport application
the previous-hop from which the CONNECT was received an ACCEPT or specific data along with some SCMP control messages. This option can be
REFUSE message. Since the ACCEPT (or REFUSE) message has to be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and REFUSE messages. The
acknowledged by the previous-hop, it is assigned a new Reference format of the UserData parameter is shown in Section 10.3.7. This option may
number that will be returned in the ACK. The CONNECT to which the be included by the origin, or the target, by adding the UserData parameter
ACCEPT (or REFUSE) is a reply is identified by placing the CONNECT's to the mentioned SCMP messages.
Reference number in the LnkReference field of the ACCEPT (or REFUSE).
The ACCEPT message contains the FlowSpec as accepted by the
application at the target.
3.1.4 Processing ACCEPT Messages 4.5 Stream Setup
This section presents a description of stream setup. For simplicity, we
assume that everything succeeds, e.g. any required resources are available,
messages are properly delivered, and the routing is correct. Possible
failures in the setup phase are handled in Section 5.2.
3.1.4.1 ACCEPT Processing by an Intermediate ST agent 4.5.1 Information from the Application
When an intermediate ST agent receives an ACCEPT, it first verifies Before stream setup can be started, the application has to collect the
that the message is a response to an earlier CONNECT. If not, it necessary information to determine the characteristics for the connection.
responds to the next-hop ST agent with an ERROR message, with This includes identifying the participants and selecting the QoS parameters
ReasonCode (LnkRefUnknown). Otherwise, it responds to the next-hop ST of the data flow. Information passed to the ST agent by the application
agent with an ACK, and propagates the ACCEPT message to the includes:
previous-hop along the same path traced by the CONNECT but in the
reverse direction toward the origin. o the list of the stream's targets (Section 10.3.6). The list may be
empty (Section 4.5.3.1),
o the flow specification containing the desired quality of service for
the stream (Section 9),
o information on the groups in which the stream is a member, if any
(Section 7),
o information on the options selected for the stream (Section 4.4),
4.5.2 Initial Setup at the Origin
The ST agent at the origin then performs the following operations:
o allocates a stream ID (SID) for the stream (Section 8.1),
o invokes the routing function to determine the set of next-hops for
the stream (Section 4.5.2.1),
o invokes the Local Resource Manager (LRM) to reserve resources
(Section 4.5.2.2),
o creates local database entries to store information on the new
stream,
o propagates the stream creation request to the next-hops determined
by the routing function (Section 4.5.3).
4.5.2.1 Invoking the Routing Function
An ST agent that is setting up a stream invokes the routing function to find
a path to reach each of the targets specified by the target list provided by
the application. This is similar to the routing decision in IP. However, in
this case the route is to a multitude of targets with QoS requirements
rather than to a single destination.
The result of the routing function is a set of next-hop ST agents. The set
of next-hops selected by the routing function is not necessarily the same as
the set of next-hops that IP would select given a number of independent IP
datagrams to the same destinations. The routing algorithm may attempt to
optimize parameters other than the number of hops that the packets will
take, such as delay, local network bandwidth consumption, or total internet
bandwidth consumption. Alternatively, the routing algorithm may use a
simple route lookup for each target.
Once a route is selected by the routing function, it persists for the whole
stream lifetime, unless a network failure occurs.
4.5.2.2 Reserving Resources
The ST agent invokes the Local Resource Manager (LRM) to perform the
appropriate reservations. The ST agent presents the LRM with information
including:
o the flow specification with the desired quality of service for the
stream (Section 9),
o the version number associated with the flow specification (Section
9).
o information on the groups the stream is member in, if any (Section
7),
The flow specification contains information needed by the LRM to allocate
resources. The LRM updates the flow specification contents information
before returning it to the ST agent. Section 9.2.3 defines the fields of the
flow specification to be updated by the LRM.
The membership of a stream in a group may affect the amount of resources
that have to be allocated by the LRM, see Section 7.
4.5.3 Sending CONNECT Messages
The ST agent sends a CONNECT message to each of the next-hop ST agents
identified by the routing function. Each CONNECT message contains the SID,
the selected stream options, the FlowSpec, and a TargetList. The format of
the CONNECT message is defined by Section 10.4.4. In general, the FlowSpec
and TargetList depend on both the next-hop and the intervening network. Each
TargetList is a subset of the original TargetList, identifying the targets
that are to be reached through the next-hop to which the CONNECT message is
being sent.
The TargetList may be empty, see Section 4.5.3.1; if the TargetList causes a
too long CONNECT message to be generated, the CONNECT message is partitioned
as explained in Section 5.1.2. If multiple next-hops are to be reached
through a network that supports network level multicast, a different CONNECT
message must nevertheless be sent to each next-hop since each will have a
different TargetList.
4.5.3.1 Empty Target List
An application at the origin may request the local ST agent to create an
empty stream. It does so by passing an empty TargetList to the local ST
agent during the initial stream setup. When the local ST agent receives
request to create an empty stream, it allocates the stream ID (SID), updates
its local database entries to store information on the new stream and
notifies the application that stream setup is complete. The local ST agent
does not generate any CONNECT message for streams with an empty TargetList.
Targets may be later added by the origin, see Section 4.6.1, or they may
autonomously join the stream, see Section 4.6.3.
4.5.4 CONNECT Processing by an Intermediate ST agent
An ST agent receiving a CONNECT message, assuming no errors, responds to the
previous-hop with an ACK. The ACK message must identify the CONNECT message
to which it corresponds by including the reference number indicated by the
Reference field of the CONNECT message. The intermediate ST agent calls the
routing function, invokes the LRM to reserve resources, and then propagates
the CONNECT messages to its next-hops, as described in the previous
sections.
4.5.5 CONNECT Processing at the Targets
An ST agent that is the target of a CONNECT message, assuming no errors,
responds to the previous-hop with an ACK. The ST agent invokes the LRM to
reserve local resources and then queries the specified application process
whether or not it is willing to accept the connection.
The application is presented with parameters from the CONNECT message
including the SID, the selected stream options, FlowSpec, Group, and
UserData, if any, to be used as a basis for its decision. The application is
identified by a combination of the NextPcol field and the SAP field included
in the correspondent (usually single remaining) Target of the TargetList.
The contents of the SAP field may specify the port or other local identifier
for use by the protocol layer above the host ST layer. Subsequently received
data packets will carry the SID, that can be mapped into this information
and be used for their delivery.
Finally, based on the application's decision, the ST agent sends to the
previous-hop from which the CONNECT message was received either an ACCEPT or
REFUSE message. Since the ACCEPT (or REFUSE) message has to be acknowledged
by the previous-hop, it is assigned a new Reference number that will be
returned in the ACK. The CONNECT message to which ACCEPT (or REFUSE) is a
reply is identified by placing the CONNECT's Reference number in the
LnkReference field of ACCEPT (or REFUSE). The ACCEPT message contains the
FlowSpec as accepted by the application at the target.
4.5.6 ACCEPT Processing by an Intermediate ST agent
When an intermediate ST agent receives an ACCEPT, it first verifies that the
message is a response to an earlier CONNECT. If not, it responds to the
next-hop ST agent with an ERROR message, with ReasonCode (LnkRefUnknown).
Otherwise, it responds to the next-hop ST agent with an ACK, and propagates
the ACCEPT message to the previous-hop along the same path traced by the
CONNECT but in the reverse direction toward the origin.
The FlowSpec is included in the ACCEPT message so that the origin and The FlowSpec is included in the ACCEPT message so that the origin and
intermediate ST agents can gain access to the information that was intermediate ST agents can gain access to the information that was
accumulated as the CONNECT traversed the internet. Note that the accumulated as the CONNECT traversed the internet. Note that the resources,
resources, as specified in the FlowSpec in the ACCEPT message, may as specified in the FlowSpec in the ACCEPT message, may differ from the
differ from the resources that were reserved by the ST agent when the resources that were reserved when the CONNECT was originally processed.
CONNECT was originally processed. However, the ST agent does not Therefore, the ST agent presents the LRM with the FlowSpec included in the
adjust the reservation in response to the ACCEPT. It is expected that ACCEPT message. It is expected that each LRM adjusts local reservations
any excess resource allocation will be released for use by other releasing any excess resources. The LRM may choose not to adjust local
stream or datagram traffic through an explicit CHANGE message reservations when that adjustment may result in the loss of needed
initiated by the application at the origin if it does not wish to be resources. It may also choose to wait to adjust allocated resources until
charged for any excess resource allocations. all targets in transition have been accepted or refused.
3.1.4.2 ACCEPT Processing by the Origin In the case where the intermediate ST agent is acting as the origin with
respect to this target, see Section 4.6.3.1, the ACCEPT message is not
propagated upstream.
The origin will eventually receive an ACCEPT (or REFUSE) message from 4.5.7 ACCEPT Processing by the Origin
each of the targets. As each ACCEPT is received, the application is
notified of the target and the resources that were successfully The origin will eventually receive an ACCEPT (or REFUSE) message from each
allocated along the path to it, as specified in the FlowSpec of the targets. As each ACCEPT is received, the application is notified of
contained in the ACCEPT message. The application may then use the the target and the resources that were successfully allocated along the path
information to either adopt or terminate the portion of the stream to to it, as specified in the FlowSpec contained in the ACCEPT message. The
each target. When ACCEPT (or REFUSE) from all targets have been application may then use the information to either adopt or terminate the
received at the origin, the application is notified that stream setup portion of the stream to each target. When ACCEPT (or REFUSE) from all
is complete. For problems due to CONNECT timeout, please refer to targets have been received at the origin, the application is notified that
Section 4.1.1. stream setup is complete.
When an ACCEPT is received by the origin, the path to the target is When an ACCEPT is received by the origin, the path to the target is
considered to be established and the ST agent is allowed to forward considered to be established and the ST agent is allowed to forward the data
the data along this path as explained in Section 3.3 and in the ST along this path as explained in Section 2 and in Section 3.1.
user service description in Section 2.
3.1.5 Processing REFUSE Messages 4.5.8 REFUSE Processing by the Intermediate ST agent
If an application at a target does not wish to participate in the stream, it
sends a REFUSE message back to the origin with ReasonCode (ApplDisconnect).
An intermediate ST agent that receives a REFUSE message with ReasonCode
(ApplDisconnect) acknowledges it by sending an ACK to the next-hop, invokes
the LRM to adjusts reservations as appropriate, deletes the target entry
from the internal database, and propagates the REFUSE message back to the
previous-hop ST agent.
3.1.5.1 REFUSE Processing by the Intermediate ST agent In the case where the intermediate ST agent is acting as the origin with
respect to this target, see Section 4.6.3.1, the REFUSE message is not
propagated upstream.
If an application at a target does not wish to participate in the 4.5.9 REFUSE Processing by the Origin
stream, it sends a REFUSE message back to the origin with ReasonCode
(ApplDisconnect). An intermediate ST agent that receives a REFUSE
message with ReasonCode (ApplDisconnect) acknowledges it by sending
an ACK to the next-hop, considers which resources are to be released,
deletes the target entry from the internal database, and propagates
the REFUSE message back to the previous-hop ST agent.
If, after deleting the specified target, the next-hop has no When the REFUSE message reaches the origin, the ST agent at the origin sends
remaining targets, then those resources associated with that next-hop an ACK and notifies the application that the target is no longer part of the
ST agent may be released. Note that network resources may not stream and also if the stream has no remaining targets. If there are no
actually be released if network multicasting is being used since they remaining targets, the application may wish to terminate the stream or keep
may still be required for traffic to other next-hops in the multicast the stream active to allow stream joining as described in Section 4.6.3.
group.
3.1.5.2 REFUSE Processing by the Origin 4.5.10 Other Functions during Stream Setup
When the REFUSE reaches the origin, the origin sends an ACK and Some other functions have to be accomplished an by ST agent as CONNECT
notifies the application that the target is no longer part of the messages travel downstream and ACCEPT (or REFUSE) messages travel upstream
stream and also if the stream has no remaining targets. If there are during the stream setup phase. They were not mentioned in the previous
no remaining targets, the application may wish to terminate the sections to keep the discussion as simple as possible. These functions
stream or keep the stream active to allow stream joining as described include:
in Section 3.4.2.
3.2 Stream Options o computing the smallest Maximum Transmission Unit size over the path
to the targets, as part of the MTU discovery mechanism presented
in Section 8.6. This is done by updating the MaxMsgSize field of
the CONNECT message, see Section 10.4.4. This value is carried
back to origin in the MaxMsgSize field of the ACCEPT message,
see Section 10.4.1.
An application may select among some stream options. The desired o counting the number of IP clouds that have to be traversed to reach
options are indicated to the ST agent at the origin when a new stream the targets, as part of the IP encapsulation mechanism described
is created. Options apply to single streams and are valid during the in Section 8.7. This is done by updating the IPHops field of the
whole stream's lifetime. The options chosen by the application at the CONNECT message, see Section 10.4.4. This value is carried back
origin are included into the initial CONNECT message(s). When a to origin in the IPHops field of the ACCEPT message, see Section
CONNECT message reaches a target, the application at the target is 10.4.1.
notified of the stream options that have been selected.
3.2.1 No Recovery o updating the RecoveryTimeout value for the stream, as part of the
The NoRecovery option is used to indicate that ST agents should not stream recovery mechanism presented in Section 6.2. This is
attempt recovery in case of network or component failure. If a done by updating the RecoveryTimeout field of the CONNECT
failure occurs, the origin will be notified via a REFUSE message and message, see Section 10.4.4. This value is carried back to
the targets via a DISCONNECT, with an appropriate ReasonCode origin in the RecoveryTimeout field of the ACCEPT message, see
indicating the reason of the failure. The application at the origin Section 10.4.1.
may decide whether to rebuild the deleted portion of the stream by
sending a CONNECT message. The NoRecovery option is specified by
setting the S-bit in the CONNECT message, see Section 11.4.
3.2.2 Join Authorization Level 4.6 Modifying an Existing Stream
When a new stream is created, it is necessary to define the join Some applications may wish to modify a stream after it has been created.
authorization level associated with the stream. This level determines Possible changes include expanding a stream, reducing it, and changing its
the protocol behavior in case of stream joining, see Section 3.4.2. FlowSpec. The origin may add or remove targets as described in Section 4.6.1
The join authorization level for a stream is defined by the J-bit and and Section 4.6.2. Targets may request to join the stream as described in
N-bit in the CONNECT message header, see Section 11.4. One of the Section 4.6.3 or, they may decide to leave a stream as described in Section
following authorization levels has to be selected: 4.6.4. Section 4.6.5 explains how to change a stream's FlowSpec.
o Level 0 - Refuse Join (JN = 00): No targets are allowed to As defined by Section 2, an ST agent can handle only one stream modification
join this stream. at a time. If a stream modification operation is already underway, further
requests are queued and handled when the previous operation has been
completed. This also applies to two subsequent requests of the same kind,
e.g. two subsequent changes to the FlowSpec.
o Level 1 - Ask Origin (JN = 01): The application at the stream 4.6.1 The Origin Adding New Targets
origin is asked whether the new target is allowed to join the stream.
o Level 2 - OK, Notify Origin (JN = 10): The targets joins the It is possible for an application at the origin to add new targets to an
stream. The origin is notified that the target has joined. existing stream any time after the stream has been established. Before new
targets are added, the application has to collect the necessary information
on the new targets. Such information is passed to the ST agent at the
origin.
o Level 3 - OK (JN = 11): The targets joins the stream. No The ST agent at the origin issues a CONNECT message that contains the SID,
notifications are sent to the stream origin. the FlowSpec, and the TargetList specifying the new targets. This is similar
to sending a CONNECT message during stream establishment, with the following
exceptions: the origin checks that a) the SID is valid, b) the targets are
not already members of the stream, c) the FlowSpec of the new target, if
present, matches the FlowSpec of the existing stream, i.e it requires an
equal or smaller amount of resources to be allocated. If the FlowSpec of the
new target does not match the FlowSpec of the existing stream, an error is
generated with ReasonCode (FlowSpecMismatch). Functions to compare flow
specifications are provided by the LRM, see Section 1.4.5.
3.3 Data Transfer An intermediate ST agent that is already a node in the stream looks at the
SID and verifies that the stream is the same. It then checks if the
intersection of the TargetList and the targets of the established stream is
empty. If this is not the case, it responds with a REFUSE message with
ReasonCode (RouteLoop) that contains a TargetList of those targets that were
duplicates.
An application is not guaranteed that the data reaches its For each new target in the TargetList, processing is much the same as for
destinations: ST is unreliable and it does not make any attempt to the original CONNECT. The CONNECT is acknowledged, propagated, and network
recover from packet loss, e.g. due to the underlying network. In case resources are reserved. Intermediate or target ST agents that are not
the data reaches its destination, it does it accordingly to the already nodes in the stream behave as in case of stream setup (see Section
negotiated quality of service. 4.5.4 and Section 4.5.5).
An ST agent forwards the data only along already established paths to 4.6.2 The Origin Removing a Target
targets. A path is considered to be established when the next-hop ST It is possible for an application at the origin to remove existing targets
agent on the path sends an ACCEPT message. This implies that the of a stream any time after the targets have accepted the stream. The
target and all other intermediate ST agents on the path to the target application at the origin specifies the set of targets that are to be
are ready to handle the incoming data packets. In no cases an ST removed and informs the local ST agent. Based on this information, the ST
agent will forward data to a next-hop ST agent that has not agent sends DISCONNECT messages with the ReasonCode (ApplDisconnect) to the
explicitly accepted the stream. next-hops relative to the targets.
To be fairly sure that all targets receive the data with the desired An ST agent that receives a DISCONNECT message must acknowledge it by
quality of service, an application should send the data only after sending an ACK to the previous-hop. The ST agent updates its state and
the whole stream has been established. Depending on the local API, an notifies the LRM of the target deletion so that the LRM can modify
application may not be prevented to send data before the completion reservations as appropriate. When the DISCONNECT message reaches the target,
of stream setup, but it should be aware that the data could be lost the ST agent also notifies the application that the target is no longer part
or not reach all the intended targets. of the stream. When there are no remaining targets that can be reached
through a particular next-hop, the ST agent informs the LRM and it deletes
the next-hop from its next-hops set.
At the end of the connection setup phase, the origin, each target, SCMP also provides a flooding mechanism to delete targets that joined the
and each intermediate ST agent has a database entry that allows it to stream without notifying the origin. The special case of target deletion via
forward the data packets from the origin to the targets and to flooding is described in Section 5.7.
recover from failures of the intermediate ST agents or networks. The
database should be optimized to make the packet forwarding task most
efficient. The time critical operation is an intermediate ST agent
receiving a packet from the previous-hop ST agent and forwarding it
to the next-hop ST agents. The database entry must also contain the
FlowSpec, utilization information, the address of the origin and
previous-hop, and the addresses of the targets and next-hops, so it
can perform enforcement and recover from failures.
An ST agent receives data packets encapsulated by an ST header. A 4.6.3 A Target Joining a Stream
data packet received by an ST agent contains the SID. This SID was
selected at the origin so that it is globally unique and thus can be
used as an index into the database, to obtain quickly the necessary
replication and forwarding information.
The forwarding information will be network and implementation An application may request to join an existing stream. It has to collect
specific, but must identify the next-hop ST agents. It is suggested information on the stream including the stream ID (SID) and the IP address
that the cached information for a next-hop agent include the local of the stream's origin. This can be done out-of-band, e.g. via regular IP.
network address of the next- hop. If the data packet must be The information is then passed to the local ST agent. The ST agent generates
forwarded to multiple next- hops across a single network that a JOIN message containing the application's request to join the stream and
supports multicast, the database may specify the next-hops by a sends it toward the stream origin.
(local network) multicast address. If the network does not support
multicast, or the next-hops are on different networks, multiple
copies of the data packet must be sent.
No data fragmentation is supported during the data transfer phase. An ST agent receiving a JOIN message, assuming no errors, responds with an
The application is expected to segment its PDUs according to the ACK. The ACK message must identify the JOIN message to which it corresponds
minimum MTU over all paths in the stream. The application receives by including the Reference number indicated by the Reference field of the
information on the MTUs relative to the paths to the targets as part JOIN message. If the ST agent is not traversed by the stream that has to be
of the ACCEPT message, see also Section . The minimum MTU over all joined, it propagates the JOIN message toward the stream's origin. Once a
paths has to be calculated from the MTUs relative to the single JOIN message has been acknowledged, ST agents do not retain any state
paths. If the application at the origin sends a too large data information related to the JOIN message.
packet, the ST agent at the origin generates an error and it does not
forward the data.
3.4 Modifying an Existing Stream Eventually, an ST agent traversed by the stream or the stream's origin
itself is reached. This agent must respond to a received JOIN first with an
ACK to the ST agent from which the message was received, then, it issues
either a CONNECT or a JOIN-REJECT message and sends it toward the target.
The response to the join request is based on the join authorization level
associated with the stream, see Section 4.4.2:
Some applications may wish to modify a stream after it has been o If the stream has authorization level #0 (refuse join):
created. Possible changes include expanding a stream, reducing it, The ST agent sends a JOIN-REJECT message toward the target with
and changing its FlowSpec. In ST, changes to a stream may be ReasonCode (JoinAuthFailure).
initiated both by the origin and the targets. Targets may be added by
the origin as described in Section 3.4.1 or they may request to join
the stream as described in Section 3.4.2. The origin can reduce a
stream by dropping some or all of its targets. This is described in
Section 3.4.3. Targets may spontaneously decide to leave a stream as
described in Section 3.4.4. Section 3.4.5 explains how to change a
stream's FlowSpec.
As defined by the ST service model, see Section 2, an ST agent can o If the stream has authorization level #1 (ok, notify origin):
handle only one stream modification at a time. If a stream The ST agent sends a CONNECT message toward the target with a
modification operation is already underway, further requests are TargetList including the target that requested to join the stream.
queued and handled when the previous operation has been completed. This eventually results in adding the target to the stream. When the
This also applies to two subsequent requests of the same kind, e.g. ST agent receives the ACCEPT message indicating that the new tar-
two subsequent changes to the FlowSpec. get has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6). Instead, it issues a NOTIFY message with
ReasonCode (TargetJoined) and with TargetList including the target
to inform the origin of the new target.
3.4.1 The Origin Adding New Targets o If the stream has authorization level #2 (ok):
The ST agent sends a CONNECT message toward the target with a
TargetList including the target that requested to join the stream.
This eventually results in adding the target to the stream. When the
ST agent receives the ACCEPT message indicating that the new tar-
get has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6), nor does it notify the origin.
It is possible for an application at the origin to add new targets to 4.6.3.1 Router as Origin
an existing stream any time after the stream has been established.
Before new targets are added, the application has to collect the
necessary information on the new targets. Such information is passed
to the ST agent at the origin.
The ST agent at the origin issues a CONNECT message that contains the When a stream has join authorization level #2, see Section 4.4.2, it is
SID, the FlowSpec, and the TargetList specifying the new targets. possible that the stream origin is unaware of some targets participating in
This is similar to sending a CONNECT message during stream the stream. In this case, the router ST agent that first sent a CONNECT
establishment, with the following exceptions: the origin checks that message to this target has to act as the stream origin for the given target.
a) the SID is valid, b) the targets are not already members of the This includes:
stream, c) the FlowSpec of the new target, if present, matches the
FlowSpec of the existing stream, i.e it requires an equal or smaller
amount of resources to be allocated. If the FlowSpec of the new
target does not match the FlowSpec of the existing stream, it is
simply ignored.
An intermediate ST agent that is already a node in the stream looks o if the whole stream is deleted, the router must disconnect the
at the SID and verifies that the stream is the same. It then checks target.
if the intersection of the TargetList and the targets of the
established stream is empty. If this is not the case, it responds
with an ERROR message with the appropriate ReasonCode (RouteLoop)
that contains a TargetList of those targets that were duplicates.
For each new target in the TargetList, processing is much the same as o if the stream FlowSpec is changed, the router must change the
for the original CONNECT. The CONNECT is acknowledged, propagated, FlowSpec for the target as appropriate.
and network resources are reserved. However, it may be possible to
route to the new targets using previously allocated paths or an
existing multicast group. In that case, additional resources do not
need to be reserved but more next-hops might have to be added to an
existing multicast group.
Intermediate or target ST agents that are not already nodes in the o proper handling of ACCEPT and REFUSE messages, without propagation
stream behave as in case of stream setup (see Section 3.1.3.1 and to upstream ST agents.
Section 3.1.3.2).
3.4.2 A Target Joining a Stream Of course, the router behaves normally for all other targets added to the
stream as a consequence of a CONNECT message issued by the origin.
An application may request to join an existing stream. It has to 4.6.4 A Target Deleting Itself
collect information on the stream including the stream ID (SID) and
the IP address of the stream's origin. This can be done out-of- band,
e.g. via regular IP. The information is then passed to the local ST
agent together with the FlowSpec. The ST agent generates a JOIN
message containing the application's request to join the stream and
sends it toward the stream origin.
An ST agent receiving a JOIN message, assuming no errors, responds The application at the target may inform the local ST agent that it wants to
with an ACK. The ACK message must identify the JOIN message to which be removed from the stream. The ST agent then forms a REFUSE message with
it corresponds by including the Reference number indicated by the the target itself as the only entry in the TargetList and with ReasonCode
Reference field of the Join message. If the ST agent is not traversed (ApplDisconnect). The REFUSE message is sent back to the origin via the
by the stream that has to be joined, it propagates the JOIN message previous-hop. If a stream has multiple targets and one target leaves the
toward the stream's origin. Eventually, an ST agent traversed by the stream using this REFUSE mechanism, the stream to the other targets is not
stream or the stream's origin itself is reached. This ST agent affected; the stream continues to exist.
responds to the join request based on the join authorization level
associated with the stream, cf. Section 3.2.2.:
o level 0 (refuse join) An ST agent that receives a REFUSE message acknowledges it by sending an ACK
to the next-hop. The target is deleted and the LRM is notified so that it
adjusts reservations as appropriate. The REFUSE message is also propagated
back to the previous-hop ST agent except in the case where the agent is
acting as the origin, see Section 4.6.3.1.
It is not allowed to join the stream. No further actions are taken. When the REFUSE reaches the origin, the origin sends an ACK and notifies the
application that the target is no longer part of the stream.
o level 1 (ask origin) 4.6.5 Changing a Stream's FlowSpec
The JOIN message is propagated back until the origin is reached. At The application at the origin may wish to change the FlowSpec of an
the origin, the appli- cation is requested to either grant or deny established stream. Changing the FlowSpec is a critical operation and it
the permission to join the stream. If the permis- sion is denied, no may even lead in some cases to the deletion of the stream. Possible problems
further actions are taken. Otherwise, the origin issues a CONNECT with FlowSpec changes are discussed in Section 5.6.
message with a TargetList including the target that requested to join
the stream. The target is then added as in normal stream setup.
o level 2 (ok, notify origin) To change the stream's FlowSpec, the application informs the ST agent at the
origin of the new FlowSpec and of the list of targets relative to the
change. The ST agent at the origin then issues one CHANGE message per
next-hop including the new FlowSpec and sends it to the relevant next-hop ST
agents. If the G-bit field of the CHANGE message is set (1), the change
affects all targets in the stream.
The ST agent sends a CONNECT message with a TargetList including the The CHANGE message contains a bit called I-bit, see Section 10.4.3. By
target that requested to join the stream. This results in adding the default, the I-bit is set to zero (0) to indicate that the LRM is expected
target to the stream. When the ST agent which is already part in the to try and perform the requested FlowSpec change without risking to tear
stream receives the ACCEPT message indicating that the new target has down the stream. Applications that desire a higher probability of success
been added, it does not propagate the ACCEPT message backwards. and are willing to take the risk of breaking the stream can indicate this by
Instead, it issues a NOTIFY message with ReasonCode(TargetJoined) to setting the I-bit to one (1). Applications that require the requested
inform the origin of the new target. modification in order to continue operating are expected to set this bit.
o level 3 (ok) An intermediate ST agent that receives a CHANGE message first sends an ACK
The ST agent sends a CONNECT message with a TargetList including the to the previous-hop and then provides the FlowSpec to the LRM. If the LRM
target that requested to join the stream. This results in adding the can perform the change, the ST agent propagates the CHANGE messages along
target to the stream. When the ST agent which is already part in the the established paths.
stream receives the ACCEPT message indicating that the new target has
been added, it does not propagate the ACCEPT message backwards, nor
it notifies the origin.
3.4.2.1 ST FlowSpec If the whole process succeeds, the CHANGE messages will eventually reach the
targets. Targets respond with an ACCEPT (or REFUSE) message that is
propagated back to the origin. In processing the ACCEPT message on the way
back to the origin, excess resources may be released by the LRM as described
in Section 4.5.6. The REFUSE message must have the ReasonCode (ApplRefused).
Some rules on the FlowSpec are defined for targets that join an SCMP also provides a flooding mechanism to change targets that joined the
existing stream. Targets are allowed to express their wishes in terms stream without notifying the origin. The special case of target change via
of FlowSpec as part of the JOIN-REQUEST message, see Section 11.8. flooding is described in Section 5.7.
Let us call this FlowSpec FT and the current FlowSpec for the stream
F. There are three cases:
o F > FT, i.e., F requires a larger amount of resources to be 4.7 Stream Tear Down
allocated than FT. If authorized to join the stream, the target will A stream is usually terminated by the origin when it has no further data to
receive a CONNECT message including FlowSpec FT. send. A stream is also torn down if the application should terminate
abnormally or if certain network failures are encountered. Processing in
this case is identical to the previous descriptions except that the
ReasonCode (ApplAbort, NetworkFailure, etc.) is different.
o F = FT, i.e., F requires the same amount of resources to be When all targets have left a stream, the origin notifies the application of
allocated as FT. If authorized to join the stream, the target will that fact, and the application is then responsible for terminating the
receive a CONNECT message including FlowSpec FT = F. stream. Note, however, that the application may decide to add targets to the
stream instead of terminating it, or may just leave the stream open with no
targets in order to permit stream joins.
o F < FT, i.e., F requires a smaller amount of resources to be 5 Exceptional Cases
allocated than FT. If authorized to join the stream, the target will
receive a CONNECT message including FlowSpec F. The tar- get may
always REFUSE the stream if FlowSpec F is believed to be
insufficient, or, it may join the stream and perhaps later request
the stream origin to modify the whole stream's FlowSpec. This request
has to be sent out-of-band.
If the target does not specify any FlowSpec, i.e., no FlowSpec The previous descriptions covered the simple cases where everything worked.
parameter is included in the JOIN-REQUEST message, see Section 11.8, We now discuss what happens when things do not succeed. Included are
it will receive FlowSpec F as part of the CONNECT message. situations where messages exceed a network MTU, are lost, the requested
resources are not available, the routing fails or is inconsistent.
3.4.2.2 Router as Origin 5.1 Long ST Messages
When join authorization level 3 is chosen, see Section 3.2.2 and It is possible that an ST agent, or an application, will need to send a
Section 3.4.2, it is possible that the stream origin is unaware that message that exceeds a network's Maximum Transmission Unit (MTU). This case
a target participates in the stream. In this case, the router that must be handled but not via fragmentation, since ST2 does not support
first sent a CONNECT message to this target has to act as the stream fragmentation of either data or control messages.
origin for the given target. This includes:
o if the whole stream is deleted, the router must disconnect 5.1.1 Handling of Long Data Packets
the target.
o if the stream FlowSpec is changed, the router must change the ST agents discard data packets that exceed the MTU of the next-hop network.
FlowSpec for the target as appropriate. No error message is generated. Applications should avoid sending data
packets larger than the minimum MTU supported by a given stream. The
application, both at the origin and targets, can learn the stream minimum
MTU through the MTU discovery mechanism described in Section 8.6.
Of course, the router behaves normally for all other targets added to 5.1.2 Handling of Long Control Packets
the stream as a consequence of a CONNECT message issued by the
origin. Note that, for targets that joined a stream without notifying
the origin, some operations are not possible. For instance, the
origin cannot explicitly drop these targets from the stream.
3.4.3 The Origin Removing Targets Each ST agent knows the MTU of the networks to which it is connected, and
those MTUs restrict the size of the SCMP message it can send. An SCMP
message size can exceed the MTU of a given network for a number of reasons:
The application at the origin specifies a set of targets that are to o the TargetList parameter (Section 10.3.6) may be too long;
be removed from the stream and an appropriate ReasonCode
(ApplDisconnect). The targets are partitioned into multiple
DISCONNECT messages based on the next-hop to the individual targets.
If the TargetList is too long to fit into one DISCONNECT message, it
is partitioned as described in Section 3.1.2.2.
An ST agent that receives a DISCONNECT message acknowledges it by o the RecordRoute parameter (Section 10.3.5) may be too long.
sending an ACK back to the previous-hop. The DISCONNECT is also
propagated to the relevant next-hop ST agents. Before propagating the
message, the TargetList is partitioned based on next-hop ST agents.
If, after deleting the specified targets, any next-hop has no o the UserData parameter (Section 10.3.7) may be too long;
remaining targets, then those resources associated with that next-hop
ST agent may be released. Note that network resources may not
actually be released if network multicasting is being used since they
may still be required for traffic to other next-hops in the multicast
group.
When the DISCONNECT reaches a target, the target sends an ACK and o the PDUInError field of the ERROR message (Section 10.4.6) may be
notifies the application that it is no longer part of the stream and too long;
for which reason. The ST agent at the target deletes the stream from An ST agent receiving or generating a too long SCMP message should:
its database after performing any necessary management and accounting
functions. Note that the stream is not deleted if the ST agent is
also a router for the stream and there are remaining downstream
targets.
3.4.4 A Target Deleting Itself o break the message into multiple messages, each carrying part of the
TargetList. Any RecordRoute and UserData parameters are
replicated in each message for delivery to all targets.
Applications that support a large number of targets may avoid
using long TargetList parameters, and are expected to do so, by
exploiting the stream joining functions, see Section 4.6.3. One
exception to this rule exists. In the case of a long TargetList
parameter to be included in a STATUS-RESPONSE message, the
TargetList parameter is just truncated to the point where the
list can fit in a single message, see Section 8.4.
The application at the target may inform ST that it wants to be o for down stream agents: if the TargetList parameter contains a
removed from the stream and the appropriate ReasonCode single Target element and the message size is still too long,
(ApplDisconnect). The ST agent then forms a REFUSE message with the ST agent should issue a REFUSE message with ReasonCode
itself as the only entry in the TargetList. The REFUSE is sent back (RecordRouteSize) if the size of the RecordRoute parameter
to the origin via the previous-hop. If a stream has multiple targets causes the SCMP message size to exceed the network MTU, or
and one target leaves the stream using this REFUSE mechanism, the with ReasonCode (UserDataSize) if the size of the UserData
stream to the other targets is not affected; the stream continues to parameter causes the SCMP message size to exceed the network
exist. MTU. If both RecordRoute and UserData parameters are present
the ReasonCode (UserDataSize) should be sent. For messages
generated at the target: the target ST agent must check for SCMP
messages that may exceed the MTU on the complete
target-to-origin path, and inform the application that a too
long SCMP messages has been generated. The format for the error
reporting is a local implementation issue. The error codes are
the same as previously stated.
An ST agent that receives such a REFUSE message acknowledges it by ST agents generating too long ERROR messages, simply truncate the PDUInError
sending an ACK to the next-hop. The target is deleted and, if the field to the point where the message is smaller than the network MTU.
next-hop has no remaining targets, then the resources associated with
that next-hop ST agent may be released. Note that network resources
may not actually be released if network multicasting is being used
since they may still be required for traffic to other next-hops in
the multicast group. The REFUSE is also propagated back to the
previous-hop ST agent.
When the REFUSE reaches the origin, the origin sends an ACK and 5.2 Timeout Failures
notifies the application that the target is no longer part of the
stream.
3.4.5 Changing a Stream's FlowSpec As described in Section 4.3, SCMP message delivery is made reliable through
the use of acknowledgments, timeouts, and retransmission. The ACCEPT,
CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and REFUSE messages
must always be acknowledged, see Section 4.2. In addition, for some SCMP
messages (CHANGE, CONNECT, JOIN) the sending ST agent also expects a
response back (ACCEPT/REFUSE, CONNECT/ JOIN-REJECT) after ACK has been
received. Also, the STATUS message must be replied with a STATUS-RESPONSE
message.
The application at the sender may wish to change the FlowSpec of an The following sections describe the handling of each of the possible failure
established stream. To do so, it informs the ST agent at the origin cases due to timeout situations while waiting for an acknowledgment or a
of the new FlowSpec and of the list of targets relative to the response. The timeout related variables, and their names, used in the next
change. The origin then issues one CHANGE message with the new sections are for reference purposes only. They may be implementation
FlowSpec per next-hop and sends it to the relevant next-hop ST specific. Different implementations are not required to share variable
agents. CHANGE messages are structured and processed similarly to names, or even the mechanism by which the timeout and retransmission
CONNECT messages. behavior is implemented.
A next-hop ST agent that is an intermediate ST agent and receives a 5.2.1 Failure due to ACCEPT Acknowledgment Timeout
CHANGE message similarly determines if it can implement the new
FlowSpec along the hop to each of its next-hop ST agents, and if so,
it propagates the CHANGE messages along the established paths. If
this process succeeds, the CHANGE messages will eventually reach the
targets, which will each respond with an ACCEPT (or REFUSE) message
that is propagated back to the origin.
If the change to the FlowSpec is in a direction that makes fewer An ST agent that sends an ACCEPT message upstream expects an ACK from the
demands of the involved networks, then the change has a high previous-hop ST agent. If no ACK is received before the ToAccept timeout
probability of success along the path of the established stream. Each expires, the ST agent should retry and send the ACCEPT message again. After
ST agent receiving the CHANGE message makes the necessary requested NAccept unsuccessful retries, the ST agent sends a REFUSE message toward the
changes to the network resource allocations, and if successful, origin, and a DISCONNECT message toward the targets. Both REFUSE and
propagates the CHANGE message along the established paths. If the DISCONNECT must identify the affected targets and specify the ReasonCode
change cannot be made then the ST agent must recover using DISCONNECT (RetransTimeout).
and REFUSE messages as in the case of a network failure, see Section
5.2. Note that a failure to change the resources requested for
specific targets should not cause other targets in the stream to be
deleted.
3.5 Stream Tear Down 5.2.2 Failure due to CHANGE Acknowledgment Timeout
A stream is usually terminated by the origin when it has no further An ST agent that sends a CHANGE message downstream expects an ACK from the
data to send, but may also be partially torn down by the individual next-hop ST agent. If no ACK is received before the ToChange timeout
targets. These cases will not be further discussed since they have expires, the ST agent should retry and send the CHANGE message again. After
already been described above. NChange unsuccessful retries, the ST agent aborts the change attempt and it
sends a REFUSE message toward the origin with ReasonCode (RetransTimeout).
A stream is also torn down if the application should terminate 5.2.3 Failure due to CHANGE Response Timeout
abnormally. Processing in this case is identical to the previous
descriptions except that the ReasonCode (ApplAbort) is different.
When all targets have left a stream, the origin notifies the After correctly receiving the ACK to a CHANGE message, an ST agent expects
application of that fact, and the application then is responsible for to receive an ACCEPT, or REFUSE message in response. If one of these
terminating the stream. Note, however, that the application may messages is not received before the ToChangeResp timer expires, the ST agent
decide to add targets to the stream instead of terminating it. 4 aborts the change attempt and it sends a REFUSE message toward the origin
Exceptional Cases with ReasonCode (ResponseTimeout).
The previous descriptions covered the simple cases where everything 5.2.4 Failure due to CONNECT Acknowledgment Timeout
worked. We now discuss what happens when things do not succeed.
Included are situations where messages are lost, the requested
resources are not available, the routing fails or is inconsistent.
4.1 Setup Failures An ST agent that sends a CONNECT message downstream expects an ACK from the
next-hop ST agent. If no ACK is received before the ToConnect timeout
expires, the ST agent should retry and send the CONNECT message again. After
NConnect unsuccessful retries, the ST agent sends a REFUSE message toward
the origin, and a DISCONNECT message toward the targets. Both REFUSE and
DISCONNECT must identify the affected targets and specify the ReasonCode
(RetransTimeout).
4.1.1 Setup Failure due to CONNECT Timeout 5.2.5 Failure due to CONNECT Response Timeout
When sending a CONNECT message, an ST agent expects an ACK from the After correctly receiving the ACK to a CONNECT message, an ST agent expects
next hop ST agent. If the CONNECT fails due to timeout (see Section to receive an ACCEPT or REFUSE message in response. If one of these message
7.3), the ST agent sends a REFUSE message back in the direction of is not received before the ToConnectResp timer expires, the ST agent aborts
the origin with the appropriate ReasonCode (ConnectTimeout). the connection setup attempt and it sends a REFUSE message toward the origin
and a DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must
identify the affected targets and specify the ReasonCode (ResponseTimeout).
4.1.2 Setup Failure due to ACCEPT Timeout 5.2.6 Failure due to DISCONNECT Acknowledgment Timeout
An ST agent that propagates an ACCEPT message backward toward the An ST agent that sends a DISCONNECT message downstream expects an ACK from
origin expects an ACK from the previous hop ST agent. If the ACCEPT the next-hop ST agent. If no ACK is received before the ToDisconnect
fails due to timeout (see Section 7.3), the ST agent replaces the timeout expires, the ST agent should retry and send the DISCONNECT message
ACCEPT with a REFUSE and sends a DISCONNECT in the direction toward again. After NDisconnect unsuccessful retries, the ST agent simply gives up
the target. Both REFUSE and DISCONNECT must identify the affected and it assumes the next-hop ST agent is not part in the stream any more.
targets and specify the appropriate ReasonCode (AcceptTimeout).
4.1.3 Setup Failure due to Routing Failures 5.2.7 Failure due to JOIN Acknowledgment Timeout
It is possible for an ST agent to receive a CONNECT message that An ST agent that sends a JOIN message toward the origin expects an ACK from
contains a known SID, but from an ST agent other than the previous- a neighbour ST agent. If no ACK is received before the ToJoin timeout
hop ST agent of the stream with that SID. This may be: expires, the ST agent should retry and send the JOIN message again. After
NJoin unsuccessful retries, the ST agent sends a JOIN-REJECT message back
in the direction of the target with ReasonCode (RetransTimeout).
1. that two branches of the tree forming the stream have joined 5.2.8 Failure due to JOIN Response Timeout
back together,
2. the result of an attempted recovery of a partially failed After correctly receiving the ACK to a JOIN message, the ST agent at the
stream, or target expects to receive a CONNECT or JOIN-REJECT message in response. If
one of these message is not received before the ToJoinResp timer expires,
the ST agent aborts the stream join attempt and it returns an error
correspondent to ReasonCode (RetransTimeout) to the application.
Note that, after correctly receiving the ACK to a JOIN message, intermediate
ST agents do not maintain any state on the stream joining attempt. As a
consequence, they do not set the ToJoinResp timer and do not wait for a
CONNECT or JOIN-REJECT message. This is described in Section 4.6.3.
5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout
An ST agent that sends a JOIN-REJECT message toward the target expects an
ACK from a neighbour ST agent. If no ACK is received before the ToJoinReject
timeout expires, the ST agent should retry and send the JOIN-REJECT message
again. After NJoinReject unsuccessful retries, the ST agent simply gives up.
5.2.10 Failure due to NOTIFY Acknowledgment Timeout
An ST agent that sends a NOTIFY message to a neighbour ST agent expects an
ACK from that neighbour ST agent. If no ACK is received before the ToNotify
timeout expires, the ST agent should retry and send the NOTIFY message
again. After NNotify unsuccessful retries, the ST agent simply gives up and
behaves as if the ACK message was received.
5.2.11 Failure due to REFUSE Acknowledgment Timeout
An ST agent that sends a REFUSE message upstream expects an ACK from the
previous-hop ST agent. If no ACK is received before the ToRefuse timeout
expires, the ST agent should retry and send the REFUSE message again. After
NRefuse unsuccessful retries, the ST agent gives up and it assumes it is not
part in the stream any more.
5.2.12 Failure due to STATUS Response Timeout
After sending a STATUS message to a neighbour ST agent, an ST agent expects
to receive a STATUS-RESPONSE message in response. If this message is not
received before the ToStatusResp timer expires, the ST agent sends the
STATUS message again. After NStatus unsuccessful retries, the ST agent gives
up and assumes that the neighbor ST agent is not active.
5.3 Setup Failures due to Routing Failures
It is possible for an ST agent to receive a CONNECT message that contains a
known SID, but from an ST agent other than the previous-hop ST agent of the
stream with that SID. This may be:
1. that two branches of the tree forming the stream have joined back
together,
2. the result of an attempted recovery of a partially failed stream, or
3. an erroneous routing loop. 3. an erroneous routing loop.
The TargetList contained in the CONNECT is used to distinguish the The TargetList contained in the CONNECT is used to distinguish the different
different cases by comparing each newly received target with those of cases by comparing each newly received target with those of the previously
the previously existing stream: existing stream:
o if the IP address of the targets differ, it is case #1; o if the IP address of the target(s) differ, it is case #1;
o if the target matches a target in the existing stream, it may o if the target matches a target in the existing stream, it may be
be case #2 or #3. case #2 or #3.
Case #1 is handled in Section 4.2.2 on path convergence. The Case #1 is handled in Section 5.3.1, while the other cases are handled in
remaining cases requiring recovery, a partially failed stream and an Section 5.3.2.
erroneous routing loop, are not easily distinguishable. In attempting
recovery of a failed stream, an ST agent may issue new CONNECT 5.3.1 Path Convergence
messages to the affected targets. Such a CONNECT may reach an ST
agent downstream of the failure before that ST agent has received a It is possible for an ST agent to receive a CONNECT message that contains a
DISCONNECT from the neighbourhood of the failure. Until that ST agent known SID, but from an ST agent other than the previous-hop ST agent of the
receives the DISCONNECT, it cannot distinguish between a failure stream with that SID. This might be the result of two branches of the tree
recovery and an erroneous routing loop. That ST agent must therefore forming the stream have joined back together. Detection of this case and
respond to the CONNECT with a REFUSE message with the affected other possible sources was discussed in Section 5.2.
SCMP does not allow for streams which have converged path, i.e streams are
always tree-shaped and not graph-like. At the point of convergence, the ST
agent which detects the condition generates a REFUSE message with ReasonCode
(PathConvergence). Also, as a help to the upstream ST agent, the detecting
agent places the IP address of one of the stream's connected targets in the
ValidTargetIPAddress field of the REFUSE message. This IP address will be
used by upstream ST agents to avoid splitting the stream.
An upstream ST agent that receives the REFUSE with ReasonCode
(PathConvergence) will check to see if the listed IP address is one of the
known stream targets. If it is not, the REFUSE is propagated to the
previous-hop agent. If the listed IP address is known by the upstream ST
agent, this ST agent is the ST agent that caused the split in the stream.
(This agent may even be the origin). This agent then avoids splitting the
stream by using the next-hop of that known target as the next-hop for the
refused targets. It sends a CONNECT with the affected targets to the
existing valid next-hop.
The above process will proceed, hop by hop, until the ValidTargetIPAddress
matches the IP address of a known target. The only case where this process
will fail is when the known target is deleted prior to the REFUSE
propagating to the origin. In this case the origin can just reissue the
CONNECT and start the whole process over again.
5.3.2 Other Cases
The remaining cases including a partially failed stream and an erroneous
routing loop, are not easily distinguishable. In attempting recovery of a
failed stream, an ST agent may issue new CONNECT messages to the affected
targets. Such a CONNECT may reach an ST agent downstream of the failure
before that ST agent has received a DISCONNECT from the neighbourhood of the
failure. Until that ST agent receives the DISCONNECT, it cannot distinguish
between a failure recovery and an erroneous routing loop. That ST agent must
therefore respond to the CONNECT with a REFUSE message with the affected
targets specified in the TargetList and an appropriate ReasonCode targets specified in the TargetList and an appropriate ReasonCode
(StreamExists). (StreamExists).
The ST agent immediately preceding that point, i.e., the latest ST The ST agent immediately preceding that point, i.e., the latest ST agent to
agent to send the CONNECT message, will receive the REFUSE message. send the CONNECT message, will receive the REFUSE message. It must release
It must release any resources reserved exclusively for traffic to the any resources reserved exclusively for traffic to the listed targets. If
listed targets. If this ST agent was not the one attempting the this ST agent was not the one attempting the stream recovery, then it cannot
stream recovery, then it cannot distinguish between a failure distinguish between a failure recovery and an erroneous routing loop. It
recovery and an erroneous routing loop. It should repeat the CONNECT should repeat the CONNECT after a ToConnect timeout, see Section 5.2.4. If
after a ToConnect timeout, cf. Section 7.3 and Section 4.1.1. If after NConnect retransmissions it continues to receive REFUSE messages, it
after NConnect retransmissions it continues to receive REFUSE should propagate the REFUSE message toward the origin, with the TargetList
messages, it should propagate the REFUSE message toward the origin, that specifies the affected targets, but with a different ReasonCode
with the TargetList that specifies the affected targets, but with a (RouteLoop).
different error code (RouteLoop).
The REFUSE message with this error code (RouteLoop) is propagated by The REFUSE message with this ReasonCode (RouteLoop) is propagated by each ST
each ST agent without retransmitting any CONNECT messages. At each ST agent without retransmitting any CONNECT messages. At each ST agent, it
agent, it causes any resources reserved exclusively for the listed causes any resources reserved exclusively for the listed targets to be
targets to be released. The REFUSE will be propagated to the origin released. The REFUSE will be propagated to the origin in the case of an
in the case of an erroneous routing loop. In the case of stream erroneous routing loop. In the case of stream recovery, it will be
recovery, it will be propagated to the ST agent that is attempting propagated to the ST agent that is attempting the recovery, which may be an
the recovery, which may be an intermediate ST agent or the origin intermediate ST agent or the origin itself. In the case of a stream
itself. In the case of a stream recovery, the ST agent attempting the recovery, the ST agent attempting the recovery may issue new CONNECT
recovery may issue new CONNECT messages to the same or to different messages to the same or to different next-hops.
next-hops.
If an ST agent receives both a REFUSE message and a DISCONNECT If an ST agent receives both a REFUSE message and a DISCONNECT message with
message with a target in common then it can release the relevant a target in common then it can release the relevant resources and propagate
resources and propagate neither the REFUSE nor the DISCONNECT. neither the REFUSE nor the DISCONNECT.
If the origin receives such a REFUSE message, it should attempt to If the origin receives such a REFUSE message, it should attempt to send a
send a new CONNECT to all the affected targets. Since routing errors new CONNECT to all the affected targets. Since routing errors in an internet
in an internet are assumed to be temporary, the new CONNECTs will are assumed to be temporary, the new CONNECTs will eventually find
eventually find acceptable routes to the targets, if one exists. If acceptable routes to the targets, if one exists. If no further routes exist
no further routes exist after NRetryRoute tries, the application after NRetryRoute tries, the application should be informed so that it may
should be informed so that it may take whatever action it seems take whatever action it seems necessary.
necessary.
4.2 Further Issues 5.4 Problems due to Routing Inconsistency
4.2.1 Problems due to Routing Inconsistency When an intermediate ST agent receives a CONNECT, it invokes the routing
algorithm to select the next-hop ST agents based on the TargetList and the
networks to which it is connected. If the resulting next-hop to any of the
targets is across the same network from which it received the CONNECT (but
not the previous-hop itself), there may be a routing problem. However, the
routing algorithm at the previous-hop may be optimizing differently than the
local algorithm would in the same situation. Since the local ST agent cannot
distinguish the two cases, it should permit the setup but send back to the
previous-hop ST agent an informative NOTIFY message with the appropriate
ReasonCode (RouteBack), pertinent TargetList, and in the NextHopIPAddress
element the address of the next-hop ST agent returned by its routing
algorithm.
When an intermediate ST agent receives a CONNECT, it invokes the The ST agent that receives such a NOTIFY should ACK it. If the ST agent is
routing algorithm to select the next-hop ST agents based on the using an algorithm that would produce such behaviour, no further action is
TargetList and the networks to which it is connected. If the taken; if not, the ST agent should send a DISCONNECT to the next-hop ST
resulting next-hop to any of the targets is across the same network agent to correct the problem.
from which it received the CONNECT (but not the previous-hop itself),
there may be a routing problem. However, the routing algorithm at the
previous-hop may be optimizing differently than the local algorithm
would in the same situation. Since the local ST agent cannot
distinguish the two cases, it should permit the setup but send back
to the previous-hop ST agent an informative NOTIFY message with the
appropriate ReasonCode(RouteBack), pertinent TargetList, and in the
NextHopIPAddress element the address of the next-hop ST agent
returned by its routing algorithm.
The ST agent that receives such a NOTIFY should ACK it. If the ST Alternatively, if the next-hop returned by the routing function is in fact
agent is using an algorithm that would produce such behaviour, no the previous-hop, a routing inconsistency has been detected. In this case, a
further action is taken; if not, the ST agent should send a REFUSE is sent back to the previous-hop ST agent containing an appropriate
DISCONNECT to the next-hop ST agent to correct the problem. ReasonCode (RouteInconsist), pertinent TargetList, and in the
NextHopIPAddress element the address of the previous-hop. When the
previous-hop receives the REFUSE, it will recompute the next-hop for the
affected targets. If there is a difference in the routing databases in the
two ST agents, they may exchange CONNECT and REFUSE messages again. Since
such routing errors in the internet are assumed to be temporary, the
situation should eventually stabilize.
Alternatively, if the next-hop returned by the routing function is in 5.5 Problems in Reserving Resources
fact the previous-hop, a routing inconsistency has been detected. In
this case, a REFUSE is sent back to the previous- hop ST agent
containing an appropriate ReasonCode (RouteInconsist), pertinent
TargetList, and in the NextHopIPAddress element the address of the
previous-hop. When the previous-hop receives the REFUSE, it will
recompute the next-hop for the affected targets. If there is a
difference in the routing databases in the two ST agents, they may
exchange CONNECT and REFUSE messages again. Since such routing errors
in the internet are assumed to be temporary, the situation should
eventually stabilize.
4.2.2 Path Convergence As mentioned in Section 1.4.5, resource reservation is handled by the LRM.
The LRM may not be able to satisfy a particular request during stream setup
or modification for a number of reasons, including a mismatched FlowSpec, an
unknown FlowSpec version, an error in processing a FlowSpec, and an
inability to allocate the requested resource. This section discusses these
cases and specifies the ReasonCodes that should be used when these error
cases are encountered.
It is possible for an ST agent to receive a CONNECT message that 5.5.1 Mismatched FlowSpecs
contains a known SID, but from an ST agent other than the previous
hop ST agent of the stream with that SID. This might be the result of
two branches of the tree forming the stream have joined back
together. Other cases are discussed in Section 4.1.3.
This version of ST does not allow streams which have converged path, In some cases the LRM may require a requested FlowSpec to match an existing
i.e streams are always tree-shaped and not graph-like. The ST agent FlowSpec, e.g. when adding new targets to an existing stream, see Section
which detects this condition informs the previous hop ST agent (the 4.6.1. In case of FlowSpec mismatch the LRM notifies the processing ST agent
latest ST agent to send the CONNECT message) by sending a NOTIFY which should respond with ReasonCode (FlowSpecMismatch).
message with ReasonCode(PathConverge). Upon receipt of the NOTIFY
message, the previous hop ST agent will find alternate route to the
listed targets with a different next hop ST agent. If there is no
next hop ST agent other than the one it receives the NOTIFY message
from, the ST agent must release any resources reserved for the listed
targets and send a REFUSE message with ReasonCode(PathConverge) to
its previous hop ST agent. In the same way, the REFUSE message is
possibly propagated back by each ST agent. At each ST agent, it
causes any resources reserved exclusively for the listed targets to
be released. When the REFUSE reaches the origin, the ST agent at the
origin should attempt to send a CONNECT with the listed targets to a
different route. If no route exists, or after NRetryRoute tries, the
application should be informed so that it may take whatever actions
it seems necessary.
4.2.3 Problems in Reserving Resources 5.5.2 Unknown FlowSpec Version
If the local or network resources are not available, an ST agent may: When the LRM is invoked, it is passed information including the version of
the FlowSpec, see Section 4.5.2.2. If this version is not know by the LRM,
the LRM notifies the ST agent. The ST agent should respond with a REFUSE
message with ReasonCode (FlowVerUnknown).
o try alternative paths to the targets: the ST agent calls the 5.5.3 LRM Unable to Process FlowSpec
routing function to find a different path to the targets. If an
alternative path is found, stream connection setup continues in the
usual way, as described in Section 3.1.
o preempt one or more of the already established streams: this The LRM may encounter an LRM or FlowSpec specific error while attempting to
way, the ST agent attempts to free enough resources to allow for the satisfy a request. An example of such an error is given in Section 9.2.1.
new stream to be established. Stream preemption is discussed in These error are implementation specific and will not be enumerated with ST
Section 5.3. ReasonCodes. They are covered by a single, generic ReasonCode. When an LRM
encounters such an error, it should notify the ST agent which should respond
with the generic ReasonCode (FlowSpecError).
o refuse to establish the stream along this path: the origin ST 5.5.4 Insufficient Resources
agent informs the application of the stream setup failure; an ST
agent at a router or target issues a REFUSE message (as described in If the LRM cannot make the necessary reservations because sufficient
Section 3.1.5) with ReasonCode (CantGetResrc). resources are not available, an ST agent may:
o try alternative paths to the targets: the ST agent calls the routing
function to find a different path to the targets. If an alternative
path is found, stream connection setup continues in the usual way,
as described in Section 4.5.
o refuse to establish the stream along this path: the origin ST agent
informs the application of the stream setup failure; an ST agent at
a router or target issues a REFUSE message (as described in
Section 4.5.8) with ReasonCode (CantGetResrc).
It depends on the local implementations whether an ST agent tries It depends on the local implementations whether an ST agent tries
alternative paths or preempts other streams. Also, the order of the alternative paths or refuses to establish the stream. In any case, if enough
actions taken is not defined here. In any case, if enough resources resources cannot be found over different paths, the ST agent has to
cannot be found over different paths or as a consequence of stream explicitly refuse to establish the stream.
preemption, the ST agent has to explicitly refuse to establish the
stream.
4.2.4 Problems Caused by CHANGE Messages 5.6 Problems Caused by CHANGE Messages
A CHANGE might fail for several reasons, including: A CHANGE might fail for several reasons, including:
o the request may be for a larger amount of network resources o insufficient resources: the request may be for a larger amount of
when those resources are not available; network resources when those resources are not available, ReasonCode
(CantGetResrc);
o it might be required that all the former resources are o a target application not agreeing to the change, ReasonCode
released before the new ones are requested and, due to unlucky (ApplRefused);
timing, an unrelated request for network resources might be processed
between the time the resources are released and the time the new
resources are requested, so that the former resources are no longer
available.
If the attempt to change the FlowSpec fails then the ST agent where The affected stream can be left in one of two states as a result of change
the failure occurs must intentionally break the affected portion of failures: a) the stream can revert back to the state it was in prior to the
the stream. This is done by sending REFUSE and DISCONNECT messages CHANGE message being processed, or b) the stream may be torn down.
with ReasonCode (ChgFailed). 5 Failure Detection and Recovery
5.1 Failure Detection The expected common case of failure will be when the requested change cannot
be satisfied, but the pre-change resources remain allocated and available
for use by the stream. In this case, the ST agent at the point where the
failure occurred must inform upstream ST agents of the failure. (In the
case where this ST agent is the target, there may not actually be a failure,
the application may merely have not agreed to the change). The ST agent
informs upstream ST agents by sending a REFUSE message with ReasonCode
(CantGetResrc or ApplRefused). To indicate that the pre-change FlowSpec is
still available and that the stream still exists, the ST agent sets to one
(1) the E-bit of the REFUSE message, see Section 10.4.11. Upstream ST agents
receiving the REFUSE message inform the LRM so that it can attempt to revert
back to the pre-change FlowSpec. It is permissible, but not desirable, for
excess resources to remain allocated.
The ST failure detection mechanism is based on two assumptions: For the case when the attempt to change the stream results in the loss of
previously reserved resources, the stream is torn down. This can happen, for
instance, when the I-bit is set (Section 4.6.5) and the LRM releases
pre-change stream resources before the new ones are reserved, and neither
new nor former resources are available. In this case, the ST agent where the
failure occurs must inform other ST agents of the break in the affected
portion of the stream. This is done by the ST agent by sending a REFUSE
message upstream and a DISCONNECT message downstream, both with the
ReasonCode (CantGetResrc). To indicate that pre-change stream resources have
been lost, the E-bit of the REFUSE message is set to zero (0).
Note that a failure to change the resources requested for specific targets
should not cause other targets in the stream to be deleted.
5.7 Unknown Targets in DISCONNECT and CHANGE
The handling of unknown targets listed in a DISCONNECT or CHANGE message is
dependent on a stream's join authorization level, see Section 4.4.2. For
streams with join authorization levels #0 and #1, see Section 4.4.2, the all
targets must be known. In this case, when processing a CHANGE message, the
agent should generate a refuse with ReasonCode (TargetUnknown). When
processing a DISCONNECT message, it is possible that the DISCONNECT is a
duplicate of an old request so the agent should respond as if it has
successfully disconnected the target. That is, it should respond with an ACK
message.
For streams with join authorization level #2, it is possible that the origin
is not aware of some targets that participate in the stream. The origin may
delete or change these targets via the following flooding mechanism.
If no next-hop ST agent can be associated with a target, the
CHANGE/DISCONNECT/message including the target is replicated to all known
next-hop ST agents. This has the effect of propagating the CHANGE/DISCONNECT
message to all downstream ST agents. Eventually, the ST agent that acts as
the origin for the target (Section 4.6.3.1) is reached and the target is
deleted.
Target deletion/change via flooding is not expected to be the normal case.
It is included to present the applications with uniform capabilities for all
stream types. Flooding only applies to streams with join authorization level
#2.
6 Failure Detection and Recovery
6.1 Failure Detection
The SCMP failure detection mechanism is based on two assumptions:
1. If a neighbor of an ST agent is up, and has been up without a 1. If a neighbor of an ST agent is up, and has been up without a
disruption, and has not notified the ST agent of a problem with disruption, and has not notified the ST agent of a problem with streams that
streams that pass through both, then the ST agent can assume that pass through both, then the ST agent can assume that there has not been any
there has not been any problem with those streams. problem with those streams.
2. A network through which an ST agent has routed a stream will 2. A network through which an ST agent has routed a stream will notify
notify the ST agent if there is a problem that affects the stream the ST agent if there is a problem that affects the stream data packets but
data packets but does not affect the control packets. does not affect the control packets.
The purpose of the robustness protocol defined here is for ST agents The purpose of the robustness protocol defined here is for ST agents to
to determine that the streams through a neighbor have been broken by determine that the streams through a neighbor have been broken by the
the failure of the neighbor or the intervening network. This protocol failure of the neighbor or the intervening network. This protocol should
should detect the overwhelming majority of failures that can occur. detect the overwhelming majority of failures that can occur. Once a failure
Once a failure is detected, the recovery procedures described in is detected, the recovery procedures described in Section 6.2 are initiated
Section 5.2 are initiated by the ST agents. by the ST agents.
5.1.1 Network Failures 6.1.1 Network Failures
An ST agent can detect network failures by two mechanisms: An ST agent can detect network failures by two mechanisms:
o the network can report a failure, or o the network can report a failure, or
o the ST agent can discover a failure by itself. o the ST agent can discover a failure by itself.
They differ in the amount of information that an ST agent has They differ in the amount of information that an ST agent has available to
available to it in order to make a recovery decision. For example, a it in order to make a recovery decision. For example, a network may be able
network may be able to report that reserved bandwidth has been lost to report that reserved bandwidth has been lost and the reason for the loss
and the reason for the loss and may also report that connectivity to and may also report that connectivity to the neighboring ST agent remains
the neighboring ST agent remains intact. In this case, the ST agent intact. On the other hand, an ST agent may discover that communication with
may request the network to allocate bandwidth anew. On the other a neighboring ST agent has ceased because it has not received any traffic
hand, an ST agent may discover that communication with a neighboring from that neighbor in some time period. If an ST agent detects a failure, it
ST agent has ceased because it has not received any traffic from that may not be able to determine if the failure was in the network while the
neighbor in some time period. If an ST agent detects a failure, it neighbor remains available, or the neighbor has failed while the network
may not be able to determine if the failure was in the network while remains intact.
the neighbor remains available, or the neighbor has failed while the
network remains intact.
5.1.2 Detecting ST Agents Failures 6.1.2 Detecting ST Agents Failures
Each ST agent periodically sends each neighbour with which it shares Each ST agent periodically sends each neighbour with which it shares one or
one or more streams a HELLO message. This message exchange is between more streams a HELLO message. This message exchange is between ST agents,
ST agents, not entities representing streams or applications. That not entities representing streams or applications. That is, an ST agent need
is, an ST agent need only send a single HELLO message to a neighbour only send a single HELLO message to a neighbour regardless of the number of
regardless of the number of streams that flow between them. All ST streams that flow between them. All ST agents (host as well as intermediate)
agents (host as well as intermediate) must participate in this must participate in this exchange. However, only ST agents that share active
exchange. However, only ST agents that share active streams need to streams can participate in this exchange and it is an error to send a HELLO
participate in this exchange and it is an error to send a HELLO message to a neighbour ST agent with no streams in common, e.g. to check
message to a neighbour ST agent with no streams in common, e.g. to whether it is active. STATUS messages can be used to poll status of
check whether it is active. Note that STATUS messages can be used to neighbour ST agents, see Section 8.4.
poll neighbour ST agents.
A HELLO message is ACKed if the Reference field is non-zero. As well The HELLO message has two fields:
as identifying the sender, the HELLO message has two fields:
o a HelloTimer field that is in units of milliseconds modulo o a HelloTimer field that is in units of milliseconds modulo the
the maximum for the field size, and maximum for the field size, and
o a Restarted-bit specifying that the ST agent has been o a Restarted-bit specifying that the ST agent has been restarted
restarted recently. recently.
The HelloTimer must appear to be incremented every millisecond The HelloTimer must appear to be incremented every millisecond whether a
whether a HELLO message is sent or not, but it is allowable for an ST HELLO message is sent or not. The HelloTimer wraps around to zero after
agent to create a new HelloTimer only when it sends a HELLO message. reaching the maximum value. Whenever an ST agent suffers a catastrophic
The HelloTimer wraps around to zero after reaching the maximum value. event that may result in it losing ST state information, it must reset its
Whenever an ST agent suffers a catastrophic event that may result in HelloTimer to zero and must set the Restarted-bit in all HELLO messages sent
it losing ST state information, it must reset its HelloTimer to zero in the following HelloTimerHoldDown seconds.
and must set the Restarted-bit for the following HelloTimerHoldDown
seconds.
Each ST stream has a RecoveryTimeout value associated with it. This If an ST agent receives a HELLO message that contains the Restarted-bit set,
value is assigned by the origin and carried into the CONNECT message, it must assume that the sending ST agent has lost its state. If it shares
see Section 11.4. streams with that neighbor, it must initiate stream recovery activity, see
Section 6.2. If it does not share streams with that neighbor, it should not
attempt to create one until that bit is no longer set. If an ST agent
receives a CONNECT message from a neighbor whose Restarted-bit is still set,
it must respond with ERROR with the appropriate ReasonCode (RestartRemote).
If it receives a CONNECT message while its own Restarted-bit is set, it must
respond with ERROR with the appropriate ReasonCode (RestartLocal).
An ST agent must send HELLO messages to its neighbour with a period Each ST stream has a RecoveryTimeout value associated with it. This value is
shorter than the smallest RecoveryTimeout of all the active streams assigned by the origin and carried into the CONNECT message, see Section
that pass between the two ST agents, regardless of direction. This 4.5.10.
period must be smaller by a factor, called HelloLossFactor, which is
at least as large as the greatest number of consecutive HELLO
messages that could credibly be lost while the communication between
the two ST agents is still viable.
An ST agent may send simultaneous HELLO messages to all its neighbors An ST agent must send HELLO messages to its neighbour with a period shorter
at the rate necessary to support the smallest RecoveryTimeout of any than the smallest RecoveryTimeout of all the active streams that pass
active stream. Alternately, it may send HELLO messages to different between the two ST agents, regardless of direction. This period must be
neighbors independently at different rates corresponding to smaller by a factor, called HelloLossFactor, which is at least as large as
RecoveryTimeouts of individual streams. the greatest number of consecutive HELLO messages that could credibly be
lost while the communication between the two ST agents is still viable.
The ST agent that receives a HELLO message expects to receive at An ST agent may send simultaneous HELLO messages to all its neighbors at the
least one new HELLO message from a neighbor during the rate necessary to support the smallest RecoveryTimeout of any active stream.
RecoveryTimeout of every active stream through that neighbor. It can Alternately, it may send HELLO messages to different neighbors independently
detect duplicate or delayed HELLO messages by saving the HelloTimer at different rates corresponding to RecoveryTimeouts of individual streams.
field of the most recent valid HELLO message from that neighbor and
comparing it with the HelloTimer field of incoming HELLO messages. It
will only accept an incoming HELLO message from that neighbor if it
has a HelloTimer field that is greater than the most recent valid
HELLO message by the time elapsed since that message was received
plus twice the maximum likely delay variance from that neighbor. If
the ST agent does not receive a valid HELLO message within the
RecoveryTimeout of a stream, it must assume that the neighboring ST
agent or the communication link between the two has failed and it
must initiate stream recovery activity.
Furthermore, if an ST agent receives a HELLO message that contains The ST agent that receives a HELLO message expects to receive at least one
the Restarted-bit set, it must assume that the sending ST agent has new HELLO message from a neighbor during the RecoveryTimeout of every active
lost its ST state. If it shares streams with that neighbor, it must stream through that neighbor. It can detect duplicate or delayed HELLO
initiate stream recovery activity. If it does not share streams with messages by saving the HelloTimer field of the most recent valid HELLO
that neighbor, it should not attempt to create one until that bit is message from that neighbor and comparing it with the HelloTimer field of
no longer set. If an ST agent receives a CONNECT message from a incoming HELLO messages. It will only accept an incoming HELLO message from
neighbor whose Restarted-bit is still set, it must respond with ERROR that neighbor if it has a HelloTimer field that is greater than the most
with the appropriate ReasonCode (RemoteRestart). If it receives a recent valid HELLO message by the time elapsed since that message was
CONNECT message while its own Restarted-bit is set, it must respond received plus twice the maximum likely delay variance from that neighbor.
with ERROR with the appropriate ReasonCode (RestartLocal).
5.2 Failure Recovery If the ST agent does not receive a valid HELLO message within the
RecoveryTimeout of a stream, it must assume that the neighboring ST agent or
the communication link between the two has failed and it must initiate
stream recovery activity, as described below in Section 6.2.
If an intermediate ST agent fails or a network or part of a network 6.2 Failure Recovery
fails, the previous-hop ST agent and the various next-hop ST agents
will discover the fact by the failure detection mechanism described
in Section 5.1.
The recovery of an ST stream is a relatively complex and time If an intermediate ST agent fails or a network or part of a network fails,
consuming effort because it is designed in a general manner to the previous-hop ST agent and the various next-hop ST agents will discover
operate across a large number of networks with diverse the fact by the failure detection mechanism described in Section 6.1.
characteristics. Therefore, it may require information to be
distributed widely, and may require relatively long timers. On the
other hand, since a network is a homogeneous system, failure recovery
in the network may be a relatively faster and simpler operation.
Therefore an ST agent that detects a failure should attempt to fix
the network failure before attempting recovery of the ST stream. If
the stream that existed between two ST agents before the failure
cannot be reconstructed by network recovery mechanisms alone, then
the ST stream recovery mechanism must be invoked.
If stream recovery is necessary, the different ST agents may need to The recovery of an ST stream is a relatively complex and time consuming
perform different functions, depending on their relation to the effort because it is designed in a general manner to operate across a large
failure: number of networks with diverse characteristics. Therefore, it may require
information to be distributed widely, and may require relatively long
timers. On the other hand, since a network is a homogeneous system, failure
recovery in the network may be a relatively faster and simpler operation.
Therefore an ST agent that detects a failure should attempt to fix the
network failure before attempting recovery of the ST stream. If the stream
that existed between two ST agents before the failure cannot be
reconstructed by network recovery mechanisms alone, then the ST stream
recovery mechanism must be invoked.
o An ST agent that is a next-hop of a failure should first If stream recovery is necessary, the different ST agents may need to perform
verify that there was a failure. It can do this using STATUS messages different functions, depending on their relation to the failure:
to query its upstream neighbor. If it cannot communicate with that
neighbor, then it should first send a REFUSE message with the
appropriate Reason- Code ("failure") to the neighbor to speed up the
failure recovery in case the hop is unidirec- tional, i.e., the
neighbor can hear the ST agent but the ST agent cannot hear the
neighbor. The ST agent detecting the failure must then send
DISCONNECT messages with the same Rea- sonCode toward the targets.
The intermediate ST agents process this DISCONNECT message just like o An ST agent that is a next-hop of a failure should first verify that
the DISCON- NECT that tears down the stream. However, a target ST there was a failure. It can do this using STATUS messages to
agent that receives a DISCONNECT message with the appropriate query its upstream neighbor. If it cannot communicate with that
ReasonCode ("failure") will maintain the stream state and notify the neighbor, then it should first send a REFUSE message upstream
next higher protocol of the failure. In effect, these DISCONNECT with the appropriate ReasonCode (STAgentFailure) to the
messages tear down the stream from the point of the failure to the neighbor to speed up the failure recovery in case the hop is
targets, but inform the targets that the stream may be fixed shortly. unidirectional, i.e., the neighbor can hear the ST agent but the
ST agent cannot hear the neighbor. The ST agent detecting the
failure must then send DISCONNECT messages with the same
ReasonCode toward the targets. All downstream ST agents process
this DISCONNECT message just like the DISCONNECT that tears
down the stream. If recovery is successful, targets will receive
new CONNECT messages.
o An ST agent that is the previous-hop before the failed o An ST agent that is the previous-hop before the failed component
component first verifies that there was a failure by querying the first verifies that there was a failure by querying the
downstream neighbor using STATUS messages. If the neighbor has lost downstream neighbor using STATUS messages. If the neighbor has
its state but is available, then the ST agent may reconstruct the lost its state but is available, then the ST agent may try and
stream if the NoRe- covery option is not selected. If it cannot reconstruct the stream, unless the NoRecovery option was
communicate with the next-hop, then the ST agent detecting the selected, as explained below. If it cannot communicate with the
failure releases any resources that are dedicated exclusively to next-hop, then the ST agent detecting the failure sends a
sending data on the broken branch and sends a DISCONNECT message with DISCONNECT message with the appropriate ReasonCode
the appropriate ReasonCode ("failure") toward the affected targets. (STAgentFailure) toward the affected targets. It does so to speed
It does so to speed up failure recovery in case the communication may up failure recovery in case the communication may be
be unidirectional and this message might be delivered successfully. unidirectional and this message might be delivered successfully.
The ST agent that is the previous-hop before the failed component can Based on the NoRecovery option, the ST agent that is the previous-hop before
attempt to recover the streams for which the NoRecovery option is not the failed component takes the following actions:
selected:
o If the NoRecovery option is selected, then the ST agent sends o If the NoRecovery option is selected, then the ST agent sends a
a REFUSE message with the appropriate ReasonCode ("failure") to the REFUSE message with the appropriate ReasonCode (STAgentFailure)
previous-hop. The TargetList in these messages contains all the to the previous-hop. The TargetList in these messages contains
targets that were reached through the broken branch. Multiple REFUSE all the targets that were reached through the broken branch. As
mes- sages may be required if the PDU is too long for the MTU of the discussed in Section 5.1.2, multiple REFUSE messages may be
intervening network. The REFUSE message is propagated all the way to required if the PDU is too long for the MTU of the intervening
the origin, which can attempt recovery of the stream by sending a new network. The REFUSE message is propagated all the way to the ori-
CONNECT to the affected targets. The new CONNECT will be treated by gin. The application at the origin can attempt recovery of the
stream by sending a new CONNECT to the affected targets. For
established streams, the new CONNECT will be treated by
intermediate ST agents as an addition of new targets into the intermediate ST agents as an addition of new targets into the
established stream. established stream.
o If the NoRecovery option is not selected, the ST agent can o If the NoRecovery option is not selected, the ST agent can attempt
attempt recovery of the stream. It does so by issuing a new CONNECT recovery of the stream. It does so by issuing a new CONNECT
message to the affected targets. If the ST agent can- not find new message to the affected targets. If the ST agent cannot find new
routes to some targets, or if the only route to some targets is routes to some targets, or if the only route to some targets is
through the previ- ous-hop, then it sends one or more REFUSE messages through the previous-hop, then it sends one or more REFUSE
to the previous-hop with the appropriate ReasonCode ("failure") messages to the previous-hop with the appropriate ReasonCode
specifying the affected targets in the TargetList. The pre- vious-hop (CantRecover) specifying the affected targets in the TargetList.
can then attempt recovery of the stream by issuing a CONNECT to those The previous-hop can then attempt recovery of the stream by
targets. If it cannot find an appropriate route, it will propagate issuing a CONNECT to those targets. If it cannot find an
the REFUSE message toward the ori- gin. appropriate route, it will propagate the REFUSE message toward
the origin.
Regardless of which ST agent attempts recovery of a damaged stream, Regardless of which ST agent attempts recovery of a damaged stream, it will
it will issue one or more CONNECT messages to the affected targets. issue one or more CONNECT messages to the affected targets. These CONNECT
These CONNECT messages are treated by intermediate ST agents as messages are treated by intermediate ST agents as additions of new targets
additions of new targets into the established stream. The FlowSpecs into the established stream. The FlowSpecs of the new CONNECT messages are
of the new CONNECT messages are the same as the ones contained in the the same as the ones contained in the most recent CONNECT or CHANGE messages
most recent CONNECT or CHANGE messages that the ST agent had sent that the ST agent had sent toward the affected targets when the stream was
toward the affected targets when the stream was operational. operational.
5.2.1 Problems in Stream Recovery Upon receiving an ACCEPT during the a stream recovery, the agent
reconstructing the stream must ensure that the FlowSpec and other stream
attributes (e.g. MaxMsgSize and RecoveryTimeout) of the re-established
stream are equal to, or are less restrictive, than the pre-failure stream.
If they are more restrictive, the recovery attempt must be aborted. If they
are equal, or are less restrictive, then the recovery attempt is successful.
When the attempt is a success, failure recovery related ACCEPTs are not
forwarded upstream by the recovering agent.
The reconstruction of a broken stream may not proceed smoothly. Since Any ST agent that decides that enough recovery attempts have been made, or
there may be some delay while the information concerning the failure that recovery attempts have no chance of succeeding, may indicate that no
is propagated throughout an internet, routing errors may occur for further attempts at recovery should be made. This is done by setting the
some time after a failure. As a result, the ST agent attempting the N-bit in the REFUSE message, see Section 10.4.11. This bit must be set by
recovery may receive ERROR messages for the new CONNECTs that are agents, including the target, that know that there is no chance of recovery
caused by internet routing errors. The ST agent attempting the succeeding. An ST agent that receives a REFUSE message with the N-bit set
recovery should be prepared to resend CONNECTs before it succeeds in (1) will not attempt recovery, regardless of the NoRecovery option, and it
reconstructing the stream. If the failure partitions the internet and will set the N-bit when propagating the REFUSE message upstream.
a new set of routes cannot be found to the targets, the REFUSE
messages will eventually be propagated to the origin, which can then 6.2.1 Problems in Stream Recovery
inform the application so it can decide whether to terminate or to The reconstruction of a broken stream may not proceed smoothly. Since there
continue to attempt recovery of the stream. may be some delay while the information concerning the failure is propagated
throughout an internet, routing errors may occur for some time after a
failure. As a result, the ST agent attempting the recovery may receive ERROR
messages for the new CONNECTs that are caused by internet routing errors.
The ST agent attempting the recovery should be prepared to resend CONNECTs
before it succeeds in reconstructing the stream. If the failure partitions
the internet and a new set of routes cannot be found to the targets, the
REFUSE messages will eventually be propagated to the origin, which can then
inform the application so it can decide whether to terminate or to continue
to attempt recovery of the stream.
The new CONNECT may at some point reach an ST agent downstream of the The new CONNECT may at some point reach an ST agent downstream of the
failure before the DISCONNECT does. In this case, the ST agent that failure before the DISCONNECT does. In this case, the ST agent that receives
receives the CONNECT is not yet aware that the stream has suffered a the CONNECT is not yet aware that the stream has suffered a failure, and
failure, and will interpret the new CONNECT as resulting from a will interpret the new CONNECT as resulting from a routing failure. It will
routing failure. It will respond with an ERROR message with the respond with an ERROR message with the appropriate ReasonCode
appropriate ReasonCode (StreamExists). Since the timeout that the ST (StreamExists). Since the timeout that the ST agents immediately preceding
agents immediately preceding the failure and immediately following the failure and immediately following the failure are approximately the
the failure are approximately the same, it is very likely that the same, it is very likely that the remnants of the broken stream will soon be
remnants of the broken stream will soon be torn down by a DISCONNECT torn down by a DISCONNECT message with the appropriate ReasonCode
message with the appropriate ReasonCode ("failure"). Therefore, the ("failure"). Therefore, the ST agent that receives the ERROR message with
ST agent that receives the ERROR message with ReasonCode ReasonCode (StreamExists) should retransmit the CONNECT message after the
(StreamExists) should retransmit the CONNECT message after the ToConnect timeout expires. If this fails again, the request will be retried
ToConnect timeout expires. If this fails again, the request will be for NConnect times. Only if it still fails will the ST agent send a REFUSE
retried for NConnect times. Only if it still fails will the ST agent message with the appropriate ReasonCode (RouteLoop) to its previous-hop.
send a REFUSE message with the appropriate ReasonCode (RouteLoop) to This message will be propagated back to the ST agent that is attempting
its previous-hop. This message will be propagated back to the ST recovery of the damaged stream. That ST agent can issue a new CONNECT
agent that is attempting recovery of the damaged stream. That ST message if it so chooses. The REFUSE is matched to a CONNECT message created
agent can issue a new CONNECT message if it so chooses. The REFUSE is by a recovery operation through the LnkReference field in the CONNECT.
matched to a CONNECT message created by a recovery operation through
the LnkReference field in the CONNECT.
ST agents that have propagated a CONNECT message and have received a ST agents that have propagated a CONNECT message and have received a REFUSE
REFUSE message should maintain this information for some period of message should maintain this information for some period of time. If an ST
time. If an ST agent receives a second CONNECT message for a target agent receives a second CONNECT message for a target that recently resulted
that recently resulted in a REFUSE, that ST agent may respond with a in a REFUSE, that ST agent may respond with a REFUSE immediately rather than
REFUSE immediately rather than attempting to propagate the CONNECT. attempting to propagate the CONNECT. This has the effect of pruning the
This has the effect of pruning the tree that is formed by the tree that is formed by the propagation of CONNECT messages to a target that
propagation of CONNECT messages to a target that is not reachable by is not reachable by the routes that are selected first. The tree will pass
the routes that are selected first. The tree will pass through any through any given ST agent only once, and the stream setup phase will be
given ST agent only once, and the stream setup phase will be
completed faster. completed faster.
If a CONNECT message reaches a target, the target should as If a CONNECT message reaches a target, the target should as efficiently as
efficiently as possible use the state that it has saved from before possible use the state that it has saved from before the stream failed
the stream failed during recovery of the stream. It will then issue during recovery of the stream. It will then issue an ACCEPT message toward
an ACCEPT message toward the origin. The ACCEPT message will be the origin. The ACCEPT message will be intercepted by the ST agent that is
intercepted by the ST agent that is attempting recovery of the attempting recovery of the damaged stream, if not the origin. If the
damaged stream, if not the origin. If the FlowSpec contained in the FlowSpec contained in the ACCEPT specifies the same selection of parameters
ACCEPT specifies the same selection of parameters as were in effect as were in effect before the failure, then the ST agent that is attempting
before the failure, then the ST agent that is attempting recovery recovery will not propagate the ACCEPT. If the selections of the parameters
will not propagate the ACCEPT. If the selections of the parameters are different, then the ST agent that is attempting recovery will send the
are different, then the ST agent that is attempting recovery will origin a NOTIFY message with the appropriate ReasonCode (FailureRecovery)
send the origin a NOTIFY message with the appropriate ReasonCode that contains a FlowSpec that specifies the new parameter values. The origin
(FailureRecovery) that contains a FlowSpec that specifies the new may then have to change its data generation characteristics and the stream's
parameter values. The origin may then have to change its data parameters with a CHANGE message to use the newly recovered subtree.
generation characteristics and the stream's parameters with a CHANGE
message to use the newly recovered subtree.
5.3 Stream Preemption 6.3 Stream Preemption
An intermediate ST agent may decide to break a stream intentionally.
This is called stream preemption. Usually streams are preempted in
order to free resources for a new stream which has a higher priority.
ST does not define when stream preemption should be used but it
provides the means to implement it.
If an ST agent decides that it is necessary to preempt one or more of As mentioned in Section 1.4.5, it is possible that the LRM decides to break
the stream traversing it, the decision on which streams have to be a stream intentionally. This is called stream preemption. Streams are
preempted has to be made. ST provides two ways of optimizing such expected to be preempted in order to free resources for a new stream which
decision: has a higher priority.
1. Streams can be assigned an StreamImportance value from 0 If the LRM decides that it is necessary to preempt one or more of the stream
(most important) to 7 (least important). This value is carried in the traversing it, the decision on which streams have to be preempted has to be
CONNECT message when the stream is setup, see Section 11.4. made. There are two ways for an application to influence such decision:
2. An application may specify that a set of streams are related 1. based on FlowSpec information. For instance, with the ST2+ FlowSpec,
to each other and that they are all candidate for preemption if one streams can be assigned a precedence value from 0 (least important) to 256
of them gets preempted. It can be done by using the fate- sharing (most important). This value is carried in the FlowSpec when the stream is
relationship defined in Section 6. This helps making a good choice setup, see Section 9.2, so that the LRM is informed about it.
when more than one stream have to be preempted, because it leads to
breaking a single application as oppo- site to as many applications 2. with the group mechanism. An application may specify that a set of
streams are related to each other and that they are all candidate for
preemption if one of them gets preempted. It can be done by using the
fate-sharing relationship defined in Section 7.1.2. This helps the LRM
making a good choice when more than one stream have to be preempted, because
it leads to breaking a single application as opposed to as many applications
as the number of preempted streams. as the number of preempted streams.
Stream preemption requires the following actions from the ST agents: If the LRM preempts a stream, it must notify the local ST agent. The
following actions are performed by the ST agent:
o An intermediate ST agent that breaks the stream intentionally o The ST agent at the host where the stream was preempted sends
sends DISCONNECT messages with the appropriate ReasonCode DISCONNECT messages with the appropriate ReasonCode
(StreamPreempted) toward the affected targets. It sends a REFUSE (StreamPreempted) toward the affected targets. It sends a REFUSE
message with the appropriate ReasonCode (StreamPreempted) to the message with the appropriate ReasonCode (StreamPreempted) to the
previous-hop. previous-hop.
o A previous-hop ST agent of the preempted stream acts as in o A previous-hop ST agent of the preempted stream acts as in case of
case of failure recovery, cf. Section 5.2. If the NoRecovery option failure recovery, see Section 6.2.
is set, is propagates the REFUSE message back to the origin. If the
NoRecovery option is not set, it attempts to rebuild the deleted
paths and, in case this does not work, it propagates the REFUSE
message to the previous-hop.
o A target or next-hop ST agent of the preempted stream acts as o A next-hop ST agent of the preempted stream acts as in case of
in case of failure recovery, cf. Section 5.2. It releases resources failure recovery, see Section 6.2.
that are allocated to the stream, but it maintains the inter- nal
state information describing the stream for some time in case the
stream is quickly fixed.
Note that, as opposite to failure recovery, there is no need to Note that, as opposite to failure recovery, there is no need to verify that
verify that the failure actually occurred, because this is explicitly the failure actually occurred, because this is explicitly indicated by the
indicated by the ReasonCode (StreamPreempted). ReasonCode (StreamPreempted).
6 A Group of Streams 7 A Group of Streams
There may be need to associate related streams. The group mechanism There may be need to associate related streams. The group mechanism is
is simply an association technique that allows ST agents to identify simply an association technique that allows ST agents to identify the
the different streams that are to be associated. different streams that are to be associated.
A group consists of a set of streams and a relationship. The set of A group consists of a set of streams and a relationship. The set of streams
streams may be empty. The relationship applies to all group members. may be empty. The relationship applies to all group members. Each group is
Each group is identified by a group name. The group name is unique identified by a group name. The group name must be globally unique.
across the Internet.
Streams belong to the same group if they have the same GroupName in Streams belong to the same group if they have the same GroupName in the
the GroupName field of the Group parameter. The relationship is GroupName field of the Group parameter, see Section 10.3.2. The relationship
defined by the Relationship field. Group membership must be specified is defined by the Relationship field. Group membership must be specified at
at stream creation time and persists for the whole stream lifetime. A stream creation time and persists for the whole stream lifetime. A single
single stream may belong to multiple groups. stream may belong to multiple groups.
The ST agent that creates a new group is called group initiator. Any The ST agent that creates a new group is called group initiator. Any ST
ST agent can be a group initiator. The initiator allocates the agent can be a group initiator. The initiator allocates the GroupName and
GroupName and the Relationship among group members. The initiator may the Relationship among group members. The initiator may or may not be the
or may not be the origin of a stream belonging to the group. The origin of a stream belonging to the group. GroupName generation is described
group name has to be generated as described in Section 6.1. in Section 8.2.
Relationships defined by this version of the protocol are listed in
Section 6.2.
6.1 Group Name Generator 7.1 Basic Group Relationships
The GroupName includes a 16-bit unique identifier, a 32-bit IP This version of ST defines four basic group relationships. An ST2+
address, and a 32-bit creation timestamp. It is defined in Section implementation must support all four basic relationships. Adherence to
6.3. An ST implementation has to provide a group name generator specified relationships are usually best effort. The basic relationships
facility, so that an application or higher layer protocol can obtain are described in detail below in Section 7.1.1 - Section 7.1.4.
a unique GroupName from the ST layer. This is a mechanism for the
application to request the allocation of a GroupName that is
independent of the request to create a stream. The GroupName is used
by the application or higher layer protocol when creating the streams
that are to be part of the group.
For instance, the following two functions could be made available: 7.1.1 Bandwidth Sharing
o AllocateGroupName() -> result, GroupName Streams associated with the same group share the same network bandwidth. The
intent is to support applications such as audio conferences where, of all
participants, only some are allowed to speak at one time. In such a
scenario, global bandwidth utilization can be lowered by allocating only
those resources that can be used at once, e.g. it is sufficient to reserve
bandwidth for a small set of audio streams.
o ReleaseGroupName() -> result The basic concept of a shared bandwidth group is that the LRM will allocate
up to some specified multiplier of the most demanding stream that it knows
about in the group. The LRM will allocate resources incrementally, as stream
setup requests are received, until the total group requirements are
satisfied. Subsequent setup requests will share the group's resources and
will not need any additional resources allocated. The procedure will result
in standard allocation where only one stream in a group traverses a host,
and shared allocations where multiple streams traverse a host.
6.2 Basic ST Relationships To illustrate, let's call the multiplier mentioned above "N", and the most
demanding stream that an agent knows about in a group Bmax. For an
application that intends to allow three participants to speak at the same
time, N has a value of three and each LRM will allocate for the group an
amount of bandwidth up to 3*Bmax even when there are many more steams in the
group. The LRM will reserve resources incrementally, per stream request,
until N*Bmax resources are allocated. Each host may be traversed by a
different set and number of streams all belonging to the same group.
This version of ST defines four basic relationships. An ST2+ An ST agent receiving a stream request presents the LRM with all necessary
implementation must support all four basic relationships. The basic group information, see also Section 4.5.2.2. If maximum bandwidth, N*Bmax,
relationships are described in detail below in Section 6.2.1 - for the group has already been allocated and a new stream with a bandwidth
Section 6.2.4. demand less than Bmax is being established, the LRM won't allocate any
further bandwidth.
ST provides the means to define new relationships as the need for If there is less than N*Bmax resources allocated, the LRM will expand the
them becomes clear in the future. This can be done by assigning one resources allocated to the group by the amount requested in the new
of the unused bits of the Relationship field of the Group parameter. FlowSpec, up to N*Bmax resources. The LRM will update the FlowSpec based on
what resources are available to the stream, but not the total resources
allocated for the group.
The next sections describe the four basic relationships. It should be noted that ST agents and LRMs become aware of a group's
requirements only when the streams belonging to the group are created. In
case of the bandwidth sharing relationship, an application should attempt to
establish the most demanding streams first to minimize stream setup efforts.
If on the contrary the less demanding streams are built first, it will be
always necessary to allocate additional bandwidth in consecutive steps as
the most demanding streams are built. It is also up to the applications to
coordinate their different FlowSpecs and decide upon an appropriate value
for N.
6.2.1 Bandwidth Sharing 7.1.2 Fate Sharing
Streams belonging to this group share the same network bandwidth. Streams belonging to this group share the same fate. If a stream is deleted,
This is intended to support applications as audio conferences where, the other members of the group are also deleted. This is intended to support
of all participants, only some at a time are allowed to speak. In stream preemption by indicating which streams are mutually related. If
such a scenario, global bandwidth utilization can be optimized, e.g. preemption of multiple streams is necessary, this information can be used by
it is sufficient to reserve bandwidth for a small set of audio the LRM to delete a set of related streams, e.g. with impact on a single
streams. application, instead of making a random choice with the possible effect of
interrupting several different applications. This attribute does not apply
to normal stream shut down, i.e. ReasonCode (ApplDisconnect). On normal
disconnect, other streams belonging to such groups remain active.
The N parameter indicates for how many streams at the same time This relationship provides a hint on which streams should be preempted.
bandwidth should be allocated. An ST agent allocates N times the Still, the LRM responsible for the preemption is not forced to behave
bandwidth required by the most demanding stream in the group, say accordingly, and other streams could be preempted first based on different
Bmax. If the application intends for instance to allow three criteria.
participants to speak at the same time, N has a value of three and
the ST agent will allocate for the group an amount of bandwidth equal
to 3*Bmax.
This mechanism does not always allocate an optimal amount of 7.1.3 Route Sharing
bandwidth (as when a stream requires 4 Mbits/s and all the other
streams in the same group require 1 Mbits/s only: N=3 causes the
allocation of 12 Mbits/s). However, it is simple to implement and it
works well with streams that have homogeneous requirements. An
alternative would be to keep track of the single streams requirements
and allocate the exact amount of bandwidth.
An ST agent always attempts to reserve N*Bmax bandwidth. If less Streams belonging to this group share the same paths as much as is possible.
bandwidth than N*Bmax is available, the new stream is not built. If This can be desirable for several reasons, e.g. to exploit the same
bandwidth for the group has already been allocated and a new stream allocated resources or in the attempt to maintain the transmission order. An
with a bandwidth demand inferior to Bmax is being established, the ST ST agent attempts to select the same path although the way this is
agent, depending on the local implementation, may not need to contact implemented depends heavily on the routing algorithm which is used.
the local resource manager and it can proceed directly with the
stream setup.
Note that ST agents become aware of a group's requirements only when If the routing algorithm is sophisticated enough, an ST agent can suggest
the streams belonging to the group are created. In case of the that a stream is routed over an already established path. Otherwise, it can
bandwidth sharing relationship, an application should attempt to ask the routing algorithm for a set of legal routes to the destination and
establish the most demanding streams first to minimize stream setup check whether the desired path is included in those feasible.
efforts. If on the contrary the less demanding streams are built
first, it will be always necessary to allocate additional bandwidth
in consecutive steps as the most demanding streams are built.
6.2.2 Fate Sharing Route sharing is a hint to the routing algorithm used by ST. Failing to
route a stream through a shared path should not prevent the creation of a
new stream or result in the deletion of an existing stream.
Streams belonging to this group share the same fate. If a stream is 7.1.4 Subnet Resources Sharing
deleted, the other members of the group are also deleted. This is
intended to support stream preemption by indicating which streams are
mutually related. If preemption of multiple streams is necessary,
this information can be used to delete a set of related streams, e.g.
with impact on a single application, instead of making a random
choice with the possible effect of interrupting several different
applications.
This relationship provides a hint on which streams should be This relationship provides a hint to the data link layer functions. Streams
preempted. Still, the entity responsible for the preemption is not belonging to this group may share the same MAC layer resources. As an
forced to behave accordingly, and other streams could be preempted example, the same MAC layer multicast address may be used for all the
first based on different criteria. streams in a given group. This mechanism allows for a better utilization of
MAC layer multicast addresses and it is especially useful when used with
network adapters that offer a very small number of MAC layer multicast
addresses.
6.2.3 Route Sharing 7.2 Relationships Orthogonality
Streams belonging to this group share the same paths. This can be The four basic relationships, as they have been defined, are orthogonal.
desirable for several reasons, e.g. to exploit the same allocated This means, any combinations of the basic relationships are allowed. For
resources or in the attempt to maintain the transmission order. An ST instance, let's consider an application that requires full-duplex service
agent attempts to select the same path although the way this is for a stream with multiple targets. Also, let's suppose that only N targets
implemented depends heavily on the routing algorithm which is used. are allowed to send data back to the origin at the same time. In this
scenario, all the reverse streams could belong to the same group. They could
be sharing both the paths and the bandwidth attributes. The Path&Bandwidth
sharing relationship is obtained from the basic set of relationships. This
example is important because it shows how full-duplex service can be
efficiently obtained in ST.
If the routing algorithm is sophisticated enough, an ST agent can 8 Ancillary Functions
suggest that a stream is routed over an already established path.
Otherwise, it can ask the routing algorithm for a set of legal routes
to the destination and check whether the desired path is included in
those feasible.
Route sharing is a hint to the routing algorithm used by ST. Failing Certain functions are required by ST host and intermediate agent
to route a stream through the shared path does not normally cause the implementations. Such functions are described in this section.
deletion of the stream: the stream is built over an alternative path
whenever possible.
6.2.4 Subnet Resources Sharing 8.1 Stream ID Generation
Streams belonging to this group share the same MAC layer subnetwork The stream ID, or SID, is composed of 16-bit unique identifier and the
addresses. As an example, the same MAC layer multicast address can be stream origin's 32-bit IP address. Stream IDs must be globally unique. The
used for all the streams in a given group. This mechanism allows for specific definition and format of the 16 -bit field is left to the
a better utilization of MAC layer multicast addresses and it is implementor. This field is expected to have only local significance.
especially useful when used with network adapters that offer a very
small number of MAC layer multicast addresses.
This relationship provides a hint to the data link layer functions. An ST implementation has to provide a stream ID generator facility, so that
an application or higher layer protocol can obtain a unique IDs from the ST
layer. This is a mechanism for the application to request the allocation of
stream ID that is independent of the request to create a stream. The Stream
ID is used by the application or higher layer protocol when creating the
streams.
6.3 Relationships Orthogonality For instance, the following two functions could be made available:
The four basic relationships, as they have been defined, are
orthogonal. This means, any combinations of the basic relationships
are allowed. For instance, let's consider an application that
requires full-duplex service for a stream with multiple targets.
Also, let's suppose that only N targets are allowed to send data back
to the origin at the same time. In this scenario, all the reverse
streams could belong to the same group. They could be sharing both
the paths and the bandwidth. The Path&Bandwidth sharing relationship
is obtained from the basic set of relationships. This example is
important because it shows how full-duplex service can be obtained in
ST.
As new relationships are defined, it should be indicated whether they o AllocateStreamID() -> result, StreamID
are or not orthogonal with respect to the previously defined ones.
This will be reflected by illegal values for the Relationship field
of the Group parameter (see Section 10.3.3).
7 Ancillary Functions o ReleaseStreamID(StreamID) -> result
7.1 Stream IDs Generation 8.2 Group Name Generator
To Be Written GroupName generation is similar to Stream ID generation. The GroupName
includes a 16-bit unique identifier, a 32-bit creation timestamp, and a
32-bit IP address. Group names are globally unique. A GroupName includes the
creator's IP address, so this reduces a global uniqueness problem to a
simple local problem. The specific definitions and formats of the 16-bit
field and the 32-bit creation timestamp are left to the implementor. These
fields must be locally unique, and only have local significance.
7.2 Checksum Computation An ST implementation has to provide a group name generator facility, so that
an application or higher layer protocol can obtain a unique GroupName from
the ST layer. This is a mechanism for the application to request the
allocation of a GroupName that is independent of the request to create a
stream. The GroupName is used by the application or higher layer protocol
when creating the streams that are to be part of the group.
The standard Internet checksum algorithm is used for ST: "The For instance, the following two functions could be made available:
checksum field is the 16-bit one's complement of the one's complement
sum of all 16-bit words in the header. For purposes of computing the
checksum, the value of the checksum field is zero (0)." See
[RFC1071], [RFC1141], and [RFC791] for suggestions for efficient
checksum algorithms.
7.3 SCMP Reliability o AllocateGroupName() -> result, GroupName
The ST Control Message Protocol is made reliable through the use of o ReleaseGroupName(GroupName) -> result
retransmission when response is not received in a timely manner. In
general, when sending a SCMP messages which requires an ACK back, the
sending ST agent needs to set the Toxxxx timer (where xxxx is the
SCMP message type, e.g. ToConnect). If it does not receive an ACK
back before the Toxxxx timer expires, the ST agent should retransmit
the SCMP message. If no ACK has been received within Nxxxx
retransmissions, then a SCMP timeout condition occurs and the ST
agent enters its SCMP timeout recovery state. The actions performed
by the ST agent as the result of the SCMP timeout condition differ
for different SCMP message. In some cases (CONNECT,ACCEPT) the ST
agent handles the timeout by sending additional SCMP message
(REFUSE/DISCONNECT) to its neighbour ST agents (see Section 4.1.1 &
Section 4.1.2), while in other cases (REFUSE, DISCONNECT) it simply
gives up sine there is nothing else it can do.
For some SCMP messages (CONNECT,CHANGE) the sending ST agent also 8.3 Checksum Computation
expects a response back (ACCEPT/REFUSE) after ACK has been received.
For these cases, the ST agent needs to set the Rtoxxxx timer after it
receives the ACK. If it does not receive the appropriate response
back when Rtoxxxx expires, the ST agent updates its state data and
perform appropriate recovery action as described in other sections.
Timeout and retransmission algorithm is implementation dependent and The standard Internet checksum algorithm is used for ST: "The checksum field
it is outside the scope of this document. However, it must be is the 16-bit one's complement of the one's complement sum of all 16-bit
reasonable enough not to cause excessive retransmission of SCMP words in the header. For purposes of computing the checksum, the value of
message while maintain the robustness of the protocol. Algorithms on the checksum field is zero (0)." See [RFC1071], [RFC1141], and [RFC791] for
this subject are described in [WoHD95], [Jaco88], [KaPa87]. suggestions for efficient checksum algorithms.
7.4 Network MTU Discovery 8.4 Collecting Information From Neighbour ST Agent
At connection setup, the application at the origin asks the local ST The STATUS message can be used to collect information about neighbor ST
agent to create streams with certain QoS requirements. The local ST agents, streams the neighbour supports, and specific targets of streams the
agent fills out its network MTU value as part of the parameter in the neighbour supports. An agent receiving a STATUS message provides the
CONNECT message and forwards it to the next hop ST agents. Each ST requested information via a STATUS-RESPONSE message.
agent in the path checks to see if its network MTU is smaller than
the one specified in the CONNECT message and, if it is, the ST agent
updates the MTU in the CONNECT message accordingly. If the target
application decides to accept the stream, the ST agent at the target
copies the MTU value in the CONNECT message to appropriate field in
the ACCEPT message and sends it back to the application at the
origin. The MTU in the ACCEPT message is the minimum MTU of network
to that target. If the application has multiple targets then the
minimum MTU of the stream is the smallest MTU received from all the
ACCEPT messages. It is the responsibility of the application to
segment its PDUs according to the minimum MTU of the stream since no
data fragmentation is supported during the data transfer phase.
7.5 Packet Discarding on Network Congestion The STATUS message can be used to collect different information from a
neighbour. It can be used to:
TBD o identify a neighbour is ST capable. If an ST agent wishes to check
if a neighbour is ST capable, it should generate a STATUS message
with an SID which has all its fields set to zero. An agent
receiving a STATUS message with such SID should answer with a
STATUS-RESPONSE containing the same SID, and no other stream
information. The receiving ST agent must answer as soon as
possible to aid in Round Trip Time estimation, see Section 8.4;
7.6 IP Encapsulation of ST o obtain information on a particular stream. If an ST agent wishes to
check a neighbour's general information related to a specific
stream, it should generate a STATUS message containing the
stream's SID. An ST agent receiving such a message, will first
check to see if the stream is known. If not known, the receiving
ST agent sends a STATUS-RESPONSE containing the same SID, and
no other stream information. If the stream is known, the
receiving ST agent sends a STATUS-RESPONSE containing the
stream's SID, IPHops, FlowSpec, group membership (if any), and as
many targets as can be included in a single message as limited by
MTU, see Section 5.1.2. Note that all targets may not be included
in a response to a request for general stream information. If
information on a specific target in a stream is desired, the
mechanism described next should be used.
ST packets may be encapsulated in IP to allow them to pass through o obtain information on particular targets in a stream. If an ST agent
routers that don't support the ST Protocol. Of course, ST resource wishes to check a neighbour's information related to on or more
management is precluded over such a path, and packet overhead is specific targets of a specific stream, it should generate a
increased by encapsulation, but if the performance is reasonably STATUS message containing the stream's SID and a TargetList
predictable this may be better than not communicating at all. parameter listing the relevant targets. An ST agent receiving
such a message, will first check to see if the stream and target
are known. If the stream is not known, the agent follows the
process described above. If both the stream and targets are
known, the agent responds with STATUS-RESPONSE containing the
stream's SID, IPHops, FlowSpec, group membership (if any), and
the requested targets that are known. If the stream is known but
the target is not, the agent responds with a STATUS-RESPONSE
containing the stream's SID, IPHops, FlowSpec, group membership
(if any), but no targets.
IP-encapsulated ST packets begin with a normal IP header. Most fields The specific formats for STATUS and STATUS-RESPONSE messages are defined in
of the IP header should be filled in according to the same rules that Section 10.4.12 and Section 10.4.13.
apply to any other IP packet. Three fields of special interest are:
o Protocol is 5 to indicate an ST packet is enclosed, as 8.5 Round Trip Time Estimation
opposed to TCP or UDP, for example. The assignment of protocol 5 to
ST is an arranged coincidence with the assignment of IP Version 5 to
ST [RFC1190].
o Destination Address is that of the next-hop ST agent. This SCMP is made reliable through use of retransmission when an expected
may or may not be the target of the ST stream. There may be an acknowledgment is not received in a timely manner. Timeout and
intermediate ST agent to which the packet should be routed to take retransmission algorithm is implementation dependent and it is outside the
advantage of service guarantees on the path past that agent. Such an scope of this document. However, it must be reasonable enough not to cause
intermediate agent would not be on a directly-connected network (or excessive retransmission of SCMP message while maintain the robustness of
else IP encapsulation wouldn't be needed), so it would probably not the protocol. Algorithms on this subject are described in [WoHD95],
be listed in the normal routing table. Additional routing mechanisms, [Jaco88], [KaPa87].
not defined here, will be required to learn about such agents.
o Type-of-Service may be set to an appropriate value for the Most existing algorithms are based on an estimation of the Round Trip Time
service being requested (usually low delay, high throughput, normal (RTT) between two hosts. With SCMP, if an ST agent wishes to have an
estimate of the RTT to and from a neighbor, it should generate a STATUS
message with an SID which has all its fields set to zero. An ST agent
receiving a STATUS message with such SID should immediately answer with a
STATUS-RESPONSE message containing the same SID, and no other stream
information. The time interval between the send and receive operations can
be used as an estimate of the RTT to and from the neighbor.
8.6 Network MTU Discovery
At connection setup, the application at the origin asks the local ST agent
to create streams with certain QoS requirements. The local ST agent fills
out its network MTU value in the MaxMsgSize parameter in the CONNECT message
and forwards it to the next-hop ST agents. Each ST agent in the path checks
to see if its network MTU is smaller than the one specified in the CONNECT
message and, if it is, the ST agent updates the MaxMsgSize in the CONNECT
message to it's network MTU. If the target application decides to accept the
stream, the ST agent at the target copies the MTU value in the CONNECT
message to appropriate field in the ACCEPT message and sends it back to the
application at the origin. The MaxMsgSize field in the ACCEPT message is the
minimum MTU of network to that target. If the application has multiple
targets then the minimum MTU of the stream is the smallest MaxMsgSize
received from all the ACCEPT messages. It is the responsibility of the
application to segment its PDUs according to the minimum MaxMsgSize of the
stream since no data fragmentation is supported during the data transfer
phase.
8.7 IP Encapsulation of ST
ST packets may be encapsulated in IP to allow them to pass through routers
that don't support the ST Protocol. Of course, ST resource management is
precluded over such a path, and packet overhead is increased by
encapsulation, but if the performance is reasonably predictable this may be
better than not communicating at all.
IP-encapsulated ST packets begin with a normal IP header. Most fields of the
IP header should be filled in according to the same rules that apply to any
other IP packet. Three fields of special interest are:
o Protocol is 5 to indicate an ST packet is enclosed, as opposed to
TCP or UDP, for example. The assignment of protocol 5 to ST is
an arranged coincidence with the assignment of IP Version 5 to ST
[RFC1190].
o Destination Address is that of the next-hop ST agent. This may or
may not be the target of the ST stream. There may be an
intermediate ST agent to which the packet should be routed to
take advantage of service guarantees on the path past that agent.
Such an intermediate agent would not be on a directly-connected
network (or else IP encapsulation wouldn't be needed), so it
would probably not be listed in the normal routing table.
Additional routing mechanisms, not defined here, will be required
to learn about such agents.
o Type-of-Service may be set to an appropriate value for the service
being requested (usually low delay, high throughput, normal
reliability). This feature is not implemented uniformly in the reliability). This feature is not implemented uniformly in the
Internet, so its use can't be precisely defined here. Internet, so its use can't be precisely defined here.
IP encapsulation adds little difficulty for the ST agent that IP encapsulation adds little difficulty for the ST agent that receives the
receives the packet. However, when IP encapsulation is performed it packet. However, when IP encapsulation is performed it must be done in both
must be done in both directions. To process the encapsulated IP directions. To process the encapsulated IP message, the ST agents simply
message, the ST agents simply remove the IP header and proceed with remove the IP header and proceed with ST header as usual.
ST header as usual.
The more difficult part is during setup, when the ST agent must The more difficult part is during setup, when the ST agent must decide
decide whether or not to encapsulate. If the next-hop ST agent is on whether or not to encapsulate. If the next-hop ST agent is on a remote
a remote network and the route to that network is through a router network and the route to that network is through a router that supports IP
that supports IP but not ST, then encapsulation is required. The ST but not ST, then encapsulation is required. The ST agents make encapsulation
agents make encapsulation decision based on information provided by decision based on information provided by routing function to indicate
routing function to indicate whether the routers in the path support whether the routers in the path support ST.
ST. It is outside the scope of this document to address routing
function and therefore neither its algorithm nor implementation is
specified here. ST assumes that appropriate routing algorithm exists
to which ST has access.
On forwarding, the (mostly constant) IP Header must be inserted and On forwarding, the (mostly constant) IP Header must be inserted and the IP
the IP checksum appropriately updated. checksum appropriately updated.
7.7 IP Multicasting Applications are informed about the number of IP hops traversed on the way
to the targets. The IPHops field value of the CONNECT message, see Section
10.4.4, is incremented at this purpose in case an ST agent uses IP
encapsulation to reach its next-hop. The value is then returned to the
origin in the IPHops field of the ACCEPT message, Section 10.4.1.
If an ST agent must use IP encapsulation to reach multiple next-hops 8.8 IP Multicasting
toward different targets, then either the packet must be replicated
for transmission to each next-hop, or IP multicasting may be used if
it is implemented in the next-hop ST agents and in the intervening IP
routers.
When the stream is established, the collection of next-hop ST agents If an ST agent must use IP encapsulation to reach multiple next-hops toward
must be set up as an IP multicast group. The ST agent must allocate different targets, then either the packet must be replicated for
appropriate IP multicast address (see Section 10.3.4) and fill that transmission to each next-hop, or IP multicasting may be used if it is
address in the IPMulticastAddress field of the CONNECT message. The implemented in the next-hop ST agents and in the intervening IP routers.
IP multicast address in the CONNECT message is used to inform the
next hop ST agents that they should join the multicast group to
receive subsequent PDUs. Obviously, the CONNECT message itself must
be sent using unicast. The next hop ST agents must be able to receive
on the specified multicast address in order to accept the connection.
The following permanent IP multicast addresses have been assigned to When the stream is established, the collection of next-hop ST agents must be
ST: set up as an IP multicast group. The ST agent must allocate appropriate IP
multicast address (see Section 10.3.3) and fill that address in the
IPMulticastAddress field of the CONNECT message. The IP multicast address in
the CONNECT message is used to inform the next-hop ST agents that they
should join the multicast group to receive subsequent PDUs. Obviously, the
CONNECT message itself must be sent using unicast. The next-hop ST agents
must be able to receive on the specified multicast address in order to
accept the connection.
224.0.0.7 All ST routers If the next-hop ST agent can not receive on the specified multicast address,
it sends a REFUSE message with ReasonCode (BadMcastAddress). Upon receiving
the REFUSE, the upstream agent can choose to retry with a different
multicast address. Alternatively, it can choose to loose the efficiency of
multicast and use unicast delivery.
The following permanent IP multicast addresses have been assigned to ST:
224.0.0.7 All ST routers
224.0.0.8 All ST hosts 224.0.0.8 All ST hosts
In addition, a block of transient IP multicast addresses, 224.1.0.0 - In addition, a block of transient IP multicast addresses, 224.1.0.0 -
224.1.255.255, has been allocated for ST multicast groups. Note that 224.1.255.255, has been allocated for ST multicast groups. For instance, the
in the case of Ethernet, an ST multicast address of "224.1.cc.dd" following two functions could be made available:
maps to an Ethernet multicast address of "01:00:5E:01:cc:dd", see
[RFC1112].
7.8 Routing
ST requires access to routing information in order to select a path o AllocateMcastAddr() -> result, McastAddr
from an origin to the destination(s). However, routing is considered
to be a separate issue and neither the routing algorithm nor its
implementation is specified here. ST should operate equally well with
any reasonable routing algorithm.
While ST may be capable of using several types of information that o ListenMcastAddr(McastAddr) -> result
are not currently available, the minimal information required is that
provided by IP, namely the ability to find an interface and next hop
router for a specified IP destination address and Type of Service.
Methods to make more information available and to use it are left for
further study. For initial ST implementations, any routing
information that is required but not automatically provided will be
assumed to be manually configured into the ST agents.
8 FlowSpec o ReleaseMcastAddr(McastAddr) -> result
The FlowSpec is used to convey stream service requirements end-to- 9 The ST2 Flow Specification
end. The contents of the FlowSpec are transparent to the ST agents.
An ST agent extracts the FlowSpec from the correspondent incoming
SCMP message and passes it to the LRM as required. The LRM updates
the FlowSpec values based on the amount of resources that it has
allocated to the stream.
8.1 FlowSpec Versions This section defines the ST2 flow specification. The flow specification
contains the user application requirements in terms of quality of service.
Its contents are transparent to the setup protocol. The setup protocol
carries the flow specification as part of the FlowSpec parameter, which is
described in Section 10.3.1.
ST is not dependent on a particular FlowSpec format and it is ST2 is not dependent on a particular flow specification format and it is
expected that other versions of the FlowSpec than those introduced expected that other versions of the flow specification will be needed in the
below in this section will be needed in the future. Different future. Different flow specification formats are distinguished by the value
FlowSpec formats are distinguished by the value of the Version field. of the Version field of the FlowSpec parameter, see Section 10.3.1. A single
The following values are reserved: stream is always associated with a single flow specification format, i.e.
0 - Null FlowSpec /* mandatory */ the Version field is consistent throughout the whole stream. The following
Version field values are defined:
0 - Null FlowSpec /* must be supported */
1 - ST Version 1 1 - ST Version 1
2 - ST Version 1.5 2 - ST Version 1.5
3 - RFC 1190 FlowSpec 3 - RFC 1190 FlowSpec
4 - HeiTS FlowSpec 4 - HeiTS FlowSpec
5 - BerKom FlowSpec 5 - BerKom FlowSpec
6 - RFC 1363 FlowSpec 6 - RFC 1363 FlowSpec
7 - ST2+ FlowSpec /* must be supported */
7 - ST2+ FlowSpec /* mandatory */ FlowSpecs version #0 and #7 have to be supported by ST2+ implementations.
Version numbers in the range 1-6 indicate flow specifications are currently
used in existing ST2 implementations. Values in the 128-256 range are
reserved for private and experimental use.
A single stream is always associated to a single FlowSpec format. 9.1 FlowSpec Version #0 - (Null FlowSpec)
Changes to the FlowSpec are also relative to the same FlowSpec
format, i.e. the value of the Version field cannot be changed during
the lifetime of the stream.
8.2 The Null FlowSpec (#0) The flow specification identified by a #0 value of the Version field is
called the Null FlowSpec. This flow specification causes no resources to be
allocated. It is ignored by the LRMs. Its contents are never updated. Stream
setup takes place in the usual way leading to successful stream
establishment, but no resources are actually reserved.
The FlowSpec identified by a value of 0 for its Version field is The purpose of the Null FlowSpec is that of facilitating interoperability
called the "Null FlowSpec". An ST agent that receives the Null tests by allowing streams to be built without actually allocating the
FlowSpec always assumes that sufficient resources for the stream are correspondent amount of resources. The Null FlowSpec may also be used for
available. The Null FlowSpec fields values are never updated. Stream testing and debugging purposes.
setup takes place in the usual way, but no resources are actually
reserved.
The main purpose of the Null FlowSpec is that of facilitating The Null FlowSpec comprises the 4-byte FlowSpec parameter only, see Section
interoperability tests by allowing streams to be built without 10.3.1. The third byte (Version field) must be set to 0.
actually allocating the correspondent amount of resources. The Null
FlowSpec may also be used for testing and debugging purposes.
The complete format is specified in Section 10.3.2. 9.2 FlowSpec Version #7 - ST2+ FlowSpec
8.3 The ST Current FlowSpec (#7) The flow specification identified by a #7 value of the Version field is the
ST2+ FlowSpec, to be used in the current version of ST2. It allows the user
applications to express their real-time requirements in the form of a QoS
class, precedence, and 3 basic QoS parameters:
FlowSpec #7 is the FlowSpec to be used by the current version of ST. o message size,
It contains values for 3 basic QoS parameters: message size, o message rate,
throughput, and delay. Also, it is possible to specify a QoS class,
e.g. guaranteed. Each parameter has to be expressed via a set of
values:
o the "desired" values are assigned by the application and o end-to-end delay.
never changed by the LRM
o the "limit" values are assigned by the application and never The QoS class indicates what kind of QoS guarantees are expected by the
changed by the LRM application, e.g. strict guarantees or predictive, see Section 9.2.1. QoS
parameters are expressed via a set of values:
o the "actual" values indicate the guarantees that the system o the "desired" values indicate the QoS desired by the application.
is able to provide. They are updated by the LRM at each node. The These values are assigned by the application and never modified by
"actual" values are always bounded by the "limit" values. the LRM.
8.3.1 Qos Classes o the "limit" values indicate the lowest QoS the application is
willing to accept. These values are also assigned by the
application and never modified by the LRM.
We also define two QoS classes: o the "actual" values indicate the QoS that the system is able to
provide. They are updated by the LRM at each node. The "actual"
values are always bounded by the "limit" and "desired" values.
1. QOS_GUARANTEED 9.2.1 QoS Classes
2. QOS_PREDICTIVE Two QoS classes are defined:
o The QOS_GUARANTEED service class implies that the negotiated 1 - QOS_PREDICTIVE /* QoSClass field value = 0x01, must be supported*/
QoS for the stream is never violated during the data transfer. For
instance, the desired rate is the peak rate for the transmission.
This may sometimes lead to overbooking of resources, but it provides
strict real-time guarantees.
o The QOS_PREDICTIVE service class implies that the negotiated 2 - QOS_GUARANTEED /* QoSClass field value = 0x10, optional */
QoS may be violated for short time intervals. Reservations are done
for the average case as opposite to the peak case required by the
QOS_GUARANTEED service class.
If a LRM that doesn't support class QOS_PREDICTIVE (QOS_GUARANTEED) o The QOS_PREDICTIVE class implies that the negotiated QoS may be
receives a FlowSpec containing a QOS_PREDICTIVE (QOS_GUARANTEED) violated for short time intervals during the data transfer. An
class, it informs the local ST agent. The ST agent may try different application has to provide values that take into account the
paths or delete the correspondent portion of the stream with average case, e.g. the "desired" message rate is the average rate
ReasonCode (QoSClassUnknown). for the transmission. Reservations are done for the average
case as opposite to the peak case required by the QOS_GUARANTEED
service class. This QoS class must be supported by all
implementations.
8.3.2 Maximum Message Size o The QOS_GUARANTEED class implies that the negotiated QoS for the
stream is never violated during the data transfer. An
application has to provide values that take into account the
worst possible case, e.g. the "desired" message rate is the peak
rate for the transmission. As a result, sufficient resources to
handle the peak rate are reserved. This strategy may lead to
overbooking of resources, but it provides strict real-time
guarantees. Support of this QoS class is optional.
This parameter is expressed in bytes. It represents the maximum size If a LRM that doesn't support class QOS_GUARANTEED receives a FlowSpec
allowed for messages sent as part of the stream. The LRM first checks containing QOS_GUARANTEED class, it informs the local ST agent. The ST agent
whether it is possible to get the value desired by the application may try different paths or delete the correspondent portion of the stream as
(DesMaxSize). If not, it updates the actual value (ActMaxSize) with described in Section 5.5.3, i.e. ReasonCode (FlowSpecError).
the available size unless this value is inferior to the minimum
allowed by the application (LimitMaxSize), in which case it informs 9.2.2 Precedence
the local ST agent that it is not possible to build the stream along
Precedence is the importance of the connection being established. Zero
represents the lowest precedence. In general, the distinction between
precedence and priority is that precedence specifies streams that are
permitted to take previously committed resources from another stream, while
priority identifies those PDUs that a stream is most willing to have
dropped.
9.2.3 Maximum Data Size
This parameter is expressed in bytes. It represents the maximum amount of
data, excluding ST and other headers, allowed to be sent in a messages as
part of the stream. The LRM first checks whether it is possible to get the
value desired by the application (DesMaxSize). If not, it updates the actual
value (ActMaxSize) with the available size unless this value is inferior to
the minimum allowed by the application (LimitMaxSize), in which case it
informs the local ST agent that it is not possible to build the stream along
this path. this path.
8.3.3 Rate or Throughput 9.2.4 Message Rate
This parameter is expressed in bytes/seconds. It represents the This parameter is expressed in messages/seconds. It represents the
transmission rate for the stream. The LRM first checks whether it is transmission rate for the stream. The LRM first checks whether it is
possible to get the value desired by the application (DesRate). If possible to get the value desired by the application (DesRate). If not, it
not, it updates the actual value (ActRate) with the available rate updates the actual value (ActRate) with the available rate unless this value
unless this value is inferior to the minimum allowed by the is inferior to the minimum allowed by the application (LimitRate), in which
application (LimitRate), in which case it informs the local ST agent case it informs the local ST agent that it is not possible to build the
that it is not possible to build the stream along this path. stream along this path.
8.3.4 Maximum Delay and Delay Jitter 9.2.5 Delay and Delay Jitter
This parameter is expressed in milliseconds. It represents the The delay parameter is expressed in milliseconds. It represents the maximum
maximum end-to-end for the stream. The LRM first checks whether it is end-to-end delay for the stream. The LRM first checks whether it is possible
possible to get the value desired by the application (DesMaxDelay). to get the value desired by the application (DesMaxDelay). If not, it
If not, it updates the actual value (ActMaxDelay) with the available updates the actual value (ActMaxDelay) with the available delay unless this
rate unless this value is greater than the maximum delay allowed by value is greater than the maximum delay allowed by the application
the application (LimitMaxDelay), in which case it informs the local (LimitMaxDelay), in which case it informs the local ST agent that it is not
ST agent that it is not possible to build the stream along this path. possible to build the stream along this path.
The LRM also updates the MinDelay field by adding the minimum The LRM also updates at each node the MinDelay field by incrementing it by
possible delay to the next- hop. Information on the minimum possible the minimum possible delay to the next-hop. Information on the minimum
delay allows to calculate another important QoS parameter, the delay possible delay allows to calculate the maximum end-to-end delay range, i.e.
jitter. the time interval in which a data packet can be received. This interval
should not exceed the DesMaxDelayRange value indicated by the application.
The maximum end-to-end delay range is an upper bound to the delay jitter.
The complete format is specified in Section 10.3.2. 9.2.6 ST2+ FlowSpec Format
9 ST State Machines The ST2+ FlowSpec has the following format:
To be separately published. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QosClass | Precedence | 0(unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxSize | LimitMaxSize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActMaxSize | DesMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitMaxDelay | ActMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxDelayRange | ActMinDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 ST Protocol Data Units Figure 9: The ST2+ FlowSpec.
All ST packets arrive at the same Network Service Access Point (NSAP) The LRM modifies only "actual" fields, i.e. those beginning with "Act". The
that IP uses to receive IP datagrams, e.g., ST would use the same user application assignees values to all other fields.
ethertype (0x800) as does IP. The two types of packets are
distinguished by the IP Version Number field, i.e. the first four (4)
bits of the packet; IP currently uses a value of 4, while ST has been
assigned the value 5 (see [RFC791]). There is no requirement for
compatibility between IP and ST packet headers beyond the first four
bits.
The ST PDUs sent between ST agents consist of an ST Header o QoSClass indicates which of the two defined classes of service
encapsulating either a higher layer PDU or an ST Control Message. applies. The two classes are: QOS_PREDICTIVE (QoSClass = 1) and
Data packets are distinguished from control messages via the D-bit QOS_GUARANTEED (QoSClass = 2).
(bit 8) in the ST header.
The ST Header also includes an ST Version Number, a total length o Precedence indicates the stream's precedence. Zero represents the
field, a header checksum, a unique id, and the stream origin 32-bit lowest precedence.
IP address. The unique id and the stream origin 32-bit IP address
form the stream id (SID). This is shown in Figure 8. Please refer to
Section 13 for an explanation of the notation.
Figure 8: ST Header o DesRate is the desired transmission rate for the stream in
messages/second. This field is set by the origin and is not
modified by intermediate agents.
o ST is the IP Version Number assigned to identify ST packets. o LimitRate is the minimum acceptable transmission rate in
The value for ST is 5. messages/second. This field is set by the origin and is not
modified by intermediate agents.
o Ver is the ST Version Number. The value for the current ST2+ o ActRate is the actual transmission rate allocated for the stream in
version is 3. messages/second. Each agent updates this field with the available
rate unless this value is less than LimitRate, in which case a
REFUSE is generated.
o D (bit 8) is set to 1 in all ST data packets and to 0 in all o DesMaxSize is the desired maximum data size in bytes that will be
SCMP control messages. sent in a message in the stream. This field is set by the origin.
o Pri (bits 9-11) is the packet-drop priority field, to be used o LimitMaxSize is the minimum acceptable data size in bytes. This
as described in Section 7.5. field is set by the origin
o TotalBytes is the length, in bytes, of the entire ST packet, o ActMaxSize is the actual maximum data size that may be sent in a
it includes the ST Header but does not include any local network message in the stream. This field is updated by each agent based
headers or trailers. In general, all length fields in the ST Proto- on MTU and available resources. If available maximum size is
col are in units of bytes. less than LimitMaxSize, the connection must be refused
o HeaderChecksum covers only the ST Header (12 bytes). The ST o DesMaxDelay is the desired maximum end-to-end delay for the stream
Protocol uses 16-bit checksums here in the ST Header and in each in milliseconds. This field is set by the origin
Control Message. For checksum computation, see Section 7.2.
o UniqueID is the first element of the stream id (SID). It is o LimitMaxDelay is the upper-bound of acceptable end-to-end delay
locally unique at the stream origin, see Section 7.1. for the stream in milliseconds. This field is set by the origin.
o OriginIPAddress is the second element of the SID. It is the o ActMaxDelay is the maximum end-to-end delay that will be seen by
32-bit IP address of the stream origin, see Section 7.1. data in the stream. Each ST agent adds to this field the maximum
delay that will be introduced by the agent, including transmission
time to the next-hop ST agent. If the actual maximum exceeds
LimitMaxDelay, then the connection is refused.
Bits 12-15 must be set to zero (0) in the current ST version. In the o DesMaxDelayRange is the desired maximum delay range that may be
future, it is possible that this 4-bit field will be used for encountered end-to-end by stream data in milliseconds. This value
substream filtering, e.g., as described in [WoHD95]. is set by the origin.
10.1 ST Data Packets o ActMinDelay is the actual minimum end-to-end delay that will be
encountered by stream data in milliseconds. Each ST agent adds to
this field the minimum delay that will be introduced by the agent,
including transmission time to the next-hop ST agent. The delay
range for the stream can be calculated from the actual maximum and
minimum delay fields. It is expected that the range will be
important to some applications.
10 ST2 Protocol Data Units Specification
ST packets whose D-bit is non-zero are data packets. Their 10.1 Data PDU
interpretation is a matter for the higher layer protocols and
consequently is not specified here. The data packets are not
protected by an ST checksum and will be delivered to the higher layer
protocol even with errors. ST agents will not pass data packets over
a new hop whose setup is not complete.
10.1.1 Stream ID IP and ST packets can be distinguished by the IP Version Number field, i.e.
the first four (4) bits of the packet; IP currently uses a value of 4, while
ST has been assigned the value 5 (see [RFC791]). There is no requirement for
compatibility between IP and ST packet headers beyond the first four bits.
The UniqueID and OriginIPAddress fields form the Stream ID (SID), The ST PDUs sent between ST agents consist of an ST Header encapsulating
which is used by the ST agents to identify which stream the data either a higher layer PDU or an ST Control Message. Data packets are
packets belong to. Within the same stream, the same SID is used in distinguished from control messages via the D-bit (bit 8) in the ST header.
data packets and control messages.
NOTE: In some exceptional situations, e.g. usually due to a crash and The ST Header also includes an ST Version Number, a total length field, a
subsequent reboot, it is possible that an ST agent receives a data header checksum, a unique id, and the stream origin 32-bit IP address. The
packet belonging to a stream of which the ST agent has lost state unique id and the stream origin 32-bit IP address form the stream id (SID).
information. In this case, the ST agent is not able to forward the This is shown in Figure 10. Please refer to Section 10.6 for an explanation
packet and has to discard it. Since SIDs include the 32-bit IP of the notation.
address of the stream origin, it is possible for the ST agent to
disconnect from the stream.
10.2 ST Control Messages 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST=5 | Ver=3 |D| Pri | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HeaderChecksum | UniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCMP control messages are exchanged between neighbor ST agents using Figure 10: ST Header
a D-bit of zero (0). The control protocol follows a request-response
model with all requests expecting responses. Retransmission after
timeout (see Section 7.3) is used to allow for lost or ignored
messages. Control messages do not extend across packet boundaries; if
a control message is too large for the MTU of a hop, its information
is partitioned and a control message per partition is sent (see
Section 3.1.2.2). All control messages have the following format:
Figure 9: ST Control Message Format o ST is the IP Version Number assigned to identify ST packets. The
value for ST is 5.
o Ver is the ST Version Number. The value for the current ST2+ version
is 3.
o D (bit 8) is set to 1 in all ST data packets and to 0 in all SCMP
control messages.
o Pri (bits 9-11) is the packet-drop priority field with zero (0)
being lowest priority and seven the highest. The field is to be
used as described in Section 3.2.2.
o TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header but does not include any local network
headers or trailers. In general, all length fields in the ST
Protocol are in units of bytes.
o HeaderChecksum covers only the ST Header (12 bytes). The ST Protocol
uses 16-bit checksums here in the ST Header and in each Control
Message. For checksum computation, see Section 8.3.
o UniqueID is the first element of the stream ID (SID). It is locally
unique at the stream origin, see Section 8.1.
o OriginIPAddress is the second element of the SID. It is the 32-bit
IP address of the stream origin, see Section 8.1.
Bits 12-15 must be set to zero (0) in the current ST version and are
reserved for future use, e.g., as described in [WoHD95].
10.1.1 ST Data Packets
ST packets whose D-bit is non-zero are data packets. Their interpretation is
a matter for the higher layer protocols and consequently is not specified
here. The data packets are not protected by an ST checksum and will be
delivered to the higher layer protocol even with errors. ST agents will not
pass data packets over a new hop whose setup is not complete.
10.2 Control PDUs
SCMP control messages are exchanged between neighbor ST agents using a D-bit
of zero (0). The control protocol follows a request-response model with all
requests expecting responses. Retransmission after timeout (see Section
4.3) is used to allow for lost or ignored messages. Control messages do not
extend across packet boundaries; if a control message is too large for the
MTU of a hop, its information is partitioned and a control message per
partition is sent (see Section 5.1.2). All control messages have the
following format
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 | Options | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OpCodeSpecificData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ST Control Message Format
o OpCode identifies the type of control message. o OpCode identifies the type of control message.
o Options is used to convey OpCode-specific variations for a o Options is used to convey OpCode-specific variations for a control
control message. message.
o TotalBytes is the length of the control message, in bytes, o TotalBytes is the length of the control message, in bytes, including
including all OpCode specific fields and optional parameters. The all OpCode specific fields and optional parameters. The value is
value is always divisible by four (4). always divisible by four (4).
o Reference is a transaction number. Each sender of a request o Reference is a transaction number. Each sender of a request control
control message assigns a Refer- ence number to the message that is message assigns a Reference number to the message that is unique
unique with respect to the stream. The Reference number is used by with respect to the stream. The Reference number is used by the
the receiver to detect and discard duplicates. Each acknowledgment receiver to detect and discard duplicates. Each acknowledgment
carries the Reference number of the request being acknowledged. carries the Reference number of the request being acknowledged.
Reference zero (0) is never used, and Reference numbers are assumed Reference zero (0) is never used, and Reference numbers are
to be monotonically increasing with wraparound so that the older-than assumed to be monotonically increasing with wraparound so that the
and more-recent-than relations are well defined. older-than and more-recent-than relations are well defined.
o LnkReference contains the Reference field of the request o LnkReference contains the Reference field of the request control
control message that caused this request control message to be message that caused this request control message to be created. It
created. It is used in situations where a single request leads to is used in situations where a single request leads to multiple
multiple responses from the same ST agent. Examples are CONNECT and responses from the same ST agent. Examples are CONNECT and CHANGE
CHANGE mes- sages that are first acknowledged hop-by-hop and then messages that are first acknowledged hop-by-hop and then lead to
lead to an ACCEPT or REFUSE response from each target. an ACCEPT or REFUSE response from each target.
o SenderIPAddress is the 32-bit IP address of the network o SenderIPAddress is the 32-bit IP address of the network interface
interface that the ST agent used to send the control message. This that the ST agent used to send the control message. This value
value changes each time the packet is forwarded by an ST agent (hop- changes each time the packet is forwarded by an ST agent
by-hop). (hop-by-hop).
o Checksum is the checksum of the control message. Because the o Checksum is the checksum of the control message. Because the control
control messages are sent in packets that may be delivered with bits messages are sent in packets that may be delivered with bits in
in error, each control message must be checked before it is acted error, each control message must be