RFCs in HTML Format


RFC 1190

Network Working Group                                  CIP Working Group
Request for Comments: 1190                           C. Topolcic, Editor
Obsoletes: IEN-119                                          October 1990


        Experimental Internet Stream Protocol, Version 2 (ST-II)


1.         Abstract

   This memo defines the Internet Stream Protocol, Version 2 (ST-II), an
   IP-layer protocol that provides end-to-end guaranteed service across
   an internet.  This specification obsoletes IEN 119 "ST - A Proposed
   Internet Stream Protocol" written by Jim Forgie in 1979, the previous
   specification of ST.  ST-II is not compatible with Version 1 of the
   protocol, but maintains much of the architecture and philosophy of
   that version.  It is intended to fill in some of the areas left
   unaddressed, to make it easier to implement, and to support a wider
   range of applications.























CIP Working Group                                               [Page 1]

RFC 1190 Internet Stream Protocol October 1990 1.1. Table of Contents Status of this Memo . . . . . . . . . . . . 1 1. Abstract . . . . . . . . . . . . . . . 1 1.1. Table of Contents . . . . . . . . . . . 2 1.2. List of Figures . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . 7 2.1. Major Differences Between ST and ST-II . . . . 8 2.2. Concepts and Terminology . . . . . . . . . 9 2.3. Relationship Between Applications and ST . . . . 11 2.4. ST Control Message Protocol . . . . . . . . 12 2.5. Flow Specifications . . . . . . . . . . . 14 3. ST Control Message Protocol Functional Description . 17 3.1. Stream Setup . . . . . . . . . . . . . 18 3.1.1. Initial Setup at the Origin . . . . . . . 18 3.1.2. Invoking the Routing Function . . . . . . 19 3.1.3. Reserving Resources . . . . . . . . . . 19 3.1.4. Sending CONNECT Messages . . . . . . . . 20 3.1.5. CONNECT Processing by an Intermediate Agent . . 22 3.1.6. Setup at the Targets . . . . . . . . . 23 3.1.7. ACCEPT Processing by an Intermediate Agent . . 24 3.1.8. ACCEPT Processing by the Origin . . . . . . 26 3.1.9. Processing a REFUSE Message . . . . . . . 27 3.2. Data Transfer . . . . . . . . . . . . . 30 3.3. Modifying an Existing Stream . . . . . . . . 31 3.3.1. Adding a Target . . . . . . . . . . . 31 3.3.2. The Origin Removing a Target . . . . . . . 33 3.3.3. A Target Deleting Itself . . . . . . . . 35 3.3.4. Changing the FlowSpec . . . . . . . . . 36 3.4. Stream Tear Down . . . . . . . . . . . . 36 3.5. Exceptional Cases . . . . . . . . . . . 37 3.5.1. Setup Failure due to CONNECT Timeout . . . . 37 3.5.2. Problems due to Routing Inconsistency . . . . 38 3.5.3. Setup Failure due to a Routing Failure . . . 39 3.5.4. Problems in Reserving Resources . . . . . . 41 3.5.5. Setup Failure due to ACCEPT Timeout . . . . 41 3.5.6. Problems Caused by CHANGE Messages . . . . . 42 3.5.7. Notification of Changes Forced by Failures . . 42 3.6. Options . . . . . . . . . . . . . . . 44 3.6.1. HID Field Option . . . . . . . . . . . 44 3.6.2. PTP Option . . . . . . . . . . . . . 44 3.6.3. FDx Option . . . . . . . . . . . . . 45 3.6.4. NoRecovery Option . . . . . . . . . . 46 3.6.5. RevChrg Option . . . . . . . . . . . 46 3.6.6. Source Route Option . . . . . . . . . . 46 3.7. Ancillary Functions . . . . . . . . . . . 48 3.7.1. Failure Detection . . . . . . . . . . 48 3.7.1.1. Network Failures . . . . . . . . . . 48 3.7.1.2. Detecting ST Stream Failures . . . . . . 49 3.7.1.3. Subset . . . . . . . . . . . . . 51 CIP Working Group [Page 2]
RFC 1190 Internet Stream Protocol October 1990 3.7.2. Failure Recovery . . . . . . . . . . . 51 3.7.2.1. Subset . . . . . . . . . . . . . 55 3.7.3. A Group of Streams . . . . . . . . . . 56 3.7.3.1. Group Name Generator . . . . . . . . 57 3.7.3.2. Subset . . . . . . . . . . . . . 57 3.7.4. HID Negotiation . . . . . . . . . . . 58 3.7.4.1. Subset . . . . . . . . . . . . . 64 3.7.5. IP Encapsulation of ST . . . . . . . . . 64 3.7.5.1. IP Multicasting . . . . . . . . . . 65 3.7.6. Retransmission . . . . . . . . . . . 66 3.7.7. Routing . . . . . . . . . . . . . . 67 3.7.8. Security . . . . . . . . . . . . . 67 3.8. ST Service Interfaces . . . . . . . . . . 68 3.8.1. Access to Routing Information . . . . . . 69 3.8.2. Access to Network Layer Resource Reservation . 70 3.8.3. Network Layer Services Utilized . . . . . . 71 3.8.4. IP Services Utilized . . . . . . . . . 71 3.8.5. ST Layer Services Provided . . . . . . . 72 4. ST Protocol Data Unit Descriptions . . . . . . . 75 4.1. Data Packets . . . . . . . . . . . . . 76 4.2. ST Control Message Protocol Descriptions . . . . 77 4.2.1. ST Control Messages . . . . . . . . . . 79 4.2.2. Common SCMP Elements . . . . . . . . . 80 4.2.2.1. DetectorIPAddress . . . . . . . . . 80 4.2.2.2. ErroredPDU . . . . . . . . . . . . 80 4.2.2.3. FlowSpec & RFlowSpec . . . . . . . . 81 4.2.2.4. FreeHIDs . . . . . . . . . . . . 84 4.2.2.5. Group & RGroup . . . . . . . . . . 85 4.2.2.6. HID & RHID . . . . . . . . . . . . 86 4.2.2.7. MulticastAddress . . . . . . . . . . 86 4.2.2.8. Name & RName . . . . . . . . . . . 87 4.2.2.9. NextHopIPAddress . . . . . . . . . . 88 4.2.2.10. Origin . . . . . . . . . . . . . 88 4.2.2.11. OriginTimestamp . . . . . . . . . . 89 4.2.2.12. ReasonCode . . . . . . . . . . . . 89 4.2.2.13. RecordRoute . . . . . . . . . . . 94 4.2.2.14. SrcRoute . . . . . . . . . . . . 95 4.2.2.15. Target and TargetList . . . . . . . . 96 4.2.2.16. UserData . . . . . . . . . . . . 98 4.2.3. ST Control Message PDUs . . . . . . . . 99 4.2.3.1. ACCEPT . . . . . . . . . . . . . 100 4.2.3.2. ACK . . . . . . . . . . . . . . 102 4.2.3.3. CHANGE-REQUEST . . . . . . . . . . 103 4.2.3.4. CHANGE . . . . . . . . . . . . . 104 4.2.3.5. CONNECT . . . . . . . . . . . . . 105 4.2.3.6. DISCONNECT . . . . . . . . . . . . 110 4.2.3.7. ERROR-IN-REQUEST . . . . . . . . . . 111 4.2.3.8. ERROR-IN-RESPONSE . . . . . . . . . 112 4.2.3.9. HELLO . . . . . . . . . . . . . 113 4.2.3.10. HID-APPROVE . . . . . . . . . . . 114 4.2.3.11. HID-CHANGE-REQUEST . . . . . . . . . 115 CIP Working Group [Page 3]
RFC 1190 Internet Stream Protocol October 1990 4.2.3.12. HID-CHANGE . . . . . . . . . . . . 116 4.2.3.13. HID-REJECT . . . . . . . . . . . . 118 4.2.3.14. NOTIFY . . . . . . . . . . . . . 120 4.2.3.15. REFUSE . . . . . . . . . . . . . 122 4.2.3.16. STATUS . . . . . . . . . . . . . 124 4.2.3.17. STATUS-RESPONSE . . . . . . . . . . 126 4.3. Suggested Protocol Constants . . . . . . . . 127 5. Areas Not Addressed . . . . . . . . . . . . 131 6. Glossary . . . . . . . . . . . . . . . 135 7. References . . . . . . . . . . . . . . . 143 8. Security Considerations. . . . . . . . . . . 144 9. Authors' Addresses . . . . . . . . . . . . 145 Appendix 1. Data Notations . . . . . . . . . . 147 1.2. List of Figures Figure 1. Protocol Relationships . . . . . . . . . 6 Figure 2. Topology Used in Protocol Exchange Diagrams . . 16 Figure 3. Virtual Link Identifiers for SCMP Messages . . 16 Figure 4. HIDs Assigned for ST User Packets . . . . . 18 Figure 5. Origin Sending CONNECT Message . . . . . . 21 Figure 6. CONNECT Processing by an Intermediate Agent . . 22 Figure 7. CONNECT Processing by the Target . . . . . . 24 Figure 8. ACCEPT Processing by an Intermediate Agent . . 25 Figure 9. ACCEPT Processing by the Origin . . . . . . 26 Figure 10. Sending REFUSE Message . . . . . . . . . 28 Figure 11. Routing Around a Failure . . . . . . . . 29 Figure 12. Addition of Another Target . . . . . . . . 32 Figure 13. Origin Removing a Target . . . . . . . . 34 Figure 14. Target Deleting Itself . . . . . . . . . 35 Figure 15. CONNECT Retransmission after a Timeout . . . . 38 Figure 16. Processing NOTIFY Messages . . . . . . . . 43 Figure 17. Source Routing Option . . . . . . . . . 47 Figure 18. Typical HID Negotiation (No Multicasting) . . . 60 Figure 19. Multicast HID Negotiation . . . . . . . . 61 Figure 20. Multicast HID Re-Negotiation . . . . 62 Figure 21. ST Header . . . . . . . . . . . . . 75 Figure 22. ST Control Message Format . . . . . . . . 77 Figure 23. ErroredPDU . . . . . . . . . . . . . 80 Figure 24. FlowSpec & RFlowSpec . . . . . . . . . . 81 Figure 25. FreeHIDs . . . . . . . . . . . . . . 85 Figure 26. Group & RGroup . . . . . . . . . . . . 85 Figure 27. HID & RHID . . . . . . . . . . . . . 86 Figure 28. MulticastAddress . . . . . . . . . . . 86 Figure 29. Name & RName . . . . . . . . . . . . 87 Figure 30. NextHopIPAddress . . . . . . . . . . . 88 CIP Working Group [Page 4]
RFC 1190 Internet Stream Protocol October 1990 Figure 31. Origin . . . . . . . . . . . . . . 88 Figure 32. OriginTimestamp . . . . . . . . . . . 89 Figure 33. ReasonCode . . . . . . . . . . . . . 89 Figure 34. RecordRoute . . . . . . . . . . . . . 94 Figure 35. SrcRoute . . . . . . . . . . . . . . 95 Figure 36. Target . . . . . . . . . . . . . . 97 Figure 37. TargetList . . . . . . . . . . . . . 97 Figure 38. UserData . . . . . . . . . . . . . . 98 Figure 39. ACCEPT Control Message . . . . . . . . . 101 Figure 40. ACK Control Message . . . . . . . . . . 102 Figure 41. CHANGE-REQUEST Control Message . . . . . . 103 Figure 42. CHANGE Control Message . . . . . . . . . 105 Figure 43. CONNECT Control Message . . . . . . . . . 109 Figure 44. DISCONNECT Control Message . . . . . . . . 110 Figure 45. ERROR-IN-REQUEST Control Message . . . . . . 111 Figure 46. ERROR-IN-RESPONSE Control Message . . . . . 112 Figure 47. HELLO Control Message . . . . . . . . . 113 Figure 48. HID-APPROVE Control Message . . . . . . . 114 Figure 49. HID-CHANGE-REQUEST Control Message . . . . . 115 Figure 50. HID-CHANGE Control Message . . . . . . . . 117 Figure 51. HID-REJECT Control Message . . . . . . . . 119 Figure 52. NOTIFY Control Message . . . . . . . . . 121 Figure 53. REFUSE Control Message . . . . . . . . . 123 Figure 54. STATUS Control Message . . . . . . . . . 125 Figure 55. STATUS-RESPONSE Control Message . . . . . . 126 Figure 56. Transmission Order of Bytes . . . . . . . 147 Figure 57. Significance of Bits . . . . . . . . . . 147 CIP Working Group [Page 5]
RFC 1190 Internet Stream Protocol October 1990 +--------------------+ | Conference Control | +--------------------+ | +-------+ +-------+ | | Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application | Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer +-------+ +-------+ | +-----+ +------+ +-----+ +-----+ | | | | | | | V V | | | | | ------------ +-----+ +-----+ | | | | | | PVP | | NVP | | | | | | +-----+ +-----+ + | | | | | \ | \ \ | | | | | +-----|--+-----+ | | | | | Appl.|control V V V V V | ST data | +-----+ +-------+ +-----+ | & control| | UDP | | TCP | ... | | Transport | | +-----+ +-------+ +-----+ Layer | /| / | \ / / | / /| |\ / | +------+--|--\-----+-/--|--- ... -+ / | | \ / | | | \ / | / | | \ / | | | \ +----|--- ... -+ | ----------- | \ / | | | \ / | | | V | | | V | | | +------+ | | | +------+ | +------+ | | | SCMP | | | | | ICMP | | | IGMP | | Internet | +------+ | | | +------+ | +------+ | Layer | | | | | | | | | V V V V V V V V V +-----------------+ +-----------------------------------+ | STream protocol |->| Internet Protocol | +-----------------+ +-----------------------------------+ | \ / | | \ / | | X | ------------ | / \ | | / \ | VV VV +----------------+ +----------------+ | (Sub-) Network |...| (Sub-) Network | (Sub-)Network | Protocol | | Protocol | Layer +----------------+ +----------------+ Figure 1. Protocol Relationships CIP Working Group [Page 6]
RFC 1190 Internet Stream Protocol October 1990 2. Introduction ST has been developed to support efficient delivery of streams of packets to either single or multiple destinations in applications requiring guaranteed data rates and controlled delay characteristics. The motivation for the original protocol was that IP [2] [15] did not provide the delay and data rate characteristics necessary to support voice applications. ST is an internet protocol at the same layer as IP, see Figure 1. ST differs from IP in that IP, as originally envisioned, did not require routers (or intermediate systems) to maintain state information describing the streams of packets flowing through them. ST incorporates the concept of streams across an internet. Every intervening ST entity maintains state information for each stream that passes through it. The stream state includes forwarding information, including multicast support for efficiency, and resource information, which allows network or link bandwidth and queues to be assigned to a specific stream. This pre-allocation of resources allows data packets to be forwarded with low delay, low overhead, and a low probability of loss due to congestion. The characteristics of a stream, such as the number and location of the endpoints, and the bandwidth required, may be modified during the lifetime of the stream. This allows ST to give a real time application the guaranteed and predictable communication characteristics it requires, and is a good vehicle to support an application whose communications requirements are relatively predictable. ST proved quite useful in several early experiments that involved voice conferences in the Internet. Since that time, ST has also been used to support point-to-point streams that include both video and voice. Recently, multimedia conferencing applications have been developed that need to exchange real-time voice, video, and pointer data in a multi-site conferencing environment. Multimedia conferencing across an internet is an application for which ST provides ideal support. Simulation and wargaming applications [14] also place similar requirements on the communication system. Other applications may include scientific visualization between a number of workstations and one or more remote supercomputers, and the collection and distribution of real-time sensor data from remote sensor platforms. ST may also be useful to support activities that are currently supported by IP, such as bulk file transfer using TCP. Transport protocols above ST include the Packet Video Protocol (PVP) [5] and the Network Voice Protocol (NVP) [4], which are end-to-end protocols used directly by applications. Other transport layer protocols that may be used over ST include TCP [16], VMTP [3], etc. They provide the user interface, flow control, and packet ordering. This specification does not describe these higher layer protocols. CIP Working Group [Page 7]
RFC 1190 Internet Stream Protocol October 1990 2.1. Major Differences Between ST and ST-II ST-II supports a wider variety of applications than did the original ST. The differences between ST and ST-II are fairly straight forward yet provide great improvements. Four of the more notable differences are: 1 ST-II is decoupled from the Access Controller (AC). The AC, as well as providing a rudimentary access control function, also served as a centralized repository and distributor of the conference information. If an AC is necessary, it should be an entity in a higher layer protocol. A large variety of applications such as conferencing, distributed simulations, and wargaming can be run without an explicit AC. 2 The basic stream construct of ST-II is a directed tree carrying traffic away from a source to all the destinations, rather than the original ST's omniplex structure. For example, a conference is composed of a number of such trees, one for traffic from each participant. Although there are more (simplex) streams in ST-II, each is much simpler to manage, so the aggregate is much simpler. This change has a minimal impact on the application. 3 ST-II defines a number of the robustness and recovery mechanisms that were left undefined in the original ST specification. In case of a network or ST Agent failure, a stream may optionally be repaired automatically (i.e., without intervention from the user or the application) using a pruned depth first search starting at the ST Agent immediately preceding the failure. 4 ST-II does not make an inherent distinction between streams connecting only two communicants and streams among an arbitrary number of communicants. This memo is the specification for the ST-II Protocol. Since there should be no ambiguity between the original ST specification and the specification herein, the protocol is simply called ST hereafter. ST is the protocol used by ST entities to exchange information. The same protocol is used for communication among all ST entities, whether they communicate with a higher layer protocol or forward ST packets between attached networks. The remainder of this section gives a brief overview of the ST Protocol. Section 3 (page 17) provides a detailed description of the operations required by the protocol. Section 4 (page 75) provides descriptions of the ST Protocol Data Units exchanged CIP Working Group [Page 8]
RFC 1190 Internet Stream Protocol October 1990 between ST entities. Issues that have not yet been fully addressed are presented in Section 5 (page 131). A glossary and list of references are in Sections 6 (page 135) and 7 (page 143), respectively. This memo also defines "subsets" of ST that can be implemented. A subsetted implementation does not have full ST functionality, but it can interoperate with other similarly subsetted implementations, or with a full implementation, in a predictable and consistent manner. This approach allows an implementation to be built and provide service with minimum effort, and gives it an immediate and well defined growth path. 2.2. Concepts and Terminology The ST packet header is not constrained to be compatible with the IP packet header, except for the IP Version Number (the first four bits) that is used to distinguish ST packets (IP Version 5) from IP packets (IP Version 4). The ST packets, or protocol data units (PDUs), can be encapsulated in IP either to provide connectivity (possibly with degraded service) across portions of an internet that do not provide support for ST, or to allow access to services such as security that are not provided directly by ST. An internet entity that implements the ST Protocol is called an "ST Agent". We refer to two kinds of ST agents: "host ST agents", also called "host agents" and "intermediate ST agents", also called "intermediate agents". The ST agents functioning as hosts are sourcing or sinking data to a higher layer protocol or application, while ST agents functioning as intermediate agents are forwarding data between directly attached networks. This distinction is not part of the protocol, but is used for conceptual purposes only. Indeed, a given ST agent may be simultaneously performing both host and intermediate roles. Every ST agent should be capable of delivering packets to a higher layer protocol. Every ST agent can replicate ST data packets as necessary for multi-destination delivery, and is able to send packets whether received from a network interface or a higher layer protocol. There are no other kinds of ST agents. ST provides applications with an end-to-end flow oriented service across an internet. This service is implemented using objects called "streams". ST data packets are not considered to be totally independent as are IP data packets. They are transmitted only as part of a point-to-point or point-to-multi- point stream. ST creates a stream during a setup phase before data is transmitted. During the setup phase, routes are selected and internetwork resources are reserved. Except for explicit changes to the stream, the routes remain in effect until the stream is explicitly torn down. CIP Working Group [Page 9]
RFC 1190 Internet Stream Protocol October 1990 An ST stream is: o the set of paths that data generated by an application entity traverses on its way to its peer application entity(s) that receive it, o the resources allocated to support that transmission of data, and o the state information that is maintained describing that transmission of data. Each stream is identified by a globally unique "Name"; see Section 4.2.2.8 (page 87). The Name is specified in ST control operations, but is not used in ST data packets. A set of streams may be related as members of a larger aggregate called a "group". A group is identified by a "Group Name"; see Section 3.7.3 (page 56). The end-users of a stream are called the "participants" in the stream. Data travels in a single direction through any given stream. The host agent that transmits the data into the stream is called the "origin", and the host agents that receive the data are called the "targets". Thus, for any stream one participant is the origin and the others are the targets. A stream is "multi-destination simplex" since data travels across it in only one direction: from the origin to the targets. A stream can be viewed as a directed tree in which the origin is the root, all the branches are directed away from the root toward the targets, which are the leaves. A "hop" is an edge of that tree. The ST agent that is on the end of an edge in the direction toward the origin is called the "previous-hop ST agent", or the "previous-hop". The ST agents that are one hop away from a previous-hop ST agent in the direction toward the targets are called the "next-hop ST agents", or the "next-hops". It is possible that multiple edges between a previous-hop and several next-hops are actually implemented by a network level multicast group. Packets travel across a hop for one of two purposes: data or control. For ST data packet handling, hops are marked by "Hop IDentifiers" (HIDs) used for efficient forwarding instead of the stream's Name. A HID is negotiated among several agents so that data forwarding can be done efficiently on both a point-to-point and multicast basis. All control message exchange is done on a point-to-point basis between a pair of agents. For control message handling, Virtual Link Identifiers are used to quickly dispatch the control messages to the proper stream's state machine. CIP Working Group [Page 10]
RFC 1190 Internet Stream Protocol October 1990 ST requires routing decisions to be made at several points in the stream setup and management process. ST assumes that an appropriate routing algorithm exists to which ST has access; see Section 3.8.1 (page 69). However, routing is considered to be a separate issue. Thus neither the routing algorithm nor its implementation is specified here. A routing algorithm may attempt to minimize the number of hops to the target(s), or it may be more intelligent and attempt to minimize the total internet resources consumed. ST operates equally well with any reasonable routing algorithm. The availability of a source routing option does not eliminate the need for an appropriate routing algorithm in ST agents. 2.3. Relationship Between Applications and ST It is the responsibility of an ST application entity to exchange information among its peers, usually via IP, as necessary to determine the structure of the communication before establishing the ST stream. This includes: o identifying the participants, o determining which are targets for which origins, o selecting the characteristics of the data flow between any origin and its target(s), o specifying the protocol that resides above ST, o identifying the Service Access Point (SAP), port, or socket relevant to that protocol at every participant, and o ensuring security, if necessary. The protocol layer above ST must pass such information down to the ST protocol layer when creating a stream. ST uses a flow specification, abbreviated herein as "FlowSpec", to describe the required characteristics of a stream. Included are bandwidth, delay, and reliability parameters. Additional parameters may be included in the future in an extensible manner. The FlowSpec describes both the desired values and their minimal allowable values. The ST agents thus have some freedom in allocating their resources. The ST agents accumulate information that describes the characteristics of the chosen path and pass that information to the origin and the targets of the stream. ST stream setup control messages carry some information that is not specifically relevant to ST, but is passed through the interface to the protocol that resides above ST. The "next CIP Working Group [Page 11]
RFC 1190 Internet Stream Protocol October 1990 protocol identifier" ("NextPcol") allows ST to demultiplex streams to a number of possible higher layer protocols. The SAP associated with each participant allows the higher layer protocol to further demultiplex to a specific application entity. A UserData parameter is provided; see Section 4.2.2.16 (page 98). 2.4. ST Control Message Protocol ST agents create and manage a stream using the ST Control Message Protocol (SCMP). Conceptually, SCMP resides immediately above ST (as does ICMP above IP) but is an integral part of ST. Control messages are used to: o create streams, o refuse creation of a stream, o delete a stream in whole or in part, o negotiate or change a stream's parameters, o tear down parts of streams as a result of router or network failures, or transient routing inconsistencies, and o reroute around network or component failures. SCMP follows a request-response model. SCMP reliability is ensured through use of retransmission after timeout; see Section 3.7.6 (page 66). An ST application that will transmit data requests its local ST agent, the origin, to create a stream. While only the origin requests creation of a stream, all the ST agents from the origin to the targets participate in its creation and management. Since a stream is simplex, each participant that wishes to transmit data must request that a stream be created. An ST agent that receives an indication that a stream is being created must: 1 negotiate a HID with the previous-hop identifying the stream, 2 map the list of targets onto a set of next-hop ST agents through the routing function, 3 reserve the local and network resources required to support the stream, CIP Working Group [Page 12]
RFC 1190 Internet Stream Protocol October 1990 4 update the FlowSpec, and 5 propagate the setup information and partitioned target list to the next-hop ST agents. When a target receives the setup message, it must inquire from the specified application process whether or not it is willing to accept the stream, and inform the origin accordingly. Once a stream is established, the origin can safely send data. ST and its implementations are optimized to allow fast and efficient forwarding of data packets by the ST agents using the HIDs, even at the cost of adding overhead to stream creation and management. Specifically, the forwarding decisions, that is, determining the set of next-hop ST agents to which a data packet belonging to a particular stream will be sent, are made during the stream setup phase. The shorthand HIDs are negotiated at that time, not only to reduce the data packet header size, but to access efficiently the stream's forwarding information. When possible, network-layer multicast is used to forward a data packet to multiple next-hop ST agents across a network. Note that when network-layer multicast is used, all members of the multicast group must participate in the negotiation of a common HID. An established stream can be modified by adding or deleting targets, or by changing the network resources allocated to it. A stream may be torn down by either the origin or the targets. A target can remove itself from a stream leaving the others unaffected. The origin can similarly remove any subset of the targets from its stream leaving the remainder unaffected. An origin can also remove all the targets from the stream and eliminate the stream in its entirety. A stream is monitored by the involved ST agents. If they detect a failure, they can attempt recovery. In general, this involves tearing down part of the stream and rebuilding it to bypass the failed component(s). The rebuilding always occurs from the origin side of the failure. The origin can optionally specify whether recovery is to be attempted automatically by intermediate ST agents or whether a failure should immediately be reported to the origin. If automatic recovery is selected but an intermediate agent determines it cannot effect the repair, it propagates the failure information backward until it reaches an agent that can effect repair. If the failure information propagates back to the origin, then the application can decide if it should abort or reattempt the recovery operation. CIP Working Group [Page 13]
RFC 1190 Internet Stream Protocol October 1990 Although ST supports an arbitrary connection structure, we recognize that certain stream topologies will be common and justify special features, or options, which allow for optimized support. These include: o streams with only a single target (see Section 3.6.2 (page 44)), and o pairs of streams to support full duplex communication between two points (see Section 3.6.3 (page 45)). These features allow the most frequently occurring topologies to be supported with less setup delay, with fewer control messages, and with less overhead than the more general situations. 2.5. Flow Specifications Real time data, such as voice and video, have predictable characteristics and make specific demands of the networks that must transfer it. Specifically, the data may be transmitted in packets of a constant size that are produced at a constant rate. Alternatively, the bandwidth may vary, due either to variable packet size or rate, with a predefined maximum, and perhaps a non-zero minimum. The variation may also be predictable based on some model of how the data is generated. Depending on the equipment used to generate the data, the packet size and rate may be negotiable. Certain applications, such as voice, produce packets at the given rate only some of the time. The networks that support real time data must add minimal delay and delay variance, but it is expected that they will be non-zero. The FlowSpec is used for three purposes. First, it is used in the setup message to specify the desired and minimal packet size and rate required by the origin. This information is used by ST agents when they attempt to reserve the resources in the intervening networks. Second, when the setup message reaches the target, the FlowSpec contains the packet size and rate that was actually obtained along the path from the origin, and the accrued mean delay and delay variance expected for data packets along that path. This information is used by the target to determine if it wishes to accept the connection. The target may reduce reserved resources if it wishes to do so and if the possibility is still available. Third, if the target accepts the connection, it returns the updated FlowSpec to the origin, so that the origin can decide if it still wishes to participate in the stream with the characteristics that were actually obtained. CIP Working Group [Page 14]
RFC 1190 Internet Stream Protocol October 1990 When the data transmitted by stream users is generated at varying rates, including bursts of varying rate and duration, there is an opportunity to provide service to more subscribers by providing guaranteed service for the average data rate of each stream, and reserving additional network capacity, shared among all streams, to service the bursts. This concept has been recognized by analog voice network providers leading to the principle of time assigned speech interpolation (TASI) in which only the talkspurts of a speech conversation are transmitted, and, during silence periods, the circuit can be used to send the talkspurts of other conversations. The FlowSpec is intended to assist algorithms that perform similar kinds of functions. We do not propose such algorithms here, but rather expect that this will be an area for experimentation. To allow for experiments, and a range of ways that application traffic might be characterized, a "DutyFactor" is included in the FlowSpec and we expect that a "burst descriptor" will also be needed. The FlowSpec will need to be revised as experience is gained with connections involving numerous participants using multiple media across heterogeneous internetworks. We feel a change of the FlowSpec does not necessarily require a new version of ST, it only requires the FlowSpec version number be updated and software to manage the new FlowSpec to be distributed. We further suggest that if the change to the FlowSpec involves additional information for improved operation, such as a burst descriptor, that it be added to the end of the FlowSpec and that the current parameters be maintained so that obsolete software can be used to process the current parameters with minimum modifications. CIP Working Group [Page 15]
RFC 1190 Internet Stream Protocol October 1990 **** **** * * ST Agent 1 * * +---+ * *------- o ---------* *-------+ B | * * * * +---+ * * **** +---+ * * | | | * * | | A +---------* * o ST Agent 3 | | * * | +---+ * * | * * *** * * * * +---+ * * ST Agent 2 * *-------+ C | * *------- o --------* * +---+ * * * * **** * * * * +---+ * * +---+ | E +--------* *-------+ D | +---+ * * +---+ *** Figure 2. Topology Used in Protocol Exchange Diagrams **** ST Agent 1 **** * +--+---14--- o -----15--+----+--44---+---+ * | +-+--11--- -----16--+-+ * | B | * | | * * |+-+--45---+---+ * | | * *++* +---+ * | | * 34 ||32 | +----4----+--+ | * || | A +----6----+----+ * o ST Agent 3 | +----5----+---+ * | +---+ * | * | 33 * | * ST *+* * | * Agent * | * * | * 2 -----24-+--+ * +---+ * +--+--23--- o -----25-+-----+--54---+ C | * * -----26-+---+ * +---+ **** -----27-+-+ | * * | | * +---+ * | | * +---+ | E +---74---+-+ +-+--64---+ D | +---+ * * +---+ *** Figure 3. Virtual Link Identifiers for SCMP Messages CIP Working Group [Page 16]
RFC 1190 Internet Stream Protocol October 1990 3. ST Control Message Protocol Functional Description This section contains a functional description of the ST Control Message Protocol (SCMP); Section 4 (page 75) specifies the formats of the control message PDUs. We begin with a description of stream setup. Mechanisms used to deal with the exceptional cases are then presented. Complications due to options that an application or a ST agent may select are then detailed. Once a stream has been established, the data transfer phase is entered; it is described. Once the data transfer phase has been completed, the stream must be torn down and resources released; the control messages used to perform this function are presented. The resources or participants of a stream may be changed during the lifetime of the stream; the procedures to make changes are described. Finally, the section concludes with a description of some ancillary functions, such as failure detection and recovery, HID negotiation, routing, security, etc. To help clarify the SCMP exchanges used to setup and maintain ST streams, we have included a series of figures in this section. The protocol interactions in the figures assume the topology shown in Figure 2. The figures, taken together, o Create a stream from an application at A to three peers at B, C and D, o Add a peer at E, o Disconnect peers B and C, and o D drops out of the stream. Other figures illustrate exchanges related to failure recovery. In order to make the dispatch function within SCMP more uniform and efficient, each end of a hop is assigned, by the agent at that end, a Virtual Link Identifier that uniquely (within that agent) identifies the hop and associates it with a particular stream's state machine(s). The identifier at the end of a link that is sending a message is called the Sender Virtual Link Identifier (SVLId); that at the receiving end is called the Receiver Virtual Link Identifier (RVLId). Whenever one agent sends a control message for the other to receive, the sender will place the receiver's identifier into the RVLId field of the message and its own identifier in the SVLId field. When a reply to the message is sent, the values in SVLId and RVLId fields will be reversed, reflecting the fact the sender and receiver roles are reversed. VLIds with values zero through three are received and should not be assigned in response to CONNECT messages. Figure 3 shows the hops that will be used in the examples and summarizes the VLIds that will be assigned to them. CIP Working Group [Page 17]
RFC 1190 Internet Stream Protocol October 1990 Similarly, Figure 4 summarizes the HIDs that will eventually be negotiated as the stream is created. **** ST Agent 1 **** * +>+--1200-> o -------->+--->+-3600->+---+ * ^ * * * | B | * | * * +->+-6000->+---+ * | * *+** +---+ * | * ^ | +-------->+-->+ * | | A | * * o St Agent 3 | +-------->+-->+ * ^ +---+ * | * | 4801 * | * *+* * V * ST Agent 2 * ^ * +---+ * +>+--2400-> o ------->+->+->+-4800->+ C | **** * | * 4801 +---+ * | * +---+ * V * +---+ | E +<-4800--+<-+->+-4800->+ D | +---+ * * 4801 +---+ *** Figure 4. HIDs Assigned for ST User Packets Some of the diagrams that follow form a progression. For example, the steps required initially to establish a connection are spread across five figures. Within a progression, the actions on the first diagram are numbered 1.1, 1.2, etc.; within the second diagram they are numbered 2.1, 2.2, etc. Points where control leaves one diagram to enter another are identified with a continuation arrow "-->>", and are continued with "[a.b] >>-->" in the other diagram. The number in brackets shows the label where control left the earlier diagram. The reception of simple acknowledgments, e.g., ACKs, in one figure from another is omitted for clarity. 3.1. Stream Setup This section presents a description of stream setup assuming that everything succeeds -- HIDs are approved, any required resources are available, and the routing is correct. 3.1.1. Initial Setup at the Origin As described in Section 2.3 (page 11), the application has collected the information necessary to determine the CIP Working Group [Page 18]
RFC 1190 Internet Stream Protocol October 1990 participants in the communication before passing it to the host ST agent at the origin. The host ST agent will take this information, allocate a Name for the stream (see Section 4.2.2.8 (page 87)), and create a stream. 3.1.2. Invoking the Routing Function An ST agent that is setting up a stream invokes a routing function to find a path to reach each of the targets specified in the TargetList. This is similar to the routing decision in IP. However, in this case the route is to a multitude of targets rather than to a single destination. The set of next-hops that an ST agent would select is not necessarily the same as the set of next hops that IP would select given a number of independent IP datagrams to the same destinations. The routing algorithm may attempt to optimize parameters other than the number of hops that the packets will take, such as delay, local network bandwidth consumption, or total internet bandwidth consumption. The result of the routing function is a set of next-hop ST agents and the parameters of the intervening network(s). The latter permit the ST agent to determine whether the selected network has the resources necessary to support the level of service requested in the FlowSpec. 3.1.3. Reserving Resources The intent of ST is to provide a guaranteed level of service by reserving internet resources for a stream during a setup phase rather than on a per packet basis. The relevant resources are not only the forwarding information maintained by the ST agents, but also packet switch processor bandwidth and buffer space, and network bandwidth and multicast group identifiers. Reservation of these resources can help to increase the reliability and decrease the delay and delay variance with which data packets are delivered. The FlowSpec contains all the information needed by the ST agent to allocate the necessary resources. When and how these resources are allocated depends on the details of the networks involved, and is not specified here. If an ST agent must send data across a network to a single next-hop ST agent, then only the point-to-point bandwidth needs to be reserved. If the agent must send data to multiple next- hop agents across one network and network layer multicasting is not available, then bandwidth must be reserved for all of them. This will allow the ST agent to CIP Working Group [Page 19]
RFC 1190 Internet Stream Protocol October 1990 use replication to send a copy of the data packets to each next-hop agent. If multicast is supported, its use will decrease the effort that the ST agent must expend when forwarding packets and also reduces the bandwidth required since one copy can be received by all next-hop agents. However, the setup phase is more complicated. A network multicast address must be allocated that contains all those next-hop agents, the sender must have access to that address, the next-hop agents must be informed of the address so they can join the multicast group identified by it (see Section 4.2.2.7 (page 86)), and a common HID must be negotiated. The network should consider the bandwidth and multicast requirements to determine the amount of packet switch processing bandwidth and buffer space to reserve for the stream. In addition, the membership of a stream in a Group may affect the resources that have to be allocated; see Section 3.7.3 (page 56). Few networks in the Internet currently offer resource reservation, and none that we know of offer reservation of all the resources specified here. Only the Terrestrial Wideband Network (TWBNet) [7] and the Atlantic Satellite Network (SATNET) [9] offer(ed) bandwidth reservation. Multicasting is more widely supported. No network provides for the reservation of packet switch processing bandwidth or buffer space. We hope that future networks will be designed to better support protocols like ST. Effects similar to reservation of the necessary resources may be obtained even when the network cannot provide direct support for the reservation. Certainly if total reservations are a small fraction of the overall resources, such as packet switch processing bandwidth, buffer space, or network bandwidth, then the desired performance can be honored if the degree of confidence is consistent with the requirements as stated in the FlowSpec. Other solutions can be designed for specific networks. 3.1.4. Sending CONNECT Messages A VLId and a proposed HID must be selected for each next-hop agent. The control packets for the next-hop must carry the VLId in the SVLId field. The data packets transmitted in the stream to the next-hop must carry the HID in the ST Header. The ST agent sends a CONNECT message to each of the ST agents identified by the routing function. Each CONNECT message contains the VLId, the proposed HID (the HID Field option bit CIP Working Group [Page 20]
RFC 1190 Internet Stream Protocol October 1990 must be set, see Section 3.6.1 (page 44)), an updated FlowSpec, and a TargetList. In general, the HID, FlowSpec, and TargetList will depend on both the next-hop and the intervening network. Each TargetList is a subset of the received (or original) TargetList, identifying the targets that are to be reached through the next-hop to which the CONNECT message is being sent. Note that a CONNECT message to a single next-hop might have to be fragmented into multiple CONNECTs if the single CONNECT is too large for the intervening network's MTU; fragmentation is performed by further dividing the TargetList. If multiple next-hops are to be reached through a network that supports network level multicast, a different CONNECT message must nevertheless be sent to each next-hop since each will have a different TargetList; see Section 4.2.3.5 (page 105). However, since an identical copy of each ensuing data packet will reach each member of the multicast group, all the CONNECT messages must propose the same HID. See Section 3.7.4 (page 58) for a detailed discussion on HID selection. In the example of Figure 2, the routing function might return that B is reachable via Agent 1 and C and D are reachable via Agent 2. Thus A would create two CONNECT messages, one each for Agents 1 and 2, as illustrated in Figure 5. Assuming that the proposed HIDs are available in the receiving agents, they would each send a responding HID-APPROVE back to Agent A. Application Agent A Agent 1 Agent 2 1.1. (open B,C,D) V 1.2. +-> (routing to B,C,D) V 1.3. +->(reserve resources from A to Agent 1) | V 1.4. | +-> CONNECT B --------->> | <RVLId=0><SVLId=4> | <Ref=10><HID=1200> V 1.5. +->(reserve resources from A to Agent 2) V 1.6. +-> CONNECT C,D ------------------>> <RVLId=0><SVLId=5> <Ref=15><HID=2400> Figure 5. Origin Sending CONNECT Message CIP Working Group [Page 21]
RFC 1190 Internet Stream Protocol October 1990 3.1.5. CONNECT Processing by an Intermediate Agent An ST agent receiving a CONNECT message should, assuming no errors, quickly select a VLId and respond to the previous-hop with either an ACK, a HID-REJECT, or a HID-APPROVE message, as is appropriate. This message must identify the CONNECT to which it corresponds by including the CONNECT's Reference number in its Reference field. Note that the VLId that this agent selects is placed in the SVLId of the response, and the previous-hop's VLId (which is contained in the SVLId of the CONNECT) is copied into the RVLId of the response. If the agent is not a target, it must then invoke the routing function, reserve resources, and send a CONNECT message(s) to its next-hop(s), as described in Sections 3.1.2-4 (pages 19- 20). Agent A Agent 1 Agent B [1.4] >>-> CONNECT B -------->+--+ <RVLId=0><SVLId=4> | V 2.1. <Ref=10><HID=1200> | (routing to B) | V 2.2. V +->(reserve resources from 1 to B) 2.3. +<- HID-APPROVE <------+ V 2.4. <RVLId=4><SVLId=14> +-> CONNECT B ---------->> <Ref=10><HID=1200> <RVLId=0><SVLId=15> <Ref=110><HID=3600> Agent A Agent 2 Agent C [1.6] >>-> CONNECT C,D ------>+-+ <RVLId=0><SVLId=5> | V 2.5. <Ref=15><HID=2400> | (routing to C,D) | V 2.6. V +-->(reserve resources from 2 to C) 2.7. +<- HID-APPROVE <------+ | V 2.8. <RVLId=5><SVLId=23> | +-> CONNECT C ---------->> <Ref=15><HID=2400> | <RVLId=0><SVLId=25> | <Ref=210><HID=4800> | | Agent D V 2.9. +->(reserve resources from 2 to D) V 2.10. +-> CONNECT D ---------->> <RVLId=0><SVLId=26> <Ref=215><HID=4800> Figure 6. CONNECT Processing by an Intermediate Agent CIP Working Group [Page 22]
RFC 1190 Internet Stream Protocol October 1990 The resources listed as Desired in a received FlowSpec may not correspond to those actually reserved in either the ST agent itself or in the network(s) used to reach the next-hop agent(s). As long as the reserved resources are sufficient to meet the specified Limits, the copy of the FlowSpec sent to a next-hop must have the Desired resources updated to reflect the resources that were actually obtained. For example, the Desired bandwidth might be reduced because the network to the next-hop could not provide all of the desired bandwidth. Also, the delay and delay variance are appropriately increased, and the link MTU may require that the DesPDUBytes field be reduced. (The minimum requirements that the origin had entered into the FlowSpec Limits fields cannot be altered by the intermediate or target agents.) 3.1.6. Setup at the Targets An ST agent that is the target of a CONNECT, whether from an intermediate ST agent, or directly from the origin host ST agent, must respond first (assuming no errors) with either a HID-REJECT or HID-APPROVE. After inquiring from the specified application process whether or not it is willing to accept the connection, the agent must also respond with either an ACCEPT or a REFUSE. In particular, the application must be presented with parameters from the CONNECT, such as the Name, FlowSpec, Options, and Group, to be used as a basis for its decision. The application is identified by a combination of the NextPcol field and the SAP field in the (usually) single remaining Target of the TargetList. The contents of the SAP field may specify the "port" or other local identifier for use by the protocol layer above the host ST layer. Subsequently received data packets will carry a short hand identifier (the HID) that can be mapped into this information and be used for their delivery. The responses to the CONNECT message are sent to the previous- hop from which the CONNECT was received. An ACCEPT contains the Name of the stream and the updated FlowSpec. Note that the application might have reduced the desired level of service in the received FlowSpec before accepting it. The target must not send the ACCEPT until HID negotiation has been successfully completed. Since the ACCEPT or REFUSE message must be acknowledged by the previous-hop, it is assigned a new Reference number that will be returned in the ACK. The CONNECT to which the ACCEPT or REFUSE is a reply is identified by placing the CONNECT's Reference number in the LnkReference field of the ACCEPT or REFUSE. CIP Working Group [Page 23]
RFC 1190 Internet Stream Protocol October 1990 Agent 1 Agent B Application B 3.1. (proc B listening) [2.4] >>-> CONNECT B ---------->+------------------+ <RVLId=0><SVLId=15> | | 3.2. <Ref=110><HID=3600> V (proc B accepts) 3.3. +<- HID-APPROVE <--------+ | <RVLId=15><SVLId=44> | <Ref=110><HID=3600> V 3.4. (wait until HID negotiated) <---+ V 3.5. <<--+<- ACCEPT B <-----------+ <RVLId=15><SVLId=44> <Ref=410><LnkRef=110> Agent 2 Agent C Application C 3.6. (proc C listening) [2.8] >>-> CONNECT C ---------->+------------------+ <RVLId=0><SVLId=25> | | 3.7. <Ref=210><HID=4800> V (proc C accepts) 3.8. +<- HID-APPROVE <--------+ | <RVLId=25><SVLId=54> | <Ref=210><HID=4800> V 3.9. (wait until HID negotiated) <---+ V 3.10. <<--+<- ACCEPT C <-----------+ <RVLId=25><SVLId=54> <Ref=510><LnkRef=210> Agent 2 Agent D Application D 3.11. (proc D listening) [2.10] >>-> CONNECT D ---------->+------------------+ <RVLId=0><SVLId=26> | | 3.12. <Ref=215><HID=4800> V (proc D accepts) 3.13. +<- HID-APPROVE <--------+ | <RVLId=26><SVLId=64> | <Ref=215><HID=4800> V 3.14. (wait until HID negotiated) <---+ V 3.15. <<--+<- ACCEPT D <-----------+ <RVLId=26><SVLId=64> <Ref=610><LnkRef=215> Figure 7. CONNECT Processing by the Target 3.1.7. ACCEPT Processing by an Intermediate Agent When an intermediate ST agent receives an ACCEPT, it first verifies that the message is a response to an earlier CONNECT. If not, it responds to the next-hop ST agent with an ERROR-IN- REPLY (LnkRefUnknown) message. Otherwise, it responds to the next-hop ST agent with an ACK, and propagates CIP Working Group [Page 24]
RFC 1190 Internet Stream Protocol October 1990 the ACCEPT message to the previous-hop along the same path traced by the CONNECT but in the reverse direction toward the origin. The ACCEPT should not be propagated until all HID negotiations with the next-hop agent(s) have been successfully completed. The FlowSpec is included in the ACCEPT message so that the origin and intermediate ST agents can gain access to the information that was accumulated as the CONNECT traversed the internet. Note that the resources, as specified in the FlowSpec in the ACCEPT message, may differ from the resources that were reserved by the agent when the CONNECT was Agent A Agent 1 Agent B +<-+<- ACCEPT B <-------<< [3.5] V | <RVLId=15><SVLId=44> 4.1. (wait for ACCEPTS) V <Ref=410><LnkRef=110> 4.2. V +-> ACK --------------->+ 4.3. (wait until HID negotiated)<-+ <RVLId=44><SVLId=15> V <Ref=410> 4.4. <<--+<-- ACCEPT B <---------+ <RVLId=4><SVLId=14> <Ref=115><LnkRef=10> Agent A Agent 2 Agent C +<-+<- ACCEPT C <------<< [3.10] | | <RVLId=25><SVLId=54> | V <Ref=510><LnkRef=210> 4.5. | +-> ACK --------------->+ | <Ref=510> | <RVLId=54><SVLId=25> | | Agent D V +<-+<- ACCEPT D <------<< [3.15] V | <RVLId=26><SVLId=64> 4.6. (wait for ACCEPTS) V <Ref=610><LnkRef=215> 4.7. V +-> ACK --------------->+ 4.8. (wait until HID negotiated)<-+ <RVLId=64><SVLId=26> V <Ref=610> 4.9. <<--+<- ACCEPT C <----------+ <RVLId=5><SVLId=23> | <Ref=220><LnkRef=15>| V 4.10. <<--+<- ACCEPT D <----------+ <RVLId=5><SVLId=23> <Ref=225><LnkRef=15> Figure 8. ACCEPT Processing by an Intermediate Agent CIP Working Group [Page 25]
RFC 1190 Internet Stream Protocol October 1990 originally processed. However, the agent does not adjust the reservation in response to the ACCEPT. It is expected that any excess resource allocation will be released for use by other stream or datagram traffic through an explicit CHANGE message initiated by the application at the origin if it does not wish to be charged for any excess resource allocations. 3.1.8. ACCEPT Processing by the Origin The origin will eventually receive an ACCEPT (or REFUSE or ERROR-IN-REQUEST) message from each of the targets. As each ACCEPT is received, the application should be notified of the target and the resources that were successfully allocated along the path to it, as specified in the FlowSpec contained in the ACCEPT message. The application may then use the information to either adopt or terminate the portion of the stream to each target. When ACCEPTs (or failures) from all targets have been received at the origin, the application is notified that stream setup is complete, and that data may be sent. Application A Agent A Agent 1 Agent 2 +<-- ACCEPT B <--------<< [4.4] | <RVLId=4><SVLId=14> V <Ref=115><LnkRef=10> 5.1. +--> ACK ----------------->+ | <RVLId=14><SVLId=4> V <Ref=115> 5.2. +<-- (inform A of B's FlowSpec) | +<-- ACCEPT C <----------------<< [4.9] | | <RVLId=5><SVLId=23> | V <Ref=220><LnkRef=15> 5.3. | +--> ACK ------------------------->+ | | <RVLId=23><SVLId=5> | V <Ref=220> 5.4. +<-- (inform A of C's FlowSpec) | +<-- ACCEPT D <----------------<< [4.10] | | <RVLId=5><SVLId=23> | V <Ref=225><LnkRef=15> 5.5. | +--> ACK ------------------------->+ | | <RVLId=23><SVLId=5> | V <Ref=225> 5.6. +<-- (inform A of D's FlowSpec) V 5.7. (wait until HIDs negotiated) V 5.8. (inform A open to B,C,D) Figure 9. ACCEPT Processing by the Origin CIP Working Group [Page 26]
RFC 1190 Internet Stream Protocol October 1990 There are several pieces of information contained in the FlowSpec that the application must combine before sending data through the stream. The PDU size should be computed from the minimum value of the DesPDUBytes field from all ACCEPTs and the protocol layers above ST should be informed of the limit. It is expected that the next higher protocol layer above ST will segment its PDUs accordingly. Note, however, that the MTU may decrease over the life of the stream if new targets are subsequently added. Whether the MTU should be increased as targets are dropped from a stream is left for further study. The available bandwidth and packet rate limits must also be combined. In this case, however, it may not be possible to select a pair of values that may be used for all paths, e.g., one path may have selected a low rate of large packets while another selected a high rate of small packets. The application may remedy the situation by either tearing down the stream, dropping some participants, or creating a second stream. After any differences have been resolved (or some targets have been deleted by the application to permit resolution), the application at the origin should send a CHANGE message to release any excess resources along paths to those targets that exceed the resolved parameters for the stream, thereby reducing the costs that will be incurred by the stream. 3.1.9. Processing a REFUSE Message REFUSE messages are used to indicate a failure to reach an application at a target; they are propagated toward the origin of a stream. They are used in three situations: 1 during stream setup or expansion to indicate that there is no satisfactory path from an ST agent to a target, 2 when the application at the target either does not exist does not wish to be a participant, or wants to cease being a participant, and 3 when a failure has been detected and the agents are trying to find a suitable path around the failure. The cases are distinguished by the ReasonCode field and an agent receiving a REFUSE message must examine that field in order to determine the proper action to be taken. In particular, if the ReasonCode indicates that the CONNECT message reached the target then the REFUSE should be propagated back to the origin, releasing resources as appropriate along the way. If the ReasonCode indicates that CIP Working Group [Page 27]
RFC 1190 Internet Stream Protocol October 1990 the CONNECT message did not reach the target then the intermediate (origin) ST agent(s) should check for alternate routes to the target before propagating the REFUSE back another hop toward the origin. This implies that an agent must keep track of the next-hops that it has tried, on a target by target basis, in order not to get caught in a loop. An ST agent that receives a REFUSE message must acknowledge it by sending an ACK to the next-hop. The REFUSE must also be propagated back to the previous-hop ST agent. Note that the ST agent may not have any information about the target in Appl. Agent A Agent 2 Agent E (proc E NOT listening) 1. (add E) 2. +----->+-> CONNECT E ---------->+->+ <RVLId=23><SVLId=5> | | <Ref=65> V | 3. +<-- ACK <---------------+ | <RVLId=5><SVLId=23> V 4. <Ref=65> (routing to E) V 5. (reserve resources 2 to E) V 6. +--> CONNECT E --------->+ <RVLId=0><SVLId=27> | <Ref=115><HID=4600> | V 7. +<-+<- REFUSE B <-----------+ | | <RVLId=27><SVLId=74> | | <Ref=705><LnkRef=115> | V <RC=SAPUnknown> 8. | +-> ACK ---------------->+ | | <RVLId=74><SVLId=27> | | V <Ref=705> | 9. | (free link 27) V 10. V (free link 74) 11. +<- REFUSE B <-----------+ | <RVLId=5><SVLId=23> | | <Ref=550><LnkRef=65> V 12. | <RC=SAPUnknown> (free resources 2 to E) V 13. +-> ACK --------------->+ | <RVLId=23><SVLId=5> | | <Ref=550> V 14. V (keep link 23 for C,D) 15. (keep link 5 for C,D) V 16. (inform application failed SAPUnknown) Figure 10. Sending REFUSE Message CIP Working Group [Page 28]
RFC 1190 Internet Stream Protocol October 1990 the TargetList. This may result from interacting DISCONNECT and REFUSE messages and should be logged and silently ignored. If, after deleting the specified target, the next-hop has no remaining targets, then those resources associated with that next-hop agent may be released. Note that network resources may not actually be released if network multicasting is being Appl. Agent A Agent 2 Agent 1 Agent 3 Agent B 1. (network from 1 to B fails) 2. (add B) 3. +-> CONNECT B ----------------->+ <RVLId=0><SVLId=6> | <Ref=35><HID=100> | 3. +<- HID-APPROVE <---------------+ <RVLId=6><SVLId=11> | <Ref=35><HID=100> V 4. (routing to B: no route) V 5. +<-+-- REFUSE B ----------------+ | | <RVLId=6><SVLId=11> | | <Ref=155><LnkRef=35> | V <RC=NoRouteToDest> 6. | +-> ACK -------------------->+ | | <RVLId=11><SVLId=6> V 7. | V <Ref=155> (drop link 6) 8. V (drop link 11) 9. (find alternative route: via agent 2) 10. (resources from A to 2 already allocated: V reuse control link & HID, no additional resources required) 11. +-> CONNECT B -------->+->+ <RVLId=23><SVLId=5>| | <Ref=40> V | 12. +<- ACK <--------------+ | <RVLId=5><SVLId=23> V 13. <Ref=40> (routing to B: via agent 3) V 14. +-> CONNECT B -->+ 15. <RVLId=0><SVLId=24> +-> CONNECT B --------->+ <Ref=245><HID=4801> V <RVLId=0><SVLId=32> | 16. +<- HID-APPROVE -+ <Ref=310><HID=6000> | <RVLId=24><SVLId=33> | <Ref=245><HID=4801> V 17. +<- HID-APPROVE --------+ <RVLId=32><SVLId=45>| <Ref=310><HID=6000> V 18. (ACCEPT handling follows normally to complete stream setup) Figure 11. Routing Around a Failure CIP Working Group [Page 29]
RFC 1190 Internet Stream Protocol October 1990 used since they may still be required for traffic to other next-hops in the multicast group. When the REFUSE reaches a origin, the origin sends an ACK and notifies the application via the next higher layer protocol that the target listed in the TargetList is no longer part of the stream and also if the stream has no remaining targets. If there are no remaining targets, the application may wish to terminate the stream. Figure 10 illustrates the protocol exchanges for processing a REFUSE generated at the target, either because the target application is not running or that the target application rejects membership in the stream. Figure 11 illustrates the case of rerouting around a failure by an intermediate agent that detects a failure or receives a refuse. The protocol exchanges used by an application at the target to delete itself from the stream is discussed in Section 3.3.3 (page 35). 3.2. Data Transfer At the end of the connection setup phase, the origin, each target, and each intermediate ST agent has a database entry that allows it to forward the data packets from the origin to the targets and to recover from failures of the intermediate agents or networks. The database should be optimized to make the packet forwarding task most efficient. The time critical operation is an intermediate agent receiving a packet from the previous-hop agent and forwarding it to the next-hop agent(s). The database entry must also contain the FlowSpec, utilization information, the address of the origin and previous-hop, and the addresses of the targets and next-hops, so it can perform enforcement and recover from failures. An ST agent receives data packets encapsulated by an ST header. A data packet received by an ST agent contains the non-zero HID assigned to the stream for the branch from the previous-hop to itself. This HID was selected so that it is unique at the receiving ST agent and thus can be used, e.g., as an index into the database, to obtain quickly the necessary replication and forwarding information. The forwarding information will be network and implementation specific, but must identify the next-hop agent or agents and their respective HIDs. It is suggested that the cached information for a next-hop agent include the local network address of the next- hop. If the data packet must be forwarded to multiple next-hops across a single network that supports multicast, the database may specify a single HID and may identify the next-hops by a (local network) multicast address. CIP Working Group [Page 30]
RFC 1190 Internet Stream Protocol October 1990 If the network does not support multicast, or the next-hops are on different networks, then the database must indicate multiple (next-hop, HID) tuples. When multiple copies of the data packet must be sent, it may be necessary to invoke a packet replicator. Data packets should not require fragmentation as the next higher protocol layer at the origin was informed of the minimum MTU over all paths in the stream and is expected to segment its PDUs accordingly. However, it may be the case that a data packet that is being rerouted around a failed network component may be too large for the MTU of an intervening network. This should be a transient condition that will be corrected as soon as the new minimum MTU has been propagated back to the origin. Disposition by a mechanism other than dropping of the too large PDUs is left for further study. 3.3. Modifying an Existing Stream Some applications may wish to change the parameters of a stream after it has been created. Possible changes include adding or deleting targets and changing the FlowSpec. These are described below. 3.3.1. Adding a Target It is possible for an application to add a new target to an existing stream any time after ST has incorporated information about the stream into its database. At a high level, the application entities exchanges whatever information is necessary. Although the mechanism or protocol used to accomplish this is not specified here, it is necessary for the higher layer protocol to inform the host ST agent at the origin of this event. The host ST agent at the target must also be informed unless this had previously been done. Generally, the transfer of a target list from an ST agent to another, or from a higher layer protocol to a host ST agent, will occur atomically when the CONNECT is received. Any information concerning a new target received after this point can be viewed as a stream expansion by the receiving ST agent. However, it may be possible that an ST agent can utilize such information if it is received before it makes the relevant routing decisions. These implementation details are not specified here, but implementations must be prepared to receive CONNECT messages that represent expansions of streams that are still in the process of being setup. To expand an existing stream, the origin issues one or more CONNECT messages that contain the Name, the VLId, the FlowSpec, and the TargetList specifying the new target or targets. The origin issues multiple CONNECT messages if CIP Working Group [Page 31]
RFC 1190 Internet Stream Protocol October 1990 either the targets are to be reached through different next-hop agents, or a single CONNECT message is too large for the network MTU. The HID Field option is not set since the HID has already been (or is being) negotiated for the hop; consequently, the CONNECT is acknowledged with an ACK instead of a HID-REJECT or HID-APPROVE. Application Agent A Agent 2 Agent E 1. (open E) 2. V (proc E listening) 3. +->(routing to E) V 4. +-> (check resources from A to Agent 2: already allocated, V reuse control link & HID, no additional resources needed) 5. +-> CONNECT E --------->+->+ <RVLId=23><SVLId=5> | V 6. <Ref=20> V (routing to E) 7. +<- ACK <---------------+ V <RVLId=5><SVLId=23> +->(reserve resources 2 to E) <Ref=20> V 8. +-> CONNECT E --------->+ <RVLId=0><SVLId=27> | <Ref=230><HID=4800> | 9. +<- HID-APPROVE <-------+ <RVLId=27><SVLId=74>| <Ref=230><HID=4800> V 10. (proc E accepts) 11. (wait until HID negotiated) V 12. +<-+<- ACCEPT E <----------+ V | <RVLId=27><SVLId=74> 13. (wait for ACCEPTS) V <Ref=710><LnkRef=230> 14. V +-> ACK --------------->+ 15. (wait until HID negotiated)<-+ <RVLId=74><SVLId=27> V <Ref=710> 16. +<- ACCEPT E <-------+ | <RVLId=5><SVLId=23> V <Ref=235><LnkRef=20> 17. +-> ACK ------------>+ | <RVLId=23><SVLId=5> V <Ref=235> 18. +<-(inform A of E's FlowSpec) V 19. +<-(wait for ACCEPTS) V 20. +<-(wait until HID negotiated) V 21. (inform A open to E) Figure 12. Addition of Another Target CIP Working Group [Page 32]
RFC 1190 Internet Stream Protocol October 1990 An ST agent that is already a node in the stream recognizes the RVLId and verifies that the Name of the stream is the same. It then checks if the intersection of the TargetList and the targets of the established stream is empty. If this is not the case, then the receiver responds with an ERROR-IN-REQUEST with the appropriate reason code (RouteLoop) that contains a TargetList of those targets that were duplicates; see Section 4.2.3.5 (page 106). For each new target in the TargetList, processing is much the same as for the original CONNECT; see Sections 3.1.2-4 (pages 19-20). The CONNECT must be acknowledged, propagated, and network resources must be reserved. However, it may be possible to route to the new targets using previously allocated paths or an existing multicast group. In that case, additional resources do not need to be reserved but more next-hop(s) might have to be added to an existing multicast group. Nevertheless, the origin, or any intermediate ST agent that receives a CONNECT for an existing stream, can make a routing decision that is independent of any it may have made previously. Depending on the routing algorithm that is used, the ST agent may decide to reach the new target by way of an established branch, or it may decide to create a new branch. The fact that a new target is being added to an existing stream may result in a suboptimal overall routing for certain routing algorithms. We take this problem to be unavoidable since it is unlikely that the stream routing can be made optimal in general, and the only way to avoid this loss of optimality is to redefine the routing of potentially the entire stream, which would be too expensive and time consuming. 3.3.2. The Origin Removing a Target The application at the origin specifies a set of targets that are to be removed from the stream and an appropriate reason code (ApplDisconnect). The targets are partitioned into multiple DISCONNECT messages based on the next-hop to the individual targets. As with CONNECT messages, an ST agent that is sending a DISCONNECT must make sure that the message fits into the MTU for the intervening network. If the message is too large, the TargetList must be further partitioned into multiple DISCONNECT messages. An ST agent that receives a DISCONNECT message must acknowledge it by sending an ACK back to the previous-hop. The DISCONNECT must also be propagated to the relevant next-hop ST agents. Before propagating the message, however, the TargetList should be partitioned based on next-hop ST CIP Working Group [Page 33]
RFC 1190 Internet Stream Protocol October 1990 agent and MTU, as described above. Note that there may be targets in the TargetList for which the ST agent has no information. This may result from interacting DISCONNECT and REFUSE messages and should be logged and silently ignored. If, after deleting the specified targets, any next-hop has no remaining targets, then those resources associated with that next-hop agent may be released. Note that network resources may not actually be released if network multicasting is being used since they may still be required for traffic to other next-hops in the multicast group. Application Application Agent A Agent 1 Agent 2 Agent B C 1. (close B,C ApplDisconnect) V 2. +->+-+-> DISCONNECT B ----->+ 3. | | <RVLId=14><SVLId=4>+-+-> DISCONNECT B ------>+ | | <Ref=25> | | <RVLId=44><SVLId=15>| | V <RC=ApplDisconnect>| | <Ref=120> | 4. | (free A to 1 resrc.) | V <RC=ApplDisconnect> | 5. | V (free 1 to B resrc.) | 6. | +<- ACK <--------------+ V 7. | | <RVLId=4><SVLId=14>| +<- ACK <---------------+ | V <Ref=25> | | <RVLId=15><SVLId=44>| 8. | (free link 4) V | <Ref=120> | 9. | (free link 14) V | 10. | (free link 15) V 11. | (inform B that stream closed ApplDisconnect) 12. | (free link 44) V 13. +<-+-+-> DISCONNECT C ---------->+ 14. | | <RVLId=23><SVLId=5> +-+-> DISCONNECT C ------>+ | | <Ref=30> | | <RVLId=54><SVLId=25>| | V <RC=ApplDisconnect> | | <Ref=240> | 15. | (keep A to 2 resrc for | V <RC=ApplDisconnect> | 16. | data going to D,E) | (free 2 to C resrc.) | | V | 17. | +<- ACK <-------------------+ V 18. | | <RVLId=5><SVLId=23> | +<- ACK <---------------+ | V <Ref=30> | | <RVLId=25><SVLId=54>| 19. | (keep link 5 for D,E) V | <Ref=240> | 20. | (keep link 23 for D,E) V | 21. | (free link 25) V 22. | (inform C that stream closed ApplDisconnect>) 23. V (free link 54) 24. (inform A closed to B,C ApplDisconnect) Figure 13. Origin Removing a Target CIP Working Group [Page 34]
RFC 1190 Internet Stream Protocol October 1990 When the DISCONNECT reaches a target, the target sends an ACK and notifies the application that it is no longer part of the stream and the reason. The application should then inform ST to terminate the stream, and ST should delete the stream from its database after performing any necessary management and accounting functions. 3.3.3. A Target Deleting Itself The application at the target may inform ST that it wants to be removed from the stream and the appropriate reason code (ApplDisconnect). The agent then forms a REFUSE message with itself as the only entry in the TargetList. The REFUSE is sent back to the origin via the previous-hop. If a stream has multiple targets and one target leaves the stream using this REFUSE mechanism, the stream to the other targets is not affected; the stream continues to exist. An ST agent that receives such a REFUSE message must acknowledge it by sending an ACK to the next-hop. The target is deleted and, if the next-hop has no remaining targets, then the those resources associated with that next-hop agent may be released. Note that network resources may not actually be released if network multicasting is being used since they may still be required for traffic to other next-hops in the multicast group. The REFUSE must also be propagated back to the previous-hop ST agent. Agent A Agent 2 Agent E 1. (close E ApplDisconnect) V 2. +<- REFUSE E --+ | <RVLId=27><SVLId=74> | <Ref=720> V <RC=ApplDisconnect> 3. +<-+-> ACK ------>+ | | <RVLId=74><SVLId=27> 4. V V <Ref=720> 5. +<-+<- REFUSE E --+ (prune allocations) | | <RVLId=5><SVLId=23> | | <Ref=245> | V <RC=ApplDisconnect> 6. | +-> ACK ------>+ | | <RVLId=23><SVLId=5> | V <Ref=245> 7. V (prune allocations) 8. (inform application closed E ApplDisconnect) Figure 14. Target Deleting Itself CIP Working Group [Page 35]
RFC 1190 Internet Stream Protocol October 1990 When the REFUSE reaches the origin, the origin sends an ACK and notifies the application that the target listed in the TargetList is no longer part of the stream. If the stream has no remaining targets, the application may choose to terminate the stream. 3.3.4. Changing the FlowSpec An application may wish to change the FlowSpec of an established stream. To do so, it informs ST of the new FlowSpec and the list of targets that are to be changed. The origin ST agent then issues one or more CHANGE messages with the new FlowSpec and sends them to the relevant next-hop agents. CHANGE messages are structured and processed similarly to CONNECT messages. A next-hop agent that is an intermediate agent and receives a CHANGE message similarly determines if it can implement the new FlowSpec along the hop to each of its next-hop agents, and if so, it propagates the CHANGE messages along the established paths. If this process succeeds, the CHANGE messages will eventually reach the targets, which will each respond with an ACCEPT message that is propagated back to the origin. Note that since a CHANGE may be sent containing a FlowSpec with a range of permissible values for bandwidth, delay, and/or error rate, and the actual values returned in the ACCEPTs may differ, then another CHANGE may be required to release excess resources along some of the paths. 3.4. Stream Tear Down A stream is usually terminated by the origin when it has no further data to send, but may also be partially torn down by the individual targets. These cases will not be further discussed since they have already been described in Sections 3.3.2-3 (pages 33-35). A stream is also torn down if the application should terminate abnormally. Processing in this case is identical to the previous descriptions except that the appropriate reason code is different (ApplAbort). When all targets have left a stream, the origin notifies the application of that fact, and the application then is responsible for terminating the stream. Note, however, that the application may decide to add a target(s) to the stream instead of terminating it. CIP Working Group [Page 36]
RFC 1190 Internet Stream Protocol October 1990 3.5. Exceptional Cases The previous descriptions covered the simple cases where everything worked. We now discuss what happens when things do not succeed. Included are situations where messages are lost, the requested resources are not available, the routing fails or is inconsistent. In order for the ST Control Message Protocol to be reliable over an unreliable internetwork, the problems of corruption, duplication, loss, and ordering must be addressed. Corruption is handled through use of checksumming, as described in Section 4 (page 76). Duplication of control messages is detected by assigning a transaction number (Reference) to each control message; duplicates are discarded. Loss is detected using a timeout at the sender; messages that are not acknowledged before the timeout expires are retransmitted; see Section 3.7.6 (page 66). If a message is not acknowledged after a few retransmissions a fault is reported. The protocol does not have significant ordering constraints. However, minor sequencing of control messages for a stream is facilitated by the requirement that the Reference numbers be monotonically increasing; see Section 4.2 (page 78). 3.5.1. Setup Failure due to CONNECT Timeout If a response (an ERROR-IN-REQUEST, an ACK, a HID-REJECT, or a HID-APPROVE) has not been received within time ToConnect, the ST agent should retransmit the CONNECT message. If no response has been received within NConnect retransmissions, then a fault occurs and a REFUSE message with the appropriate reason code (RetransTimeout) is sent back in the direction of the origin, and, in place of the CONNECT, a DISCONNECT is sent to the next-hop (in case the response to the CONNECT is the message that was lost). The agent will expect an ACK for both the REFUSE and the DISCONNECT messages. If it does not receive an ACK after retransmission time ToRefuse and ToDisconnect respectively, it will resend the REFUSE/DISCONNECT message. If it does not receive ACKs after sending NRefuse/ NDisconnect consecutive REFUSE/DISCONNECT messages, then it simply gives up trying. CIP Working Group [Page 37]
RFC 1190 Internet Stream Protocol October 1990 Sending Agent Receiving Agent 1. ->+----> CONNECT X ------>//// (message lost or garbled) | <RVLId=0><SVLId=99> V <Ref=1278><HID=1234> 2. (timeout) V 3. +----> CONNECT X ------------>+ 4. | <RVLId=0><SVLId=99> +----> CONNECT X ----------->+ | <Ref=1278><HID=1234> V <RVLId=0><SVLId=1010> | 5. | //<- HID-APPROVE <----------+ <Ref=6666><HID=6666> V 6. | <RVLId=99><SVLId=88> +<- HID-APPROVE <---------+ V <Ref=1278><HID=1234> <RVLId=1010><SVLId=1111> 7. (timeout) <Ref=6666><HID=6666> V 8. +----> CONNECT X ------------>+ <RVLId=0><SVLId=99> | <Ref=1278><HID=1234> V 9. +<-+<- HID-APPROVE <----------+ | <RVLId=99><SVLId=88> V <Ref=1278><HID=1234> (cancel timer) Figure 15. CONNECT Retransmission after a Timeout 3.5.2. Problems due to Routing Inconsistency When an intermediate agent receives a CONNECT, it selects the next-hop agents based on the TargetList and the networks to which it is connected. If the resulting next-hop to any of the targets is across the same network from which it received the CONNECT (but not the previous-hop itself), there may be a routing problem. However, the routing algorithm at the previous-hop may be optimizing differently than the local algorithm would in the same situation. Since the local ST agent cannot distinguish the two cases, it should permit the setup but send back to the previous-hop agent an informative NOTIFY message with the appropriate reason code (RouteBack), pertinent TargetList, and in the NextHopIPAddress element the address of the next-hop ST agent returned by its routing algorithm. The agent that receives such a NOTIFY should ACK it. If the agent is using an algorithm that would produce such behavior, no further action is taken; if not, the agent should send a DISCONNECT to the next-hop agent to correct the problem. Alternatively, if the next-hop returned by the routing function is in fact the previous-hop, a routing inconsistency has been detected. In this case, a REFUSE is sent back to CIP Working Group [Page 38]
RFC 1190 Internet Stream Protocol October 1990 the previous-hop agent containing an appropriate reason code (RouteInconsist), pertinent TargetList, and in the NextHopIPAddress element the address of the previous-hop. When the previous-hop receives the REFUSE, it will recompute the next-hop for the affected targets. If there is a difference in the routing databases in the two agents, they may exchange CONNECT and REFUSE messages again. Since such routing errors in the internet are assumed to be temporary, the situation should eventually stabilize. 3.5.3. Setup Failure due to a Routing Failure It is possible for an agent to receive a CONNECT message that contains a known Name, but from an agent other than the previous-hop agent of the stream with that Name. This may be: 1 that two branches of the tree forming the stream have joined back together, 2 a deliberate source routing loop, 3 the result of an attempted recovery of a partially failed stream, or 4 an erroneous routing loop. The TargetList is used to distinguish the cases 1 and 2 (see also Section 4.2.3.5 (page 107)) by comparing each newly received target with those of the previously existing stream: o if the IP address of the targets differ, it is case 1; o if the IP address of the targets match but the source route(s) are different, it is case 2; o if the target (including any source route) matches a target (including any source route) in the existing stream, it may be case 3 or 4. It is expected that the joining of branches will become more common as routing decisions are based on policy issues and not just simple connectivity. Unfortunately, there is no good way to merge the two parts of the stream back into a single stream. They must be treated independently with respect to processing in the agent. In particular, a separate state machine is required, the Virtual Link Identifiers and HIDs from the previous-hops and to the next-hops must be different, and duplicate resources must be reserved in both the agent and in any next-hop networks. Processing is the same for a deliberate source routing loop. CIP Working Group [Page 39]
RFC 1190 Internet Stream Protocol October 1990
RFC 1190 Internet Stream Protocol October 1990 3.7.3. A Group of Streams There may be a need to associate related streams. The Group mechanism is simply an association technique that allows ST agents to identify the different streams that are to be associated. Streams are in the same Group if they have the same Group Name in the GroupName field of the (R)Group parameter. At this time there are no ST control messages that modify Groups. Group Names have the same format as stream Names, and can share the same name space. A stream that is a member of a Group can specify one or more (Subgroup Identifier, Relation) tuples. The Relation specifies how the members of the Subgroup of the Group are related. The Subgroups Identifiers need only be unique within the Group. Streams can be associated into Groups to support activities that deal with a number of streams simultaneously. The operation of Groups of streams is a matter for further study, and this mechanism is provided to support that study. This mechanism allows streams to be identified as belonging to a given Group and Subgroup, but in order to have any effect, the behavior that is expected of the Relation must be implemented in the ST agents. Possible applications for this mechanism include the following: o Associating streams that are part of a floor-controlled conference. In this case, only one origin can send data through its stream at any given time. Therefore, at any point where more than one stream passes through a branch or network, only enough bandwidth for one stream needs to be allocated. o Associating streams that cannot exist independently. An example of this may be the various streams that carry the audio, video, and data components of a conference, or the various streams that carry data from the different participants in a conference. In this case, if some ST agent must preempt more than a single stream, and it has selected any one of the streams so associated, then it should also preempt the rest of the members of that Subgroup rather than preempting any other streams. o Associating streams that must not be completed independently. This example is similar to the preceding one, but relates to the stream setup phase. In this example, any single member of a Subgroup of streams need not be completed unless the rest are also completed. Therefore, if one stream becomes blocked, all the others will also be blocked. In this case, if there are not enough resources to support all the conferences that are attempted, some number of the conferences will complete CIP Working Group [Page 56]
RFC 1190 Internet Stream Protocol October 1990
RFC 1190 Internet Stream Protocol October 1990 A GroupName has the same format as a Name; see Figure 29. 4.2.2.6. HID & RHID The HID parameter (PCode = 5) is used in the NOTIFY message when the notification is related to a HID, and possibly in the STATUS-RESPONSE message to convey additional HIDs that are valid for a stream when there are more than one. It consists of the PCode and PBytes bytes prepended to a HID; HIDs were described in Section 4 (page 76). The RHID parameter (PCode = 14) is used in conjunction with the FDx option to convey the HID that is to be used in the reverse direction. It consists of the PCode and PBytes bytes prepended to a HID. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode | 4 | HID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27. HID & RHID 4.2.2.7. MulticastAddress The MulticastAddress parameter (PCode = 6) is an optional parameter that is used, when setting up a network level multicast group, to communicate an IP and/or local network multicast address to the next-hop agents that should become members of the group. LocalNetBytes is the length of the Local Net Multicast Address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode = 6 | PBytes | LocalNetBytes | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Local Net Multicast Address : Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 28. MulticastAddress CIP Working Group [Page 86]
RFC 1190 Internet Stream Protocol October 1990 IP Multicast Address is described in [6]. This field is zero (0) if no IP multicast address is known or is applicable. The block of addresses 224.1.0.0 - 224.1.255.255 has been allocated for use by ST. Local Net Multicast Address is the multicast address to be used on the local network. It corresponds to the IP Multicast Address when the latter is non-zero. 4.2.2.8. Name & RName Each stream is uniquely (i.e., globally) identified by a Name. A Name is created by the origin host ST agent and is composed of 1) a 16-bit number chosen to make the Name unique within the agent, 2) the IP address of the origin ST agent, and 3) a 32-bit timestamp. If the origin has multiple IP addresses, then any that can be used to reach target may be used in the Name. The intent is that the <Unique ID, IP Address> tuple be unique for the lifetime of the stream. It is suggested that to increase robustness a Unique ID value not be reused for a period of time on the order of 5 minutes. The Timestamp is included both to make the Name unique over long intervals (e.g., forever) for purposes of network management and accounting/billing, and to protect against failure of an ST agent that causes knowledge of active Unique IDs to be lost. The assumption is that all ST agents have access to some "clock". If this is not the case, the agent should have access to some form of non-volatile memory in which it can store some number that at least gets incremented per restart. The Name parameter (PCode = 7) is used in most control messages to identify a stream. The RName parameter (PCode = 15) is used in conjunction with the FDx option to convey the Name of the reverse stream in an ACCEPT message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode | 12 | Unique ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29. Name & RName CIP Working Group [Page 87]
RFC 1190 Internet Stream Protocol October 1990
RFC 1190 Internet Stream Protocol October 1990 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 3 |G| 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId | SVLId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Name Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 42. CHANGE Control Message 4.2.3.5. CONNECT CONNECT (OpCode = 5) requests the setup of a new stream or an addition to or recovery of an existing stream. Only the origin can issue the initial set of CONNECTs to setup a stream, and the first CONNECT to each next-hop is used to convey the initial suggestion for a HID. If the stream's data packets will be sent to some set of next-hop ST agents by multicast then the CONNECTs to that set must suggest the same HID. Otherwise, the HIDs in the various CONNECTs can be different. The CONNECT message must fit within the maximum allowable packet size (MTU) for the intervening network. If a CONNECT message is too large, it must be fragmented into multiple CONNECT messages by partitioning the TargetList; see Section 4.2 (page 77). Any UserData parameter will be replicated in each fragment for delivery to all targets. CIP Working Group [Page 105]
RFC 1190 Internet Stream Protocol October 1990 The next-hop can initially respond with any of the following five responses: 1 ERROR-IN-REQUEST, which implies that the CONNECT was not valid and has been ignored, 2 ACK, which implies that the CONNECT with the H bit not set was valid and is being processed, 3 HID-APPROVE, which implies that the CONNECT with the H bit set was valid, and the suggested HID can be used or was deferred, 4 HID-REJECT, which implies that the CONNECT with the H bit set was valid but the suggested HID cannot be used and another must be suggested in a subsequent HID-CHANGE message, or 5 REFUSE, which implies that the CONNECT was valid but the included list of targets in the REFUSE cannot be processed for the stated reason. The next-hop will later relay back either an ACCEPT or REFUSE from each target not already specified in the REFUSE of case 5 above (note multiple targets may be included in a single REFUSE message). An intermediate ST agent that receives a CONNECT selects the next-hop ST agents, partitions the TargetList accordingly, reserves network resources in the direction toward the next-hop, updating the FlowSpec accordingly (see Section 4.2.2.3 (page 81)), selects a proposed HID for each next- hop, and sends the resulting CONNECTs. If the intermediate ST agent that is processing a CONNECT fails to find a route to a target, then it responds with a REFUSE with the appropriate reason code. If the next-hop to a target is by way of the network from which it received the CONNECT, then it sends a NOTIFY with the appropriate reason code (RouteBack). In either case, the TargetList specifies the affected targets. The intermediate ST agent will only route to and propagate a CONNECT to the targets for which it does not issue either an ERROR-IN-REQUEST or a REFUSE. CIP Working Group [Page 106]
RFC 1190 Internet Stream Protocol October 1990 The processing of a received CONNECT message requires care to avoid routing loops that could result from delays in propagating routing information among ST agents. If a received CONNECT contains a new Name, a new stream should be created (unless the Virtual Link Identifier matches a known link in which case an ERROR-IN-REQUEST should be sent). If the Name is known, there are four cases: 1 the Virtual Link Identifier matches and the Target matches a current Target -- the duplicate target should be ignored. 2 the Virtual Link Identifier matches but the Target is new -- the stream should be expanded to include the new target. 3 the Virtual Link Identifier differs and the Target matches a current Target -- an ERROR-IN-REQUEST message should be sent specifying that the target is involved in a routing loop. If a reroute, the old path will eventually timeout and send a DISCONNECT; a subsequent retransmission of the rerouted CONNECT will then be processed under case 2 above. 4 the Virtual Link Identifier differs but the Target is new -- a new (instance of the) stream should be created for the target that is deliberately part of a loop using a SrcRoute parameter. Note that the test for a known or matching Target includes comparing any SrcRoute parameter that might be present. Option bits are specified by either the origin's service user or by an intermediate agent, depending on the specific option. Bits not specified below are currently unspecified, and should be set to zero (0) by the origin agent and not changed by other agents unless those agents know their meaning. H (bit 8) is used for the HID Field option; see Section 3.6.1 (page 44). It is set to one (1) only if the HID field contains either zero (when the HID selection is being deferred), or the proposed HID. This bit is zero (0) if the HID field does not contain valid data and should be ignored. P (bit 9) is used for the PTP option; see Section 3.6.2 (page 44). S (bit 10) is used for the NoRecovery option; see Section 3.6.4 (page 46). CIP Working Group [Page 107]
RFC 1190 Internet Stream Protocol October 1990 TSP (bits 14 and 15) specifies the origin's proposal for the use of data packet timestamps; see Section 4 (page 76). Its values and semantics are: 00 No proposal. 01 Cannot insert timestamps. 10 Must always insert timestamps. 11 Can insert timestamps if requested. RVLId, the receiver's Virtual Link Identifier, is set to zero in all CONNECT messages until its value arrives in the SVLId field of an acknowledgment to the CONNECT. SVLId, the sender's Virtual Link Identifier, is set to a value chosen by each hop to facilitate efficient dispatching of subsequent control messages. HID is the identifier that will be used with data packets moving through the stream in the direction from the origin to the targets. It is a hop-by-hop shorthand identifier for the stream's Name, and is chosen by each agent for the branch to the next-hop agents. The contents of the HID field are only valid, and a HID- REJECT or HID-APPROVE reply may only be sent, when the HID Field option (H bit) is set (1). If the HID Field option is specified and the proposed HID is zero, the selection of the HID is deferred to the receiving next- hop agent. If the HID Field option is not set (H bit is 0), then the HID field does not contain valid data and should be ignored; see Section 3.6.1 (page 44). TargetList is the list of IP addresses of the target processes. It is of arbitrary size up to the maximum allowed for packets traveling across the specific network. CIP Working Group [Page 108]
RFC 1190 Internet Stream Protocol October 1990 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 5 |H|P|S| 0 |TSP| TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId/0 | SVLId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | HID/0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Name Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Origin Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList Parameter(s) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Group Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : MulticastAddress Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RFlowSpec Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RGroup Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! RHID Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 43. CONNECT Control Message CIP Working Group [Page 109]
RFC 1190 Internet Stream Protocol October 1990 4.2.3.6. DISCONNECT DISCONNECT (OpCode = 6) is used by an origin to tear down an established stream or part of a stream, or by an intermediate agent that detects a failure between itself and its previous-hop, as distinguished by the ReasonCode. The DISCONNECT message specifies the list of targets that are to be disconnected. An ACK is required in response to a DISCONNECT message. The DISCONNECT message is propagated all the way to the specified targets. The targets are expected to terminate their participation in the stream. Note that in the case of a failure it may be advantageous to retain state information as the stream should be repaired shortly; see Section 3.7.2 (page 52). G (bit 8) is used to request a DISCONNECT of all the stream's targets; the TargetList parameter may be omitted when the G bit is set (1). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 6 |G| 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId | SVLId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference | LnkReference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | ReasonCode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Name Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 44. DISCONNECT Control Message CIP Working Group [Page 110]
RFC 1190 Internet Stream Protocol October 1990
RFC 1190 Internet Stream Protocol October 1990 [This page intentionally left blank.] CIP Working Group [Page 134]
RFC 1190 Internet Stream Protocol October 1990 6. Glossary appropriate reason code This phrase refers to one or perhaps a set of reason codes that indicate why a particular action is being taken. Typically, these result from detection of errors or anomalous conditions. It can also indicate that an application component or agent has presented invalid parameters. DefaultRecoveryTimeout The DefaultRecoveryTimeout is maintained by each ST agent. It indicates the default time interval to use for sending HELLO messages. downstream The direction in a stream from an origin toward its targets. element The fields and parameters of the ST control messages are collectively called elements. FlowSpec The Flow Specification, abbreviated "FlowSpec" is used by an application to specify required and desired characteristics of the stream. The FlowSpec specifies bandwidth, delay, and reliability parameters. Both minimal requirements and desired characteristics are included. This information is then used to guide route selection and resource allocation decisions. The desired vs. required characteristics are used to guide tradeoff decisions among competing stream requests. group A set of related streams can be associated as a group. This is done by generating a Group Name and assigning it to each of the related streams. The grouping information can then be used by the ST agents in making resource management and other control decisions. For example, when preemption is necessary to establish a high precedence stream, we can exploit the group information to minimize the number of stream groups that are preempted. Group Name The Group Name is used to indicate that a collection of streams are related. A Group Name is structured to ensure that it is unique across all hosts: it includes the address of the host where it was generated combined with a unique number generated by that host. A timestamp is added to ensure that the overall name is unique over all time. (A Group Name has the same format as a stream Name.) CIP Working Group [Page 135]
RFC 1190 Internet Stream Protocol October 1990
RFC 1190 Internet Stream Protocol October 1990 ST agent An ST agent is an entity that implements the ST Protocol. ST Control Message Protocol The ST Control Message Protocol is the subset of the overall ST Protocol responsible for creation, modification, maintenance, and tear down of a stream. It also includes support for event notification and status monitoring. stream A stream is the basic object managed by the ST Protocol for transmission of data. A stream has one origin where data are generated and one or more targets where the data are received for processing. A flow specification, provided by the origin and negotiated among the origin, intermediate, and target ST agents, identifies the requirements of the application and the guarantees that can be assured by the ST agents. subsets Subsets of the ST Protocol are permitted, as defined in various sections of this specification. Subsets are defined to allow simplified implementations that can still effectively interoperate with more complete implementations without causing disruption. SVLId Abbreviation for Sender's Virtual Link Identifier. It uniquely identifies to the receiver the virtual link identifier that should be placed into the RVLId field of all replies sent over the virtual link for a given stream. See definition for Virtual Link Identifier below. target An ST target is the destination where data supplied by the origin will be delivered for higher layer protocol or application processing. tear down The tear down phase of a stream begins when the origin indicates that it has no further data to send and the ST agents through which the stream passes should dismantle the stream and release its resources. ToAccept ToAccept is a timeout in seconds maintained by each ST agent. It sets the retransmission interval for ACCEPT messages. ToConnect ToConnect is a timeout in seconds maintained by each ST agent. It sets the retransmission interval a CONNECT messages. CIP Working Group [Page 141]
RFC 1190 Internet Stream Protocol October 1990 ToDisconnect ToDisconnect is a timeout in seconds maintained by each ST agent. It sets the retransmission interval for DISCONNECT messages. ToHIDAck ToHIDAck is a timeout in seconds maintained by each ST agent. It sets the retransmission interval for HID-CHANGE-REQUEST messages. ToHIDChange ToHIDChange is a timeout in seconds maintained by each ST agent. It sets the retransmission interval for HID-CHANGE messages. ToRefuse ToRefuse is a timeout in seconds maintained by each ST agent. It sets the retransmission interval for REFUSE messages. upstream The direction in a stream from a target toward the origin. Virtual Link A virtual link is one edge of the tree describing the path of data flow through a stream. A separate virtual link is assigned to each pair of neighbor ST agents, even when multiple next-hops are be reached through a single network level multicast group. The virtual link allows efficient demultiplexing of ST Control Message PDUs received from a single physical link or network. Virtual Link Identifier For each ST Control Message sent, the sender provides its own virtual link identifier and that of the receiver (if known). Either of these identifiers, combined with the address of the corresponding host, can be used to identify uniquely the virtual control link to the agent. However, virtual link identifiers are chosen by the associated agent so that the agent may precisely identify the stream, state machine, and other protocol processing data elements managed by that agent, without regard to the source of the control message. Virtual link identifiers are not negotiated, and do not change during the lifetime of a stream. They are discarded when the stream is torn down. CIP Working Group [Page 142]
RFC 1190 Internet Stream Protocol October 1990 7. References [1] Braden, B., Borman, D., and C. Partridge, "Computing the Internet Checksum", RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Laboratories, September 1988 [2] Braden, R. (ed.), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989. [3] Cheriton, D., "VMTP: Versatile Message Transaction Protocol Specification", RFC 1045, Stanford University, February 1988. [4] Cohen, D., "A Network Voice Protocol NVP-II", USC/Information Sciences Institute, April 1981. [5] Cole, E., "PVP - A Packet Video Protocol", W-Note 28, USC/Information Sciences Institute, August 1981. [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989. [7] Edmond W., Seo K., Leib M., and C. Topolcic, "The DARPA Wideband Network Dual Bus Protocol", accepted for presentation at ACM SIGCOMM '90, September 24-27, 1990. [8] Forgie, J., "ST - A Proposed Internet Stream Protocol", IEN 119, M. I. T. Lincoln Laboratory, 7 September 1979. [9] Jacobs I., Binder R., and E. Hoversten E., "General Purpose Packet Satellite Network", Proc. IEEE, vol 66, pp 1448-1467, November 1978. [10] Jacobson, V., "Congestion Avoidance and Control", ACM SIGCOMM-88, August 1988. [11] Karn, P. and C. Partridge, "Round Trip Time Estimation", ACM SIGCOMM-87, August 1987. CIP Working Group [Page 143]
RFC 1190 Internet Stream Protocol October 1990 [12] Mallory, T., and A. Kullberg, "Incremental Updating of the Internet Checksum", RFC 1141, BBN Communications Corporation, January 1990. [13] Mills, D., "Network Time Protocol (Version 2) Specification and Implementation", RFC 1119, University of Delaware, September 1989 (Revised February 1990). [14] Pope, A., "The SIMNET Network and Protocols", BBN Report No. 7102, BBN Systems and Technologies, July 1989. [15] Postel, J., ed., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981. [16] Postel, J., ed., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981. [17] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [18] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. [19] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5, 1989-05-15. [20] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating Families, SDN.301.1, Rev. 1.2, 1988-07-12. 8. Security Considerations See section 3.7.8. CIP Working Group [Page 144]
RFC 1190 Internet Stream Protocol October 1990 9. Authors' Addresses Stephen Casner USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: (213) 822-1511 x153 EMail: Casner@ISI.Edu Charles Lynn, Jr. BBN Systems and Technologies, a division of Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02138 Phone: (617) 873-3367 EMail: CLynn@BBN.Com Philippe Park BBN Systems and Technologies, a division of Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02138 Phone: (617) 873-2892 EMail: ppark@BBN.COM Kenneth Schroder BBN Systems and Technologies, a division of Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02138 Phone: (617) 873-3167 EMail: Schroder@BBN.Com Claudio Topolcic BBN Systems and Technologies, a division of Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02138 Phone: (617) 873-3874 EMail: Topolcic@BBN.Com CIP Working Group [Page 145]
RFC 1190 Internet Stream Protocol October 1990 [This page intentionally left blank.] CIP Working Group [Page 146]
RFC 1190 Internet Stream Protocol October 1990 Appendix 1. Data Notations The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data with the most significant octet on the left and the least significant octet on the right. The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | 7 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 10 | 11 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 56. Transmission Order of Bytes Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal). 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+ Figure 57. Significance of Bits Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first. Fields whose length is fixed and fully illustrated are shown with a vertical bar (|) at the end; fixed fields whose contents are abbreviated are shown with an exclamation point (!); variable fields are shown with colons (:). CIP Working Group [Page 147]
RFC 1190 Internet Stream Protocol October 1990 Optional parameters are separated from control messages with a blank line. The order of any optional parameters is not meaningful.



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""