idnits 2.17.1 draft-ietf-st2-spec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 773 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 385: '...ified in this document, MUST implement...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1995) is 10634 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Cole81' on line 4753 looks like a reference -- Missing reference section? 'Cohe81' on line 4750 looks like a reference -- Missing reference section? 'DHHS92' on line 4760 looks like a reference -- Missing reference section? 'RFC1190' on line 4737 looks like a reference -- Missing reference section? 'DeAl92' on line 4756 looks like a reference -- Missing reference section? 'RFC1633' on line 4740 looks like a reference -- Missing reference section? 'VoHN93' on line 4744 looks like a reference -- Missing reference section? 'RFC1363' on line 4729 looks like a reference -- Missing reference section? 'RFC1071' on line 4704 looks like a reference -- Missing reference section? 'RFC1141' on line 4726 looks like a reference -- Missing reference section? 'RFC791' on line 4731 looks like a reference -- Missing reference section? 'WoHD95' on line 4711 looks like a reference -- Missing reference section? 'Jaco88' on line 4720 looks like a reference -- Missing reference section? 'KaPa87' on line 4723 looks like a reference -- Missing reference section? 'RFC1700' on line 4734 looks like a reference -- Missing reference section? 'RFC1112' on line 4708 looks like a reference -- Missing reference section? 'RFC1122' on line 4716 looks like a reference -- Missing reference section? 'Schu94' on line 4764 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ST Working Group L. Delgrossi and L. Berger 3 Internet-Draft March 1995 4 File: draft-ietf-st2-spec-03.txt Expires: July 1995 6 Internet Stream Protocol Version 2 (ST2) 8 Protocol Specification - Version ST2+ 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work in 21 progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract: 31 This memo contains a revised specification of the Internet STream 32 Protocol Version 2 (ST2). ST2 is an experimental resource reservation 33 protocol intended to provide end-to-end real-time guarantees over an 34 internet. It allows its applications to build multi-destination 35 simplex data streams with a desired quality of service. The revised 36 version of ST2 specified in this memo is called ST2+. 38 1 Introduction 6 39 1.1 What is ST2? 6 40 1.2 ST2 and IP 8 41 1.3 Protocol History 8 42 1.3.1 RFC1190 ST and ST2+ Major Differences 9 43 1.4 Supporting Modules for ST2 10 44 1.4.1 Data Transfer Protocol 11 45 1.4.2 Setup Protocol 11 46 1.4.3 Flow Specification 11 47 1.4.4 Routing Function 12 48 1.4.5 Local Resource Manager 12 49 1.5 ST2 Basic Concepts 14 50 1.5.1 Streams 14 51 1.5.2 Data Transmission 15 52 1.5.3 Flow Specification 16 53 1.6 Outline of This Document 17 55 2 ST2 User Service Description 18 56 2.1 Stream Operations and Primitive Functions 18 57 2.2 State Diagrams 20 58 2.3 State Transition Tables 23 60 3 The ST2 Data Transfer Protocol 23 61 3.1 Data Transfer with ST 24 62 3.2 ST Protocol Functions 25 63 3.2.1 Stream Identification 25 64 3.2.2 Packet Discarding based on Data Priority 25 66 4 SCMP Functional Description 25 67 4.1 Types of Streams 27 68 4.1.1 Stream Building 27 69 4.1.2 Knowledge of Receivers 27 70 4.2 Control PDUs 28 71 4.3 SCMP Reliability 29 72 4.4 Stream Options 30 73 4.4.1 No Recovery 30 74 4.4.2 Join Authorization Level 31 75 4.4.3 Record Route 31 76 4.4.4 User Data 31 77 4.5 Stream Setup 32 78 4.5.1 Information from the Application 32 79 4.5.2 Initial Setup at the Origin 32 80 4.5.2.1 Invoking the Routing Function 33 81 4.5.2.2 Reserving Resources 33 82 4.5.3 Sending CONNECT Messages 34 83 4.5.3.1 Empty Target List 34 84 4.5.4 CONNECT Processing by an Intermediate ST agent 34 85 4.5.5 CONNECT Processing at the Targets 34 86 4.5.6 ACCEPT Processing by an Intermediate ST agent 35 87 4.5.7 ACCEPT Processing by the Origin 36 88 4.5.8 REFUSE Processing by the Intermediate ST agent 36 89 4.5.9 REFUSE Processing by the Origin 36 90 4.5.10 Other Functions during Stream Setup 36 91 4.6 Modifying an Existing Stream 37 92 4.6.1 The Origin Adding New Targets 37 93 4.6.2 The Origin Removing a Target 38 94 4.6.3 A Target Joining a Stream 39 95 4.6.3.1 Router as Origin 40 96 4.6.4 A Target Deleting Itself 40 97 4.6.5 Changing a Stream's FlowSpec 41 98 4.7 Stream Tear Down 41 100 5 Exceptional Cases 42 101 5.1 Long ST Messages 42 102 5.1.1 Handling of Long Data Packets 42 103 5.1.2 Handling of Long Control Packets 42 104 5.2 Timeout Failures 43 105 5.2.1 Failure due to ACCEPT Acknowledgment Timeout 44 106 5.2.2 Failure due to CHANGE Acknowledgment Timeout 44 107 5.2.3 Failure due to CHANGE Response Timeout 44 108 5.2.4 Failure due to CONNECT Acknowledgment Timeout 44 109 5.2.5 Failure due to CONNECT Response Timeout 45 110 5.2.6 Failure due to DISCONNECT Acknowledgment Timeout 45 111 5.2.7 Failure due to JOIN Acknowledgment Timeout 45 112 5.2.8 Failure due to JOIN Response Timeout 45 113 5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout 45 114 5.2.10 Failure due to NOTIFY Acknowledgment Timeout 46 115 5.2.11 Failure due to REFUSE Acknowledgment Timeout 46 116 5.2.12 Failure due to STATUS Response Timeout 46 117 5.3 Setup Failures due to Routing Failures 46 118 5.3.1 Path Convergence 47 119 5.3.2 Other Cases 47 120 5.4 Problems due to Routing Inconsistency 48 121 5.5 Problems in Reserving Resources 49 122 5.5.1 Mismatched FlowSpecs 49 123 5.5.2 Unknown FlowSpec Version 49 124 5.5.3 LRM Unable to Process FlowSpec 50 125 5.5.4 Insufficient Resources 50 126 5.6 Problems Caused by CHANGE Messages 50 127 5.7 Unknown Targets in DISCONNECT and CHANGE 51 129 6 Failure Detection and Recovery 52 130 6.1 Failure Detection 52 131 6.1.1 Network Failures 52 132 6.1.2 Detecting ST Agents Failures 53 133 6.2 Failure Recovery 54 134 6.2.1 Problems in Stream Recovery 57 135 6.3 Stream Preemption 58 137 7 A Group of Streams 59 138 7.1 Basic Group Relationships 59 139 7.1.1 Bandwidth Sharing 59 140 7.1.2 Fate Sharing 60 141 7.1.3 Route Sharing 61 142 7.1.4 Subnet Resources Sharing 61 143 7.2 Relationships Orthogonality 61 145 8 Ancillary Functions 62 146 8.1 Stream ID Generation 62 147 8.2 Group Name Generator 62 148 8.3 Checksum Computation 63 149 8.4 Neighbour ST Agent Identification and 63 150 Information Collection 151 8.5 Round Trip Time Estimation 64 152 8.6 Network MTU Discovery 64 153 8.7 IP Encapsulation of ST 65 154 8.8 IP Multicasting 66 156 9 The ST2+ Flow Specification 67 157 9.1 FlowSpec Version #0 - (Null FlowSpec) 68 158 9.2 FlowSpec Version #7 - ST2+ FlowSpec 68 159 9.2.1 QoS Classes 69 160 9.2.2 Precedence 69 161 9.2.3 Maximum Data Size 70 162 9.2.4 Message Rate 70 163 9.2.5 Delay and Delay Jitter 70 164 9.2.6 ST2+ FlowSpec Format 70 166 10 ST2 Protocol Data Units Specification 72 167 10.1 Data PDU 72 168 10.1.1 ST Data Packets 74 169 10.2 Control PDUs 74 170 10.3 Common SCMP Elements 75 171 10.3.1 FlowSpec 76 172 10.3.2 Group 76 173 10.3.3 MulticastAddress 77 174 10.3.4 Origin 78 175 10.3.5 RecordRoute 78 176 10.3.6 Target and TargetList 79 177 10.3.7 UserData 80 178 10.3.8 Handling of Undefined Parameters 81 179 10.4 ST Control Message PDUs 81 180 10.4.1 ACCEPT 81 181 10.4.2 ACK 83 182 10.4.3 CHANGE 84 183 10.4.4 CONNECT 84 184 10.4.5 DISCONNECT 86 185 10.4.6 ERROR 87 186 10.4.7 HELLO 88 187 10.4.8 JOIN 89 188 10.4.9 JOIN-REJECT 90 189 10.4.10 NOTIFY 91 190 10.4.11 REFUSE 92 191 10.4.12 STATUS 94 192 10.4.13 STATUS-RESPONSE 94 193 10.5 Suggested Protocol Constants 95 194 10.5.1 SCMP Messages 95 195 10.5.2 SCMP Parameters 96 196 10.5.3 ReasonCode 96 197 10.5.4 Timeouts and Other Constants 98 198 10.6 Data Notations 99 200 11 Security Considerations 100 202 12 Acknowledgments and Author's Addresses 100 204 13 References 101 205 1 Introduction 207 1.1 What is ST2? 209 The Internet Stream Protocol, Version 2 (ST2) is an experimental 210 connection-oriented internetworking protocol that operates at the same 211 layer as connectionless IP. It has been developed to support the 212 efficient delivery of data streams to single or multiple destinations 213 in applications that require guaranteed quality of service. ST2 is 214 part of the IP protocol family and serves as an adjunct to, not a 215 replacement for, IP. The main application areas of the protocol are 216 the real-time transport of multimedia data, e.g. digital audio and 217 video packet streams, and distributed simulation/gaming, across 218 internets. 220 ST2 can be used to reserve bandwidth for real-time streams across 221 network routes. This reservation, together with appropriate network 222 access and packet scheduling mechanisms in all nodes running the 223 protocol, guarantees a well-defined Quality of Service (QoS) to ST2 224 applications. It ensures that real-time packets are delivered within 225 their deadlines, that is, at the time where they need to be presented. 226 This facilitates a smooth delivery of data that is essential for time- 227 critical applications, but can typically not be provided by best- 228 effort IP communication. 230 DATA PATH CONTROL PATH 231 ========= ============ 232 Upper +------------------+ +---------+ 233 Layer | Application data | | Control | 234 +------------------+ +---------+ 235 | | 236 | V 237 | +-------------------+ 238 SCMP | | SCMP | | 239 | +-------------------+ 240 | | 241 V V 242 +-----------------------+ +------------------------+ 243 ST | ST | | | ST | | | 244 +-----------------------+ +------------------------+ 245 D-bit=1 D-bit=0 247 Figure 1: ST2 Data and Control Path 249 Just like IP, ST2 actually consists of two protocols: ST for the data 250 transport and SCMP, the Stream Control Message Protocol, for all 251 control functions. ST is simple and contains only a single PDU format 252 that is designed for fast and efficient data forwarding in order to 253 achieve low communication delays. SCMP, however, is more complex than 254 IP's ICMP. As with ICMP and IP, SCMP packets are transferred within ST 255 packets as shown in Figure 1. 257 +--------------------+ 258 | Conference Control | 259 +--------------------+ 260 +-------+ +-------+ | 261 | Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application 262 | Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer 263 +-------+ +-------+ | +-----+ +------+ +-----+ +-----+ 264 | | | | | | | 265 V V | | | | | ------------ 266 +-----+ +-----+ | | | | | 267 | PVP | | NVP | | | | | | 268 +-----+ +-----+ + | | | | 269 | \ | \ \ | | | | 270 | +-----|--+-----+ | | | | 271 | Appl.|control V V V V V 272 | ST data | +-----+ +-------+ +-----+ 273 | & control| | UDP | | TCP | ... | RTP | Transport 274 | | +-----+ +-------+ +-----+ Layer 275 | /| / | \ / / | / /| 276 |\ / | +------+--|--\-----+-/--|--- ... -+ / | 277 | \ / | | | \ / | / | 278 | \ / | | | \ +----|--- ... -+ | ----------- 279 | \ / | | | \ / | | 280 | V | | | V | | 281 | +------+ | | | +------+ | +------+ | 282 | | SCMP | | | | | ICMP | | | IGMP | | Internet 283 | +------+ | | | +------+ | +------+ | Layer 284 | | | | | | | | | 285 V V V V V V V V V 286 +-----------------+ +-----------------------------------+ 287 | STream protocol |->| Internet Protocol | 288 +-----------------+ +-----------------------------------+ 289 | \ / | 290 | \ / | 291 | X | ------------ 292 | / \ | 293 | / \ | 294 VV VV 295 +----------------+ +----------------+ 296 | (Sub-) Network |...| (Sub-) Network | (Sub-)Network 297 | Protocol | | Protocol | Layer 298 +----------------+ +----------------+ 300 Figure 2. Protocol Relationships 302 1.2 ST2 and IP 304 ST2 is designed to coexist with IP on each node. A typical distributed 305 multimedia application would use both protocols: IP for the transfer 306 of traditional data and control information, and ST2 for the transfer 307 of real-time data. Whereas IP typically will be accessed from TCP or 308 UDP, ST2 will be accessed via new end-to-end real-time protocols. The 309 position of ST2 with respect to the other protocols of the Internet 310 family is represented in Figure 2. 312 Both ST2 and IP apply the same addressing schemes to identify 313 different hosts. ST2 and IP packets differ in the first four bits, 314 which contain the internetwork protocol version number: number 5 is 315 reserved for ST2 (IP itself has version number 4). As a network layer 316 protocol, like IP, ST2 operates independently of its underlying 317 subnets. Existing implementations use ARP for address resolution, and 318 use the same Layer 2 SAPs as IP. 320 As a special function, ST2 messages can be encapsulated in IP packets. 321 This is represented in Figure 2 as a link between ST2 and IP. This link 322 allows ST2 messages to pass through routers which do not run ST2. 323 Resource management is typically not available for these IP route 324 segments. IP encapsulation is, therefore, suggested only for portions 325 of the network which do not constitute a system bottleneck. 327 In Figure 2, the RTP protocol is shown as an example of transport 328 layer on top of ST2. Others include the Packet Video Protocol (PVP) 329 [Cole81], the Network Voice Protocol (NVP) [Cohe81], and others such 330 as the Heidelberg Transport Protocol (HeiTP) [DHHS92]. 332 1.3 Protocol History 334 The first version of ST was published in the late 1970's and was used 335 throughout the 1980's for experimental transmission of voice, video, 336 and distributed simulation. The experience gained in these 337 applications led to the development of the revised protocol version 338 ST2. The revision extends the original protocol to make it more 339 complete and more applicable to emerging multimedia environments. The 340 specification of this protocol version is contained in Internet RFC 341 1190 which was published in October 1990 [RFC1190]. 343 With more and more developments of commercial distributed multimedia 344 applications underway and with a growing dissatisfaction at the 345 transmission quality for audio and video over IP in the MBONE, 346 interest in ST2 has grown over the last years. Companies have products 347 available incorporating the protocol. The BERKOM MMTS project of the 348 German PTT [DeAl92] uses ST2 as its core protocol for the provision of 349 multimedia teleservices such as conferencing and mailing. In addition, 350 implementations of ST2 for Digital Equipment, IBM, NeXT, Macintosh, 351 PC, Silicon Graphics, and Sun platforms are available. 353 In 1993, the IETF started a new working group on ST2 as part of ongoing 354 efforts to develop protocols that address resource reservation issues. 355 The group's mission was to clean up the existing protocol 356 specification to ensure better interoperability between the existing 357 and emerging implementations. It was also the goal to produce an 358 updated experimental protocol specification that reflected the 359 experiences gained with the existing ST2 implementations and 360 applications. Which led to the specification of the ST2+ protocol 361 contained in this document. 363 1.3.1 RFC1190 ST and ST2+ Major Differences 365 The protocol changes from RFC1190 were motivated by protocol 366 simplification and clarification, and codification of extensions in 367 existing implementations. This section provides a list of major 368 differences, and is probably of interest only to those who have 369 knowledge of RFC1190. The major differences between the versions are: 371 o Elimination of "Hop IDentifiers" or HIDs. HIDs added much complexity 372 to the protocol and was found to be a major impediment to 373 interoperability. HIDs have been replaced by globally unique 374 identifiers called "Stream IDentifiers" or SIDs. 376 o Elimination of a number of stream options. A number of options were 377 found to not be used by any implementation, or were thought to add 378 more complexity than value. These options were removed. Removed 379 options include: point-to-point, full-duplex, reverse charge, and 380 source route. 382 o Elimination of the concept of "subset" implementations. RFC1190 383 permitted subset implementations, to allow for easy implementation 384 and experimentation. This led to interoperability problems. Agents 385 implementing the protocol specified in this document, MUST implement 386 the full protocol. A number of the protocol functions are best- 387 effort. It is expected that some implementations will make more 388 effort than others in satisfying particular protocol requests. 390 o Clarification of the capability of targets to request to join a 391 steam. RFC1190 can be interpreted to support target requests, but 392 most implementors did not understand this and did not add support 393 for this capability. The lack of this capability was found to be a 394 significant limitation in the ability to scale the number of 395 participants in a single ST stream. This clarification is based on 396 work done by IBM Heidelberg. 398 o Separation of functions between ST and supporting modules. An effort 399 was made to improve the separation of functions provided by ST and 400 those provided by other modules. This is reflected in reorganization 401 of some text and some PDU formats. ST was also made FlowSpec 402 independent, although it does define a FlowSpec for testing and 403 interoperability purposes. 405 o General reorganization and re-write of the specification. This 406 document has been organized with the goal of improved readability 407 and clarity. Some sections have been added, and an effort was made 408 to improve the introduction of concepts. 410 1.4 Supporting Modules for ST2 412 ST2 is one piece of a larger mosaic. This section presents the overall 413 communication architecture and clarifies the role of ST2 with respect 414 to its supporting modules. 416 ST2 proposes a two-step communication model. In the first step, the 417 real-time channels for the subsequent data transfer are built. This is 418 called stream setup. It includes selecting the routes to the 419 destinations and reserving the correspondent resources. In the second 420 step, the data is transmitted over the previously established streams. 421 This is called data transfer. While stream setup does not have to be 422 completed in real-time, data transfer has stringent real-time 423 requirements. The architecture used to describe the ST2 communication 424 model includes: 426 o a data transfer protocol for the transmission of real-time data over 427 the established streams, 429 o a setup protocol to establish real-time streams based on the flow 430 specification, 432 o a flow specification to express user real-time requirements, 434 o a routing function to select routes in the Internet, 436 o a local resource manager to appropriately handle resources involved 437 in the communication. 439 This document defines a data protocol (ST), a setup protocol (SCMP), 440 and a flow specification (ST2+ FlowSpec). It does not define a routing 441 function and a local resource manager. However, ST2 assumes their 442 existence. 444 Alternative architectures are possible, see [RFC1633] for an example 445 alternative architecture that could be used when implementing ST2. 447 1.4.1 Data Transfer Protocol 449 The data transfer protocol defines the format of the data packets 450 belonging to the stream. Data packets are delivered to the targets 451 along the stream paths previously established by the setup protocol. 452 Data packets are delivered with the quality of service associated with 453 the stream. 455 Data packets contain a globally unique stream identifier that 456 indicates which stream they belong to. The stream identifier is also 457 known by the setup protocol, which uses it during stream 458 establishment. The data transfer protocol for ST2, known simply as ST, 459 is completely defined by this document. 461 1.4.2 Setup Protocol 463 The setup protocol is responsible for establishing, maintaining, and 464 releasing real-time streams. It relies on the routing function to 465 select the paths from the source to the destinations. At each host/ 466 router on these paths, it presents the flow specification associated 467 with the stream to the local resource manager. This causes the 468 resource managers to reserve appropriate resources for the stream. The 469 setup protocol for ST2 is called Stream Control Message Protocol, or 470 SCMP, and is completely defined by this document. 472 1.4.3 Flow Specification 474 The flow specification is a data structure including the ST2 475 applications' QoS requirements. At each host/router, it is used by the 476 local resource manager to appropriately handle resources so that such 477 requirements are met. Distributing the flow specification to all 478 resource managers along the communication paths is the task of the 479 setup protocol. However, the contents of the flow specification are 480 transparent to the setup protocol, which simply carries the flow 481 specification. Any operations on the flow specification, including 482 updating internal fields and comparing flow specifications are 483 performed by the resource managers. 485 This document defines a specific flow specification format that allows 486 for interoperability among existing ST2 implementations. 487 Implementations may support more than one flow specification format 488 and the means are provided to add new formats as they are defined in 489 the future. However, the flow specification format has to be 490 consistent throughout the stream, i.e. it is not possible to use 491 different flow specification formats for different parts of the same 492 stream. 494 1.4.4 Routing Function 496 The routing function is an external unicast route generation 497 capability. It provides the setup protocol with the path to reach each 498 of the desired destinations. The routing function is called on a hop- 499 by-hop basis and provides next-hop information. Once a route is 500 selected by the routing function, it persists for the whole stream 501 lifetime. The routing function may try to optimize based on the number 502 of targets, the requested resources, or use of local network multicast 503 or bandwidth capabilities. Alternatively, the routing function may 504 even be based on simple connectivity information. 506 The setup protocol is not necessarily aware of the criteria used by 507 the routing function to select routes. It works with any routing 508 function algorithm. The algorithm adopted is a local matter at each 509 host/router and different hosts/routers may use different algorithms. 510 The interface between setup protocol and routing function is also a 511 local matter and therefore it is not specified by this document. 513 This version of ST does not support source routing. It does support 514 route recording. It does include provisions that allow identification 515 of ST capable neighbours. Identification of remote ST hosts/routers is 516 not specifically addressed. 518 1.4.5 Local Resource Manager 520 At each host/router traversed by a stream, the Local Resource Manager 521 (LRM) is responsible for handling local resources. The LRM knows which 522 resources are on the system and what capacity they can provide. 523 Resources include: 525 o CPUs on end systems and routers to execute the application and 526 protocol software, 528 o main memory space for this software (as in all real-time systems, 529 code should be pinned in main memory, as swapping it out would have 530 detrimental effects on system performance), 532 o buffer space to store the data, e.g., communication packets, passing 533 through the nodes, 535 o network adapters, and 537 o transmission networks between the nodes. Networks may be as simple 538 as point-to-point links or as complex as switched networks such as 539 Frame Relay and ATM networks. 541 During stream setup and modification, the LRM is presented by the 542 setup protocol with the flow specification associated to the stream. 543 For each resource it handles, the LRM is expected to perform the 544 following functions: 546 o Stream Admission Control: it checks whether, given the flow 547 specification, there are sufficient resources left to handle the new 548 data stream. If the available resources are insufficient, the new 549 data stream must be rejected. 551 o QoS Computation: it calculates the best possible performance the 552 resource can provide for the new data stream under the current 553 traffic conditions, e.g. throughput and delay values are computed. 555 o Resource Reservation: it reserves the resource capacities required 556 to meet the desired QoS. 558 During data transfer, the LRM is responsible for: 560 o QoS Enforcement: it enforces the QoS requirements by appropriate 561 scheduling of resource access. For example, data packets from an 562 application with a short guaranteed delay must be served prior to 563 data from an application with a less strict delay bound. 565 The LRM may also provide the following additional functions: 567 o Data Regulation: to smooth a stream's data traffic, e.g. as with the 568 leaky bucket algorithm. 570 o Policing: to prevent applications exceed their negotiated QoS, e.g. 571 to send data at a higher rate than indicated in the flow 572 specification. 574 o Stream Preemption: to free up resources for other streams with 575 higher priority or importance. 577 The strategies adopted by the LRMs to handle resources are resource- 578 dependent and may vary at every host/router. However, it is necessary 579 that all LRMs have the same understanding of the flow specification. 580 The interface between setup protocol and LRM is a local matter at 581 every host and therefore it is not specified by this document. An 582 example of LRM is the Heidelberg Resource Administration Technique 583 (HeiRAT) [VoHN93]. 585 It is also assumed that the LRM provides functions to compare flow 586 specifications, i.e. to decide whether a flow specification requires a 587 greater, equal, or smaller amount of resource capacities to be 588 reserved. 590 1.5 ST2 Basic Concepts 592 The following sections present at an introductory level some of the 593 fundamental ST2 concepts including streams, data transfer, and flow 594 specification. 596 Hosts Connections... : ...and Streams 597 ==================== : ============== 598 data Origin : Origin 599 packets +-----------+ : +----+ 600 +----|Application| : | | 601 | |-----------| : +----+ 602 +--->| ST Agent | : | | 603 +-----------+ : | | 604 | : | | 605 V : | | 606 +-------------+ : | | 607 | | : | | 608 +-------------| Network A | : +-------+ +--------+ 609 | | | : | | 610 | +-------------+ : | | 611 | | Target 2 : | | 612 | Target 1 | and Router : | | 613 | +-----------+ | +-----------+ : V V 614 | |Application|<-+ | |Application|<-+ : +----+ +----+ 615 | |-----------| | | |-----------| | : | | Target 2 | | 616 +->| ST Agent |--+ +->| ST Agent |--+ : +----+ & Router +----+ 617 +-----------+ +-----------+ : Target 1 | | 618 | : | | 619 V : | | 620 +-------------+ : | | 621 | | : | | 622 +-------------| Network B | : +----------+ | 623 | | | : | | 624 | +-------------+ : | | 625 | Target 3 | Target 4 : | | 626 | +-----------+ | +-----------+ : V V 627 | |Application|<-+ | |Application|<-+ : +----+ +----+ 628 | |-----------| | | |-----------| | : | | | | 629 +->| ST Agent |--+ +->| ST Agent |--+ : +----+ +----+ 630 +-----------+ +-----------+ : Target 3 Target 4 631 : 633 Figure 3: The Stream Concept 635 1.5.1 Streams 637 Streams form the core concepts of ST2. They are established between a 638 sending origin and one or more receiving targets in the form of a 639 routing tree. Streams are uni-directional from the origin to the 640 targets. Nodes in the tree represent so-called ST agents, entities 641 executing the ST2 protocol; links in the tree are called hops. Any 642 node that can sit in the middle of the tree is call an intermediate 643 agent, or router. An agent may have any combination of origin, target, 644 or intermediate capabilities. 646 Figure 3 illustrates a stream from an origin to four targets, where 647 the ST agent on Target 2 also functions as a router. Let us use this 648 Target 2/Router node to explain some basic ST2 terminology: the 649 direction of the stream from this node to Target 3 and 4 is called 650 downstream, the direction towards the Origin node upstream. ST agents 651 that are one hop away from a given node are called previous-hops in 652 the upstream, and next-hops in the downstream direction. 654 Streams are maintained using SCMP messages. Typical SCMP messages are 655 CONNECT and ACCEPT to build a stream, DISCONNECT and REFUSE to close a 656 stream, CHANGE to modify the quality of service associated with a 657 stream, and JOIN to request to be added to a stream. 659 Each ST agent maintains state information describing the streams 660 flowing through it. It can actively gather and distribute such 661 information. It can recognize failed neighbour ST agents through the 662 use of periodic HELLO message exchanges. It can ask other ST agents 663 about a particular stream via a STATUS message. These ST agents then 664 send back a STATUS-RESPONSE message. NOTIFY messages can be used to 665 inform other ST agents of significant events. 667 ST2 offers a wealth of functionalities for stream management. Streams 668 can be grouped together to minimize allocated resources or to process 669 them in the same way in case of failures. During audio conferences, 670 for example, only a limited set of participants may talk at once. 671 Using the group mechanism, resources for only a portion of the audio 672 streams of the group need to be reserved. Using the same concept, an 673 entire group of related audio and video streams can be dropped if one 674 of them is preempted. 676 1.5.2 Data Transmission 678 Data transfer in ST2 is simplex in the downstream direction. Data 679 transport through streams is very simple. ST2 puts only a small header 680 in front of the user data. The header contains a protocol 681 identification that distinguishes ST2 from IP packets, an ST2 version 682 number, a priority field (specifying a relative importance of streams 683 in cases of conflict), a length counter, a stream identification, and 684 a checksum. These elements form an 12-byte header. 686 Efficiency is also achieved by avoiding fragmentation and reassembly 687 on all agents. Stream establishment yields a maximum message size for 688 data packets on a stream. This maximum message size is communicated to 689 the upper layers, so that they provide data packets of suitable size 690 to ST2. 692 Communication with multiple next-hops can be made even more efficient 693 using MAC Layer multicast when it is available. If a subnet supports 694 multicast, a single multicast packet is sufficient to reach all next- 695 hops connected to this subnet. This leads to a significant reduction 696 of the bandwidth requirements of a stream. If multicast is not 697 provided, separate packets need to be sent to each next-hop. 699 As ST2 relies on reservation, it does not contain error correction 700 mechanisms features for data exchange such as those found in TCP. It 701 is assumed that real-time data, such as digital audio and video, 702 require partially correct delivery only. In many cases, retransmitted 703 packets would arrive too late to meet their real-time delivery 704 requirements. Also, depending on the data encoding and the particular 705 application, a small number of errors in stream data are acceptable. 706 In any case, reliability can be provided by layers on top of ST2 when 707 needed. 709 1.5.3 Flow Specification 711 As part of establishing a connection, SCMP handles the negotiation of 712 quality-of-service parameters for a stream. In ST2 terminology, these 713 parameters form a flow specification (FlowSpec) which is associated 714 with the stream. Different versions of FlowSpecs exist, see [RFC1190], 715 [DHHS92] and [RFC1363], and can be distinguished by a version number. 716 Typically, they contain parameters such as average and maximum 717 throughput, end-to-end delay, and delay variance of a stream. SCMP 718 itself only provides the mechanism for relaying the quality-of-service 719 parameters. 721 Three kinds of entities participate in the quality-of-service 722 negotiation: application entities on the origin and target sites as 723 the service users, ST agents, and local resource managers (LRM). The 724 origin application supplies the initial FlowSpec requesting a 725 particular service quality. Each ST agent which obtains the FlowSpec 726 as part of a connection establishment message, it presents the local 727 resource manager with it. ST2 does not determine how resource managers 728 make reservations and how resources are scheduled according to these 729 reservations; ST2, however, assumes these mechanisms as its basis. 731 An example of the FlowSpec negotiation procedure is illustrated in 732 Figure 4. Depending on the success of its local reservations, the LRM 733 updates the FlowSpec fields and returns the FlowSpec to the ST agent, 734 which passes it downstream as part of the connection message. 735 Eventually, the FlowSpec is communicated to the application at the 736 target which may base its accept/reject decision for establishing the 737 connection on it and may finally also modify the FlowSpec. If a target 738 accepts the connection, the (possibly modified) FlowSpec is propagated 739 back to the origin which can then calculate an overall service quality 740 for all targets. The application entity the origin may later request a 741 CHANGE to adjust reservations. 743 Origin Router Target 1 744 +------+ 1a +------+ 1b +------+ 745 | |-------------->| |------------->| | 746 +------+ +------+ +------+ 747 ^ | ^ | 748 | | | 2 | 749 | | +------------------------------------------+ 750 + + 751 +-------------+ \ \ +-------------+ +-------------+ 752 |Max Delay: 12| \ \ |Max Delay: 12| |Max Delay: 12| 753 |-------------| \ \ |-------------| |-------------| 754 |Min Delay: 2| \ \ |Min Delay: 5| |Min Delay: 9| 755 |-------------| \ \ |-------------| |-------------| 756 |Max Size:4096| + + |Max Size:2048| |Max Size:2048| 757 +-------------+ | | +-------------+ +-------------+ 758 FlowSpec | | 1 759 | +---------------+ 760 | | 761 | V 762 2 | +------+ 763 +-------------->| | 764 +------+ 765 Target 2 766 +-------------+ 767 |Max Delay: 12| 768 |-------------| 769 |Min Delay: 4| 770 |-------------| 771 |Max Size:4096| 772 +-------------+ 774 Figure 4: Quality-of-Service Negotiation with FlowSpecs 776 1.6 Outline of This Document 778 This document contains the specification of the ST2+ version of the 779 ST2 protocol. In the rest of the document, whenever the terms "ST" or 780 "ST2" are used, they refer to the ST2+ version of ST2. 782 The document is organized as follows: 784 o Section 2 describes the ST2 user service from an application point 785 of view. 787 o Section 3 illustrates the ST2 data transfer protocol, ST. 789 o Section 4 through Section 8 specify the ST2 setup protocol, SCMP. 791 o the ST2 flow specification is presented in Section 9. 793 o the formats of protocol elements and PDUs are defined in Section 10. 795 2 ST2 User Service Description 797 This section describes the ST user service from the high-level point 798 of view of an application. It defines the ST stream operations and 799 primitive functions. It specifies which operations on streams can be 800 invoked by the applications built on top of ST and when the ST 801 primitive functions can be legally executed. Note that the presented 802 ST primitives do not specify an API. They are used here with the only 803 purpose of illustrating the service model for ST. 805 2.1 Stream Operations and Primitive Functions 807 An ST application at the origin may create, expand, reduce, change, 808 send data to, and delete a stream. When a stream is expanded, new 809 targets are added to the stream; when a stream is reduced, some of the 810 current targets are dropped from it. When a stream is changed, the 811 associated quality of service is modified. 813 An ST application at the target may join, receive data from, and leave 814 a stream. This translates into the following stream operations: 816 o OPEN: create new stream [origin], CLOSE: delete stream [origin], 818 o ADD: expand stream, i.e. add new targets to it [origin], 820 o DROP: reduce stream, i.e. drop targets from it [origin], 822 o JOIN: join a stream [target], LEAVE: leave a stream [target], 824 o DATA: send data through stream [origin], 826 o CHG: change a stream's QoS [origin], 828 Each stream operation may require the execution of several primitive 829 functions to be completed. For instance, to open a new stream, a 830 request is first issued by the sender and an indication is generated 831 at one or more receivers; then, the receivers may each accept or 832 refuse the request and the correspondent indications are generated at 833 the sender. A single receiver case is shown in Figure 5 below. 835 Sender Network Receiver 836 | | | 837 OPEN.req | | | 838 |-----------------> | | 839 | |-----------------> | 840 | | | OPEN.ind 841 | | | OPEN.accept 842 | |<----------------- | 843 |<----------------- | | 844 OPEN.accept-ind | | | 845 | | | 847 Figure 5: Primitives for the OPEN Stream Operation 849 Table 1 defines the ST service primitive functions associated to each 850 stream operation. The column labelled "O/T" indicates whether the 851 primitive is executed at the origin or at the target. 853 +===================================================+ 854 |Primitive | Descriptive |O/T| 855 |===================================================| 856 |OPEN.req | open a stream | O | 857 |OPEN.ind | connection request indication | T | 858 |OPEN.accept | accept stream | T | 859 |OPEN.refuse | refuse stream | T | 860 |OPEN.accept-ind| connection accept indication | O | 861 |OPEN.refuse-ind| connection refuse indication | O | 862 |ADD.req | add targets to stream | O | 863 |ADD.ind | add request indication | T | 864 |ADD.accept | accept stream | T | 865 |ADD.refuse | refuse stream | T | 866 |ADD.accept-ind | add accept indication | O | 867 |ADD.refuse-ind | add refuse indication | O | 868 |JOIN.req | join a stream | T | 869 |JOIN.ind | join request indication | O | 870 |JOIN.reject | reject a join | O | 871 |JOIN.reject-ind| join reject indication | T | 872 |DATA.req | send data | O | 873 |DATA.ind | receive data indication | T | 874 |CHG.req | change stream QoS | O | 875 |CHG.ind | change request indication | T | 876 |CHG.accept | accept change | T | 877 |CHG.refuse | refuse change | T | 878 |CHG.accept-ind | change accept indication | O | 879 |CHG.refuse-ind | change refuse indication | O | 880 |DROP.req | drop targets | O | 881 |DROP.ind | disconnect indication | T | 882 |LEAVE.req | leave stream | T | 883 |LEAVE.ind | leave stream indication | O | 884 |CLOSE.req | close stream | O | 885 |CLOSE.ind | close stream indication | T | 886 +---------------------------------------------------+ 888 Table 1: ST Primitives 890 2.2 State Diagrams 892 It is not sufficient to define the set of ST stream operations. It is 893 also necessary to specify when the operations can be legally executed. 894 For this reason, a set of states is now introduced and the transitions 895 from one state to the others are specified. States are defined with 896 respect to a single stream. The previously defined stream operations 897 can be legally executed only from an appropriate state. 899 An ST agent may, with respect to an ST stream, be in one of the 900 following states: 902 o IDLE: the stream has not been created yet. 904 o PENDING: the stream is in the process of being established. 906 o ACTIVE: the stream is established and active. 908 o ADDING: the stream is established. A stream expansion is underway. 910 o CHGING: the stream is established. A stream change is underway. 912 Previous experience with ST has lead to limits on the stream 913 operations that can be executed at the simultaneously. These 914 restrictions are: 916 1. A single ADD or CHG operation can be processed at one time. If an 917 ADD or CHG is already underway, further requests are queued by the 918 ST agent and handled only after the previous operation has been 919 completed. This also applies to two subsequent requests of the same 920 kind, e.g. two ADD or two CHG operations. The second operation is 921 not executed until the first one has been completed. 923 2. Deleting a stream, leaving a stream, or dropping targets from a 924 stream is possible only after stream establishment has been 925 completed. A stream is considered to be established when all the 926 next-hops of the origin have either accepted or refused the stream. 927 Note that stream refuse is automatically forced after timeout if no 928 reply comes from a next-hop. 930 3. An ST agent forwards data only along already established paths to 931 the targets, see also Section 3.1. A path is considered to be 932 established when the next-hop on the path has explicitly accepted 933 the stream. This implies that the target and all other intermediate 934 ST agents are ready to handle the incoming data packets. In no cases 935 an ST agent will forward data to a next-hop ST agent that has not 936 explicitly accepted the stream. To be sure that all targets receive 937 the data, an application should send the data only after all paths 938 have been established, i.e. the stream is established. 940 4. It is allowed to send data from the CHGING and ADDING states. While 941 sending data from the CHGING state, the quality of service to the 942 targets affected by the change should be assumed to be the more 943 restrictive quality of service. When sending data from the ADDING 944 state, the targets that receive the data include at least all the 945 targets that were already part of the stream at the time the ADD 946 operation was invoked. 948 The rules introduced above require ST agents to queue incoming 949 requests when the current state does not allow to process them 950 immediately. In order to preserve the semantics, ST agents have to 951 maintain the order of the requests, i.e. implement FIFO queuing. 952 Exceptionally, the CLOSE request at the origin and the LEAVE request 953 at the target may be immediately processed: in this cases, the queue 954 is deleted and it is possible that requests in the queue are not 955 processed. 957 The following state diagrams define the ST service. Separate diagrams 958 are presented for the origin and the targets. 960 The symbol (a/r)* indicates that all targets in the target list have 961 explicitly accepted or refused the stream, or refuse has been forced 962 after timeout. If the target list is empty, i.e. it contains no 963 targets, the (a/r)* condition is immediately satisfied, so the empty 964 stream is created and state ESTBL is entered. 966 The separate OPEN and ADD primitives at the target are for conceptual 967 purposes only. The target is actually unable to distinguish between an 968 OPEN and an ADD. This is reflected in Figure 7 and Table 3 through the 969 notation OPEN/ADD. 971 +------------+ 972 | |<-------------------+ 973 +---------->| IDLE |-------------+ | 974 | | | OPEN.req | | 975 | +------------+ | | 976 CLOSE.req | CLOSE.req ^ ^ CLOSE.req V | CLOSE.req 977 | | | +---------+ | 978 | | | | PENDING |-|-+ JOIN.reject 979 | | -------------| |<|-+ 980 | JOIN.reject | +---------+ | 981 | DROP.req +----------+ | | 982 | +-----| | | | 983 | | | ESTDL | OPEN.(a/r)* | | 984 | +---->| |<------------+ | 985 | +----------+ | 986 | | ^ | ^ | 987 | | | | | | 988 +----------+ CHG.req| | | | Add.(a/r)* +----------+ 989 | |<-------+ | | +-------------- | | 990 | CHGING | | | | ADDING | 991 | |-----------+ +----------------->| | 992 +----------+ CHG.(a/r)* JOIN.ind +----------+ 993 | ^ ADD.req | ^ 994 | | | | 995 +---+ +---+ 996 DROP.req DROP.req 997 JOIN.reject JOIN.reject 999 Figure 6: ST Service at the Origin 1001 +--------+ 1002 | |-----------------------+ 1003 | IDLE | | 1004 | |<---+ | OPEN/ADD.ind 1005 +--------+ | CLOSE.ind | JOIN.req 1006 ^ | OPEN/ADD.refuse | 1007 | | JOIN.refect-ind | 1008 CLOSE.ind | | V 1009 DROP.ind | | +---------+ 1010 LEAVE.req | +-------------| | 1011 | | PENDING | 1012 +-------+ | | 1013 | | +---------+ 1014 | ESTBL | OPEN/ADD.accept | 1015 | |<-----------------------+ 1016 +-------+ 1018 Figure 7: ST Service at the Target 1020 2.3 State Transition Tables 1022 Table 2 and Table 3 define which primitives can be processed from 1023 which states and the possible state transitions. 1025 +=============================================================================+ 1026 |Primitive |IDLE| PENDING | ESTBL | CHGING | ADDING | 1027 |=============================================================================| 1028 |OPEN.req | ok | - | - | - | - | 1029 |OPEN.accept-ind| - |if(a,r)*->ESTBL| - | - | - | 1030 |OPEN.refuse-ind| - |if(a,r)*->ESTBL| - | - | - | 1031 |ADD.req | - | queued |->ADDING| queued | queued | 1032 |ADD.accept-ind | - | - | - | - |if(a,r)*->ESTBL| 1033 |ADD.refuse-ind | - | - | - | - |if(a,r)*->ESTBL| 1034 |JOIN.ind | - | queued |->ADDING| queued |queued | 1035 |JOIN.reject | - | OK | ok | ok | ok | 1036 |DATA.req | - | - | ok | ok | ok | 1037 |CHG.req | - | queued |->CHGING| queued |queued | 1038 |CHG.accept-ind | - | - | - |if(a,r)*->ESTBL| - | 1039 |CHG.refuse.ind | - | - | - |if(a,r)*->ESTBL| - | 1040 |DROP.req | - | - | ok | ok | ok | 1041 |LEAVE.ind | - | OK | ok | ok | ok | 1042 |CLOSE.req | - | OK | ok | ok | ok | 1043 +-----------------------------------------------------------------------------+ 1044 Table 2: Primitives and States at the Origin 1046 +======================================================+ 1047 | Primitive | IDLE | PENDING | ESTBL | 1048 |======================================================| 1049 | OPEN/ADD.ind | ->PENDING | - | - | 1050 | OPEN/ADD.accept | - | ->ESTBL | - | 1051 | OPEN/ADD.refuse | - | ->IDLE | - | 1052 | JOIN.req | ->PENDING | - | - | 1053 | JOIN.reject-ind |- | ->IDLE | - | 1054 | DATA.ind | - | - | ok | 1055 | CHG.ind | - | - | ok | 1056 | CHG.accept | - | - | ok | 1057 | DROP.ind | - | ok | ok | 1058 | LEAVE.req | - | ok | ok | 1059 | CLOSE.ind | - | ok | ok | 1060 | CHG.ind | - | - | ok | 1061 +------------------------------------------------------+ 1062 Table 3: Primitives and States at the Target 1064 3 The ST2 Data Transfer Protocol 1066 This section presents the ST2 data transfer protocol, ST. First, data 1067 transfer is described in Section 3.1, then, the data transfer protocol 1068 functions are illustrated in Section 3.2. 1070 3.1 Data Transfer with ST 1072 Data transmission with ST is unreliable. An application is not 1073 guaranteed that the data reaches its destinations and ST makes no 1074 attempts to recover from packet loss, e.g. due to the underlying 1075 network. However, if the data reaches its destination, it should do so 1076 accordingly to the quality of service associated with the stream. 1078 Additionally, ST may deliver data corrupted in transmission. Many 1079 types of real-time data, such as digital audio and video, require 1080 partially correct delivery only. In many cases, retransmitted packets 1081 would arrive too late to meet their real-time delivery requirements. 1082 On the other hand, depending on the data encoding and the particular 1083 application, a small number of errors in stream data are acceptable. 1084 In any case, reliability can be provided by layers on top of ST2 if 1085 needed. 1087 Also, no data fragmentation is supported during the data transfer 1088 phase. The application is expected to segment its data PDUs according 1089 to the minimum MTU over all paths in the stream. The application 1090 receives information on the MTUs relative to the paths to the targets 1091 as part of the ACCEPT message, see Section 8.6. The minimum MTU over 1092 all paths can be calculated from the MTUs relative to the single 1093 paths. ST agents silently discard too long data packets, see also 1094 Section 5.1.1. 1096 An ST agent forwards the data only along already established paths to 1097 targets. A path is considered to be established once the next-hop ST 1098 agent on the path sends an ACCEPT message, see Section 2.2. This 1099 implies that the target and all other intermediate ST agents on the 1100 path to the target are ready to handle the incoming data packets. In 1101 no cases will an ST agent forward data to a next-hop ST agent that has 1102 not explicitly accepted the stream. 1104 To be reasonably sure that all targets receive the data with the 1105 desired quality of service, an application should send the data only 1106 after the whole stream has been established. Depending on the local 1107 API, an application may not be prevented from sending data before the 1108 completion of stream setup, but it should be aware that the data could 1109 be lost or not reach all intended targets. This behavior may actually 1110 be desirable to applications, such as those application that have 1111 multiple targets which can each process data as soon as it is 1112 available (e.g. a lecture or distributed gaming). 1114 It is desirable for implementations to take advantage of networks that 1115 support multicast. If a network does not support multicast, or for the 1116 case where the next-hops are on different networks, multiple copies of 1117 the data packet must be sent. 1119 3.2 ST Protocol Functions 1121 The ST protocol provides two functions: 1123 o stream identification 1125 o data priority 1127 3.2.1 Stream Identification 1129 ST data packets are encapsulated by an ST header containing the Stream 1130 IDentifier (SID). This SID is selected at the origin so that it is 1131 globally unique over the Internet. The SID must be known by the setup 1132 protocol as well. At stream establishment time, the setup protocol 1133 builds, at each agent traversed by the stream, an entry into its local 1134 database containing stream information. The SID can be used as a 1135 reference into this database, to obtain quickly the necessary 1136 replication and forwarding information. 1138 Stream IDentifiers are intended to be used to make the packet 1139 forwarding task most efficient. The time-critical operation is an 1140 intermediate ST agent receiving a packet from the previous-hop ST 1141 agent and forwarding it to the next-hop ST agents. 1143 The format of data PDUs including the SID is defined in Section 10.1. 1144 Stream IDentifier generation is discussed in Section 8.1. 1146 3.2.2 Packet Discarding based on Data Priority 1148 ST provides a well defined quality of service to its applications. 1149 However, there may be cases where the network is temporarily congested 1150 and the ST agents have to discard certain packets to minimize the 1151 overall impact to other streams. The ST protocol provides a mechanism 1152 to discard data packets based on the Priority field in the data PDU, 1153 see Section 10.1. The application assigns each data packet with a 1154 discard-priority level, carried into the Priority field. ST agents 1155 will attempt to discard lower priority packets first during periods of 1156 network congestion. Applications may choose to send data at multiple 1157 priority levels so that less important data may be discarded first. 1159 4 SCMP Functional Description 1161 ST agents create and manage streams using the ST Control Message 1162 Protocol (SCMP). Conceptually, SCMP resides immediately above ST (as 1163 does ICMP above IP). SCMP follows a request-response model. SCMP 1164 messages are made reliable through the use of retransmission after 1165 timeout. 1167 This section contains a functional description of stream management 1168 with SCMP. To help clarify the SCMP exchanges used to setup and 1169 maintain ST streams, we include an example of a simple network 1170 topology, represented in Figure 8. Using the SCMP messages described 1171 in this section it will be possible for an ST application to: 1173 o Create a stream from A to the peers at B, C and D, 1175 o Add a peer at E, 1177 o Drop peers B and C, and 1179 o Let F join the stream 1181 o Delete the stream. 1183 +---------+ +---+ 1184 | |----| B | 1185 +---------+ +----------+ | | +---+ 1186 | |------| Router 1 |---| Subnet2 | 1187 | | +----------+ | | 1188 | | | | 1189 | | +---------+ 1190 | | | 1191 | Subnet1 | | 1192 | | +----------+ 1193 | | | Router 3 | 1194 +---+ | | +----------+ 1195 | A |---| | +----------+ | 1196 +---+ | |----| Router 2 | | 1197 | | +----------+ | 1198 +---------+ | | 1199 | | 1200 | +----------+ +---+ 1201 +----------| |----| C | 1202 | | +---+ 1203 +---------+ | Subnet3 | 1204 +---+ | | +---+ | | +---+ 1205 | F |---| Subnet4 |---| E |--| |----| D | 1206 +---+ | | +---+ +----------+ +---+ 1207 +---------+ 1209 Figure 8: Sample Topology for an ST Stream 1211 We first describe the possible types of stream in Section 4.1; Section 1212 4.2 introduces SCMP control message types; SCMP reliability is 1213 discussed in Section 4.3; stream options are covered in Section 4.4; 1214 stream setup is presented in Section 4.5; Section 4.6 illustrates 1215 stream modification including stream expansion, reduction, changes of 1216 the quality of service associated to a stream. Finally, stream 1217 deletion is handled in Section 4.7. 1219 4.1 Types of Streams 1221 SCMP allows for the setup and management of different types of 1222 streams. Streams differ in the way they are built and the information 1223 maintained on connected targets. 1225 4.1.1 Stream Building 1227 Streams may be built in a sender-oriented fashion, receiver-oriented 1228 fashion, or with a mixed approach: 1230 o in the sender-oriented fashion, the application at the origin 1231 provides the ST agent with the list of receivers for the stream. New 1232 targets, if any, are also added from the origin. 1234 o in the receiver-oriented approach, the application at the origin 1235 creates an empty stream that contains no targets. Each target joins 1236 then the stream autonomously. 1238 o in the mixed approach, the application at the origin creates a 1239 stream that contains some targets and other targets join then the 1240 stream autonomously. 1242 ST2 provides stream options to support sender-oriented and mixed 1243 approach steams. Receiver-oriented streams can be emulated through the 1244 use of mixed streams. The fashion by which targets may be added to a 1245 particular stream is controlled via join authorization levels. Join 1246 authorization levels are described in Section 4.4.2. 1248 4.1.2 Knowledge of Receivers 1250 When streams are built in the sender-oriented fashion, all ST agents 1251 will have full information on all targets down stream of a particular 1252 agent. In this case, target information is relayed down stream from 1253 agent-to-agent during stream set-up. 1255 When targets add themselves to mixed approach streams, upstream ST 1256 agents may or may not be informed. Propagation of information on 1257 targets that "join" a stream is also controlled via join authorization 1258 levels. As previously mentioned, join authorization levels are 1259 described in Section 4.4.2. 1261 This leads to two types of streams: 1263 o full target information is propagated in a full-state stream. For 1264 such streams, all agents are aware of all downstream targets 1265 connected to the stream. This results in target information being 1266 maintained at the origin and routers. Operations on single targets 1267 are always possible, i.e. change a certain target, or, drop that 1268 target from the stream. It is also always possible for any ST agent 1269 to attempt recovery of all downsteam targets. 1271 o in light-weight streams, it is possible that the origin and other 1272 upstream agents have no knowledge about some targets. This results 1273 in less maintained state and easier stream management, but it limits 1274 operations on specific targets. Special actions may be required to 1275 support change and drop operations on unknown targets, see Section 1276 5.7. Also, stream recovery may not be possible. Of course, generic 1277 functions such as deleting the whole stream, are still possible. It 1278 is expected that applications that will have a large number of 1279 targets will use light-weight streams in order to limit state in 1280 agents and the number of targets per control message. 1282 Full-state streams serve well applications as video conferencing or 1283 distributed gaming, where it is important to have knowledge on the 1284 connected receivers, e.g. to limit who participates. Light-weight 1285 streams may be exploited by applications such as remote lecturing or 1286 playback applications of radio and TV broadcast where the receivers do 1287 not need to be known by the sender. Section 4.4.2 defines join 1288 authorization levels, which support two types of full-state streams 1289 and one type of light-weight streams. 1291 4.2 Control PDUs 1293 SCMP defines the following PDUs (the main purpose of each PDU is also 1294 indicated): 1296 1. ACCEPT to accept a new stream 1297 2. ACK to acknowledge an incoming message 1298 3. CHANGE to change the quality of service associated with 1299 a stream 1300 4. CONNECT to establish a new stream or add new targets to 1301 an existing stream 1302 5. DISCONNECT to remove some or all of the stream's targets 1303 6. ERROR to indicate an error contained into an incoming 1304 message 1305 7. HELLO to detect failures of neighbour ST agents 1306 8. JOIN to request stream joining from a target 1307 9. JOIN-REJECT to reject a stream joining request from a target 1308 10. NOTIFY to inform an ST agent of a significant event 1309 11. REFUSE to refuse the establishment of a new stream 1310 12. STATUS to query an ST agent on a specific stream 1311 13. STATUS-RESPONSE to reply queries on a specific stream 1313 SCMP follows a request-response model with all requests expecting 1314 responses. Retransmission after timeout is used to allow for lost or 1315 ignored messages. Control messages do not extend across packet 1316 boundaries; if a control message is too large for the MTU of a hop, its 1317 information is partitioned and a control message per partition is 1318 sent, as described in Section 5.1.2. 1320 The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY and 1321 REFUSE must always be explicitly acknowledged: 1323 o with an ACK message, if the message was received correctly and it 1324 was possible to parse and correctly extract and interpret its 1325 header, fields and parameters, 1327 o with an ERROR message, if a syntax error was detected in the header, 1328 fields, or parameters included in the message. The errored PDU may 1329 be optionally returned as part of the ERROR message. An ERROR 1330 message indicates a syntax error only. If any other errors are 1331 detected, it is necessary to first acknowledge with ACK and then 1332 take appropriate actions. For instance, suppose a CHANGE message 1333 contains an unknown SID: first, an ACK message has to be sent, then 1334 a REFUSE message with ReasonCode (SIDUnknown) follows. 1336 If no ACK or ERROR message are received before the correspondent timer 1337 expires, a timeout failure occurs. The way an ST agent should handle 1338 timeout failures is described in Section 5.2. 1340 ACK, ERROR, and STATUS-RESPONSE messages are never acknowledged. 1342 HELLO messages are a special case. If they contain a syntax error, an 1343 ERROR message should be generated in response. Otherwise, no 1344 acknowledgment or response should be generated. Use of HELLO messages 1345 is discussed in Section 6.1.2. 1347 STATUS messages containing a syntax error should be replied with an 1348 ERROR message. Otherwise, a STATUS-RESPONSE message should be sent 1349 back in response. Use of STATUS and STATUS-RESPONSE are discussed in 1350 Section 8.4. 1352 4.3 SCMP Reliability 1354 SCMP is made reliable through the use of retransmission when response 1355 is not received in a timely manner. The ACCEPT, CHANGE, CONNECT, 1356 DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and REFUSE messages all must be 1357 answered with an ACK message, see Section 4.2. In general, when 1358 sending a SCMP message which requires an ACK response, the sending ST 1359 agent needs to set the Toxxxx timer (where xxxx is the SCMP message 1360 type, e.g. ToConnect). If it does not receive an ACK before the Toxxxx 1361 timer expires, the ST agent should retransmit the SCMP message. If no 1362 ACK has been received within Nxxxx retransmissions, then a SCMP 1363 timeout condition occurs and the ST agent enters its SCMP timeout 1364 recovery state. The actions performed by the ST agent as the result of 1365 the SCMP timeout condition differ for different SCMP messages and are 1366 described in Section 5.2. 1368 For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the sending 1369 ST agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN- 1370 REJECT) after ACK has been received. For these cases, the ST agent 1371 needs to set the ToxxxxResp timer after it receives the ACK. (As 1372 before, xxxx is the initiating SCMP message type, e.g. ToConnectResp). 1373 If it does not receive the appropriate response back when ToxxxxResp 1374 expires, the ST agent updates its state and performs appropriate 1375 recovery action as described in Section 5.2. 1377 The timeout and retransmission algorithm is implementation dependent 1378 and it is outside the scope of this document. Most existing algorithms 1379 are based on an estimation of the Round Trip Time (RTT) between two 1380 agents. Therefore, SCMP contains a mechanism, see Section 8.5, to 1381 estimate this RTT. Note that the timeout related variable names 1382 described above are for reference purposes only, implementors may 1383 choose to combine certain variables. 1385 4.4 Stream Options 1387 An application may select among some stream options. The desired 1388 options are indicated to the ST agent at the origin when a new stream 1389 is created. Options apply to single streams and are valid during the 1390 whole stream's lifetime. The options chosen by the application at the 1391 origin are included into the initial CONNECT message, see Section 1392 4.5.3. When a CONNECT message reaches a target, the application at the 1393 target is notified of the stream options that have been selected, see 1394 Section 4.5.5. 1396 4.4.1 No Recovery 1398 When a stream failure is detected, an ST agent would normally attempt 1399 stream recovery, as described in Section 6.2. The NoRecovery option is 1400 used to indicate that ST agents should not attempt recovery for the 1401 stream. The protocol behaviour in case the NoRecovery option has been 1402 selected is illustrated in Section 6.2. The NoRecovery option is 1403 specified by setting the S-bit in the CONNECT message, see Section 1404 10.4.4. The S-bit can be set only by the origin and it is never 1405 modified by intermediate and target ST agents. 1407 4.4.2 Join Authorization Level 1409 When a new stream is created, it is necessary to define the join 1410 authorization level associated with the stream. This level determines 1411 the protocol behavior in case of stream joining, see Section 4.1 and 1412 Section 4.6.3. The join authorization level for a stream is defined by 1413 the J-bit and N-bit in the CONNECT message header, see Section 10.4.4. 1414 One of the following authorization levels has to be selected: 1416 o Level 0 - Refuse Join (JN = 00): No targets are allowed to join this 1417 stream. 1419 o Level 1 - OK, Notify Origin (JN = 01): Targets are allowed to join 1420 the stream. The origin is notified that the target has joined. 1422 o Level 2 - OK (JN = 10): Targets are allowed to join the stream. No 1423 notification is sent to the stream origin. 1425 Some applications may choose to maintain tight control on their 1426 streams and will not permit any connections without the origin's 1427 permission. For such streams, target applications may request to be 1428 added by sending an out-of-band, i.e. via regular IP, request to the 1429 origin. The origin, if it so chooses, can then add the target 1430 following the process described in Section 4.6.1. 1432 The selected authorization level impacts stream handling and the state 1433 that is maintained for the stream, as described in Section 4.1. 1435 4.4.3 Record Route 1437 The RecordRoute option can be used to request the route between the 1438 origin and a target be recorded and delivered to the application. This 1439 option may be used while connecting, accepting, changing, or refusing 1440 a stream. The results of a RecordRoute option requested by the origin, 1441 i.e. as part of the CONNECT or CHANGE messages, are delivered to the 1442 target. The results of a RecordRoute option requested by the target, 1443 i.e. as part of the ACCEPT or REFUSE messages, are delivered to the 1444 origin. 1446 The RecordRoute option is specified by adding the RecordRoute 1447 parameter to the mentioned SCMP messages. The format of the 1448 RecordRoute parameter is shown in Section 10.3.5. When adding this 1449 parameter, the ST agent at the origin must determine the number of 1450 entries that may be recorded as explained in Section 10.3.5. 1452 4.4.4 User Data 1453 The UserData option can be used by applications to transport 1454 application specific data along with some SCMP control messages. This 1455 option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and 1456 REFUSE messages. The format of the UserData parameter is shown in 1457 Section 10.3.7. This option may be included by the origin, or the 1458 target, by adding the UserData parameter to the mentioned SCMP 1459 messages. This option may only be included once per SCMP message. 1461 4.5 Stream Setup 1463 This section presents a description of stream setup. For simplicity, 1464 we assume that everything succeeds, e.g. any required resources are 1465 available, messages are properly delivered, and the routing is 1466 correct. Possible failures in the setup phase are handled in Section 1467 5.2. 1469 4.5.1 Information from the Application 1471 Before stream setup can be started, the application has to collect the 1472 necessary information to determine the characteristics for the 1473 connection. This includes identifying the participants and selecting 1474 the QoS parameters of the data flow. Information passed to the ST 1475 agent by the application includes: 1477 o the list of the stream's targets (Section 10.3.6). The list may be 1478 empty (Section 4.5.3.1), 1480 o the flow specification containing the desired quality of service for 1481 the stream (Section 9), 1483 o information on the groups in which the stream is a member, if any 1484 (Section 7), 1486 o information on the options selected for the stream (Section 4.4). 1488 4.5.2 Initial Setup at the Origin 1490 The ST agent at the origin then performs the following operations: 1492 o allocates a stream ID (SID) for the stream (Section 8.1), 1494 o invokes the routing function to determine the set of next-hops for 1495 the stream (Section 4.5.2.1), 1497 o invokes the Local Resource Manager (LRM) to reserve resources 1498 (Section 4.5.2.2), 1500 o creates local database entries to store information on the new 1501 stream, 1503 o propagates the stream creation request to the next-hops determined 1504 by the routing function (Section 4.5.3). 1506 4.5.2.1 Invoking the Routing Function 1508 An ST agent that is setting up a stream invokes the routing function 1509 to find the next-hop to reach each of the targets specified by the 1510 target list provided by the application. This is similar to the 1511 routing decision in IP. However, in this case the route is to a 1512 multitude of targets with QoS requirements rather than to a single 1513 destination. 1515 The result of the routing function is a set of next-hop ST agents. The 1516 set of next-hops selected by the routing function is not necessarily 1517 the same as the set of next-hops that IP would select given a number of 1518 independent IP datagrams to the same destinations. The routing 1519 algorithm may attempt to optimize parameters other than the number of 1520 hops that the packets will take, such as delay, local network 1521 bandwidth consumption, or total internet bandwidth consumption. 1522 Alternatively, the routing algorithm may use a simple route lookup for 1523 each target. 1525 Once a next-hop is selected by the routing function, it persists for 1526 the whole stream lifetime, unless a network failure occurs. 1528 4.5.2.2 Reserving Resources 1530 The ST agent invokes the Local Resource Manager (LRM) to perform the 1531 appropriate reservations. The ST agent presents the LRM with 1532 information including: 1534 o the flow specification with the desired quality of service for the 1535 stream (Section 9), 1537 o the version number associated with the flow specification 1538 (Section 9). 1540 o information on the groups the stream is member in, if any 1541 (Section 7), 1543 The flow specification contains information needed by the LRM to 1544 allocate resources. The LRM updates the flow specification contents 1545 information before returning it to the ST agent. Section 9.2.3 defines 1546 the fields of the flow specification to be updated by the LRM. 1548 The membership of a stream in a group may affect the amount of 1549 resources that have to be allocated by the LRM, see Section 7. 1551 4.5.3 Sending CONNECT Messages 1553 The ST agent sends a CONNECT message to each of the next-hop ST agents 1554 identified by the routing function. Each CONNECT message contains the 1555 SID, the selected stream options, the FlowSpec, and a TargetList. The 1556 format of the CONNECT message is defined by Section 10.4.4. In 1557 general, the FlowSpec and TargetList depend on both the next-hop and 1558 the intervening network. Each TargetList is a subset of the original 1559 TargetList, identifying the targets that are to be reached through the 1560 next-hop to which the CONNECT message is being sent. 1562 The TargetList may be empty, see Section 4.5.3.1; if the TargetList 1563 causes a too long CONNECT message to be generated, the CONNECT message 1564 is partitioned as explained in Section 5.1.2. If multiple next-hops 1565 are to be reached through a network that supports network level 1566 multicast, a different CONNECT message must nevertheless be sent to 1567 each next-hop since each will have a different TargetList. 1569 4.5.3.1 Empty Target List 1571 An application at the origin may request the local ST agent to create 1572 an empty stream. It does so by passing an empty TargetList to the 1573 local ST agent during the initial stream setup. When the local ST 1574 agent receives request to create an empty stream, it allocates the 1575 stream ID (SID), updates its local database entries to store 1576 information on the new stream and notifies the application that stream 1577 setup is complete. The local ST agent does not generate any CONNECT 1578 message for streams with an empty TargetList. Targets may be later 1579 added by the origin, see Section 4.6.1, or they may autonomously join 1580 the stream, see Section 4.6.3. 1582 4.5.4 CONNECT Processing by an Intermediate ST agent 1584 An ST agent receiving a CONNECT message, assuming no errors, responds 1585 to the previous-hop with an ACK. The ACK message must identify the 1586 CONNECT message to which it corresponds by including the reference 1587 number indicated by the Reference field of the CONNECT message. The 1588 intermediate ST agent calls the routing function, invokes the LRM to 1589 reserve resources, and then propagates the CONNECT messages to its 1590 next-hops, as described in the previous sections. 1592 4.5.5 CONNECT Processing at the Targets 1594 An ST agent that is the target of a CONNECT message, assuming no 1595 errors, responds to the previous-hop with an ACK. The ST agent invokes 1596 the LRM to reserve local resources and then queries the specified 1597 application process whether or not it is willing to accept the 1598 connection. 1600 The application is presented with parameters from the CONNECT message 1601 including the SID, the selected stream options, Origin, FlowSpec, 1602 TargetList, and Group, if any, to be used as a basis for its decision. 1603 The application is identified by a combination of the NextPcol field, 1604 from the Origin parameter, and the service access point, or SAP, field 1605 included in the correspondent (usually single remaining) Target of the 1606 TargetList. The contents of the SAP field may specify the port or 1607 other local identifier for use by the protocol layer above the host ST 1608 layer. Subsequently received data packets will carry the SID, that can 1609 be mapped into this information and be used for their delivery. 1611 Finally, based on the application's decision, the ST agent sends to 1612 the previous-hop from which the CONNECT message was received either an 1613 ACCEPT or REFUSE message. Since the ACCEPT (or REFUSE) message has to 1614 be acknowledged by the previous-hop, it is assigned a new Reference 1615 number that will be returned in the ACK. The CONNECT message to which 1616 ACCEPT (or REFUSE) is a reply is identified by placing the CONNECT's 1617 Reference number in the LnkReference field of ACCEPT (or REFUSE). The 1618 ACCEPT message contains the FlowSpec as accepted by the application at 1619 the target. 1621 4.5.6 ACCEPT Processing by an Intermediate ST agent 1623 When an intermediate ST agent receives an ACCEPT, it first verifies 1624 that the message is a response to an earlier CONNECT. If not, it 1625 responds to the next-hop ST agent with an ERROR message, with 1626 ReasonCode (LnkRefUnknown). Otherwise, it responds to the next-hop ST 1627 agent with an ACK, and propagates the individual ACCEPT message to the 1628 previous-hop along the same path traced by the CONNECT but in the 1629 reverse direction toward the origin. 1631 The FlowSpec is included in the ACCEPT message so that the origin and 1632 intermediate ST agents can gain access to the information that was 1633 accumulated as the CONNECT traversed the internet. Note that the 1634 resources, as specified in the FlowSpec in the ACCEPT message, may 1635 differ from the resources that were reserved when the CONNECT was 1636 originally processed. Therefore, the ST agent presents the LRM with 1637 the FlowSpec included in the ACCEPT message. It is expected that each 1638 LRM adjusts local reservations releasing any excess resources. The LRM 1639 may choose not to adjust local reservations when that adjustment may 1640 result in the loss of needed resources. It may also choose to wait to 1641 adjust allocated resources until all targets in transition have been 1642 accepted or refused. 1644 In the case where the intermediate ST agent is acting as the origin 1645 with respect to this target, see Section 4.6.3.1, the ACCEPT message 1646 is not propagated upstream. 1648 4.5.7 ACCEPT Processing by the Origin 1650 The origin will eventually receive an ACCEPT (or REFUSE) message from 1651 each of the targets. As each ACCEPT is received, the application is 1652 notified of the target and the resources that were successfully 1653 allocated along the path to it, as specified in the FlowSpec contained 1654 in the ACCEPT message. The application may then use the information to 1655 either adopt or terminate the portion of the stream to each target. 1656 When ACCEPT (or REFUSE) from all targets have been received at the 1657 origin, the application is notified that stream setup is complete. 1659 When an ACCEPT is received by the origin, the path to the target is 1660 considered to be established and the ST agent is allowed to forward 1661 the data along this path as explained in Section 2 and in Section 3.1. 1663 4.5.8 REFUSE Processing by the Intermediate ST agent 1665 If an application at a target does not wish to participate in the 1666 stream, it sends a REFUSE message back to the origin with ReasonCode 1667 (ApplDisconnect). An intermediate ST agent that receives a REFUSE 1668 message with ReasonCode (ApplDisconnect) acknowledges it by sending an 1669 ACK to the next-hop, invokes the LRM to adjusts reservations as 1670 appropriate, deletes the target entry from the internal database, and 1671 propagates the REFUSE message back to the previous-hop ST agent. 1673 In the case where the intermediate ST agent is acting as the origin 1674 with respect to this target, see Section 4.6.3.1, the REFUSE message 1675 is only propagated upstream when there are no more downstream agents 1676 participating in the stream. In this case, the agent indicates that 1677 the agent is to be removed from the stream propagating the REFUSE 1678 message with the G-bit set (1). 1680 4.5.9 REFUSE Processing by the Origin 1682 When the REFUSE message reaches the origin, the ST agent at the origin 1683 sends an ACK and notifies the application that the target is no longer 1684 part of the stream and also if the stream has no remaining targets. If 1685 there are no remaining targets, the application may wish to terminate 1686 the stream or keep the stream active to allow addition of targets, or 1687 stream joining as described in Section 4.6.3. 1689 4.5.10 Other Functions during Stream Setup 1691 Some other functions have to be accomplished by an ST agent as CONNECT 1692 messages travel downstream and ACCEPT (or REFUSE) messages travel 1693 upstream during the stream setup phase. They were not mentioned in the 1694 previous sections to keep the discussion as simple as possible. These 1695 functions include: 1697 o computing the smallest Maximum Transmission Unit size over the path 1698 to the targets, as part of the MTU discovery mechanism presented in 1699 Section 8.6. This is done by updating the MaxMsgSize field of the 1700 CONNECT message, see Section 10.4.4. This value is carried back to 1701 origin in the MaxMsgSize field of the ACCEPT message, see Section 1702 10.4.1. 1704 o counting the number of IP clouds that have to be traversed to reach 1705 the targets, as part of the IP encapsulation mechanism described in 1706 Section 8.7. This is done by updating the IPHops field of the 1707 CONNECT message, see Section 10.4.4. This value is carried back to 1708 origin in the IPHops field of the ACCEPT message, see Section 1709 10.4.1. 1711 o updating the RecoveryTimeout value for the stream based on what can 1712 the agent can support. This is part of the stream recovery 1713 mechanism, in Section 6.2. This is done by updating the 1714 RecoveryTimeout field of the CONNECT message, see Section 10.4.4. 1715 This value is carried back to origin in the RecoveryTimeout field of 1716 the ACCEPT message, see Section 10.4.1. 1718 4.6 Modifying an Existing Stream 1720 Some applications may wish to modify a stream after it has been 1721 created. Possible changes include expanding a stream, reducing it, and 1722 changing its FlowSpec. The origin may add or remove targets as 1723 described in Section 4.6.1 and Section 4.6.2. Targets may request to 1724 join the stream as described in Section 4.6.3 or, they may decide to 1725 leave a stream as described in Section 4.6.4. Section 4.6.5 explains 1726 how to change a stream's FlowSpec. 1728 As defined by Section 2, an ST agent can handle only one stream 1729 modification at a time. If a stream modification operation is already 1730 underway, further requests are queued and handled when the previous 1731 operation has been completed. This also applies to two subsequent 1732 requests of the same kind, e.g. two subsequent changes to the 1733 FlowSpec. 1735 4.6.1 The Origin Adding New Targets 1737 It is possible for an application at the origin to add new targets to 1738 an existing stream any time after the stream has been established. 1739 Before new targets are added, the application has to collect the 1740 necessary information on the new targets. Such information is passed 1741 to the ST agent at the origin. 1743 The ST agent at the origin issues a CONNECT message that contains the 1744 SID, the FlowSpec, and the TargetList specifying the new targets. This 1745 is similar to sending a CONNECT message during stream establishment, 1746 with the following exceptions: the origin checks that a) the SID is 1747 valid, b) the targets are not already members of the stream, c) that 1748 the LRM evaluates the FlowSpec of the new target to be the same as the 1749 FlowSpec of the existing stream, i.e it requires an equal or smaller 1750 amount of resources to be allocated. If the FlowSpec of the new target 1751 does not match the FlowSpec of the existing stream, an error is 1752 generated with ReasonCode (FlowSpecMismatch). Functions to compare 1753 flow specifications are provided by the LRM, see Section 1.4.5. 1755 An intermediate ST agent that is already a participant in the stream 1756 looks at the SID and StreamCreationTime, and verifies that the stream 1757 is the same. It then checks if the intersection of the TargetList and 1758 the targets of the established stream is empty. If this is not the 1759 case, it responds with a REFUSE message with ReasonCode (TargetExists) 1760 that contains a TargetList of those targets that were duplicates. To 1761 indicate that the stream exists, and includes the listed targets, the 1762 ST agent sets to one (1) the E-bit of the REFUSE message, see Section 1763 10.4.11. 1765 The agent then proceeds processing each new target in the TargetList. 1767 For each new target in the TargetList, processing is much the same as 1768 for the original CONNECT. The CONNECT is acknowledged, propagated, and 1769 network resources are reserved. Intermediate or target ST agents that 1770 are not already participants in the stream behave as in case of stream 1771 setup (see Section 4.5.4 and Section 4.5.5). 1773 4.6.2 The Origin Removing a Target 1775 It is possible for an application at the origin to remove existing 1776 targets of a stream any time after the targets have accepted the 1777 stream. The application at the origin specifies the set of targets 1778 that are to be removed and informs the local ST agent. Based on this 1779 information, the ST agent sends DISCONNECT messages with the 1780 ReasonCode (ApplDisconnect) to the next-hops relative to the targets. 1782 An ST agent that receives a DISCONNECT message must acknowledge it by 1783 sending an ACK to the previous-hop. The ST agent updates its state and 1784 notifies the LRM of the target deletion so that the LRM can modify 1785 reservations as appropriate. When the DISCONNECT message reaches the 1786 target, the ST agent also notifies the application that the target is 1787 no longer part of the stream. When there are no remaining targets that 1788 can be reached through a particular next-hop, the ST agent informs the 1789 LRM and it deletes the next-hop from its next-hops set. 1791 SCMP also provides a flooding mechanism to delete targets that joined 1792 the stream without notifying the origin. The special case of target 1793 deletion via flooding is described in Section 5.7. 1795 4.6.3 A Target Joining a Stream 1797 An application may request to join an existing stream. It has to 1798 collect information on the stream including the stream ID (SID) and 1799 the IP address of the stream's origin. This can be done out-of-band, 1800 e.g. via regular IP. The information is then passed to the local ST 1801 agent. The ST agent generates a JOIN message containing the 1802 application's request to join the stream and sends it toward the 1803 stream origin. 1805 An ST agent receiving a JOIN message, assuming no errors, responds 1806 with an ACK. The ACK message must identify the JOIN message to which 1807 it corresponds by including the Reference number indicated by the 1808 Reference field of the JOIN message. If the ST agent is not traversed 1809 by the stream that has to be joined, it propagates the JOIN message 1810 toward the stream's origin. Once a JOIN message has been acknowledged, 1811 ST agents do not retain any state information related to the JOIN 1812 message. 1814 Eventually, an ST agent traversed by the stream or the stream's origin 1815 itself is reached. This agent must respond to a received JOIN first 1816 with an ACK to the ST agent from which the message was received, then, 1817 it issues either a CONNECT or a JOIN-REJECT message and sends it 1818 toward the target. The response to the join request is based on the 1819 join authorization level associated with the stream, see Section 1820 4.4.2: 1822 o If the stream has authorization level #0 (refuse join): 1823 The ST agent sends a JOIN-REJECT message toward the target with 1824 ReasonCode (JoinAuthFailure). 1826 o If the stream has authorization level #1 (ok, notify origin): 1827 The ST agent sends a CONNECT message toward the target with a 1828 TargetList including the target that requested to join the stream. 1829 This eventually results in adding the target to the stream. When 1830 the ST agent receives the ACCEPT message indicating that the new 1831 target has been added, it does not propagate the ACCEPT message 1832 backwards (Section 4.5.6). Instead, it issues a NOTIFY message 1833 with ReasonCode (TargetJoined) so that upstream agents, including 1834 the origin, may add the new target to maintained state 1835 information. The NOTIFY message includes all target specific 1836 information. 1838 o If the stream has authorization level #2 (ok): 1839 The ST agent sends a CONNECT message toward the target with a 1840 TargetList including the target that requested to join the stream. 1841 This eventually results in adding the target to the stream. When 1842 the ST agent receives the ACCEPT message indicating that the new 1843 target has been added, it does not propagate the ACCEPT message 1844 backwards (Section 4.5.6), nor does it notify the origin. A NOTIFY 1845 message is generated with ReasonCode (TargetJoined) if the target 1846 specific information needs to be propagated back to the origin. An 1847 example of such information is change in MTU, see Section 8.6. 1849 4.6.3.1 Router as Origin 1851 When a stream has join authorization level #2, see Section 4.4.2, it 1852 is possible that the stream origin is unaware of some targets 1853 participating in the stream. In this case, the router ST agent that 1854 first sent a CONNECT message to this target has to act as the stream 1855 origin for the given target. This includes: 1857 o if the whole stream is deleted, the router must disconnect the 1858 target. 1860 o if the stream FlowSpec is changed, the router must change the 1861 FlowSpec for the target as appropriate. 1863 o proper handling of ACCEPT and REFUSE messages, without propagation 1864 to upstream ST agents. 1866 o generation of NOTIFY messages when needed. (As described above.) 1868 The router behaves normally for all other targets added to the stream 1869 as a consequence of a CONNECT message issued by the origin. 1871 4.6.4 A Target Deleting Itself 1873 The application at the target may inform the local ST agent that it 1874 wants to be removed from the stream. The ST agent then forms a REFUSE 1875 message with the target itself as the only entry in the TargetList and 1876 with ReasonCode (ApplDisconnect). The REFUSE message is sent back to 1877 the origin via the previous-hop. If a stream has multiple targets and 1878 one target leaves the stream using this REFUSE mechanism, the stream 1879 to the other targets is not affected; the stream continues to exist. 1881 An ST agent that receives a REFUSE message acknowledges it by sending 1882 an ACK to the next-hop. The target is deleted and the LRM is notified 1883 so that it adjusts reservations as appropriate. The REFUSE message is 1884 also propagated back to the previous-hop ST agent except in the case 1885 where the agent is acting as the origin. In this case a NOTIFY may be 1886 propagated instead, see Section 4.6.3. 1888 When the REFUSE reaches the origin, the origin sends an ACK and 1889 notifies the application that the target is no longer part of the 1890 stream. 1892 4.6.5 Changing a Stream's FlowSpec 1894 The application at the origin may wish to change the FlowSpec of an 1895 established stream. Changing the FlowSpec is a critical operation and 1896 it may even lead in some cases to the deletion of the affected 1897 targets. Possible problems with FlowSpec changes are discussed in 1898 Section 5.6. 1900 To change the stream's FlowSpec, the application informs the ST agent 1901 at the origin of the new FlowSpec and of the list of targets relative 1902 to the change. The ST agent at the origin then issues one CHANGE 1903 message per next-hop including the new FlowSpec and sends it to the 1904 relevant next-hop ST agents. If the G-bit field of the CHANGE message 1905 is set (1), the change affects all targets in the stream. 1907 The CHANGE message contains a bit called I-bit, see Section 10.4.3. By 1908 default, the I-bit is set to zero (0) to indicate that the LRM is 1909 expected to try and perform the requested FlowSpec change without 1910 risking to tear down the stream. Applications that desire a higher 1911 probability of success and are willing to take the risk of breaking 1912 the stream can indicate this by setting the I-bit to one (1). 1913 Applications that require the requested modification in order to 1914 continue operating are expected to set this bit. 1916 An intermediate ST agent that receives a CHANGE message first sends an 1917 ACK to the previous-hop and then provides the FlowSpec to the LRM. If 1918 the LRM can perform the change, the ST agent propagates the CHANGE 1919 messages along the established paths. 1921 If the whole process succeeds, the CHANGE messages will eventually 1922 reach the targets. Targets respond with an ACCEPT (or REFUSE) message 1923 that is propagated back to the origin. In processing the ACCEPT 1924 message on the way back to the origin, excess resources may be 1925 released by the LRM as described in Section 4.5.6. The REFUSE message 1926 must have the ReasonCode (ApplRefused). 1928 SCMP also provides a flooding mechanism to change targets that joined 1929 the stream without notifying the origin. The special case of target 1930 change via flooding is described in Section 5.7. 1932 4.7 Stream Tear Down 1933 A stream is usually terminated by the origin when it has no further 1934 data to send. A stream is also torn down if the application should 1935 terminate abnormally or if certain network failures are encountered. 1936 Processing in this case is identical to the previous descriptions 1937 except that the ReasonCode (ApplAbort, NetworkFailure, etc.) is 1938 different. 1940 When all targets have left a stream, the origin notifies the 1941 application of that fact, and the application is then responsible for 1942 terminating the stream. Note, however, that the application may decide 1943 to add targets to the stream instead of terminating it, or may just 1944 leave the stream open with no targets in order to permit stream joins. 1946 5 Exceptional Cases 1948 The previous descriptions covered the simple cases where everything 1949 worked. We now discuss what happens when things do not succeed. 1950 Included are situations where messages exceed a network MTU, are lost, 1951 the requested resources are not available, the routing fails or is 1952 inconsistent. 1954 5.1 Long ST Messages 1956 It is possible that an ST agent, or an application, will need to send 1957 a message that exceeds a network's Maximum Transmission Unit (MTU). 1958 This case must be handled but not via generic fragmentation, since ST2 1959 does not support generic fragmentation of either data or control 1960 messages. 1962 5.1.1 Handling of Long Data Packets 1964 ST agents discard data packets that exceed the MTU of the next-hop 1965 network. No error message is generated. Applications should avoid 1966 sending data packets larger than the minimum MTU supported by a given 1967 stream. The application, both at the origin and targets, can learn the 1968 stream minimum MTU through the MTU discovery mechanism described in 1969 Section 8.6. 1971 5.1.2 Handling of Long Control Packets 1973 Each ST agent knows the MTU of the networks to which it is connected, 1974 and those MTUs restrict the size of the SCMP message it can send. An 1975 SCMP message size can exceed the MTU of a given network for a number of 1976 reasons: 1978 o the TargetList parameter (Section 10.3.6) may be too long; 1980 o the RecordRoute parameter (Section 10.3.5) may be too long. 1982 o the UserData parameter (Section 10.3.7) may be too long; 1984 o the PDUInError field of the ERROR message (Section 10.4.6) may be 1985 too long; 1987 An ST agent receiving or generating a too long SCMP message should: 1989 o break the message into multiple messages, each carrying part of the 1990 TargetList. Any RecordRoute and UserData parameters are replicated 1991 in each message for delivery to all targets. Applications that 1992 support a large number of targets may avoid using long TargetList 1993 parameters, and are expected to do so, by exploiting the stream 1994 joining functions, see Section 4.6.3. One exception to this rule 1995 exists. In the case of a long TargetList parameter to be included in 1996 a STATUS-RESPONSE message, the TargetList parameter is just 1997 truncated to the point where the list can fit in a single message, 1998 see Section 8.4. 2000 o for down stream agents: if the TargetList parameter contains a 2001 single Target element and the message size is still too long, the ST 2002 agent should issue a REFUSE message with ReasonCode 2003 (RecordRouteSize) if the size of the RecordRoute parameter causes 2004 the SCMP message size to exceed the network MTU, or with ReasonCode 2005 (UserDataSize) if the size of the UserData parameter causes the SCMP 2006 message size to exceed the network MTU. If both RecordRoute and 2007 UserData parameters are present the ReasonCode (UserDataSize) should 2008 be sent. For messages generated at the target: the target ST agent 2009 must check for SCMP messages that may exceed the MTU on the complete 2010 target-to-origin path, and inform the application that a too long 2011 SCMP messages has been generated. The format for the error reporting 2012 is a local implementation issue. The error codes are the same as 2013 previously stated. 2015 ST agents generating too long ERROR messages, simply truncate the 2016 PDUInError field to the point where the message is smaller than the 2017 network MTU. 2019 5.2 Timeout Failures 2021 As described in Section 4.3, SCMP message delivery is made reliable 2022 through the use of acknowledgments, timeouts, and retransmission. The 2023 ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and 2024 REFUSE messages must always be acknowledged, see Section 4.2. In 2025 addition, for some SCMP messages (CHANGE, CONNECT, JOIN) the sending 2026 ST agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN- 2027 REJECT) after ACK has been received. Also, the STATUS message must be 2028 replied to with a STATUS-RESPONSE message. 2030 The following sections describe the handling of each of the possible 2031 failure cases due to timeout situations while waiting for an 2032 acknowledgment or a response. The timeout related variables, and their 2033 names, used in the next sections are for reference purposes only. They 2034 may be implementation specific. Different implementations are not 2035 required to share variable names, or even the mechanism by which the 2036 timeout and retransmission behavior is implemented. 2038 5.2.1 Failure due to ACCEPT Acknowledgment Timeout 2040 An ST agent that sends an ACCEPT message upstream expects an ACK from 2041 the previous-hop ST agent. If no ACK is received before the ToAccept 2042 timeout expires, the ST agent should retry and send the ACCEPT message 2043 again. After NAccept unsuccessful retries, the ST agent sends a REFUSE 2044 message toward the origin, and a DISCONNECT message toward the 2045 targets. Both REFUSE and DISCONNECT must identify the affected targets 2046 and specify the ReasonCode (RetransTimeout). 2048 5.2.2 Failure due to CHANGE Acknowledgment Timeout 2050 An ST agent that sends a CHANGE message downstream expects an ACK from 2051 the next-hop ST agent. If no ACK is received before the ToChange 2052 timeout expires, the ST agent should retry and send the CHANGE message 2053 again. After NChange unsuccessful retries, the ST agent aborts the 2054 change attempt by sending a REFUSE message toward the origin, and a 2055 DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must 2056 identify the affected targets and specify the ReasonCode 2057 (RetransTimeout). 2059 5.2.3 Failure due to CHANGE Response Timeout 2061 Only the origin ST agent implements this timeout. After correctly 2062 receiving the ACK to a CHANGE message, an ST agent expects to receive 2063 an ACCEPT, or REFUSE message in response. If one of these messages is 2064 not received before the ToChangeResp timer expires, the ST agent at 2065 the origin aborts the change attempt, and behaves as if a REFUSE 2066 message with the E-bit set and with ReasonCode (ResponseTimeout) is 2067 received. 2069 5.2.4 Failure due to CONNECT Acknowledgment Timeout 2071 An ST agent that sends a CONNECT message downstream expects an ACK 2072 from the next-hop ST agent. If no ACK is received before the ToConnect 2073 timeout expires, the ST agent should retry and send the CONNECT 2074 message again. After NConnect unsuccessful retries, the ST agent sends 2075 a REFUSE message toward the origin, and a DISCONNECT message toward 2076 the targets. Both REFUSE and DISCONNECT must identify the affected 2077 targets and specify the ReasonCode (RetransTimeout). 2079 5.2.5 Failure due to CONNECT Response Timeout 2081 Only the origin ST agent implements this timeout. After correctly 2082 receiving the ACK to a CONNECT message, an ST agent expects to receive 2083 an ACCEPT or REFUSE message in response. If one of these messages is 2084 not received before the ToConnectResp timer expires, the origin ST 2085 agent aborts the connection setup attempt, acts as if a REFUSE message 2086 is received, and it sends a DISCONNECT message toward the targets. 2087 Both REFUSE and DISCONNECT must identify the affected targets and 2088 specify the ReasonCode (ResponseTimeout). 2090 5.2.6 Failure due to DISCONNECT Acknowledgment Timeout 2092 An ST agent that sends a DISCONNECT message downstream expects an ACK 2093 from the next-hop ST agent. If no ACK is received before the 2094 ToDisconnect timeout expires, the ST agent should retry and send the 2095 DISCONNECT message again. After NDisconnect unsuccessful retries, the 2096 ST agent simply gives up and it assumes the next-hop ST agent is not 2097 part in the stream any more. 2099 5.2.7 Failure due to JOIN Acknowledgment Timeout 2101 An ST agent that sends a JOIN message toward the origin expects an ACK 2102 from a neighbour ST agent. If no ACK is received before the ToJoin 2103 timeout expires, the ST agent should retry and send the JOIN message 2104 again. After NJoin unsuccessful retries, the ST agent sends a JOIN- 2105 REJECT message back in the direction of the target with ReasonCode 2106 (RetransTimeout). 2108 5.2.8 Failure due to JOIN Response Timeout 2110 Only the target agent implements this timeout. After correctly 2111 receiving the ACK to a JOIN message, the ST agent at the target 2112 expects to receive a CONNECT or JOIN-REJECT message in response. If 2113 one of these message is not received before the ToJoinResp timer 2114 expires, the ST agent aborts the stream join attempt and returns an 2115 error corresponding with ReasonCode (RetransTimeout) to the 2116 application. 2118 Note that, after correctly receiving the ACK to a JOIN message, 2119 intermediate ST agents do not maintain any state on the stream joining 2120 attempt. As a consequence, they do not set the ToJoinResp timer and do 2121 not wait for a CONNECT or JOIN-REJECT message. This is described in 2122 Section 4.6.3. 2124 5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout 2126 An ST agent that sends a JOIN-REJECT message toward the target expects 2127 an ACK from a neighbour ST agent. If no ACK is received before the 2128 ToJoinReject timeout expires, the ST agent should retry and send the 2129 JOIN-REJECT message again. After NJoinReject unsuccessful retries, the 2130 ST agent simply gives up. 2132 5.2.10 Failure due to NOTIFY Acknowledgment Timeout 2134 An ST agent that sends a NOTIFY message to a neighbour ST agent 2135 expects an ACK from that neighbour ST agent. If no ACK is received 2136 before the ToNotify timeout expires, the ST agent should retry and 2137 send the NOTIFY message again. After NNotify unsuccessful retries, the 2138 ST agent simply gives up and behaves as if the ACK message was 2139 received. 2141 5.2.11 Failure due to REFUSE Acknowledgment Timeout 2143 An ST agent that sends a REFUSE message upstream expects an ACK from 2144 the previous-hop ST agent. If no ACK is received before the ToRefuse 2145 timeout expires, the ST agent should retry and send the REFUSE message 2146 again. After NRefuse unsuccessful retries, the ST agent gives up and 2147 it assumes it is not part in the stream any more. 2149 5.2.12 Failure due to STATUS Response Timeout 2151 After sending a STATUS message to a neighbour ST agent, an ST agent 2152 expects to receive a STATUS-RESPONSE message in response. If this 2153 message is not received before the ToStatusResp timer expires, the ST 2154 agent sends the STATUS message again. After NStatus unsuccessful 2155 retries, the ST agent gives up and assumes that the neighbor ST agent 2156 is not active. 2158 5.3 Setup Failures due to Routing Failures 2160 It is possible for an ST agent to receive a CONNECT message that 2161 contains a known SID, but from an ST agent other than the previous-hop 2162 ST agent of the stream with that SID. This may be: 2164 1. that two branches of the tree forming the stream have joined back 2165 together, 2167 2. the result of an attempted recovery of a partially failed stream, or 2169 3. a routing loop. 2171 The TargetList contained in the CONNECT is used to distinguish the 2172 different cases by comparing each newly received target with those of 2173 the previously existing stream: 2175 o if the IP address of the target(s) differ, it is case #1; 2177 o if the target matches a target in the existing stream, it may be 2178 case #2 or #3. 2180 Case #1 is handled in Section 5.3.1, while the other cases are handled 2181 in Section 5.3.2. 2183 5.3.1 Path Convergence 2185 It is possible for an ST agent to receive a CONNECT message that 2186 contains a known SID, but from an ST agent other than the previous-hop 2187 ST agent of the stream with that SID. This might be the result of two 2188 branches of the tree forming the stream have joined back together. 2189 Detection of this case and other possible sources was discussed in 2190 Section 5.2. 2192 SCMP does not allow for streams which have converged path, i.e streams 2193 are always tree-shaped and not graph-like. At the point of 2194 convergence, the ST agent which detects the condition generates a 2195 REFUSE message with ReasonCode (PathConvergence). Also, as a help to 2196 the upstream ST agent, the detecting agent places the IP address of 2197 one of the stream's connected targets in the ValidTargetIPAddress 2198 field of the REFUSE message. This IP address will be used by upstream 2199 ST agents to avoid splitting the stream. 2201 An upstream ST agent that receives the REFUSE with ReasonCode 2202 (PathConvergence) will check to see if the listed IP address is one of 2203 the known stream targets. If it is not, the REFUSE is propagated to 2204 the previous-hop agent. If the listed IP address is known by the 2205 upstream ST agent, this ST agent is the ST agent that caused the split 2206 in the stream. (This agent may even be the origin.) This agent then 2207 avoids splitting the stream by using the next-hop of that known target 2208 as the next-hop for the refused targets. It sends a CONNECT with the 2209 affected targets to the existing valid next-hop. 2211 The above process will proceed, hop by hop, until the 2212 ValidTargetIPAddress matches the IP address of a known target. The 2213 only case where this process will fail is when the known target is 2214 deleted prior to the REFUSE propagating to the origin. In this case 2215 the origin can just reissue the CONNECT and start the whole process 2216 over again. 2218 5.3.2 Other Cases 2220 The remaining cases including a partially failed stream and a routing 2221 loop, are not easily distinguishable. In attempting recovery of a 2222 failed stream, an ST agent may issue new CONNECT messages to the 2223 affected targets. Such a CONNECT may reach an ST agent downstream of 2224 the failure before that ST agent has received a DISCONNECT from the 2225 neighbourhood of the failure. Until that ST agent receives the 2226 DISCONNECT, it cannot distinguish between a failure recovery and an 2227 erroneous routing loop. That ST agent must therefore respond to the 2228 CONNECT with a REFUSE message with the affected targets specified in 2229 the TargetList and an appropriate ReasonCode (StreamExists). 2231 The ST agent immediately preceding that point, i.e., the latest ST 2232 agent to send the CONNECT message, will receive the REFUSE message. It 2233 must release any resources reserved exclusively for traffic to the 2234 listed targets. If this ST agent was not the one attempting the stream 2235 recovery, then it cannot distinguish between a failure recovery and an 2236 erroneous routing loop. It should repeat the CONNECT after a ToConnect 2237 timeout, see Section 5.2.4. If after NConnect retransmissions it 2238 continues to receive REFUSE messages, it should propagate the REFUSE 2239 message toward the origin, with the TargetList that specifies the 2240 affected targets, but with a different ReasonCode (RouteLoop). 2242 The REFUSE message with this ReasonCode (RouteLoop) is propagated by 2243 each ST agent without retransmitting any CONNECT messages. At each ST 2244 agent, it causes any resources reserved exclusively for the listed 2245 targets to be released. The REFUSE will be propagated to the origin in 2246 the case of an erroneous routing loop. In the case of stream recovery, 2247 it will be propagated to the ST agent that is attempting the recovery, 2248 which may be an intermediate ST agent or the origin itself. In the 2249 case of a stream recovery, the ST agent attempting the recovery may 2250 issue new CONNECT messages to the same or to different next-hops. 2252 If an ST agent receives both a REFUSE message and a DISCONNECT message 2253 with a target in common then it can, for the each target in common, 2254 release the relevant resources and propagate neither the REFUSE nor 2255 the DISCONNECT. 2257 If the origin receives such a REFUSE message, it should attempt to 2258 send a new CONNECT to all the affected targets. Since routing errors 2259 in an internet are assumed to be temporary, the new CONNECTs will 2260 eventually find acceptable routes to the targets, if one exists. If no 2261 further routes exist after NRetryRoute tries, the application should 2262 be informed so that it may take whatever action it seems necessary. 2264 5.4 Problems due to Routing Inconsistency 2266 When an intermediate ST agent receives a CONNECT, it invokes the 2267 routing algorithm to select the next-hop ST agents based on the 2268 TargetList and the networks to which it is connected. If the resulting 2269 next-hop to any of the targets is across the same network from which 2270 it received the CONNECT (but not the previous-hop itself), there may 2271 be a routing problem. However, the routing algorithm at the previous- 2272 hop may be optimizing differently than the local algorithm would in 2273 the same situation. Since the local ST agent cannot distinguish the 2274 two cases, it should permit the setup but send back to the previous- 2275 hop ST agent an informative NOTIFY message with the appropriate 2276 ReasonCode (RouteBack), pertinent TargetList, and in the 2277 NextHopIPAddress element the address of the next-hop ST agent returned 2278 by its routing algorithm. 2280 The ST agent that receives such a NOTIFY should ACK it. If the ST agent 2281 is using an algorithm that would produce such behaviour, no further 2282 action is taken; if not, the ST agent should send a DISCONNECT to the 2283 next-hop ST agent to correct the problem. 2285 Alternatively, if the next-hop returned by the routing function is in 2286 fact the previous-hop, a routing inconsistency has been detected. In 2287 this case, a REFUSE is sent back to the previous-hop ST agent 2288 containing an appropriate ReasonCode (RouteInconsist), pertinent 2289 TargetList, and in the NextHopIPAddress element the address of the 2290 previous-hop. When the previous-hop receives the REFUSE, it will 2291 recompute the next-hop for the affected targets. If there is a 2292 difference in the routing databases in the two ST agents, they may 2293 exchange CONNECT and REFUSE messages again. Since such routing errors 2294 in the internet are assumed to be temporary, the situation should 2295 eventually stabilize. 2297 5.5 Problems in Reserving Resources 2299 As mentioned in Section 1.4.5, resource reservation is handled by the 2300 LRM. The LRM may not be able to satisfy a particular request during 2301 stream setup or modification for a number of reasons, including a 2302 mismatched FlowSpec, an unknown FlowSpec version, an error in 2303 processing a FlowSpec, and an inability to allocate the requested 2304 resource. This section discusses these cases and specifies the 2305 ReasonCodes that should be used when these error cases are 2306 encountered. 2308 5.5.1 Mismatched FlowSpecs 2310 In some cases the LRM may require a requested FlowSpec to match an 2311 existing FlowSpec, e.g. when adding new targets to an existing stream, 2312 see Section 4.6.1. In case of FlowSpec mismatch the LRM notifies the 2313 processing ST agent which should respond with ReasonCode 2314 (FlowSpecMismatch). 2316 5.5.2 Unknown FlowSpec Version 2318 When the LRM is invoked, it is passed information including the 2319 version of the FlowSpec, see Section 4.5.2.2. If this version is not 2320 known by the LRM, the LRM notifies the ST agent. The ST agent should 2321 respond with a REFUSE message with ReasonCode (FlowVerUnknown). 2323 5.5.3 LRM Unable to Process FlowSpec 2325 The LRM may encounter an LRM or FlowSpec specific error while 2326 attempting to satisfy a request. An example of such an error is given 2327 in Section 9.2.1. These errors are implementation specific and will 2328 not be enumerated with ST ReasonCodes. They are covered by a single, 2329 generic ReasonCode. When an LRM encounters such an error, it should 2330 notify the ST agent which should respond with the generic ReasonCode 2331 (FlowSpecError). 2333 5.5.4 Insufficient Resources 2335 If the LRM cannot make the necessary reservations because sufficient 2336 resources are not available, an ST agent may: 2338 o try alternative paths to the targets: the ST agent calls the routing 2339 function to find a different path to the targets. If an alternative 2340 path is found, stream connection setup continues in the usual way, 2341 as described in Section 4.5. 2343 o refuse to establish the stream along this path: the origin ST agent 2344 informs the application of the stream setup failure; an ST agent at 2345 a router or target issues a REFUSE message (as described in Section 2346 4.5.8) with ReasonCode (CantGetResrc). 2348 It depends on the local implementations whether an ST agent tries 2349 alternative paths or refuses to establish the stream. In any case, if 2350 enough resources cannot be found over different paths, the ST agent 2351 has to explicitly refuse to establish the stream. 2353 5.6 Problems Caused by CHANGE Messages 2355 A CHANGE might fail for several reasons, including: 2357 o insufficient resources: the request may be for a larger amount of 2358 network resources when those resources are not available, ReasonCode 2359 (CantGetResrc); 2361 o a target application not agreeing to the change, ReasonCode 2362 (ApplRefused); 2364 The affected stream can be left in one of two states as a result of 2365 change failures: a) the stream can revert back to the state it was in 2366 prior to the CHANGE message being processed, or b) the stream may be 2367 torn down. 2369 The expected common case of failure will be when the requested change 2370 cannot be satisfied, but the pre-change resources remain allocated and 2371 available for use by the stream. In this case, the ST agent at the 2372 point where the failure occurred must inform upstream ST agents of the 2373 failure. (In the case where this ST agent is the target, there may not 2374 actually be a failure, the application may merely have not agreed to 2375 the change). The ST agent informs upstream ST agents by sending a 2376 REFUSE message with ReasonCode (CantGetResrc or ApplRefused). To 2377 indicate that the pre-change FlowSpec is still available and that the 2378 stream still exists, the ST agent sets the E-bit of the REFUSE message 2379 to one (1), see Section 10.4.11. Upstream ST agents receiving the 2380 REFUSE message inform the LRM so that it can attempt to revert back to 2381 the pre-change FlowSpec. It is permissible, but not desirable, for 2382 excess resources to remain allocated. 2384 For the case when the attempt to change the stream results in the loss 2385 of previously reserved resources, the stream is torn down. This can 2386 happen, for instance, when the I-bit is set (Section 4.6.5) and the 2387 LRM releases pre-change stream resources before the new ones are 2388 reserved, and neither new nor former resources are available. In this 2389 case, the ST agent where the failure occurs must inform other ST 2390 agents of the break in the affected portion of the stream. This is 2391 done by the ST agent by sending a REFUSE message upstream and a 2392 DISCONNECT message downstream, both with the ReasonCode 2393 (CantGetResrc). To indicate that pre-change stream resources have been 2394 lost, the E-bit of the REFUSE message is set to zero (0). 2396 Note that a failure to change the resources requested for specific 2397 targets should not cause other targets in the stream to be deleted. 2399 5.7 Unknown Targets in DISCONNECT and CHANGE 2401 The handling of unknown targets listed in a DISCONNECT or CHANGE 2402 message is dependent on a stream's join authorization level, see 2403 Section 4.4.2. For streams with join authorization levels #0 and #1, 2404 see Section 4.4.2, all targets must be known. In this case, when 2405 processing a CHANGE message, the agent should generate a REFUSE 2406 message with ReasonCode (TargetUnknown). When processing a DISCONNECT 2407 message, it is possible that the DISCONNECT is a duplicate of an old 2408 request so the agent should respond as if it has successfully 2409 disconnected the target. That is, it should respond with an ACK 2410 message. 2412 For streams with join authorization level #2, it is possible that the 2413 origin is not aware of some targets that participate in the stream. 2414 The origin may delete or change these targets via the following 2415 flooding mechanism. 2417 If no next-hop ST agent can be associated with a target, the CHANGE/ 2418 DISCONNECT message including the target is replicated to all known 2419 next-hop ST agents. This has the effect of propagating the CHANGE/ 2420 DISCONNECT message to all downstream ST agents. Eventually, the ST 2421 agent that acts as the origin for the target (Section 4.6.3.1) is 2422 reached and the target is deleted. 2424 Target deletion/change via flooding is not expected to be the normal 2425 case. It is included to present the applications with uniform 2426 capabilities for all stream types. Flooding only applies to streams 2427 with join authorization level #2. 2429 6 Failure Detection and Recovery 2431 6.1 Failure Detection 2433 The SCMP failure detection mechanism is based on two assumptions: 2435 1. If a neighbour of an ST agent is up, and has been up without a 2436 disruption, and has not notified the ST agent of a problem with 2437 streams that pass through both, then the ST agent can assume that 2438 there has not been any problem with those streams. 2440 2. A network through which an ST agent has routed a stream will notify 2441 the ST agent if there is a problem that affects the stream data 2442 packets but does not affect the control packets. 2444 The purpose of the robustness protocol defined here is for ST agents 2445 to determine that the streams through a neighbour have been broken by 2446 the failure of the neighbour or the intervening network. This protocol 2447 should detect the overwhelming majority of failures that can occur. 2448 Once a failure is detected, the recovery procedures described in 2449 Section 6.2 are initiated by the ST agents. 2451 6.1.1 Network Failures 2453 An ST agent can detect network failures by two mechanisms: 2455 o the network can report a failure, or 2457 o the ST agent can discover a failure by itself. 2459 They differ in the amount of information that an ST agent has 2460 available to it in order to make a recovery decision. For example, a 2461 network may be able to report that reserved bandwidth has been lost 2462 and the reason for the loss and may also report that connectivity to 2463 the neighbouring ST agent remains intact. On the other hand, an ST 2464 agent may discover that communication with a neighbouring ST agent has 2465 ceased because it has not received any traffic from that neighbour in 2466 some time period. If an ST agent detects a failure, it may not be able 2467 to determine if the failure was in the network while the neighbour 2468 remains available, or the neighbour has failed while the network 2469 remains intact. 2471 6.1.2 Detecting ST Agents Failures 2473 Each ST agent periodically sends each neighbour with which it shares 2474 one or more streams a HELLO message. This message exchange is between 2475 ST agents, not entities representing streams or applications. That is, 2476 an ST agent need only send a single HELLO message to a neighbour 2477 regardless of the number of streams that flow between them. All ST 2478 agents (host as well as intermediate) must participate in this 2479 exchange. However, only ST agents that share active streams can 2480 participate in this exchange and it is an error to send a HELLO 2481 message to a neighbour ST agent with no streams in common, e.g. to 2482 check whether it is active. STATUS messages can be used to poll status 2483 of neighbour ST agents, see Section 8.4. 2485 The HELLO message has two fields: 2487 o a HelloTimer field that is in units of milliseconds modulo the 2488 maximum for the field size, and 2490 o a Restarted-bit specifying that the ST agent has been restarted 2491 recently. 2493 The HelloTimer must appear to be incremented every millisecond whether 2494 a HELLO message is sent or not. The HelloTimer wraps around to zero 2495 after reaching the maximum value. Whenever an ST agent suffers a 2496 catastrophic event that may result in it losing ST state information, 2497 it must reset its HelloTimer to zero and must set the Restarted-bit in 2498 all HELLO messages sent in the following HelloTimerHoldDown seconds. 2500 If an ST agent receives a HELLO message that contains the Restarted- 2501 bit set, it must assume that the sending ST agent has lost its state. 2502 If it shares streams with that neighbour, it must initiate stream 2503 recovery activity, see Section 6.2. If it does not share streams with 2504 that neighbour, it should not attempt to create one until that bit is 2505 no longer set. If an ST agent receives a CONNECT message from a 2506 neighbour whose Restarted-bit is still set, it must respond with ERROR 2507 with the appropriate ReasonCode (RestartRemote). If it receives a 2508 CONNECT message while its own Restarted-bit is set, it must respond 2509 with ERROR with the appropriate ReasonCode (RestartLocal). 2511 Each ST stream has a RecoveryTimeout value associated with it. This 2512 value is assigned by the origin and carried into the CONNECT message, 2513 see Section 4.5.10. Each agent checks to see if it can support the 2514 requested value. If it can not, it updates the value to the smallest 2515 timeout interval it can support. The RecoveryTimeout used by a 2516 particular stream is obtained from the ACCEPT message, see Section 2517 4.5.10, and is the smallest value seen across all ACCEPT messages from 2518 participating targets. 2520 An ST agent must send HELLO messages to its neighbour with a period 2521 shorter than the smallest RecoveryTimeout of all the active streams 2522 that pass between the two ST agents, regardless of direction. This 2523 period must be smaller by a factor, called HelloLossFactor, which is 2524 at least as large as the greatest number of consecutive HELLO messages 2525 that could credibly be lost while the communication between the two ST 2526 agents is still viable. 2528 An ST agent may send simultaneous HELLO messages to all its neighbours 2529 at the rate necessary to support the smallest RecoveryTimeout of any 2530 active stream. Alternately, it may send HELLO messages to different 2531 neighbours independently at different rates corresponding to 2532 RecoveryTimeouts of individual streams. 2534 The ST agent that receives a HELLO message expects to receive at least 2535 one new HELLO message from a neighbour during the RecoveryTimeout of 2536 every active stream through that neighbour. It can detect duplicate or 2537 delayed HELLO messages by saving the HelloTimer field of the most 2538 recent valid HELLO message from that neighbour and comparing it with 2539 the HelloTimer field of incoming HELLO messages. It will only accept 2540 an incoming HELLO message from that neighbour if it has a HelloTimer 2541 field that is greater than the most recent valid HELLO message by the 2542 time elapsed since that message was received plus twice the maximum 2543 likely delay variance from that neighbour. 2545 If the ST agent does not receive a valid HELLO message within the 2546 RecoveryTimeout of a stream, it must assume that the neighbouring ST 2547 agent or the communication link between the two has failed and it must 2548 initiate stream recovery activity, as described below in Section 6.2. 2550 6.2 Failure Recovery 2552 If an intermediate ST agent fails or a network or part of a network 2553 fails, the previous-hop ST agent and the various next-hop ST agents 2554 will discover the fact by the failure detection mechanism described in 2555 Section 6.1. 2557 The recovery of an ST stream is a relatively complex and time 2558 consuming effort because it is designed in a general manner to operate 2559 across a large number of networks with diverse characteristics. 2560 Therefore, it may require information to be distributed widely, and 2561 may require relatively long timers. On the other hand, since a network 2562 is typically a homogeneous system, failure recovery in the network may 2563 be a relatively faster and simpler operation. Therefore an ST agent 2564 that detects a failure should attempt to fix the network failure 2565 before attempting recovery of the ST stream. If the stream that 2566 existed between two ST agents before the failure cannot be 2567 reconstructed by network recovery mechanisms alone, then the ST stream 2568 recovery mechanism must be invoked. 2570 If stream recovery is necessary, the different ST agents will need to 2571 perform different functions, depending on their relation to the 2572 failure: 2574 o An ST agent that is a next-hop of a failure should first verify that 2575 there was a failure. It can do this using STATUS messages to query 2576 its upstream neighbour. If it cannot communicate with that 2577 neighbour, then for each active stream from that neighbour it should 2578 first send a REFUSE message upstream with the appropriate ReasonCode 2579 (STAgentFailure). This is done to the neighbour to speed up the 2580 failure recovery in case the hop is unidirectional, i.e., the 2581 neighbour can hear the ST agent but the ST agent cannot hear the 2582 neighbour. The ST agent detecting the failure must then, for each 2583 active stream from that neighbour, send DISCONNECT messages with the 2584 same ReasonCode toward the targets. All downstream ST agents process 2585 this DISCONNECT message just like the DISCONNECT that tears down the 2586 stream. If recovery is successful, targets will receive new CONNECT 2587 messages. 2589 o An ST agent that is the previous-hop before the failed component 2590 first verifies that there was a failure by querying the downstream 2591 neighbour using STATUS messages. If the neighbour has lost its state 2592 but is available, then the ST agent may try and reconstruct 2593 (explained below) the affected streams, for those streams that do 2594 not have the NoRecovery option selected. If it cannot communicate 2595 with the next-hop, then the ST agent detecting the failure sends a 2596 DISCONNECT message, for each affected stream, with the appropriate 2597 ReasonCode (STAgentFailure) toward the affected targets. It does so 2598 to speed up failure recovery in case the communication may be 2599 unidirectional and this message might be delivered successfully. 2601 Based on the NoRecovery option, the ST agent that is the previous-hop 2602 before the failed component takes the following actions: 2604 o If the NoRecovery option is selected, then the ST agent sends, per 2605 affected stream, a REFUSE message with the appropriate ReasonCode 2606 (STAgentFailure) to the previous-hop. The TargetList in these 2607 messages contains all the targets that were reached through the 2608 broken branch. As discussed in Section 5.1.2, multiple REFUSE 2609 messages may be required if the PDU is too long for the MTU of the 2610 intervening network. The REFUSE message is propagated all the way to 2611 the origin. The application at the origin can attempt recovery of 2612 the stream by sending a new CONNECT to the affected targets. For 2613 established streams, the new CONNECT will be treated by intermediate 2614 ST agents as an addition of new targets into the established stream. 2616 o If the NoRecovery option is not selected, the ST agent can attempt 2617 recovery of the affected streams. It does so one a stream by stream 2618 basis by issuing a new CONNECT message to the affected targets. If 2619 the ST agent cannot find new routes to some targets, or if the only 2620 route to some targets is through the previous-hop, then it sends one 2621 or more REFUSE messages to the previous-hop with the appropriate 2622 ReasonCode (CantRecover) specifying the affected targets in the 2623 TargetList. The previous-hop can then attempt recovery of the stream 2624 by issuing a CONNECT to those targets. If it cannot find an 2625 appropriate route, it will propagate the REFUSE message toward the 2626 origin. 2628 Regardless of which ST agent attempts recovery of a damaged stream, it 2629 will issue one or more CONNECT messages to the affected targets. These 2630 CONNECT messages are treated by intermediate ST agents as additions of 2631 new targets into the established stream. The FlowSpecs of the new 2632 CONNECT messages are the same as the ones contained in the most recent 2633 CONNECT or CHANGE messages that the ST agent had sent toward the 2634 affected targets when the stream was operational. 2636 Upon receiving an ACCEPT during the a stream recovery, the agent 2637 reconstructing the stream must ensure that the FlowSpec and other 2638 stream attributes (e.g. MaxMsgSize and RecoveryTimeout) of the re- 2639 established stream are equal to, or are less restrictive, than the 2640 pre-failure stream. If they are more restrictive, the recovery attempt 2641 must be aborted. If they are equal, or are less restrictive, then the 2642 recovery attempt is successful. When the attempt is a success, failure 2643 recovery related ACCEPTs are not forwarded upstream by the recovering 2644 agent. 2646 Any ST agent that decides that enough recovery attempts have been 2647 made, or that recovery attempts have no chance of succeeding, may 2648 indicate that no further attempts at recovery should be made. This is 2649 done by setting the N-bit in the REFUSE message, see Section 10.4.11. 2650 This bit must be set by agents, including the target, that know that 2651 there is no chance of recovery succeeding. An ST agent that receives a 2652 REFUSE message with the N-bit set (1) will not attempt recovery, 2653 regardless of the NoRecovery option, and it will set the N-bit when 2654 propagating the REFUSE message upstream. 2656 6.2.1 Problems in Stream Recovery 2658 The reconstruction of a broken stream may not proceed smoothly. Since 2659 there may be some delay while the information concerning the failure 2660 is propagated throughout an internet, routing errors may occur for 2661 some time after a failure. As a result, the ST agent attempting the 2662 recovery may receive ERROR messages for the new CONNECTs that are 2663 caused by internet routing errors. The ST agent attempting the 2664 recovery should be prepared to resend CONNECTs before it succeeds in 2665 reconstructing the stream. If the failure partitions the internet and 2666 a new set of routes cannot be found to the targets, the REFUSE 2667 messages will eventually be propagated to the origin, which can then 2668 inform the application so it can decide whether to terminate or to 2669 continue to attempt recovery of the stream. 2671 The new CONNECT may at some point reach an ST agent downstream of the 2672 failure before the DISCONNECT does. In this case, the ST agent that 2673 receives the CONNECT is not yet aware that the stream has suffered a 2674 failure, and will interpret the new CONNECT as resulting from a 2675 routing failure. It will respond with an ERROR message with the 2676 appropriate ReasonCode (StreamExists). Since the timeout that the ST 2677 agents immediately preceding the failure and immediately following the 2678 failure are approximately the same, it is very likely that the 2679 remnants of the broken stream will soon be torn down by a DISCONNECT 2680 message. Therefore, the ST agent that receives the ERROR message with 2681 ReasonCode (StreamExists) should retransmit the CONNECT message after 2682 the ToConnect timeout expires. If this fails again, the request will 2683 be retried for NConnect times. Only if it still fails will the ST 2684 agent send a REFUSE message with the appropriate ReasonCode 2685 (RouteLoop) to its previous-hop. This message will be propagated back 2686 to the ST agent that is attempting recovery of the damaged stream. 2687 That ST agent can issue a new CONNECT message if it so chooses. The 2688 REFUSE is matched to a CONNECT message created by a recovery operation 2689 through the LnkReference field in the CONNECT. 2691 ST agents that have propagated a CONNECT message and have received a 2692 REFUSE message should maintain this information for some period of 2693 time. If an ST agent receives a second CONNECT message for a target 2694 that recently resulted in a REFUSE, that ST agent may respond with a 2695 REFUSE immediately rather than attempting to propagate the CONNECT. 2696 This has the effect of pruning the tree that is formed by the 2697 propagation of CONNECT messages to a target that is not reachable by 2698 the routes that are selected first. The tree will pass through any 2699 given ST agent only once, and the stream setup phase will be completed 2700 faster. 2702 If a CONNECT message reaches a target, the target should as 2703 efficiently as possible use the state that it has saved from before 2704 the stream failed during recovery of the stream. It will then issue an 2705 ACCEPT message toward the origin. The ACCEPT message will be 2706 intercepted by the ST agent that is attempting recovery of the damaged 2707 stream, if not the origin. If the FlowSpec contained in the ACCEPT 2708 specifies the same selection of parameters as were in effect before 2709 the failure, then the ST agent that is attempting recovery will not 2710 propagate the ACCEPT. FlowSpec comparison is done by the LRM. If the 2711 selections of the parameters are different, then the ST agent that is 2712 attempting recovery will send the origin a NOTIFY message with the 2713 appropriate ReasonCode (FailureRecovery) that contains a FlowSpec that 2714 specifies the new parameter values. The origin may then have to change 2715 its data generation characteristics and the stream's parameters with a 2716 CHANGE message to use the newly recovered subtree. 2718 6.3 Stream Preemption 2720 As mentioned in Section 1.4.5, it is possible that the LRM decides to 2721 break a stream intentionally. This is called stream preemption. 2722 Streams are expected to be preempted in order to free resources for a 2723 new stream which has a higher priority. 2725 If the LRM decides that it is necessary to preempt one or more of the 2726 stream traversing it, the decision on which streams have to be 2727 preempted has to be made. There are two ways for an application to 2728 influence such decision: 2730 1. based on FlowSpec information. For instance, with the ST2+ FlowSpec, 2731 streams can be assigned a precedence value from 0 (least important) 2732 to 256 (most important). This value is carried in the FlowSpec when 2733 the stream is setup, see Section 9.2, so that the LRM is informed 2734 about it. 2736 2. with the group mechanism. An application may specify that a set of 2737 streams are related to each other and that they are all candidate 2738 for preemption if one of them gets preempted. It can be done by 2739 using the fate-sharing relationship defined in Section 7.1.2. This 2740 helps the LRM making a good choice when more than one stream have to 2741 be preempted, because it leads to breaking a single application as 2742 opposed to as many applications as the number of preempted streams. 2744 If the LRM preempts a stream, it must notify the local ST agent. The 2745 following actions are performed by the ST agent: 2747 o The ST agent at the host where the stream was preempted sends 2748 DISCONNECT messages with the appropriate ReasonCode 2749 (StreamPreempted) toward the affected targets. It sends a REFUSE 2750 message with the appropriate ReasonCode (StreamPreempted) to the 2751 previous-hop. 2753 o A previous-hop ST agent of the preempted stream acts as in case of 2754 failure recovery, see Section 6.2. 2756 o A next-hop ST agent of the preempted stream acts as in case of 2757 failure recovery, see Section 6.2. 2759 Note that, as opposite to failure recovery, there is no need to verify 2760 that the failure actually occurred, because this is explicitly 2761 indicated by the ReasonCode (StreamPreempted). 2763 7 A Group of Streams 2765 There may be need to associate related streams. The group mechanism is 2766 simply an association technique that allows ST agents to identify the 2767 different streams that are to be associated. 2769 A group consists of a set of streams and a relationship. The set of 2770 streams may be empty. The relationship applies to all group members. 2771 Each group is identified by a group name. The group name must be 2772 globally unique. 2774 Streams belong to the same group if they have the same GroupName in 2775 the GroupName field of the Group parameter, see Section 10.3.2. The 2776 relationship is defined by the Relationship field. Group membership 2777 must be specified at stream creation time and persists for the whole 2778 stream lifetime. A single stream may belong to multiple groups. 2780 The ST agent that creates a new group is called group initiator. Any 2781 ST agent can be a group initiator. The initiator allocates the 2782 GroupName and the Relationship among group members. The initiator may 2783 or may not be the origin of a stream belonging to the group. GroupName 2784 generation is described in Section 8.2. 2786 7.1 Basic Group Relationships 2788 This version of ST defines four basic group relationships. An ST2+ 2789 implementation must support all four basic relationships. Adherence to 2790 specified relationships are usually best effort. The basic 2791 relationships are described in detail below in Section 7.1.1 - Section 2792 7.1.4. 2794 7.1.1 Bandwidth Sharing 2796 Streams associated with the same group share the same network 2797 bandwidth. The intent is to support applications such as audio 2798 conferences where, of all participants, only some are allowed to speak 2799 at one time. In such a scenario, global bandwidth utilization can be 2800 lowered by allocating only those resources that can be used at once, 2801 e.g. it is sufficient to reserve bandwidth for a small set of audio 2802 streams. 2804 The basic concept of a shared bandwidth group is that the LRM will 2805 allocate up to some specified multiplier of the most demanding stream 2806 that it knows about in the group. The LRM will allocate resources 2807 incrementally, as stream setup requests are received, until the total 2808 group requirements are satisfied. Subsequent setup requests will share 2809 the group's resources and will not need any additional resources 2810 allocated. The procedure will result in standard allocation where only 2811 one stream in a group traverses an agent, and shared allocations where 2812 multiple streams traverse an agent. 2814 To illustrate, let's call the multiplier mentioned above "N", and the 2815 most demanding stream that an agent knows about in a group Bmax. For 2816 an application that intends to allow three participants to speak at 2817 the same time, N has a value of three and each LRM will allocate for 2818 the group an amount of bandwidth up to 3*Bmax even when there are many 2819 more steams in the group. The LRM will reserve resources 2820 incrementally, per stream request, until N*Bmax resources are 2821 allocated. Each agent may be traversed by a different set and number 2822 of streams all belonging to the same group. 2824 An ST agent receiving a stream request presents the LRM with all 2825 necessary group information, see Section 4.5.2.2. If maximum 2826 bandwidth, N*Bmax, for the group has already been allocated and a new 2827 stream with a bandwidth demand less than Bmax is being established, 2828 the LRM won't allocate any further bandwidth. 2830 If there is less than N*Bmax resources allocated, the LRM will expand 2831 the resources allocated to the group by the amount requested in the 2832 new FlowSpec, up to N*Bmax resources. The LRM will update the FlowSpec 2833 based on what resources are available to the stream, but not the total 2834 resources allocated for the group. 2836 It should be noted that ST agents and LRMs become aware of a group's 2837 requirements only when the streams belonging to the group are created. 2838 In case of the bandwidth sharing relationship, an application should 2839 attempt to establish the most demanding streams first to minimize 2840 stream setup efforts. If on the contrary the less demanding streams 2841 are built first, it will be always necessary to allocate additional 2842 bandwidth in consecutive steps as the most demanding streams are 2843 built. It is also up to the applications to coordinate their different 2844 FlowSpecs and decide upon an appropriate value for N. 2846 7.1.2 Fate Sharing 2848 Streams belonging to this group share the same fate. If a stream is 2849 deleted, the other members of the group are also deleted. This is 2850 intended to support stream preemption by indicating which streams are 2851 mutually related. If preemption of multiple streams is necessary, this 2852 information can be used by the LRM to delete a set of related streams, 2853 e.g. with impact on a single application, instead of making a random 2854 choice with the possible effect of interrupting several different 2855 applications. This attribute does not apply to normal stream shut 2856 down, i.e. ReasonCode (ApplDisconnect). On normal disconnect, other 2857 streams belonging to such groups remain active. 2859 This relationship provides a hint on which streams should be 2860 preempted. Still, the LRM responsible for the preemption is not forced 2861 to behave accordingly, and other streams could be preempted first 2862 based on different criteria. 2864 7.1.3 Route Sharing 2866 Streams belonging to this group share the same paths as much as is 2867 possible. This can be desirable for several reasons, e.g. to exploit 2868 the same allocated resources or in the attempt to maintain the 2869 transmission order. An ST agent attempts to select the same path 2870 although the way this is implemented depends heavily on the routing 2871 algorithm which is used. 2873 If the routing algorithm is sophisticated enough, an ST agent can 2874 suggest that a stream is routed over an already established path. 2875 Otherwise, it can ask the routing algorithm for a set of legal routes 2876 to the destination and check whether the desired path is included in 2877 those feasible. 2879 Route sharing is a hint to the routing algorithm used by ST. Failing 2880 to route a stream through a shared path should not prevent the 2881 creation of a new stream or result in the deletion of an existing 2882 stream. 2884 7.1.4 Subnet Resources Sharing 2886 This relationship provides a hint to the data link layer functions. 2887 Streams belonging to this group may share the same MAC layer 2888 resources. As an example, the same MAC layer multicast address may be 2889 used for all the streams in a given group. This mechanism allows for a 2890 better utilization of MAC layer multicast addresses and it is 2891 especially useful when used with network adapters that offer a very 2892 small number of MAC layer multicast addresses. 2894 7.2 Relationships Orthogonality 2896 The four basic relationships, as they have been defined, are 2897 orthogonal. This means, any combinations of the basic relationships 2898 are allowed. For instance, let's consider an application that requires 2899 full-duplex service for a stream with multiple targets. Also, let's 2900 suppose that only N targets are allowed to send data back to the 2901 origin at the same time. In this scenario, all the reverse streams 2902 could belong to the same group. They could be sharing both the paths 2903 and the bandwidth attributes. The Path&Bandwidth sharing relationship 2904 is obtained from the basic set of relationships. This example is 2905 important because it shows how full-duplex service can be efficiently 2906 obtained in ST. 2908 8 Ancillary Functions 2910 Certain functions are required by ST host and intermediate agent 2911 implementations. Such functions are described in this section. 2913 8.1 Stream ID Generation 2915 The stream ID, or SID, is composed of 16-bit unique identifier and the 2916 stream origin's 32-bit IP address. Stream IDs must be globally unique. 2917 The specific definition and format of the 16 -bit field is left to the 2918 implementor. This field is expected to have only local significance. 2920 An ST implementation has to provide a stream ID generator facility, so 2921 that an application or higher layer protocol can obtain a unique IDs 2922 from the ST layer. This is a mechanism for the application to request 2923 the allocation of stream ID that is independent of the request to 2924 create a stream. The Stream ID is used by the application or higher 2925 layer protocol when creating the streams. 2927 For instance, the following two functions could be made available: 2929 o AllocateStreamID() -> result, StreamID 2931 o ReleaseStreamID(StreamID) -> result 2933 An implementation may also provide a StreamID deletion function. 2935 8.2 Group Name Generator 2937 GroupName generation is similar to Stream ID generation. The GroupName 2938 includes a 16-bit unique identifier, a 32-bit creation timestamp, and 2939 a 32-bit IP address. Group names are globally unique. A GroupName 2940 includes the creator's IP address, so this reduces a global uniqueness 2941 problem to a simple local problem. The specific definitions and 2942 formats of the 16-bit field and the 32-bit creation timestamp are left 2943 to the implementor. These fields must be locally unique, and only have 2944 local significance. 2946 An ST implementation has to provide a group name generator facility, 2947 so that an application or higher layer protocol can obtain a unique 2948 GroupName from the ST layer. This is a mechanism for the application 2949 to request the allocation of a GroupName that is independent of the 2950 request to create a stream. The GroupName is used by the application 2951 or higher layer protocol when creating the streams that are to be part 2952 of the group. 2954 For instance, the following two functions could be made available: 2956 o AllocateGroupName() -> result, GroupName 2958 o ReleaseGroupName(GroupName) -> result 2960 An implementation may also provide a GroupName deletion function. 2962 8.3 Checksum Computation 2964 The standard Internet checksum algorithm is used for ST: "The checksum 2965 field is the 16-bit one's complement of the one's complement sum of 2966 all 16-bit words in the header. For purposes of computing the 2967 checksum, the value of the checksum field is zero (0)." See [RFC1071], 2968 [RFC1141], and [RFC791] for suggestions for efficient checksum 2969 algorithms. 2971 8.4 Neighbour ST Agent Identification and Information Collection 2973 The STATUS message can be used to collect information about neighbour 2974 ST agents, streams the neighbour supports, and specific targets of 2975 streams the neighbour supports. An agent receiving a STATUS message 2976 provides the requested information via a STATUS-RESPONSE message. 2978 The STATUS message can be used to collect different information from a 2979 neighbour. It can be used to: 2981 o identifying ST capable neighbours. If an ST agent wishes to check if 2982 a neighbour is ST capable, it should generate a STATUS message with 2983 an SID which has all its fields set to zero. An agent receiving a 2984 STATUS message with such SID should answer with a STATUS-RESPONSE 2985 containing the same SID, and no other stream information. The 2986 receiving ST agent must answer as soon as possible to aid in Round 2987 Trip Time estimation, see Section 8.5; 2989 o obtain information on a particular stream. If an ST agent wishes to 2990 check a neighbour's general information related to a specific 2991 stream, it should generate a STATUS message containing the stream's 2992 SID. An ST agent receiving such a message, will first check to see 2993 if the stream is known. If not known, the receiving ST agent sends a 2994 STATUS-RESPONSE containing the same SID, and no other stream 2995 information. If the stream is known, the receiving ST agent sends a 2996 STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group 2997 membership (if any), and as many targets as can be included in a 2998 single message as limited by MTU, see Section 5.1.2. Note that all 2999 targets may not be included in a response to a request for general 3000 stream information. If information on a specific target in a stream 3001 is desired, the mechanism described next should be used. 3003 o obtain information on particular targets in a stream. If an ST agent 3004 wishes to check a neighbour's information related to on or more 3005 specific targets of a specific stream, it should generate a STATUS 3006 message containing the stream's SID and a TargetList parameter 3007 listing the relevant targets. An ST agent receiving such a message, 3008 will first check to see if the stream and target are known. If the 3009 stream is not known, the agent follows the process described above. 3010 If both the stream and targets are known, the agent responds with 3011 STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group 3012 membership (if any), and the requested targets that are known. If 3013 the stream is known but the target is not, the agent responds with a 3014 STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group 3015 membership (if any), but no targets. 3017 The specific formats for STATUS and STATUS-RESPONSE messages are 3018 defined in Section 10.4.12 and Section 10.4.13. 3020 8.5 Round Trip Time Estimation 3022 SCMP is made reliable through use of retransmission when an expected 3023 acknowledgment is not received in a timely manner. Timeout and 3024 retransmission algorithm is implementation dependent and it is outside 3025 the scope of this document. However, it must be reasonable enough not 3026 to cause excessive retransmission of SCMP message while maintaining 3027 the robustness of the protocol. Algorithms on this subject are 3028 described in [WoHD95], [Jaco88], [KaPa87]. 3030 Most existing algorithms are based on an estimation of the Round Trip 3031 Time (RTT) between two hosts. With SCMP, if an ST agent wishes to have 3032 an estimate of the RTT to and from a neighbour, it should generate a 3033 STATUS message with an SID which has all its fields set to zero. An ST 3034 agent receiving a STATUS message with such SID should answer as 3035 rapidly as possible with a STATUS-RESPONSE message containing the same 3036 SID, and no other stream information. The time interval between the 3037 send and receive operations can be used as an estimate of the RTT to 3038 and from the neighbour. 3040 8.6 Network MTU Discovery 3041 At connection setup, the application at the origin asks the local ST 3042 agent to create streams with certain QoS requirements. The local ST 3043 agent fills out its network MTU value in the MaxMsgSize parameter in 3044 the CONNECT message and forwards it to the next-hop ST agents. Each ST 3045 agent in the path checks to see if it's network MTU is smaller than the 3046 one specified in the CONNECT message and, if it is, the ST agent 3047 updates the MaxMsgSize in the CONNECT message to it's network MTU. If 3048 the target application decides to accept the stream, the ST agent at 3049 the target copies the MTU value in the CONNECT message to appropriate 3050 field in the ACCEPT message and sends it back to the application at 3051 the origin. The MaxMsgSize field in the ACCEPT message is the minimum 3052 MTU of network to that target. If the application has multiple targets 3053 then the minimum MTU of the stream is the smallest MaxMsgSize received 3054 from all the ACCEPT messages. It is the responsibility of the 3055 application to segment its PDUs according to the minimum MaxMsgSize of 3056 the stream since no data fragmentation is supported during the data 3057 transfer phase. If a particular target's MaxMsgSize is unacceptable to 3058 an application, it may disconnect the target from the stream and 3059 assume that the target cannot be supported. The application or 3060 application interface will need to take into account ST data header 3061 size in order to the application to make it's evaluation. 3063 8.7 IP Encapsulation of ST 3065 ST packets may be encapsulated in IP to allow them to pass through 3066 routers that don't support the ST Protocol. Of course, ST resource 3067 management is precluded over such a path, and packet overhead is 3068 increased by encapsulation, but if the performance is reasonably 3069 predictable this may be better than not communicating at all. 3071 IP-encapsulated ST packets begin with a normal IP header. Most fields 3072 of the IP header should be filled in according to the same rules that 3073 apply to any other IP packet. Three fields of special interest are: 3075 o Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed , 3076 as opposed to TCP or UDP, for example. 3078 o Destination Address is that of the next-hop ST agent. This may or 3079 may not be the target of the ST stream. There may be an intermediate 3080 ST agent to which the packet should be routed to take advantage of 3081 service guarantees on the path past that agent. Such an intermediate 3082 agent would not be on a directly-connected network (or else IP 3083 encapsulation wouldn't be needed), so it would probably not be 3084 listed in the normal routing table. Additional routing mechanisms, 3085 not defined here, will be required to learn about such agents. 3087 o Type-of-Service may be set to an appropriate value for the service 3088 being requested, see [RFC1700]. This feature is not implemented 3089 uniformly in the Internet, so its use can't be precisely defined 3090 here. 3092 IP encapsulation adds little difficulty for the ST agent that receives 3093 the packet. However, when IP encapsulation is performed it must be 3094 done in both directions. To process the encapsulated IP message, the 3095 ST agents simply remove the IP header and proceed with ST header as 3096 usual. 3098 The more difficult part is during setup, when the ST agent must decide 3099 whether or not to encapsulate. If the next-hop ST agent is on a remote 3100 network and the route to that network is through a router that 3101 supports IP but not ST, then encapsulation is required. The ST agents 3102 make encapsulation decision based on information provided by routing 3103 function to indicate whether the routers in the path support ST. 3105 On forwarding, the (mostly constant) IP Header must be inserted and 3106 the IP checksum appropriately updated. 3108 Applications are informed about the number of IP hops traversed on the 3109 way to the targets. The IPHops field value of the CONNECT message, see 3110 Section 10.4.4, is incremented at this purpose in case an ST agent 3111 uses IP encapsulation to reach its next-hop. The value is then 3112 returned to the origin in the IPHops field of the ACCEPT message, 3113 Section 10.4.1. 3115 When using IP Encapsulation, the MaxMsgSize field will not reflect the 3116 MTU of the IP encapsulated segments. This means that IP fragmentation 3117 and reassembly may be needed in the IP cloud to support a message of 3118 MaxMsgSize. IP fragmentation can only occur when the MTU of the IP 3119 cloud, less IP header length, is the smallest MTU in a stream's 3120 network path. 3122 8.8 IP Multicasting 3124 If an ST agent must use IP encapsulation to reach multiple next-hops 3125 toward different targets, then either the packet must be replicated 3126 for transmission to each next-hop, or IP multicasting may be used if 3127 it is implemented in the next-hop ST agents and in the intervening IP 3128 routers. 3130 When the stream is established, the collection of next-hop ST agents 3131 must be set up as an IP multicast group. The ST agent must allocate 3132 appropriate IP multicast address (see Section 10.3.3) and fill that 3133 address in the IPMulticastAddress field of the CONNECT message. The IP 3134 multicast address in the CONNECT message is used to inform the next- 3135 hop ST agents that they should join the multicast group to receive 3136 subsequent PDUs. Obviously, the CONNECT message itself must be sent 3137 using unicast. The next-hop ST agents must be able to receive on the 3138 specified multicast address in order to accept the connection. 3140 If the next-hop ST agent can not receive on the specified multicast 3141 address, it sends a REFUSE message with ReasonCode (BadMcastAddress). 3142 Upon receiving the REFUSE, the upstream agent can choose to retry with 3143 a different multicast address. Alternatively, it can choose to loose 3144 the efficiency of multicast and use unicast delivery. 3146 The following permanent IP multicast addresses have been assigned to 3147 ST: 3149 224.0.0.7 All ST routers (intermediated agents) 3150 224.0.0.8 All ST hosts (agents) 3152 In addition, a block of transient IP multicast addresses, 224.1.0.0 - 3153 224.1.255.255, has been allocated for ST multicast groups. For 3154 instance, the following two functions could be made available: 3156 o AllocateMcastAddr() -> result, McastAddr 3158 o ListenMcastAddr(McastAddr) -> result 3160 o ReleaseMcastAddr(McastAddr) -> result 3162 9 The ST2+ Flow Specification 3164 This section defines the ST2+ flow specification. The flow 3165 specification contains the user application requirements in terms of 3166 quality of service. Its contents are LRM dependent and are transparent 3167 to the ST2 setup protocol. ST2 carries the flow specification as part 3168 of the FlowSpec parameter, which is described in Section 10.3.1. The 3169 required ST2+ flow specification is included in the protocol only to 3170 support interoperability. ST2+ also defines a "null" flow 3171 specification to be used only to support testing. 3173 ST2 is not dependent on a particular flow specification format and it 3174 is expected that other versions of the flow specification will be 3175 needed in the future. Different flow specification formats are 3176 distinguished by the value of the Version field of the FlowSpec 3177 parameter, see Section 10.3.1. A single stream is always associated 3178 with a single flow specification format, i.e. the Version field is 3179 consistent throughout the whole stream. The following Version field 3180 values are defined: 3182 0 - Null FlowSpec /* must be supported */ 3183 1 - ST Version 1 3184 2 - ST Version 1.5 3185 3 - RFC 1190 FlowSpec 3186 4 - HeiTS FlowSpec 3187 5 - BerKom FlowSpec 3188 6 - RFC 1363 FlowSpec 3189 7 - ST2+ FlowSpec /* must be supported */ 3191 FlowSpecs version #0 and #7 must be supported by ST2+ implementations. 3192 Version numbers in the range 1-6 indicate flow specifications are 3193 currently used in existing ST2 implementations. Values in the 128-255 3194 range are reserved for private and experimental use. 3196 9.1 FlowSpec Version #0 - (Null FlowSpec) 3198 The flow specification identified by a #0 value of the Version field 3199 is called the Null FlowSpec. This flow specification causes no 3200 resources to be allocated. It is ignored by the LRMs. Its contents are 3201 never updated. Stream setup takes place in the usual way leading to 3202 successful stream establishment, but no resources are actually 3203 reserved. 3205 The purpose of the Null FlowSpec is that of facilitating 3206 interoperability tests by allowing streams to be built without 3207 actually allocating the correspondent amount of resources. The Null 3208 FlowSpec may also be used for testing and debugging purposes. 3210 The Null FlowSpec comprises the 4-byte FlowSpec parameter only, see 3211 Section 10.3.1. The third byte (Version field) must be set to 0. 3213 9.2 FlowSpec Version #7 - ST2+ FlowSpec 3215 The flow specification identified by a #7 value of the Version field 3216 is the ST2+ FlowSpec, to be used by all ST2+ implementations. It 3217 allows the user applications to express their real-time requirements 3218 in the form of a QoS class, precedence, and three basic QoS 3219 parameters: 3221 o message size, 3223 o message rate, 3225 o end-to-end delay. 3227 The QoS class indicates what kind of QoS guarantees are expected by 3228 the application, e.g. strict guarantees or predictive, see Section 3229 9.2.1. QoS parameters are expressed via a set of values: 3231 o the "desired" values indicate the QoS desired by the application. 3232 These values are assigned by the application and never modified by 3233 the LRM. 3235 o the "limit" values indicate the lowest QoS the application is 3236 willing to accept. These values are also assigned by the application 3237 and never modified by the LRM. 3239 o the "actual" values indicate the QoS that the system is able to 3240 provide. They are updated by the LRM at each node. The "actual" 3241 values are always bounded by the "limit" and "desired" values. 3243 9.2.1 QoS Classes 3245 Two QoS classes are defined: 3247 1 - QOS_PREDICTIVE /* QoSClass field value = 0x01, must be 3248 supported*/ 3249 2 - QOS_GUARANTEED /* QoSClass field value = 0x10, optional */ 3251 o The QOS_PREDICTIVE class implies that the negotiated QoS may be 3252 violated for short time intervals during the data transfer. An 3253 application has to provide values that take into account the average 3254 case, e.g. the "desired" message rate is the average rate for the 3255 transmission. Reservations are done for the average case as opposite 3256 to the peak case required by the QOS_GUARANTEED service class. This 3257 QoS class must be supported by all implementations. 3259 o The QOS_GUARANTEED class implies that the negotiated QoS for the 3260 stream is never violated during the data transfer. An application 3261 has to provide values that take into account the worst possible 3262 case, e.g. the "desired" message rate is the peak rate for the 3263 transmission. As a result, sufficient resources to handle the peak 3264 rate are reserved. This strategy may lead to overbooking of 3265 resources, but it provides strict real-time guarantees. Support of 3266 this QoS class is optional. 3268 If a LRM that doesn't support class QOS_GUARANTEED receives a FlowSpec 3269 containing QOS_GUARANTEED class, it informs the local ST agent. The ST 3270 agent may try different paths or delete the correspondent portion of 3271 the stream as described in Section 5.5.3, i.e. ReasonCode 3272 (FlowSpecError). 3274 9.2.2 Precedence 3276 Precedence is the importance of the connection being established. Zero 3277 represents the lowest precedence. The lowest level is expected to be 3278 used by default. In general, the distinction between precedence and 3279 priority is that precedence specifies streams that are permitted to 3280 take previously committed resources from another stream, while 3281 priority identifies those PDUs that a stream is most willing to have 3282 dropped. 3284 9.2.3 Maximum Data Size 3286 This parameter is expressed in bytes. It represents the maximum amount 3287 of data, excluding ST and other headers, allowed to be sent in a 3288 messages as part of the stream. The LRM first checks whether it is 3289 possible to get the value desired by the application (DesMaxSize). If 3290 not, it updates the actual value (ActMaxSize) with the available size 3291 unless this value is inferior to the minimum allowed by the 3292 application (LimitMaxSize), in which case it informs the local ST 3293 agent that it is not possible to build the stream along this path. 3295 9.2.4 Message Rate 3297 This parameter is expressed in messages/second. It represents the 3298 transmission rate for the stream. The LRM first checks whether it is 3299 possible to get the value desired by the application (DesRate). If 3300 not, it updates the actual value (ActRate) with the available rate 3301 unless this value is inferior to the minimum allowed by the 3302 application (LimitRate), in which case it informs the local ST agent 3303 that it is not possible to build the stream along this path. 3305 9.2.5 Delay and Delay Jitter 3307 The delay parameter is expressed in milliseconds. It represents the 3308 maximum end-to-end delay for the stream. The LRM first checks whether 3309 it is possible to get the value desired by the application 3310 (DesMaxDelay). If not, it updates the actual value (ActMaxDelay) with 3311 the available delay unless this value is greater than the maximum 3312 delay allowed by the application (LimitMaxDelay), in which case it 3313 informs the local ST agent that it is not possible to build the stream 3314 along this path. 3316 The LRM also updates at each node the MinDelay field by incrementing 3317 it by the minimum possible delay to the next-hop. Information on the 3318 minimum possible delay allows to calculate the maximum end-to-end 3319 delay range, i.e. the time interval in which a data packet can be 3320 received. This interval should not exceed the DesMaxDelayRange value 3321 indicated by the application. The maximum end-to-end delay range is an 3322 upper bound to the delay jitter. 3324 9.2.6 ST2+ FlowSpec Format 3326 The ST2+ FlowSpec has the following format: 3328 0 1 2 3 3329 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 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | QosClass | Precedence | 0(unused) | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | DesRate | 3334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3335 | LimitRate | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | ActRate | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | DesMaxSize | LimitMaxSize | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | ActMaxSize | DesMaxDelay | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | LimitMaxDelay | ActMaxDelay | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | DesMaxDelayRange | ActMinDelay | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 Figure 9: The ST2+ FlowSpec. 3350 The LRM modifies only "actual" fields, i.e. those beginning with 3351 "Act". The user application assigns values to all other fields. 3353 o QoSClass indicates which of the two defined classes of service 3354 applies. The two classes are: QOS_PREDICTIVE (QoSClass = 1) and 3355 QOS_GUARANTEED (QoSClass = 2). 3357 o Precedence indicates the stream's precedence. Zero represents the 3358 lowest precedence, and should be the default value. 3360 o DesRate is the desired transmission rate for the stream in messages/ 3361 second. This field is set by the origin and is not modified by 3362 intermediate agents. 3364 o LimitRate is the minimum acceptable transmission rate in messages/ 3365 second. This field is set by the origin and is not modified by 3366 intermediate agents. 3368 o ActRate is the actual transmission rate allocated for the stream in 3369 messages/second. Each agent updates this field with the available 3370 rate unless this value is less than LimitRate, in which case a 3371 REFUSE is generated. 3373 o DesMaxSize is the desired maximum data size in bytes that will be 3374 sent in a message in the stream. This field is set by the origin. 3376 o LimitMaxSize is the minimum acceptable data size in bytes. This 3377 field is set by the origin 3379 o ActMaxSize is the actual maximum data size that may be sent in a 3380 message in the stream. This field is updated by each agent based on 3381 MTU and available resources. If available maximum size is less than 3382 LimitMaxSize, the connection must be refused with ReasonCode 3383 (CantGetResrc). 3385 o DesMaxDelay is the desired maximum end-to-end delay for the stream 3386 in milliseconds. This field is set by the origin. 3388 o LimitMaxDelay is the upper-bound of acceptable end-to-end delay for 3389 the stream in milliseconds. This field is set by the origin. 3391 o ActMaxDelay is the maximum end-to-end delay that will be seen by 3392 data in the stream. Each ST agent adds to this field the maximum 3393 delay that will be introduced by the agent, including transmission 3394 time to the next-hop ST agent. If the actual maximum exceeds 3395 LimitMaxDelay, then the connection is refused with ReasonCode 3396 (CantGetResrc). 3398 o DesMaxDelayRange is the desired maximum delay range that may be 3399 encountered end-to-end by stream data in milliseconds. This value is 3400 set by the application at the origin. 3402 o ActMinDelay is the actual minimum end-to-end delay that will be 3403 encountered by stream data in milliseconds. Each ST agent adds to 3404 this field the minimum delay that will be introduced by the agent, 3405 including transmission time to the next-hop ST agent. Each agent 3406 must add at least 1 millisecond. The delay range for the stream can 3407 be calculated from the actual maximum and minimum delay fields. It 3408 is expected that the range will be important to some applications. 3410 10 ST2 Protocol Data Units Specification 3412 10.1 Data PDU 3414 IP and ST packets can be distinguished by the IP Version Number field, 3415 i.e. the first four (4) bits of the packet; ST has been assigned the 3416 value 5 (see [RFC1700]). There is no requirement for compatibility 3417 between IP and ST packet headers beyond the first four bits. (IP uses 3418 value 4.) 3420 The ST PDUs sent between ST agents consist of an ST Header 3421 encapsulating either a higher layer PDU or an ST Control Message. Data 3422 packets are distinguished from control messages via the D-bit (bit 8) 3423 in the ST header. 3425 The ST Header also includes an ST Version Number, a total length 3426 field, a header checksum, a unique id, and the stream origin 32-bit IP 3427 address. The unique id and the stream origin 32-bit IP address form 3428 the stream id (SID). This is shown in Figure 10. Please refer to 3429 Section 10.6 for an explanation of the notation. 3431 0 1 2 3 3432 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 3433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 | ST=5 | Ver=3 |D| Pri | 0 | TotalBytes | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | HeaderChecksum | UniqueID | 3437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | OriginIPAddress | 3439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3441 Figure 10: ST Header 3443 o ST is the IP Version Number assigned to identify ST packets. The 3444 value for ST is 5. 3446 o Ver is the ST Version Number. The value for the current ST2+ version 3447 is 3. 3449 o D (bit 8) is set to 1 in all ST data packets and to 0 in all SCMP 3450 control messages. 3452 o Pri (bits 9-11) is the packet-drop priority field with zero (0) 3453 being lowest priority and seven the highest. The field is to be used 3454 as described in Section 3.2.2. 3456 o TotalBytes is the length, in bytes, of the entire ST packet, it 3457 includes the ST Header but does not include any local network 3458 headers or trailers. In general, all length fields in the ST 3459 Protocol are in units of bytes. 3461 o HeaderChecksum covers only the ST Header (12 bytes). The ST Protocol 3462 uses 16-bit checksums here in the ST Header and in each Control 3463 Message. For checksum computation, see Section 8.3. 3465 o UniqueID is the first element of the stream ID (SID). It is locally 3466 unique at the stream origin, see Section 8.1. 3468 o OriginIPAddress is the second element of the SID. It is the 32-bit 3469 IP address of the stream origin, see Section 8.1. 3471 Bits 12-15 must be set to zero (0) in the current ST version and are 3472 reserved for future use, e.g., as described in [WoHD95]. 3474 10.1.1 ST Data Packets 3476 ST packets whose D-bit is non-zero are data packets. Their 3477 interpretation is a matter for the higher layer protocols and 3478 consequently is not specified here. The data packets are not protected 3479 by an ST checksum and will be delivered to the higher layer protocol 3480 even with errors. ST agents will not pass data packets over a new hop 3481 whose setup is not complete. 3483 10.2 Control PDUs 3485 SCMP control messages are exchanged between neighbor ST agents using a 3486 D-bit of zero (0). The control protocol follows a request-response 3487 model with all requests expecting responses. Retransmission after 3488 timeout (see Section 4.3) is used to allow for lost or ignored 3489 messages. Control messages do not extend across packet boundaries; if 3490 a control message is too large for the MTU of a hop, its information is 3491 partitioned and a control message per partition is sent (see Section 3492 5.1.2). All control messages have the following format 3494 0 1 2 3 3495 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 3496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3497 | OpCode | Options | TotalBytes | 3498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 | Reference | LnkReference | 3500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 | SenderIPAddress | 3502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3503 | Checksum | ReasonCode | 3504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3506 : OpCodeSpecificData : 3507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3509 Figure 11: ST Control Message Format 3511 o OpCode identifies the type of control message. 3513 o Options is used to convey OpCode-specific variations for a control 3514 message. 3516 o TotalBytes is the length of the control message, in bytes, including 3517 all OpCode specific fields and optional parameters. The value is 3518 always divisible by four (4). 3520 o Reference is a transaction number. Each sender of a request control 3521 message assigns a Reference number to the message that is unique 3522 with respect to the stream. The Reference number is used by the 3523 receiver to detect and discard duplicates. Each acknowledgment 3524 carries the Reference number of the request being acknowledged. 3525 Reference zero (0) is never used, and Reference numbers are assumed 3526 to be monotonically increasing with wraparound so that the older- 3527 than and more-recent-than relations are well defined. 3529 o LnkReference contains the Reference field of the request control 3530 message that caused this request control message to be created. It 3531 is used in situations where a single request leads to multiple 3532 responses from the same ST agent. Examples are CONNECT and CHANGE 3533 messages that are first acknowledged hop-by-hop and then lead to an 3534 ACCEPT or REFUSE response from each target. 3536 o SenderIPAddress is the 32-bit IP address of the network interface 3537 that the ST agent used to send the control message. This value 3538 changes each time the packet is forwarded by an ST agent (hop-by- 3539 hop). 3541 o Checksum is the checksum of the control message. Because the control 3542 messages are sent in packets that may be delivered with bits in 3543 error, each control message must be checked to be error free before 3544 it is acted upon. 3546 o ReasonCode is set to zero (0 = NoError) in most SCMP messages. 3547 Otherwise, it can be set to an appropriate value to indicate an 3548 error situation as defined in Section 10.5.3. 3550 o OpCodeSpecificData contains any additional information that is 3551 associated with the control message. It depends on the specific 3552 control message and is explained further below. In some response 3553 control messages, fields of zero (0) are included to allow the 3554 format to match that of the corresponding request message. The 3555 OpCodeSpecificData may also contain optional parameters. The 3556 specifics of OpCodeSpecificData are defined in Section 10.3. 3558 10.3 Common SCMP Elements 3560 Several fields and parameters (referred to generically as elements) 3561 are common to two or more PDUs. They are described in detail here 3562 instead of repeating their description several times. In many cases, 3563 the presence of a parameter is optional. To permit the parameters to 3564 be easily defined and parsed, each is identified with a PCode byte 3565 that is followed by a PBytes byte indicating the length of the 3566 parameter in bytes (including the PCode, PByte, and any padding 3567 bytes). If the length of the information is not a multiple of four (4) 3568 bytes, the parameter is padded with one to three zero (0) bytes. 3569 PBytes is thus always a multiple of four (4). Parameters can be 3570 present in any order. 3572 10.3.1 FlowSpec 3574 The FlowSpec parameter (PCode = 1) is used in several SCMP messages to 3575 convey the ST2 flow specification. The FlowSpec parameter has the 3576 following format: 3578 0 1 2 3 3579 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 3580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3581 | PCode = 1 | PBytes | Version | 0 | 3582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3584 : FlowSpec detail : 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 Figure 12: FlowSpec Parameter 3589 o the Version field contains the FlowSpec version. 3591 o the FlowSpec detail field contains the flow specification and is 3592 transparent to the ST agent. It is the data structure to be passed 3593 to the LRM. It must be 4-byte aligned. 3595 The Null FlowSpec, see Section 9.1, has no FlowSpec detail field. 3596 PBytes is set to four (4), and Version is set to zero (0). The ST2+ 3597 FlowSpec, see Section 9.2, is a 32-byte data structure. PBytes is set 3598 to 36, and Version is set to seven (7). 3600 10.3.2 Group 3602 The Group parameter (PCode = 2) is an optional argument used to 3603 indicate that the stream is a member in the specified group. 3605 0 1 2 3 3606 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 3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3608 | PCode = 2 | PBytes = 16 | GroupUniqueID | 3609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3610 | GroupCreationTime | 3611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3612 | GroupInitiatorIPAddress | 3613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3614 | Relationship | N | 3615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3617 Figure 13: Group Parameter 3619 o GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime 3620 together form the GroupName field. They are allocated by the group 3621 name generator function, see Section 8.2. GroupUniqueID and 3622 GroupCreationTime are implementation specific and have only local 3623 definitions. 3625 o Relationship has the following format: 3627 0 3628 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3630 | 0 (unused) |S|P|F|B| 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3633 Figure 14: Relationship Field 3635 The B, F, P, S bits correspond to Bandwidth, Fate, Path, and Subnet 3636 resources sharing, see Section 7. A value of 1 indicates that the 3637 relationship exists for this group. All combinations of the four bits 3638 are allowed. Bits 0-11 of the Relationship field are reserved for 3639 future use and must be set to 0. 3641 o N contains a legal value only if the B-bit is set. It is the value 3642 of the N parameter to be used as explained in Section 7.1.1. 3644 10.3.3 MulticastAddress 3646 The MulticastAddress parameter (PCode = 3) is an optional parameter 3647 that is used when using IP encapsulation and setting up an IP 3648 multicast group. This parameter is used to communicate the desired IP 3649 multicast address to next-hop ST agents that should become members of 3650 the group, see Section 8.8. 3652 0 1 2 3 3653 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 3654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3655 | PCode = 3 | PBytes = 8 | 0 | 3656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3657 | IPMulticastAddress | 3658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3660 Figure 15: MulticastAddress 3662 o IPMulticastAddress is the 32-bit IP multicast address to be used to 3663 receive data packets for the stream. 3665 10.3.4 Origin 3667 The Origin parameter (PCode = 4) is used to identify the next higher 3668 protocol, and the SAP being used in conjunction with that protocol. 3670 0 1 2 3 3671 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 3672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3673 | PCode = 5 | PBytes | NextPcol |OriginSAPBytes | 3674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3675 : OriginSAP : Padding | 3676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3678 Figure 16: Origin 3680 o NextPcol is an 8-bit field used in demultiplexing operations to 3681 identify the protocol to be used above ST. The values of NextPcol 3682 are in the same number space as the IP header's Protocol field and 3683 are consequently defined in the Assigned Numbers RFC [RFC1700]. 3685 o OriginSAPBytes specifies the length of the OriginSAP, exclusive of 3686 any padding required to maintain 32-bit alignment. 3688 o OriginSAP identifies the origin's SAP associated with the NextPcol 3689 protocol. 3691 Note that the 32-bit IP address of the stream origin is not included 3692 in this parameter because it is always available as part of the ST 3693 header. 3695 10.3.5 RecordRoute 3697 The RecordRoute parameter (PCode = 5) is used to request that the 3698 route between the origin and a target be recorded and delivered to the 3699 user application. The ST agent at the origin (or target) including 3700 this parameter, has to determine the parameter's length, indicated by 3701 the PBytes field. ST agents processing messages containing this 3702 parameter add their receiving IP address in the position indicated by 3703 the FreeOffset field, space permitting. If no space is available, the 3704 parameter is passed unchanged. When included by the origin, all agents 3705 between the origin and the target add their IP addresses and this 3706 information is made available to the application at the target. When 3707 included by the target, all agents between the target and the origin, 3708 inclusive, add their IP addresses and this information is made 3709 available to the application at the origin. 3711 0 1 2 3 3712 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 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 | PCode = 5 | PBytes | 0 | FreeOffset | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 | IP Address 1 | 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 : ... : 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | IP Address N | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3723 Figure 17: RecordRoute 3725 o PBytes is the length of the parameter in bytes. Length is determined 3726 by the agent (target or origin) that first introduces the parameter. 3727 Once set, the length of the parameter remains unchanged. 3729 o FreeOffset indicates the offset, relative to the start of the 3730 parameter, for the next IP address to be recorded. When the 3731 FreeOffset is greater than, or equal to, PBytes the RecordRoute 3732 parameter is full. 3734 o IP Address is filled in, space permitting, by each ST agent 3735 processing this parameter. 3737 10.3.6 Target and TargetList 3739 Several control messages use a parameter called TargetList (PCode = 3740 6), which contains information about the targets to which the message 3741 pertains. For each Target in the TargetList, the information includes 3742 the 32-bit IP address of the target, the SAP applicable to the next 3743 higher layer protocol, and the length of the SAP (SAPBytes). 3744 Consequently, a Target structure can be of variable length. Each entry 3745 has the format shown in Figure 18. 3747 0 1 2 3 3748 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 3749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3750 | Target IP Address | 3751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3752 | TargetBytes | SAPBytes | SAP : Padding | 3753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3755 Figure 18: Target 3757 o TargetIPAddress is the 32-bit IP Address of the Target. 3759 o TargetBytes is the length of the Target structure, beginning with 3760 the TargetIPAddress. 3762 o SAPBytes is the length of the SAP, excluding any padding required to 3763 maintain 32-bit alignment. 3765 o SAP may be longer than 2 bytes and it includes a padding when 3766 required. There would be no padding required for SAPs with lengths 3767 of 2, 6, 10, etc., bytes. 3769 0 1 2 3 3770 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 3771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3772 | PCode = 6 | PBytes | TargetCount = N | 3773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3774 | Target 1 | 3775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3776 : : : 3777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3778 | Target N | 3779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3781 Figure 19: TargetList 3783 10.3.7 UserData 3785 The UserData parameter (PCode = 7) is an optional parameter that may 3786 be used by the next higher protocol or an application to convey 3787 arbitrary information to its peers. This parameter is propagated in 3788 some control messages and its contents have no significance to ST 3789 agents. Note that since the size of control messages is limited by the 3790 smallest MTU in the path to the targets, the maximum size of this 3791 parameter cannot be specified a priori. If the size of this parameter 3792 causes a message to exceed the network MTU, an ST agent behaves as 3793 described in Section 5.1.2. The parameter must be padded to a multiple 3794 of 32 bits. 3796 0 1 2 3 3797 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 3798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3799 | PCode = 7 | PBytes | UserBytes | 3800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3801 : UserInfo : Padding | 3802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 Figure 20: UserData 3806 o UserBytes specifies the number of valid UserInfo bytes. 3808 o UserInfo is arbitrary data meaningful to the next higher protocol 3809 layer or application. 3811 10.3.8 Handling of Undefined Parameters 3813 An ST agent must be able to handle all parameters listed above. To 3814 support possible future uses, parameters with unknown PCodes must also 3815 be supported. If an agent receives a message containing a parameter 3816 with an unknown Pcode value, the agent should handle the parameter as 3817 if it was a UserData parameter. That is, the contents of the parameter 3818 should be ignored, and the message should be propagated, as 3819 appropriate, along with the related control message. 3821 10.4 ST Control Message PDUs 3823 ST Control messages are described in the following section. Please 3824 refer to Section 10.6 for an explanation of the notation. 3826 10.4.1 ACCEPT 3828 ACCEPT (OpCode = 1) is issued by a target as a positive response to a 3829 CONNECT message. It implies that the target is prepared to accept data 3830 from the origin along the stream that was established by the CONNECT. 3831 ACCEPT is also issued as a positive response to a CHANGE message. It 3832 implies that the target accepts the proposed stream modification. 3834 ACCEPT is relayed by the ST agents from the target to the origin along 3835 the path established by CONNECT (or CHANGE) but in the reverse 3836 direction. ACCEPT must be acknowledged with ACK at each hop. 3838 0 1 2 3 3839 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 3840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3841 | OpCode = 1 | 0 | TotalBytes | 3842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3843 | Reference | LnkReference | 3844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3845 | SenderIPAddress | 3846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3847 | Checksum | ReasonCode = 0 | 3848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3849 | MaxMsgSize | RecoveryTimeout | 3850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3851 | StreamCreationTime | 3852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3853 | IPHops | 0 | 3854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3855 : FlowSpec : 3856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3857 : TargetList : 3858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3860 : RecordRoute : 3861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 : UserData : 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3866 Figure 21: ACCEPT Control Message 3868 o Reference contains a number assigned by the ST agent sending ACCEPT 3869 for use in the acknowledging ACK. 3871 o LnkReference is the Reference number from the corresponding CONNECT 3872 (or CHANGE) 3874 o MaxMsgSize indicates the smallest MTU along the path traversed by 3875 the stream. This field is only set when responding to a CONNECT 3876 request. 3878 o RecoveryTimeout reflects the nominal number of milliseconds that the 3879 application is willing to wait for a failed system component to be 3880 detected and any corrective action to be taken. This field 3881 represents what can actually supported by each participating agent, 3882 and is only set when responding to a CONNECT request. 3884 o StreamCreationTime is the 32- bits system dependent timestamp copied 3885 from the corresponding CONNECT request. 3887 o IPHops is the number of IP encapsulated hops traversed by the 3888 stream. This field is set to zero by the origin, and is incremented 3889 at each IP encapsulating agent. 3891 10.4.2 ACK 3893 ACK (OpCode = 2) is used to acknowledge a request. The ACK message is 3894 not propagated beyond the previous-hop or next-hop ST agent. 3896 0 1 2 3 3897 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 3898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 | OpCode = 2 | 0 | TotalBytes | 3900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3901 | Reference | LnkReference = 0 | 3902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3903 | SenderIPAddress | 3904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3905 | Checksum | ReasonCode | 3906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3908 Figure 22: ACK Control Message 3910 o Reference is the Reference number of the control message being 3911 acknowledged. 3913 o ReasonCode is usually NoError, but other possibilities exist, e.g., 3914 DuplicateIgn. 3916 10.4.3 CHANGE 3918 CHANGE (OpCode = 3) is used to change the FlowSpec of an established 3919 stream. The CHANGE message is processed similarly to CONNECT, except 3920 that it travels along the path of an established stream. CHANGE must 3921 be propagated until it reaches the related stream's targets. CHANGE 3922 must be acknowledged with ACK at each hop. 3924 0 1 2 3 3925 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 3926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3927 | OpCode = 3 |G|I| 0 | TotalBytes | 3928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3929 | Reference | LnkReference = 0 | 3930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3931 | SenderIPAddress | 3932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3933 | Checksum | ReasonCode = 0 | 3934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3935 : FlowSpec : 3936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3938 : TargetList : 3939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3941 : RecordRoute : 3942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3944 : UserData : 3945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3947 Figure 23: CHANGE Control Message 3949 o G (bit 8) is used to request a global, stream-wide change; the 3950 TargetList parameter may be omitted when the G bit is specified. 3952 o I (bit 7) is used to indicate that the LRM is permitted to interrupt 3953 and, if needed, break the stream in the process of trying to satisfy 3954 the requested change. 3956 o Reference contains a number assigned by the ST agent sending CHANGE 3957 for use in the acknowledging ACK. 3959 10.4.4 CONNECT 3961 CONNECT (OpCode = 4) requests the setup of a new stream or an addition 3962 to or recovery of an existing stream. Only the origin can issue the 3963 initial set of CONNECTs to setup a stream, and the first CONNECT to 3964 each next-hop is used to convey the SID. 3966 The next-hop initially responds with an ACK, which implies that the 3967 CONNECT was valid and is being processed. The next-hop will later 3968 relay back either an ACCEPT or REFUSE from each target. An 3969 intermediate ST agent that receives a CONNECT behaves as explained in 3970 Section 4.5. 3972 0 1 2 3 3973 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 3974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3975 | OpCode = 4 |J N|S| 0 | TotalBytes | 3976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3977 | Reference | LnkReference = 0 | 3978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3979 | SenderIPAddress | 3980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3981 | Checksum | ReasonCode = 0 | 3982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3983 | MaxMsgSize | RecoveryTimeout | 3984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3985 | StreamCreationTime | 3986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3987 | IPHops | 0 | 3988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3989 : Origin : 3990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3991 : FlowSpec : 3992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3994 : TargetList : 3995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3997 : RecordRoute : 3998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4000 : Group : 4001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4003 : MulticastAddress : 4004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4006 : UserData : 4007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4009 Figure 24: CONNECT Control Message 4011 o JN (bits 8 and 9) indicate the join authorization level for the 4012 stream, see Section 4.4.2. 4014 o S (bit 10) indicates the NoRecovery option (Section 4.4.1). When the 4015 S-bit is set (1), the NoRecovery option is specified for the stream. 4017 o Reference contains a number assigned by the ST agent sending CONNECT 4018 for use in the acknowledging ACK. 4020 o MaxMsgSize indicates the smallest MTU along the path traversed by 4021 the stream. This field is initially set to the network MTU of the 4022 agent issues the CONNECT. 4024 o RecoveryTimeout is the nominal number of milliseconds that the 4025 application is willing to wait for failed system component to be 4026 detected and any corrective action to be taken. 4028 o StreamCreationTime is the 32- bits system dependent timestamp 4029 generated by the ST agent issuing the CONNECT. 4031 o IPHops is the number of IP encapsulated hops traversed by the 4032 stream. This field is set to zero by the origin, and is incremented 4033 at each IP encapsulating agent. 4035 10.4.5 DISCONNECT 4037 DISCONNECT (OpCode = 5) is used by an origin to tear down an 4038 established stream or part of a stream, or by an intermediate ST agent 4039 that detects a failure between itself and its previous-hop, as 4040 distinguished by the ReasonCode. The DISCONNECT message specifies the 4041 list of targets that are to be disconnected. An ACK is required in 4042 response to a DISCONNECT message. The DISCONNECT message is propagated 4043 all the way to the specified targets. The targets are expected to 4044 terminate their participation in the stream. 4046 0 1 2 3 4047 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 4048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4049 | OpCode = 5 |G| 0 | TotalBytes | 4050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4051 | Reference | LnkReference = 0 | 4052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4053 | SenderIPAddress | 4054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4055 | Checksum | ReasonCode | 4056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4057 | GeneratorIPAddress | 4058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4060 : TargetList : 4061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4063 : UserData : 4064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4066 Figure 25: DISCONNECT Control Message 4068 o G (bit 8) is used to request a DISCONNECT of all the stream's 4069 targets. TargetList should be omitted when the G-bit is set (1). If 4070 TargetList is present, it is ignored. 4072 o Reference contains a number assigned by the ST agent sending 4073 DISCONNECT for use in the acknowledging ACK. 4075 o ReasonCode reflects the event that initiated the message. 4077 o GeneratorIPAddress is the 32-bit IP address of the host that first 4078 generated the DISCONNECT message. 4080 10.4.6 ERROR 4082 ERROR (OpCode = 6) is sent in acknowledgment to a request in which an 4083 error is detected. No action is taken on the erroneous request. No ACK 4084 is expected. The ERROR message is not propagated beyond the previous- 4085 hop or next-hop ST agent. An ERROR is never sent in response to 4086 another ERROR. The receiver of an ERROR is encouraged to try again 4087 without waiting for a retransmission timeout. 4089 0 1 2 3 4090 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 4091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4092 | OpCode = 6 | 0 | TotalBytes | 4093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4094 | Reference | LnkReference = 0 | 4095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4096 | SenderIPAddress | 4097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4098 | Checksum | ReasonCode | 4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4100 : PDUInError : 4101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4103 Figure 26: ERROR Control Message 4105 o Reference is the Reference number of the erroneous request. 4107 o ReasonCode indicates the error that triggered the message. 4109 o PDUInError is the PDU in error, beginning with the ST Header. This 4110 parameter is optional. Its length is limited by network MTU, and may 4111 be truncated when too long. 4113 10.4.7 HELLO 4115 HELLO (OpCode = 7) is used as part of the ST failure detection 4116 mechanism, see Section 6.1. 4118 0 1 2 3 4119 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 4120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4121 | OpCode = 7 |R| 0 | TotalBytes | 4122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4123 | Reference = 0 | LnkReference = 0 | 4124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4125 | SenderIPAddress | 4126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4127 | Checksum | ReasonCode = 0 | 4128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4129 | HelloTimer | 4130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4132 Figure 27: HELLO Control Message 4134 o R (bit 8) is used for the Restarted-bit. 4136 o HelloTimer represents the time in millisecond since the agent was 4137 restarted, modulo the precision of the field. It is used to detect 4138 duplicate or delayed HELLO messages. 4140 10.4.8 JOIN 4142 JOIN (OpCode = 8) is used as part of the ST steam joining mechanism, 4143 see Section 4.6.3. 4145 0 1 2 3 4146 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 4147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4148 | OpCode = 8 | 0 | TotalBytes | 4149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4150 | Reference | LnkReference = 0 | 4151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4152 | SenderIPAddress | 4153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4154 | Checksum | ReasonCode = 0 | 4155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4156 | GeneratorIPAddress | 4157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4158 : TargetList : 4159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4161 Figure 28: JOIN Control Message 4163 o Reference contains a number assigned by the ST agent sending JOIN 4164 for use in the acknowledging ACK. 4166 o GeneratorIPAddress is the 32-bit IP address of the host that 4167 generated the JOIN message. 4169 o TargetList is the information of the target to be added to the 4170 stream. 4172 10.4.9 JOIN-REJECT 4174 JOIN-REJECT (OpCode = 9) is used as part of the ST steam joining 4175 mechanism, see Section 4.6.3. 4177 0 1 2 3 4178 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 4179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4180 | OpCode = 9 | 0 | TotalBytes | 4181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4182 | Reference | LnkReference | 4183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4184 | SenderIPAddress | 4185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4186 | Checksum | ReasonCode | 4187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4188 | GeneratorIPAddress | 4189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4191 Figure 29: JOIN-REJECT Control Message 4193 o Reference contains a number assigned by the ST agent sending the 4194 REFUSE for use in the acknowledging ACK. 4196 o LnkReference is the Reference number from the corresponding JOIN 4197 message. 4199 o ReasonCode reflects the reason why the JOIN request was rejected. 4201 o GeneratorIPAddress is the 32-bit IP address of the host that first 4202 generated the JOIN-REJECT message. 4204 10.4.10 NOTIFY 4206 NOTIFY (OpCode = 10) is issued by an ST agent to inform other ST agents 4207 of events that may be significant. NOTIFY may be propagated beyond the 4208 previous-hop or next-hop ST agent depending on the ReasonCode, see 4209 Section 10.5.3; NOTIFY must be acknowledged with an ACK. 4211 0 1 2 3 4212 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 4213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4214 | OpCode = 10 | 0 | TotalBytes | 4215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4216 | Reference | LnkReference = 0 | 4217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4218 | SenderIPAddress | 4219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4220 | Checksum | ReasonCode | 4221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4222 | DetectorIPAddress | 4223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4224 | MaxMsgSize | RecoveryTimeout | 4225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4227 : FlowSpec : 4228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4230 : TargetList : 4231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4233 : UserData : 4234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4236 Figure 30: NOTIFY Control Message 4238 o Reference contains a number assigned by the ST agent sending the 4239 NOTIFY for use in the acknowledging ACK. 4241 o ReasonCode identifies the reason for the notification. 4243 o DetectorIPAddress is the 32-bit IP address of the ST agent that 4244 detects the event. 4246 o MaxMsgSize is set when the MTU of the listed targets has changed 4247 (e.g. due to recovery), or when the notification is generated after 4248 a successful JOIN. Otherwise it is set to zero (0). 4250 o RecoveryTimeout is set the notification is generated after a 4251 successful JOIN. Otherwise it is set to zero (0). 4253 o FlowSpec is present when the notification is generated after a 4254 successful JOIN. 4256 o TargetList is present when the notification is related to one or 4257 more targets, or when MaxMsgSize is set 4259 o UserData is present if the notification is generated after a 4260 successful JOIN and the UserData parameter was set in the ACCEPT 4261 message. 4263 10.4.11 REFUSE 4265 REFUSE (OpCode = 11) is issued by a target that either does not wish to 4266 accept a CONNECT message or wishes to remove itself from an 4267 established stream. It might also be issued by an intermediate ST 4268 agent in response to a CONNECT or CHANGE either to terminate a routing 4269 loop, or when a satisfactory next-hop to a target cannot be found. It 4270 may also be a separate command when an existing stream has been 4271 preempted by a higher precedence stream or an ST agent detects the 4272 failure of a previous-hop, next-hop, or the network between them. In 4273 all cases, the TargetList specifies the targets that are affected by 4274 the condition. Each REFUSE must be acknowledged by an ACK. 4276 The REFUSE is relayed back by the ST agents to the origin (or 4277 intermediate ST agent that created the CONNECT or CHANGE) along the 4278 path traced by the CONNECT. The ST agent receiving the REFUSE will 4279 process it differently depending on the condition that caused it, as 4280 specified in the ReasonCode field. No special effort is made to 4281 combine multiple REFUSE messages since it is considered most unlikely 4282 that separate REFUSEs will happen to both pass through an ST agent at 4283 the same time and be easily combined, e.g., have identical ReasonCodes 4284 and parameters. 4286 0 1 2 3 4287 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 4288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4289 | OpCode = 11 |G|E|N| 0 | TotalBytes | 4290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4291 | Reference | LnkReference | 4292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4293 | SenderIPAddress | 4294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4295 | Checksum | ReasonCode | 4296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4297 | DetectorIPAddress | 4298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4299 | ValidTargetIPAddress | 4300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4302 : TargetList : 4303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4305 : RecordRoute : 4306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4308 : UserData : 4309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4311 Figure 31: REFUSE Control Message 4313 o G (bit 8) is used to indicate that all targets down stream from the 4314 sender are refusing. It is expected that this will be set most 4315 commonly due to network failures. The TargetList parameter is 4316 ignored or not present when this bit is set, and must be included 4317 when not set. 4319 o E (bit 9) is set by an ST agent to indicate that the request failed 4320 and that the pre-change stream attributes, including resources, and 4321 the stream itself still exist. 4323 o N (bit 10) is used to indicate that no further attempts to recover 4324 the stream should be made. This bit must be set when stream recovery 4325 should not be attempted, even in the case where the target 4326 application has shut down normally (ApplDisconnect). 4328 o Reference contains a number assigned by the ST agent sending the 4329 REFUSE for use in the acknowledging ACK. 4331 o LnkReference is either the Reference number from the corresponding 4332 CONNECT or CHANGE, if it is the result of such a message, or zero 4333 when the REFUSE was originated as a separate command. 4335 o DetectorIPAddress is the 32-bit IP address of the host that first 4336 generated the REFUSE message. 4338 o ValidTargetIPAddress is the 32-bit IP address of a host that is 4339 properly connected as part of the stream. This parameter is only 4340 used when recovering from stream convergence, otherwise it is set to 4341 zero (0). 4343 10.4.12 STATUS 4345 STATUS (OpCode = 12) is used to inquire about the existence of a 4346 particular stream identified by the SID. Use of STATUS is intended for 4347 collecting information from an neighbour ST agent, including general 4348 and specific stream information, and round trip time estimation. The 4349 use of this message type is described in Section 8.4. 4351 0 1 2 3 4352 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 4353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4354 | OpCode = 12 | 0 | TotalBytes | 4355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4356 | Reference | LnkReference = 0 | 4357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4358 | SenderIPAddress | 4359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4360 | Checksum | ReasonCode = 0 | 4361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4363 : TargetList : 4364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4366 Figure 32: STATUS Control Message 4368 o Reference contains a number assigned by the ST agent sending STATUS 4369 for use in the replying STATUS-RESPONSE. 4371 o TargetList is an optional parameter that when present indicates that 4372 only information related to the specific targets should be relayed 4373 in the STATUS-RESPONSE. 4375 10.4.13 STATUS-RESPONSE 4377 STATUS-RESPONSE (OpCode = 13) is the reply to a STATUS message. If the 4378 stream specified in the STATUS message is not known, the STATUS- 4379 RESPONSE will contain the specified SID but no other parameters. It 4380 will otherwise contain the current SID, FlowSpec, TargetList, and 4381 possibly Groups of the stream. It the full target list can not fit in 4382 a single message, only those targets that can be included in one 4383 message will be included. As mentioned in Section 10.4.12, it is 4384 possible to request information on a specific target. 4386 0 1 2 3 4387 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 4388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4389 | OpCode = 13 | 0 | TotalBytes | 4390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4391 | Reference | LnkReference = 0 | 4392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4393 | SenderIPAddress | 4394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4395 | Checksum | ReasonCode = 0 | 4396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4398 : FlowSpec : 4399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4401 : Groups : 4402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4404 : TargetList : 4405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4407 Figure 33: STATUS-RESPONSE Control Message 4409 o Reference contains a number assigned by the ST agent sending the 4410 STATUS. 4412 10.5 Suggested Protocol Constants 4414 The ST Protocol uses several fields that must have specific values for 4415 the protocol to work, and also several values that an implementation 4416 must select. This section specifies the required values and suggests 4417 initial values for others. It is recommended that the latter be 4418 implemented as variables so that they may be easily changed when 4419 experience indicates better values. Eventually, they should be managed 4420 via the normal network management facilities. 4422 ST uses IP Version Number 5. 4424 When encapsulated in IP, ST uses IP Protocol Number 5. 4426 10.5.1 SCMP Messages 4428 1) ACCEPT 4429 2) ACK 4430 3) CHANGE 4431 4) CONNECT 4432 5) DISCONNECT 4433 6) ERROR 4434 7) HELLO 4435 8) JOIN 4436 9) JOIN-REJECT 4437 10) NOTIFY 4438 11) REFUSE 4439 12) STATUS 4440 13) STATUS-RESPONSE 4442 10.5.2 SCMP Parameters 4444 1) FlowSpec 4445 2) Group 4446 3) MulticastAddress 4447 4) Origin 4448 5) RecordRoute 4449 6) TargetList 4450 7) UserData 4452 10.5.3 ReasonCode 4454 Several errors may occur during protocol processing. All ST error 4455 codes are taken from a single number space. The currently defined 4456 values and their meaning is presented in the list below. Note that new 4457 error codes may be defined from time to time. All implementations are 4458 expected to handle new codes in a graceful manner. If an unknown 4459 ReasonCode is encountered, it should be assumed to be fatal. The 4460 ReasonCode is an 8-bit field. Following values are defined: 4462 1 NoError No error has occurred. 4463 2 ErrorUnknown An error not contained in this list has been 4464 detected. 4465 3 AccessDenied Access denied. 4466 4 AckUnexpected An unexpected ACK was received. 4467 5 ApplAbort The application aborted the stream abnormally. 4468 6 ApplDisconnect The application closed the stream normally. 4469 7 ApplRefused Applications refused requested connection or 4470 change. 4471 8 AuthentFailed The authentication function failed. 4472 9 BadMcastAddress IP Multicast address is unacceptable in CONNECT 4473 10 CantGetResrc Unable to acquire (additional) resources. 4474 11 CantRelResrc Unable to release excess resources. 4475 12 CantRecover Unable to recover failed stream. 4476 13 CksumBadCtl Control PDU has a bad message checksum. 4477 14 CksumBadST PDU has a bad ST Header checksum. 4478 15 DuplicateIgn Control PDU is a duplicate and is being 4479 acknowledged. 4480 16 DuplicateTarget Control PDU contains a duplicate target, or an 4481 attempt to add an existing target. 4482 17 FlowSpecMismatch FlowSpec in request does not match 4483 existing FlowSpec. 4484 18 FlowSpecError An error occurred while processing the FlowSpec 4485 19 FlowVerUnknown Control PDU has a FlowSpec Version Number that 4486 is not supported. 4487 20 GroupUnknown Control PDU contains an unknown Group Name. 4488 21 InconsistGroup An inconsistency has been detected with the 4489 streams forming a group. 4490 22 IntfcFailure A network interface failure has been detected. 4491 23 InvalidSender Control PDU has an invalid SenderIPAddress 4492 field. 4493 24 InvalidTotByt Control PDU has an invalid TotalBytes field. 4494 25 JoinAuthFailure Join failed due to stream authorization level. 4495 26 LnkRefUnknown Control PDU contains an unknown LnkReference. 4496 27 NetworkFailure A network failure has been detected. 4497 28 NoRouteToAgent Cannot find a route to an ST agent. 4498 29 NoRouteToHost Cannot find a route to a host. 4499 30 NoRouteToNet Cannot find a route to a network. 4500 31 OpCodeUnknown Control PDU has an invalid OpCode field. 4501 32 PCodeUnknown Control PDU has a parameter with an invalid 4502 PCode. 4503 33 ParmValueBad Control PDU contains an invalid parameter value. 4504 34 PathConvergence Two branches of the stream join during the 4505 CONNECT setup. 4506 35 ProtocolUnknown Control PDU contains an unknown next-higher 4507 layer protocol identifier. 4508 36 RecordRouteSize RecordRoute parameter is too long to permit 4509 message to fit a network's MTU. 4510 37 RefUnknown Control PDU contains an unknown Reference. 4511 38 ResponseTimeout Control message has been acknowledged but not 4512 answered by an appropriate control message. 4513 39 RestartLocal The local ST agent has recently restarted. 4514 40 RestartRemote The remote ST agent has recently restarted. 4515 41 RetransTimeout An acknowledgment has not been received after 4516 several retransmissions. 4517 42 RouteBack Route to next-hop through same interface as 4518 previous-hop and is not previous-hop. 4519 43 RouteInconsist A routing inconsistency has been detected. 4520 44 RouteLoop A routing loop has been detected. 4521 45 SAPUnknown Control PDU contains an unknown next-higher 4522 layer SAP (port). 4523 46 SIDUnknown Control PDU contains an unknown SID. 4524 47 STAgentFailure An ST agent failure has been detected. 4525 48 STVer3Bad A received PDU is not ST Version 3. 4526 49 StreamExists A stream with the given SID already exists. 4528 50 StreamPreempted The stream has been preempted by one with a 4529 higher precedence. 4530 51 TargetExists A CONNECT was received that specified an 4531 existing target. 4532 52 TargetUnknown A target is not a member of the specified 4533 stream. 4534 53 TargetMissing A target parameter was expected and is not 4535 included, or is empty. 4536 54 TruncatedCtl Control PDU is shorter than expected. 4537 55 TruncatedPDU A received ST PDU is shorter than the ST Header 4538 indicates. 4539 56 UserDataSize UserData parameter too large to permit a 4540 message to fit into a network's MTU. 4542 10.5.4 Timeouts and Other Constants 4544 SCMP uses retransmission to effect reliability and thus has several 4545 "retransmission timers". Each "timer" is modeled by an initial time 4546 interval (ToXxx), which may get updated dynamically through 4547 measurement of control traffic, and a number of times (NXxx) to 4548 retransmit a message before declaring a failure. All time intervals 4549 are in units of milliseconds. Note that the variables are described 4550 for reference purposes only, different implementations may not include 4551 the identical variables. 4553 Value Timeout Name Meaning 4554 ------------------------------------------------------------------------ 4555 500 ToAccept Initial hop-by-hop timeout for acknowledgment of 4556 ACCEPT 4557 3 NAccept ACCEPT retries before failure 4558 500 ToChange Initial hop-by-hop timeout for acknowledgment of 4559 CHANGE 4560 3 NChange CHANGE retries before failure 4561 5000 ToChangeResp End-to-End CHANGE timeout for receipt of ACCEPT 4562 or REFUSE 4563 500 ToConnect Initial hop-by-hop timeout for acknowledgment of 4564 CONNECT 4565 5 NConnect CONNECT retries before failure 4566 5000 ToConnectResp End-to-End CONNECT timeout for receipt of ACCEPT 4567 or REFUSE from targets by origin 4568 500 ToDisconnect Initial hop-by-hop timeout for acknowledgment of 4569 DISCONNECT 4570 3 NDisconnect DISCONNECT retries before failure 4571 500 ToJoin Initial hop-by-hop timeout for acknowledgment of 4572 JOIN 4573 3 NJoin JOIN retries before failure 4574 500 ToJoinReject Initial hop-by-hop timeout for acknowledgment of 4575 JOIN-REJECT 4577 3 NJoinReject JOIN-REJECT retries before failure 4578 5000 ToJoinResp Timeout for receipt of CONNECT or JOIN-REJECT 4579 from origin or intermediate hop 4580 500 ToNotify Initial hop-by-hop timeout for acknowledgment of 4581 NOTIFY 4582 3 NNotify NOTIFY retries before failure 4583 500 ToRefuse Initial hop-by-hop timeout for acknowledgment of 4584 REFUSE 4585 3 NRefuse REFUSE retries before failure 4586 500 ToRetryRoute Timeout for receipt of ACCEPT or REFUSE from 4587 targets during failure recovery 4588 5 NRetryRoute CONNECT retries before failure 4589 1000 ToStatusResp Timeout for receipt of STATUS-RESPONSE 4590 3 NStatus STATUS retries before failure 4591 10000 HelloTimerHoldDown Interval that Restarted bit must be set 4592 after ST restart 4593 5 HelloLossFactor Number of consecutively missed HELLO 4594 messages before declaring link failure 4595 2000 DefaultRecoveryTimeout Interval between successive HELLOs 4596 to/from active neighbors 4598 10.6 Data Notations 4600 The convention in the documentation of Internet Protocols is to 4601 express numbers in decimal and to picture data with the most 4602 significant octet on the left and the least significant octet on the 4603 right. 4605 The order of transmission of the header and data described in this 4606 document is resolved to the octet level. Whenever a diagram shows a 4607 group of octets, the order of transmission of those octets is the 4608 normal order in which they are read in English. For example, in the 4609 following diagram the octets are transmitted in the order they are 4610 numbered. 4612 0 1 2 3 4613 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 4614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4615 | 1 | 2 | 3 | 4 | 4616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4617 | 5 | 6 | 7 | 8 | 4618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4619 | 9 | 10 | 11 | 12 | 4620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4622 Figure 34: Transmission Order of Bytes 4624 Whenever an octet represents a numeric quantity the left most bit in 4625 the diagram is the high order or most significant bit. That is, the 4626 bit labeled 0 is the most significant bit. For example, the following 4627 diagram represents the value 170 (decimal). 4629 0 1 2 3 4 5 6 7 4630 +-+-+-+-+-+-+-+-+ 4631 |1 0 1 0 1 0 1 0| 4632 +-+-+-+-+-+-+-+-+ 4634 Figure 35: Significance of Bits 4636 Similarly, whenever a multi-octet field represents a numeric quantity 4637 the left most bit of the whole field is the most significant bit. When 4638 a multi-octet quantity is transmitted the most significant octet is 4639 transmitted first. 4641 Fields whose length is fixed and fully illustrated are shown with a 4642 vertical bar (|) at the end; fixed fields whose contents are 4643 abbreviated are shown with an exclamation point (!); variable fields 4644 are shown with colons (:). Optional parameters are separated from 4645 control messages with a blank line. The order of parameters is not 4646 meaningful. 4648 11 Security Considerations 4650 This memo does not address security issues. 4652 12 Acknowledgments and Author's Addresses 4654 Many individuals have contributed to the work described in this memo. 4655 We thank the participants in the ST Working Group for their input, 4656 review, and constructive comments. George Mason University C3I Center 4657 for hosting an interim meeting. We also thank Lynne Kendall Beltran 4658 for translating our drawings into ASCII. Special thanks are due to 4659 Steve DeJarnett, who served as working group co-chair until summer 4660 1993. 4662 We would also like to acknowledge the authors of [RFC1190]. All 4663 authors of [RFC1190] should be considered authors of this document 4664 since this document contains much of their text and ideas. 4666 Louis Berger 4667 BBN Systems and Technologies 4668 1300 North 17th Street, Suite 1200 4669 Arlington, VA 22209 4670 Phone: 703-284-4651 4671 EMail: lberger@bbn.com 4672 Luca Delgrossi 4673 IBM ENC 4674 Multimedia Technology Center 4675 Vangerowstr. 18 4676 D69020 Heidelberg, Germany 4677 Phone: +49-6221-594330 4678 EMail: luca@heidelbg.ibm.com 4680 Dat Duong 4681 BBN Systems and Technologies 4682 1300 North 17th Street, Suite 1200 4683 Arlington, VA 22209 4684 Phone: 703-284-4760 4685 EMail: dat@bbn.com 4687 Steve Jackowski 4688 Syzygy Communications Incorporated 4689 269 Mt. Hermon Road 4690 Scotts Valley, CA 95066 4691 Phone: 408-439-6834 4692 EMail: stevej@syzygycomm.com 4694 Sibylle Schaller 4695 IBM ENC 4696 Broadband Multimedia Communications 4697 Vangerowstr. 18 4698 D69020 Heidelberg, Germany 4699 Phone: +49-6221-5944553 4700 EMail: schaller@heidelbg.ibm.com 4702 13 References 4704 [RFC1071] Braden, Borman, Partridge: Computing the Internet 4705 Checksum, RFC 1071, USC/Information Sciences Institute, 4706 Cray Research, BBN Laboratories, September 1988. 4708 [RFC1112] Deering, S.: Host Extensions for IP multicasting, RFC 4709 1112, Stanford University, August 1989. 4711 [WoHD95] L. Wolf, R. G. Herrtwich, L. Delgrossi: Filtering 4712 Multimedia Data in Reservation-based Networks, 4713 Kommunikation in Verteilten Systemen 1995 (KiVS), 4714 Chemnitz-Zwickau, Germany, February 1995. 4716 [RFC1122] Braden, R.: Requirements for Internet Hosts -- 4717 Communication Layers, RFC 1122, USC/Information Sciences 4718 Institute, October 1989. 4720 [Jaco88] Jacobson, V.: Congestion Avoidance and Control, ACM 4721 SIGCOMM-88, August 1988. 4723 [KaPa87] Karn, P. and C. Partridge: Round Trip Time Estimation, 4724 ACM SIGCOMM-87, August 1987. 4726 [RFC1141] Mallory, T. and A. Kullberg: Incremental Updating of the 4727 Internet Checksum, RFC 1141, BBN, January 1990. 4729 [RFC1363] C. Partridge: A Proposal Flow Specification, RFC 1363. 4731 [RFC791] Postel: Internet Protocol, RFC 791, DARPA, September 4732 1981. 4734 [RFC1700] Reynolds, Postel: Assigned Numbers, RFC 1700, ISI, 4735 October 1994. 4737 [RFC1190] Topolcic C.: Internet Stream Protocol Version 2 (ST-II), 4738 RFC1190, October 1990. 4740 [RFC1633] R. Braden, D. Clark, S. Shenker: Integrated Services in 4741 the Internet Architecture: an Overview, RFC1633, June 4742 1994. 4744 [VoHN93] C. Vogt, R. G. Herrtwich, R. Nagarajan: HeiRAT: the 4745 Heidelberg Resource Administration Technique - Design 4746 Philosophy and Goals, Kommunikation In Verteilten 4747 Systemen, Munich, Informatik Aktuell, Springer-Verlag, 4748 Heidelberg, 1993. 4750 [Cohe81] D. Cohen: A Network Voice Protocol NVP-II, University of 4751 Southern California, Los Angeles, 1981. 4753 [Cole81] R. Cole: PVP - A Packet Video Protocol, University of 4754 Southern California, Los Angeles, 1981. 4756 [DeAl92] L. Delgrossi (Ed.) The BERKOM-II Multimedia Transport 4757 System, Version 1, BERKOM Working Document, October, 4758 1992. 4760 [DHHS92] L. Delgrossi, C. Halstrick, R. G. Herrtwich, H. 4761 Stuettgen: HeiTP: a Transport Protocol for ST-II, 4762 GLOBECOM'92, Orlando (Florida), December 1992. 4764 [Schu94] H. Schulzrinne: RTP: A Transport Protocol for Real-Time 4765 Applications. Internet Draft, work in progress, 1994.