idnits 2.17.1 draft-ietf-rmt-pi-norm-revised-06.txt: -(120): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(408): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(441): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(741): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(939): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(942): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1661): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1676): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1772): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1864): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1879): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1972): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2128): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2164): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2886): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2940): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2967): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3347): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3930): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4164. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 95 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The NORM_CMD(SQUELCH) command is transmitted in response to outdated or invalid NORM_NACK content received by the sender. Invalid NORM_NACK content consists of repair requests for NormObjects for which the sender is unable or unwilling to provide repair. This includes repair requests for outdated objects, aborted objects, or those objects which the sender previously transmitted marked with the NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what content is available for repair, thus serving as a description of the sender’s current "repair window". Receivers SHALL not generate repair requests for content identified as invalid by a NORM_CMD(SQUELCH). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jan 2008) is 5938 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-rmt-bb-norm-revised-04 ** Downref: Normative reference to an Experimental RFC: RFC 4654 (ref. '5') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3940 (ref. '10') (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4566 (ref. '11') (Obsoleted by RFC 8866) == Outdated reference: A later version (-06) exists of draft-ietf-rmt-bb-fec-basic-schemes-revised-04 -- Obsolete informational reference (is this intentional?): RFC 3547 (ref. '28') (Obsoleted by RFC 6407) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Reliable Multicast Transport (RMT) B. Adamson 3 Working Group NRL 4 Internet-Draft C. Bormann 5 Expires: 31 July 2008 Universitaet Bremen TZI 6 M. Handley 7 UCL 8 J. Macker 9 NRL 10 Jan 2008 12 NACK-Oriented Reliable Multicast (NORM) Protocol 13 draft-ietf-rmt-pi-norm-revised-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 31, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes the messages and procedures of the Negative- 47 acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol. 48 This protocol is designed to provide end-to-end reliable transport of 49 bulk data objects or streams over generic IP multicast routing and 50 forwarding services. NORM uses a selective, negative acknowledgment 51 mechanism for transport reliability and offers additional protocol 52 mechanisms to allow for operation with minimal "a priori" 53 coordination among senders and receivers. A congestion control 54 scheme is specified to allow the NORM protocol to fairly share 55 available network bandwidth with other transport protocols such as 56 Transmission Control Protocol (TCP). It is capable of operating with 57 both reciprocal multicast routing among senders and receivers and 58 with asymmetric connectivity (possibly a unicast return path) between 59 the senders and receivers. The protocol offers a number of features 60 to allow different types of applications or possibly other higher 61 level transport protocols to utilize its service in different ways. 62 The protocol leverages the use of FEC-based repair and other IETF 63 reliable multicast transport (RMT) building blocks in its design. 65 Table of Contents 67 1. Introduction and Applicability. . . . . . . . . . . . . . . . . . 5 68 1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . . . . 6 69 1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 70 1.3. Environmental Requirements and Considerations. . . . . . . . . 9 71 2. Architecture Definition . . . . . . . . . . . . . . . . . . . . . 9 72 2.1. Protocol Operation Overview. . . . . . . . . . . . . . . . . . 11 73 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . . . 13 74 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 13 75 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . . . 14 76 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1. NORM Common Message Header and Extensions. . . . . . . . . . . 17 78 4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . . . . 19 79 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . . . . 20 80 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . . . . 30 81 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . . . . 32 82 4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . . . . 50 83 4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . . . . 50 84 4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . . . . . . 57 85 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . . . 59 86 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . . . . 59 87 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . . . 59 88 5.1. Sender Initialization and Transmission . . . . . . . . . . . . 61 89 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . . . . 62 90 5.2. Receiver Initialization and Reception. . . . . . . . . . . . . 63 91 5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . . . . 63 92 5.4. Sender NACK Processing and Response. . . . . . . . . . . . . . 66 93 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . . . . 66 94 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . . . . 67 95 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . . . . 68 96 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . . . . . . 69 97 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . . . 69 98 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . . . . 70 99 5.5.2. NORM Congestion Control Operation . . . . . . . . . . . . . 71 100 5.5.3. NORM Positive Acknowledgment Procedure. . . . . . . . . . . 80 101 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . . . . 82 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 82 103 6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . . . 83 104 6.1.1. IPSec Approach. . . . . . . . . . . . . . . . . . . . . . . 84 105 6.1.2. IPSec Requirements. . . . . . . . . . . . . . . . . . . . . 86 106 6.1.2.1. Selectors. . . . . . . . . . . . . . . . . . . . . . . . 86 107 6.1.2.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 87 108 6.1.2.3. Key Management . . . . . . . . . . . . . . . . . . . . . 87 109 6.1.2.4. Security Policy. . . . . . . . . . . . . . . . . . . . . 87 110 6.1.2.5. Authentication and Encryption. . . . . . . . . . . . . . 87 111 6.1.2.6. Availability . . . . . . . . . . . . . . . . . . . . . . 87 113 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 88 114 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 89 115 9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 89 116 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 90 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 118 11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 90 119 11.2. Informative References. . . . . . . . . . . . . . . . . . . . 91 120 12. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 93 121 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 94 122 1. Introduction and Applicability 124 The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) 125 protocol is designed to provide reliable transport of data from one 126 or more sender(s) to a group of receivers over an IP multicast 127 network. The primary design goals of NORM are to provide efficient, 128 scalable, and robust bulk data (e.g., computer files, transmission of 129 persistent data) transfer across possibly heterogeneous IP networks 130 and topologies. The NORM protocol design provides support for 131 distributed multicast session participation with minimal coordination 132 among senders and receivers. NORM allows senders and receivers to 133 dynamically join and leave multicast sessions at will with minimal 134 overhead for control information and timing synchronization among 135 participants. To accommodate this capability, NORM protocol message 136 headers contain some common information allowing receivers to easily 137 synchronize to senders throughout the lifetime of a reliable 138 multicast session. NORM is designed to be self-adapting to a wide 139 range of dynamic network conditions with little or no pre- 140 configuration. The protocol is purposely designed to be tolerant of 141 inaccurate timing estimations or lossy conditions that may occur in 142 many networks including mobile and wireless. The protocol is also 143 designed to exhibit convergence and efficient operation even in 144 situations of heavy packet loss and large queuing or transmission 145 delays. 147 This document is a product of the IETF RMT WG and follows the 148 guidelines provided in RFC 3269 [9]. The key words "MUST", "MUST 149 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 150 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 151 interpreted as described in BCP 14, RFC 2119 [1]. 153 Statement of Intent 155 This memo contains the definitions necessary to fully specify a 156 Reliable Multicast Transport protocol in accordance with RFC 2357. 157 RFC3940 [10] contained a previous description of the NORM Protocol 158 specification described in this document. RF3940 was published in 159 the "Experimental" category. It was the stated intent of the RMT 160 working group to re-submit this specifications as an IETF Proposed 161 Standard in due course. 163 This Proposed Standard specification is thus based on RFC3940 [10] 164 and has been updated according to accumulated experience and growing 165 protocol maturity since the publication of RFC3940. Said experience 166 applies both to this specification itself and to congestion control 167 strategies related to the use of this specification. 169 The differences between RFC3940 [10] and this document are listed in 170 Section 9. 172 1.1. NORM Delivery Service Model 174 A NORM protocol instance (NormSession) is defined within the context 175 of participants communicating connectionless (e.g., Internet Protocol 176 (IP) or User Datagram Protocol (UDP)) packets over a network using 177 pre-determined addresses and host port numbers. Generally, the 178 participants exchange packets using an IP multicast group address, 179 but unicast transport may also be established or applied as an 180 adjunct to multicast delivery. In the case of multicast, the 181 participating NormNodes will communicate using a common IP multicast 182 group address and port number that has been chosen via means outside 183 the context of the given NormSession. Other IETF data format and 184 protocol standards exist that may be applied to describe and convey 185 the required "a priori" information for a specific NormSession (e.g., 186 Session Description Protocol (SDP) [11], Session Announcement 187 Protocol (SAP) [12], etc.). 189 The NORM protocol design is principally driven by the assumption of a 190 single sender transmitting bulk data content to a group of receivers. 191 However, the protocol MAY operate with multiple senders within the 192 context of a single NormSession. In initial implementations of this 193 protocol, it is anticipated that multiple senders will transmit 194 independent of one another and receivers will maintain state as 195 necessary for each sender. However, in future versions of NORM, it 196 is possible that some aspects of protocol operation (e.g., round-trip 197 time collection) may provide for alternate modes allowing more 198 efficient performance for applications requiring multiple senders. 200 NORM provides for three types of bulk data content objects 201 (NormObjects) to be reliably transported. These types include: 203 1) static computer memory data content (NORM_OBJECT_DATA type), 205 2) computer storage files (NORM_OBJECT_FILE type), and 207 3) non-finite streams of continuous data content 208 (NORM_OBJECT_STREAM type). 210 The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is 211 simply to provide a "hint" to receivers in NormSessions serving 212 multiple types of content as to what type of storage should be 213 allocated for received content (i.e., memory or file storage). Other 214 than that distinction, the two are identical, providing for reliable 215 transport of finite (but potentially very large) units of content. 216 These static data and file services are anticipated to be useful for 217 multicast-based cache applications with the ability to reliably 218 provide transmission of large quantities of static data. Other types 219 of static data/file delivery services might make use of these 220 transport object types, too. The use of the NORM_OBJECT_STREAM type 221 is at the application’s discretion and could be used to carry static 222 data or file content also. The NORM reliable stream service opens up 223 additional possibilities such as serialized reliable messaging or 224 other unbounded, perhaps dynamically produced content. The 225 NORM_OBJECT_STREAM provides for reliable transport analogous to that 226 of the Transmission Control Protocol (TCP), although NORM receivers 227 will be able to begin receiving stream content at any point in time. 228 The applicability of this feature will depend upon the application. 230 The NORM protocol also allows for a small amount of "out-of-band" 231 data (sent as NORM_INFO messages) to be attached to the data content 232 objects transmitted by the sender. This readily-available "out-of- 233 band" data allows multicast receivers to quickly and efficiently 234 determine the nature of the corresponding data, file, or stream bulk 235 content being transmitted. This allows application-level control of 236 the receiver node’s participation in the current transport activity. 237 This also allows the protocol to be flexible with minimal pre- 238 coordination among senders and receivers. The NORM_INFO content is 239 designed to be atomic in that its size MUST fit into the payload 240 portion of a single NORM message. 242 NORM does _not_ provide for global or application-level 243 identification of data content within in its message headers. Note 244 the NORM_INFO out-of-band data mechanism could be leveraged by the 245 application for this purpose if desired, or identification could 246 alternatively be embedded within the data content. NORM does 247 identify transmitted content (NormObjects) with transport identifiers 248 that are applicable only while the sender is transmitting and/or 249 repairing the given object. These transport data content identifiers 250 (NormTransportIds) are assigned in a monotonically increasing fashion 251 by each NORM sender during the course of a NormSession. Each sender 252 maintains its NormTransportId assignments independently so that 253 individual NormObjects may be uniquely identified during transport 254 with the concatenation of the sender session-unique identifier 255 (NormNodeId) and the assigned NormTransportId. The NormTransportIds 256 are assigned from a large, but fixed, numeric space in increasing 257 order and may be reassigned during long-lived sessions. The NORM 258 protocol provides mechanisms so that the sender application may 259 terminate transmission of data content and inform the group of this 260 in an efficient manner. Other similar protocol control mechanisms 261 (e.g., session termination, receiver synchronization, etc.) are 262 specified so that reliable multicast application variants may 263 construct different, complete bulk transfer communication models to 264 meet their goals. 266 To summarize, the NORM protocol provides reliable transport of 267 different types of data content (including potentially mixed types). 268 The senders enqueue and transmit bulk content in the form of static 269 data or files and/or non-finite, ongoing stream types. NORM senders 270 provide for repair transmission of data and/or FEC content in 271 response to NACK messages received from the receiver group. 272 Mechanisms for "out-of-band" information and other transport control 273 mechanisms are specified for use by applications to form complete 274 reliable multicast solutions for different purposes. 276 1.2. NORM Scalability 278 Group communication scalability requirements lead to adaptation of 279 negative acknowledgment (NACK) based protocol schemes when feedback 280 for reliability is required [13]. NORM is a protocol centered around 281 the use of selective NACKs to request repairs of missing data. NORM 282 provides for the use of packet-level forward error correction (FEC) 283 techniques for efficient multicast repair and optional proactive 284 transmission robustness [14]. FEC-based repair can be used to 285 greatly reduce the quantity of reliable multicast repair requests and 286 repair transmissions [15] in a NACK-oriented protocol. The principal 287 factor in NORM scalability is the volume of feedback traffic 288 generated by the receiver set to facilitate reliability and 289 congestion control. NORM uses probabilistic suppression of redundant 290 feedback based on exponentially distributed random backoff timers. 291 The performance of this type of suppression relative to other 292 techniques is described in [16]. NORM dynamically measures the 293 group’s roundtrip timing status to set its suppression and other 294 protocol timers. This allows NORM to scale well while maintaining 295 reliable data delivery transport with low latency relative to the 296 network topology over which it is operating. 298 Feedback messages can be either multicast to the group at large or 299 sent via unicast routing to the sender. In the case of unicast 300 feedback, the sender "advertises" the feedback state to the group to 301 facilitate feedback suppression. In typical Internet environments, 302 it is expected that the NORM protocol will readily scale to group 303 sizes on the order of tens of thousands of receivers. A study of the 304 quantity of feedback for this type of protocol is described in [17]. 305 NORM is able to operate with a smaller amount of feedback than a 306 single TCP connection, even with relatively large numbers of 307 receivers. Thus, depending upon the network topology, it is possible 308 that NORM may scale to larger group sizes. With respect to computer 309 resource usage, the NORM protocol does _not_ require that state be 310 kept on all receivers in the group. NORM senders maintain state only 311 for receivers providing explicit congestion control feedback. NORM 312 receivers must maintain state for each active sender. This may 313 constrain the number of simultaneous senders in some uses of NORM. 315 1.3. Environmental Requirements and Considerations 317 All of the environmental requirements and considerations that apply 318 to the RMT NORM Building Block [3], the RMT FEC Building Block [4], 319 and the RMT TCP-Friendly Multicast Congestion Control (TFMCC) 320 Building Block [5], also apply to the NORM protocol. 322 The NORM protocol SHALL be capable of operating in an end-to-end 323 fashion with no assistance from intermediate systems beyond basic IP 324 multicast group management, routing, and forwarding services. While 325 the techniques utilized in NORM are principally applicable to "flat" 326 end-to-end IP multicast topologies, they could also be applied in the 327 sub-levels of hierarchical (e.g., tree-based) multicast distribution 328 if so desired. NORM can make use of reciprocal (among senders and 329 receivers) multicast communication under the Any-Source Multicast 330 (ASM) model defined in RFC 1112 [2], but SHALL also be capable of 331 scalable operation in asymmetric topologies such as Source Specific 332 Multicast (SSM) [18] where there may only be unicast routing service 333 from the receivers to the sender(s). 335 NORM is compatible with IPv4 and IPv6. Additionally, NORM may be 336 used with networks employing Network Address Translation (NAT) 337 providing the NAT device supports IP multicast and/or can cache UDP 338 traffic source port numbers for remapping feedback traffic from 339 receivers to the sender(s). 341 2. Architecture Definition 343 A NormSession is comprised of participants (NormNodes) acting as 344 senders and/or receivers. NORM senders transmit data content in the 345 form of NormObjects to the session destination address and the NORM 346 receivers attempt to reliably receive the transmitted content using 347 negative acknowledgments to request repair. Each NormNode within a 348 NormSession is assumed to have a preselected unique 32-bit identifier 349 (NormNodeId). NormNodes MUST have uniquely assigned identifiers 350 within a single NormSession to distinguish between possible multiple 351 senders and to distinguish feedback information from different 352 receivers. There are two reserved NormNodeId values. A value of 353 0x00000000 is considered an invalid NormNodeId value and a value of 354 0xffffffff is a "wildcard" NormNodeId. While the protocol does not 355 preclude multiple sender nodes concurrently transmitting within the 356 context of a single NORM session (i.e., many- to-many operation), any 357 type of interactive coordination among NORM senders is assumed to be 358 controlled by the application or higher protocol layer. There are 359 some optional mechanisms specified in this document that can be 360 leveraged for such application layer coordination. 362 As previously noted, NORM allows for reliable transmission of three 363 different basic types of data content. The first type is 364 NORM_OBJECT_DATA, which is used for static, persistent blocks of data 365 content maintained in the sender’s application memory storage. The 366 second type is NORM_OBJECT_FILE, which corresponds to data stored in 367 the sender’s non-volatile file system. The NORM_OBJECT_DATA and 368 NORM_OBJECT_FILE types both represent "NormObjects" of finite but 369 potentially very large size. The third type of data content is 370 NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of 371 undefined length. This is analogous to the reliable stream service 372 provide by TCP for unicast data transport. The format of the stream 373 content is application-defined and may be byte or message oriented. 374 The NORM protocol provides for "flushing" of the stream to expedite 375 delivery or possibly enforce application message boundaries. NORM 376 protocol implementations may offer either (or both) in-order delivery 377 of the stream data to the receive application or out-of-order (more 378 immediate) delivery of received segments of the stream to the 379 receiver application. In either case, NORM sender and receiver 380 implementations provide buffering to facilitate repair of the stream 381 as it is transported. 383 All NormObjects are logically segmented into FEC coding blocks and 384 symbols for transmission by the sender. In NORM, an FEC encoding 385 symbol directly corresponds to the payload of NORM_DATA messages or 386 "segment". Note that when systematic FEC codes are used, the payload 387 of NORM_DATA messages sent for the first portion of a FEC encoding 388 block are source symbols (actual segments of original user data), 389 while the remaining symbols for the block consist of parity symbols 390 generated by FEC encoding. These parity symbols are generally sent 391 in response to repair requests, but some number may be sent 392 proactively at the end each encoding block to increase the robustness 393 of transmission. When non-systematic FEC codes are used, all symbols 394 sent consist of FEC encoding parity content. In this case, the 395 receiver must receive a sufficient number of symbols to reconstruct 396 (via FEC decoding) the original user data for the given block. In 397 this document, the terms "symbol" and "segment" are used 398 interchangeably. 400 Transmitted NormObjects are temporarily yet uniquely identified 401 within the NormSession context using the given sender’s NormNodeId, 402 NormInstanceId, and a temporary NormObjectTransportId. Depending 403 upon the implementation, individual NORM senders may manage their 404 NormInstanceIds independently, or a common NormInstanceId may be 405 agreed upon for all participating nodes within a session if needed as 406 a session identifier. NORM NormObjectTransportId data content 407 identifiers are sender-assigned and applicable and valid only during 408 a NormObject’s actual _transport_ (i.e., for as long as the sender is 409 transmitting and providing repair of the indicated NormObject). For 410 a long-lived session, the NormObjectTransportId field can wrap and 411 previously-used identifiers may be re-used. Note that globally 412 unique identification of transported data content is not provided by 413 NORM and, if required, must be managed by the NORM application. The 414 individual segments or symbols of the NormObject are further 415 identified with FEC payload identifiers which include coding block 416 and symbol identifiers. These are discussed in detail later in this 417 document. 419 2.1. Protocol Operation Overview 421 A NORM sender primarily generates messages of type NORM_DATA. These 422 messages carry original data segments or FEC symbols and repair 423 segments/symbols for the bulk data/file or stream NormObjects being 424 transferred. By default, redundant FEC symbols are sent only in 425 response to receiver repair requests (NACKs) and thus normally little 426 or no additional transmission overhead is imposed due to FEC 427 encoding. However, the NORM implementation MAY be optionally 428 configured to proactively transmit some amount of redundant FEC 429 symbols along with the original content to potentially enhance 430 performance (e.g., improved delay) at the cost of additional 431 transmission overhead. This option may be sensible for certain 432 network conditions and can allow for robust, asymmetric multicast 433 (e.g., unidirectional routing, satellite, cable) [19] with reduced 434 receiver feedback, or, in some cases, no feedback. 436 A sender message of type NORM_INFO is also defined and is used to 437 carry OPTIONAL "out-of-band" context information for a given 438 transport object. A single NORM_INFO message can be associated with 439 a NormObject. Because of its atomic nature, missing NORM_INFO 440 messages can be NACKed and repaired with a slightly lower delay 441 process than NORM’s general FEC-encoded data content. NORM_INFO may 442 serve special purposes for some bulk transfer, reliable multicast 443 applications where receivers join the group mid-stream and need to 444 ascertain contextual information on the current content being 445 transmitted. The NACK process for NORM_INFO will be described later. 446 When the NORM_INFO message type is used, its transmission should 447 precede transmission of any NORM_DATA message for the associated 448 NormObject. 450 The sender also generates messages of type NORM_CMD to assist in 451 certain protocol operations such as congestion control, end-of- 452 transmission flushing, round trip time estimation, receiver 453 synchronization, and optional positive acknowledgment requests or 454 application defined commands. The transmission of NORM_CMD messages 455 from the sender is accomplished by one of three different procedures. 456 These procedures are: single, best effort unreliable transmission of 457 the command; repeated redundant transmissions of the command; and 458 positively-acknowledged commands. The transmission technique used 459 for a given command depends upon the function of the command. 460 Several core commands are defined for basic protocol operation. 461 Additionally, implementations MAY wish to consider providing the 462 OPTIONAL application-defined commands that can take advantage of the 463 transmission methodologies available for commands. This allows for 464 application-level session management mechanisms that can make use of 465 information available to the underlying NORM protocol engine (e.g., 466 round-trip timing, transmission rate, etc.). A notable distinction 467 between NORM_DATA message and some NORM_CMD message transmissions is 468 that typically a receiver will need to allocate resources to manage 469 reliable reception when NORM_DATA messages are received. However 470 some NORM_CMD messages may be completely atomic and no specific state 471 may need to be kept. Thus, for session management or other purposes 472 it is possible that even participants acting principally as data 473 receivers MAY transmit NORM_CMD messages. However, it is RECOMMENDED 474 that this is not done within the context of the NORM multicast 475 session unless congestion control is addressed. For example, many 476 receiver nodes transmitting NORM_CMD messages simultaneously can 477 cause congestion for the destination(s). 479 All sender transmissions are subject to rate control governed by a 480 peak transmission rate set for each participant by the application. 481 This can be used to limit the quantity of multicast data transmitted 482 by the group. When NORM’s congestion control algorithm is enabled 483 the rate for senders is automatically adjusted. In some networks, it 484 may be desirable to establish minimum and maximum bounds for the rate 485 adjustment depending upon the application even when dynamic 486 congestion control is enabled. However, in the case of the general 487 Internet, congestion control policy SHALL be observed that is 488 compatible with coexistent TCP flows. 490 NORM receivers generate messages of type NORM_NACK or NORM_ACK in 491 response to transmissions of data and commands from a sender. The 492 NORM_NACK messages are generated to request repair of detected data 493 transmission losses. Receivers generally detect losses by tracking 494 the sequence of transmission from a sender. Sequencing information 495 is embedded in the transmitted data packets and end-of-transmission 496 commands from the sender. NORM_ACK messages are generated in 497 response to certain commands transmitted by the sender. In the 498 general (and most scalable) protocol mode, NORM_ACK messages are sent 499 only in response to congestion control commands from the sender. The 500 feedback volume of these congestion control NORM_ACK messages is 501 controlled using the same timer-based probabilistic suppression 502 techniques as for NORM_NACK messages to avoid feedback implosion. In 503 order to meet potential application requirements for positive 504 acknowledgment from receivers, other NORM_ACK messages are defined 505 and available for use. 507 2.2. Protocol Building Blocks 509 The operation of the NORM protocol is based primarily upon the 510 concepts presented in the Nack-Oriented Reliable Multicast (NORM) 511 Building Block document [3]. This includes the basic NORM 512 architecture and the data transmission, repair, and feedback 513 strategies discussed in that document. Additional reliable multicast 514 building blocks are applied in creating the full NORM protocol 515 instantiation [20]. NORM also makes use of Forward Error Correction 516 encoding techniques for repair messaging and optional transmission 517 robustness as described in [14]. NORM uses the FEC Payload ID as 518 specified by the FEC Building Block Document [4]. Additionally, for 519 congestion control, this document includes a baseline congestion 520 control mechanism (NORM-CC) based on the TCP-Friendly Multicast 521 Congestion Control (TFMCC) scheme described in [24] and [5]. 523 2.3. Design Tradeoffs 525 While the various features of NORM are designed to provide some 526 measure of general purpose utility, it is important to emphasize the 527 understanding that "no one size fits all" in the reliable multicast 528 transport arena. There are numerous engineering tradeoffs involved 529 in reliable multicast transport design and this requires an increased 530 awareness of application and network architecture considerations. 531 Performance requirements affecting design can include: group size, 532 heterogeneity (e.g., capacity and/or delay), asymmetric delivery, 533 data ordering, delivery delay, group dynamics, mobility, congestion 534 control, and transport across low capacity connections. NORM 535 contains various parameters to accommodate many of these differing 536 requirements. The NORM protocol and its mechanisms MAY be applied in 537 multicast applications outside of bulk data transfer, but there is an 538 assumed model of bulk transfer transport service that drives the 539 trade-offs that determine the scalability and performance described 540 in this document. 542 The ability of NORM to provide reliable data delivery is also 543 governed by any buffer constraints of the sender and receiver 544 applications. NORM protocol implementations SHOULD be designed to 545 operate with the greatest efficiency and robustness possible within 546 application-defined buffer constraints. Buffer requirements for 547 reliability, as always, are a function of the delay-bandwidth product 548 of the network topology. NORM performs best when allowed more 549 buffering resources than typical point-to-point transport protocols. 550 This is because NORM feedback suppression is based upon randomly- 551 delayed transmissions from the receiver set, rather than immediately 552 transmitted feedback. There are definitive tradeoffs between buffer 553 utilization, group size scalability, and efficiency of performance. 554 Large buffer sizes allow the NORM protocol to perform most 555 efficiently in large delay-bandwidth topologies and allow for longer 556 feedback suppression backoff timeouts. This yields improved group 557 size scalability. NORM can operate with reduced buffering but at a 558 cost of decreased efficiency (lower relative goodput) and reduced 559 group size scalability. 561 3. Conformance Statement 563 This Protocol Instantiation document, in conjunction with the RMT 564 Building Block documents of [3] and [4], completely specifies a 565 working reliable multicast transport protocol that conforms to the 566 requirements described in RFC 2357 [21]. 568 This document specifies the following message types and mechanisms 569 which are REQUIRED in complying NORM protocol implementations: 571 +---------------------+----------------------------------------------+ 572 | Message Type | Purpose | 573 +---------------------+----------------------------------------------+ 574 |NORM_DATA | Sender message for application data | 575 | | transmission. Implementations must support | 576 | | at least one of the NORM_OBJECT_DATA, | 577 | | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM | 578 | | delivery services. The use of the NORM FEC | 579 | | Object Transmission Information header | 580 | | extension is OPTIONAL with NORM_DATA | 581 | | messages. | 582 +---------------------+----------------------------------------------+ 583 |NORM_CMD(FLUSH) | Sender command to excite receivers for | 584 | | repair requests in lieu of ongoing NORM_DATA | 585 | | transmissions. Note the use of the | 586 | | NORM_CMD(FLUSH) for positive acknowledgment | 587 | | of data receipt is OPTIONAL. | 588 +---------------------+----------------------------------------------+ 589 |NORM_CMD(SQUELCH) | Sender command to advertise its current | 590 | | valid repair window in response to invalid | 591 | | requests for repair. | 592 +---------------------+----------------------------------------------+ 593 |NORM_CMD(REPAIR_ADV) | Sender command to advertise current repair | 594 | | (and congestion control state) to group when | 595 | | unicast feedback messages are detected. | 596 | | Used to control/suppress excessive receiver | 597 | | feedback in asymmetric multicast topologies. | 598 +---------------------+----------------------------------------------+ 599 |NORM_CMD(CC) | Sender command used in collection of round | 600 | | trip timing and congestion control status | 601 | | from group (this may be OPTIONAL if | 602 | | alternative congestion control mechanism and | 603 | | round trip timing collection is used). | 604 +---------------------+----------------------------------------------+ 605 |NORM_NACK | Receiver message used to request repair of | 606 | | missing transmitted content. | 607 +---------------------+----------------------------------------------+ 608 |NORM_ACK | Receiver message used to proactively provide | 609 | | feedback for congestion control purposes. | 610 | | Also used with the OPTIONAL NORM Positive | 611 | | Acknowledgment Process. | 612 +---------------------+----------------------------------------------+ 613 This document also describes the following message types and 614 associated mechanisms which are OPTIONAL for complying NORM protocol 615 implementations: 617 +-----------------------+----------------------------------------------+ 618 | Message Type | Purpose | 619 +-----------------------+----------------------------------------------+ 620 |NORM_INFO | Sender message for providing ancillary | 621 | | context information associated with NORM | 622 | | transport objects. The use of the NORM FEC | 623 | | Object Transmission Information header | 624 | | extension is OPTIONAL with NORM_INFO | 625 | | messages. | 626 +-----------------------+----------------------------------------------+ 627 |NORM_CMD(EOT) | Sender command to indicate it has reached | 628 | | end-of-transmission and will no longer | 629 | | respond to repair requests. | 630 +-----------------------+----------------------------------------------+ 631 |NORM_CMD(ACK_REQ) | Sender command to support application- | 632 | | defined, positively acknowledged commands | 633 | | sent outside of the context of the bulk data | 634 | | content being transmitted. The NORM | 635 | | Positive Acknowledgment Procedure associated | 636 | | with this message type is OPTIONAL. | 637 +-----------------------+----------------------------------------------+ 638 |NORM_CMD(APPLICATION) | Sender command containing application- | 639 | | defined commands sent outside of the context | 640 | | of the bulk data content being transmitted. | 641 +-----------------------+----------------------------------------------+ 642 |NORM_REPORT | Optional message type reserved for | 643 | | experimental implementations of the NORM | 644 | | protocol. | 645 +-----------------------+----------------------------------------------+ 647 4. Message Formats 649 As mentioned in Section 2.1, there are two primary classes of NORM 650 messages: sender messages and receiver messages. NORM_CMD, 651 NORM_INFO, and NORM_DATA message types are generated by senders of 652 data content, and NORM_NACK and NORM_ACK messages generated by 653 receivers within a NormSession. Sender messages SHOULD be governed 654 by congestion control for Internet use. For session management or 655 other purposes, receivers may wish to employ NORM_CMD message 656 transmissions. The principal rationale for distiguishing sender and 657 receiver messages is that receivers will typically need to allocate 658 resources to support reliable reception from sender(s) and NORM 659 sender messages are subject to congestion control. NORM receivers 660 MAY employ the NORM_CMD message type for application-defined purposes 661 but it is RECOMMENDED that congestion control and feedback implosion 662 issues be addressed. Additionally, an auxiliary message type of 663 NORM_REPORT is also provided for experimental purposes. This section 664 describes the message formats used by the NORM protocol. These 665 messages and their fields are referenced in the detailed functional 666 description of the NORM protocol given in Section 5. Individual NORM 667 messages are designed to be compatible with the MTU limitations of 668 encapsulating Internet protocols including IPv4, IPv6, and UDP. The 669 current NORM protocol specification assumes UDP encapsulation and 670 leverages the transport features of UDP. The NORM messages are 671 independent of network addresses and can be used in IPv4 and IPv6 672 networks. 674 4.1. NORM Common Message Header and Extensions 676 There are some common message fields contained in all NORM message 677 types. Additionally, a header extension mechanism is defined to 678 expand the functionality of the NORM protocol without revision to 679 this document. All NORM protocol messages begin with a common header 680 with information fields as follows: 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |version| type | hdr_len | sequence | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | source_id | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 NORM Common Message Header Format 692 The "version" field is a 4-bit value indicating the protocol version 693 number. NORM implementations SHOULD ignore received messages with 694 version numbers different from their own. This number is intended to 695 indicate and distinguish upgrades of the protocol which may be non- 696 interoperable. The NORM version number for this specification is 1. 698 The message "type" field is a 4-bit value indicating the NORM 699 protocol message type. These types are defined as follows: 701 Message Value 703 NORM_INFO 1 704 NORM_DATA 2 705 NORM_CMD 3 706 NORM_NACK 4 707 NORM_ACK 5 708 NORM_REPORT 6 710 The 8-bit "hdr_len" field indicates the number of 32-bit words that 711 comprise the given message’s header portion. This is used to 712 facilitate header extensions that may be applied. The presence of 713 header extensions are implied when the "hdr_len" value is greater 714 than the base value for the given message "type". 716 The "sequence" field is a 16-bit value that is set by the message 717 originator as a monotonically increasing number incremented with each 718 NORM message transmitted. Note that two independent "sequence" 719 spaces MUST be maintained. One sequence space SHALL be kept for NORM 720 sender messages (NORM_INFO, NORM_DATA, and NORM_CMD) generated, and a 721 separate, independent "sequence" space SHALL be kept for NORM 722 receiver messages (NORM_NACK and NORM_NACK). The sender message 723 "sequence" value can be monitored by receiving nodes to detect packet 724 losses in the transmissions from a sender and used to estimate raw 725 packet loss for congestion control purposes. Note that this value is 726 NOT used in the NORM protocol to detect missing reliable data content 727 and does NOT identify the application data or FEC payload that may be 728 attached. The "sequence" field may also be leveraged for protection 729 from message "replay" attacks, particularly of NORM_NACK or other 730 feedback messages. For this reason, NORM receiver messages are also 731 sequence numbered. An independent sequence space MUST be used for 732 receiver messages because when receivers generate unicast NORM_NACK 733 or NORM_ACK messages, those messages will not be visible to the group 734 at large that may be performing loss estimation. Also, NORM 735 congestion control is applied only to sender messages. The size of 736 the "sequence" field is intended to be sufficient to allow detection 737 of a reasonable range of packet loss within the delay-bandwidth 738 product of expected network connections. 740 The "source_id" field is a 32-bit value identifying the node that 741 sent the message. A participant’s NORM node identifier (NormNodeId) 742 can be set according to application needs but unique identifiers must 743 be assigned within a single NormSession. In some cases, use of the 744 host IP address or a hash of it can suffice, but alternative 745 methodologies for assignment and potential collision resolution of 746 node identifiers within a multicast session need to be considered. 747 For example, the "source identifier" mechanism defined in the Real- 748 Time Protocol (RTP) specification [22] may be applicable to use for 749 NORM node identifiers. At this point in time, the protocol makes no 750 assumptions about how these unique identifiers are actually assigned. 752 NORM Header Extensions 754 When header extensions are applied, they follow the message type’s 755 base header and precede any payload portion. There are two formats 756 for header extensions, both of which begin with an 8-bit "het" 757 (header extension type) field. One format is provided for variable- 758 length extensions with "het" values in the range from 0 through 127. 759 The other format is for fixed length (one 32-bit word) extensions 760 with "het" values in the range from 128 through 255. These formats 761 are given here: 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | het <=127 | hel | | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 768 | Header Extension Content | 769 | ... | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 NORM Variable Length Header Extension Format 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | het >=128 | reserved | Header Extension Content | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 NORM Fixed Length (32-bit) Header Extension Format 781 The "Header Extension Content" portion of these header extension 782 format is defined for each header extension type defined for NORM 783 messages. Some header extensions are defined within this document 784 for NORM baseline FEC and congestion control operations. 786 4.2. Sender Messages 788 NORM sender messages include the NORM_DATA type, the NORM_INFO type, 789 and the NORM_CMD type. NORM_DATA and NORM_INFO messages contain 790 application data content while NORM_CMD messages are used for various 791 protocol control functions. 793 4.2.1. NORM_DATA Message 795 The NORM_DATA message is expected to be the predominant type 796 transmitted by NORM senders. These messages are used to encapsulate 797 segmented data content for objects of type NORM_OBJECT_DATA, 798 NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. NORM_DATA messages may 799 contain original or FEC-encoded application data content. 801 The format of NORM_DATA messages is comprised of three logical 802 portions: 1) a fixed-format NORM_DATA header portion, 2) a FEC 803 Payload ID portion with a format dependent upon the FEC encoding 804 used, and 3) a payload portion containing source or encoded 805 application data content. Note for objects of type 806 NORM_OBJECT_STREAM, the payload portion contains additional fields 807 used to appropriately recover stream content. NORM implementations 808 MAY also extend the NORM_DATA header to include a FEC Object 809 Transmission Information (EXT_FTI) header extension. This allows 810 NORM receivers to automatically allocate resources and properly 811 perform FEC decoding without the need for pre-configuration or out- 812 of-band information. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |version| type=2| hdr_len | sequence | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | source_id | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | instance_id | grtt |backoff| gsize | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | flags | fec_id | object_transport_id | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | fec_payload_id | 826 | ... | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | header_extensions (if applicable) | 829 | ... | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | payload_len* | payload_msg_start* | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | payload_offset* | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | payload_data* | 836 | ... | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 NORM_DATA Message Format 841 *IMPORTANT NOTE: The "payload_len", "payload_msg_start" and 842 "payload_offset" fields are present only for objects of type 843 NORM_OBJECT_STREAM. 845 The "payload_len" and "payload_offset" fields allow senders to 846 arbitrarily vary the size of NORM_DATA payload segments for streams. 847 This allows applications to flush transmitted streams as needed to 848 meet unique streaming requirements. For objects of types 849 NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary 850 since the receiver can calculate the payload length and offset 851 information from the "fec_payload_id" using the block partioning 852 algorithm described in the FEC Building Block document [4]. The 853 "payload_len" field indicates the length (in bytes) of the 854 "payload_data" content of the stream data segment. When 855 "payload_len" is equal to ZERO, this indicates that there is no 856 "payload_data" content and the "payload_msg_start" field is instead 857 to be interpreted as a stream control code. 859 The "payload_msg_start" field serves one of two exlusive purposes. 860 When "payload_len" is a non-zero value, the "payload_msg_start" 861 fields is used to mark the location (within the "payload_data") field 862 of the start byte of an application-defined message boundary. Note 863 that the "payload_msg_start" value is the byte offset of the message 864 boundary plus one. Thus, a value of "payload_msg_start" equal to 865 ZERO denotes that no message boundary is present, while a 866 "payload_msg_start" value of ONE indicates the message boundary is 867 aligned with the beginning of the "payload_data" field. This allows 868 NORM receiver applications to "synchronize" with NORM senders and to 869 be able to properly interpret application layer data when joining a 870 NORM session already in progress. The NORM sender implementation 871 SHOULD provide a mechanism for the application to mark such message 872 boundaries and set the "payload_msg_start" value accordingly. The 873 "payload_msg_start" value will always be less than or equal to the 874 "payload_len" value except for the special case of "payload_len = 0", 875 that indicates the "payload_msg_start" field should be interpreted as 876 a "stream control code" (See description below). 878 The "payload_len" and "payload_offset" fields allow senders to 879 arbitrarily vary the size of NORM_DATA payload segments for streams. 880 This allows applications to flush transmitted streams as needed to 881 meet unique streaming requirements. For objects of types 882 NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary 883 since the receiver can calculate the payload length and offset 884 information from the "fec_payload_id" using the block partioning 885 algorithm described in the FEC Building Block document [4]. When 886 systematic FEC codes (e.g., "fec_id" = 129) are used, the 887 "payload_len", "payload_msg_start", and "payload_offset" fields 888 contain actual payload_data length, start index (or stream control 889 code), and offset values for the associated application stream data 890 segment (the "payload_data" field content) for those NORM_DATA 891 messages containing source data symbols. In NORM_DATA messages that 892 contain parity information, these fields do not contain values that 893 can be directly interpreted, but instead are values computed from FEC 894 encoding the "payload_len", "payload_msg_start", and "payload_offset" 895 fields for the source data segments of the corresponding coding 896 block. 898 The "version", "type", "hdr_len", "sequence", and "source_id" fields 899 form the NORM Common Message Header as described in Section 4.1. The 900 value of the NORM_DATA "type" field is 2. The NORM_DATA _base_ 901 "hdr_len" value is 4 (32-bit words) plus the size of the 902 "fec_payload_id" field. The "fec_payload_id" field size depends upon 903 the FEC encoding used for the referenced NormObject. The "fec_id" 904 field is used to indicate the FEC coding type. For example, when 905 small block, systematic codes are used, a "fec_id" value of 129 is 906 indicated and the size of the "fec_payload_id" is two 32-bit words. 907 In this case the NORM_DATA base "hdr_len" value is 6. The cumulative 908 size of any header extensions applied is added into the "hdr_len" 909 field. 911 The "instance_id" field contains a value generated by the sender to 912 uniquely identify its current instance of participation in the 913 NormSession. This allows receivers to detect when senders have 914 perhaps left and rejoined a session in progress. When a sender 915 (identified by its "source_id") is detected to have a new 916 "instance_id", the NORM receivers SHOULD drop their previous state on 917 the sender and begin reception anew, or at least treat this 918 "instance" as a new, separate sender. 920 The "grtt" field contains a non-linear quantized representation of 921 the sender’s current estimate of group round-trip time (GRTT) (this 922 is also referred to as R_max in [24]). This value is used to control 923 timing of the NACK repair process and other aspects of protocol 924 operation as described in this document. Normally, the advertised 925 "grtt" value will correspond to what the sender has measured based on 926 feedback from the group, but, at low transmission rates, the 927 advertised "grtt" SHALL be set to MAX(grttMeasured, 928 NormSegmentSize/senderRate) where the "NormSegmentSize" is sender’s 929 segment size in bytes and the "senderRate" is the sender’s current 930 transmission rate in bytes per second. The algorithm for encoding 931 and decoding this field is described in the RMT NORM Building Block 932 document [3]. 934 The "backoff" field value is used by receivers to determine the 935 maximum backoff timer value used in the timer-based NORM NACK 936 feedback suppression. This 4-bit field supports values from 0-15 937 which is multiplied by the sender GRTT to determine the maximum 938 backoff timeout. The "backoff" field informs the receiver set of the 939 sender’s backoff factor parameter "Ksender". Recommended values and 940 their use are described in the NORM receiver NACK procedure 941 description in Section 5.3. The "gsize" field contains a 942 representation of the sender’s current estimate of group size. This 943 4-bit field can roughly represent values from ten to 500 million 944 where the most significant bit value of 0 or 1 represents a mantissa 945 of 1 or 5, respectively and the three least significant bits 946 incremented by one represent a base 10 exponent (order of magnitude). 947 For examples, a field value of "0x0" represents 1.0e+01 (10), a value 948 of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02 949 (100), and a value of "0xf" represents 5.0e+08. For NORM feedback 950 suppression purposes, the group size does not need to be represented 951 with a high degree of precision. The group size may even be 952 estimated somewhat conservatively (i.e., overestimated) to maintain 953 low levels of feedback traffic. A default group size estimate of 954 10,000 ("gsize" = 0x3) is recommended for general purpose reliable 955 multicast applications using the NORM protocol. 957 The "flags" field contains a number of different binary flags 958 providing information and hints regarding how the receiver should 959 handle the identified object. Defined flags in this field include: 961 +---------------------+-------+----------------------------------------+ 962 | Flag | Value | Purpose | 963 +---------------------+-------+----------------------------------------+ 964 |NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair | 965 | | | transmission | 966 +---------------------+-------+----------------------------------------+ 967 |NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to | 968 | | | meet a specific receiver erasure, as | 969 | | | compared to parity segments provided | 970 | | | by the sender for general purpose | 971 | | | (with respect to an FEC coding block) | 972 | | | erasure filling. | 973 +---------------------+-------+----------------------------------------+ 974 |NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO | 975 | | | for object. | 976 +---------------------+-------+----------------------------------------+ 977 |NORM_FLAG_UNRELIABLE | 0x08 | Indicates that repair transmissions | 978 | | | for the specified object will be | 979 | | | unavailable (One-shot, best effort | 980 | | | transmission). | 981 +---------------------+-------+----------------------------------------+ 982 |NORM_FLAG_FILE | 0x10 | Indicates object is "file-based" data | 983 | | | (hint to use disk storage for | 984 | | | reception). | 985 +---------------------+-------+----------------------------------------+ 986 |NORM_FLAG_STREAM | 0x20 | Indicates object is of type | 987 | | | NORM_OBJECT_STREAM. | 988 +---------------------+-------+----------------------------------------+ 990 NORM_FLAG_REPAIR is set when the associated message is a repair 991 transmission. This information can be used by receivers to help 992 observe a join policy where it is desired that newly joining 993 receivers only begin participating in the NACK process upon receipt 994 of new (non-repair) data content. NORM_FLAG_EXPLICIT is used to mark 995 repair messages sent when the data sender has exhausted its ability 996 to provide "fresh" (previously untransmitted) parity segments as 997 repair. This flag could possibly be used by intermediate systems 998 implementing functionality to control sub-casting of repair content 999 to different legs of a reliable multicast topology with disparate 1000 repair needs. NORM_FLAG_INFO is set only when optional NORM_INFO 1001 content is actually available for the associated object. Thus, 1002 receivers will NACK for retransmission of NORM_INFO only when it is 1003 available for a given object. NORM_FLAG_UNRELIABLE is set when the 1004 sender wishes to transmit an object with only "best effort" delivery 1005 and will not supply repair transmissions for the object. NORM 1006 receivers SHOULD NOT execute repair requests for objects marked with 1007 the NORM_FLAG_UNRELIABLE flag. Note that receivers may inadvertently 1008 request repair of such objects when all segments (or info content) 1009 for those objects are not received (i.e., a gap in the 1010 "object_transport_id" sequence is noted). In this case, the sender 1011 should invoke the NORM_CMD(SQUELCH) process as described in Section 1012 4.2.3. NORM_FLAG_FILE can be set as a "hint" from the sender that 1013 the associated object should be stored in non-volatile storage. 1014 NORM_FLAG_STREAM is set when the identified object is of type 1015 NORM_OBJECT_STREAM. The presence of NORM_FLAG_STREAM overrides that 1016 of NORM_FLAG_FILE with respect to interpretation of object size and 1017 the format of NORM_DATA messages. 1019 The "fec_id" field corresponds to the FEC Encoding Identifier 1020 described in the FEC Building Block document [4]. The "fec_id" value 1021 implies the format of the "fec_payload_id" field and, coupled with 1022 FEC Object Transmission Information, the procedures to decode FEC 1023 encoded content. Small block, systematic codes ("fec_id" = 129) are 1024 expected to be used for most NORM purposes and the NORM_OBJECT_STREAM 1025 requires systematic FEC codes for most efficient performance. 1027 The "object_transport_id" field is a monotonically and incrementally 1028 increasing value assigned by the sender to NormObjects being 1029 transmitted. Transmissions and repair requests related to that 1030 object use the same "object_transport_id" value. For sessions of 1031 very long or indefinite duration, the "object_transport_id" field may 1032 be repeated, but it is presumed that the 16-bit field size provides 1033 an adequate enough sequence space to avoid object confusion amongst 1034 receivers and sources (i.e., receivers SHOULD re-synchronize with a 1035 server when receiving object sequence identifiers sufficiently out- 1036 of-range with the current state kept for a given source). During the 1037 course of its transmission within a NORM session, an object is 1038 uniquely identified by the concatenation of the sender "source_id" 1039 and the given "object_transport_id". Note that NORM_INFO messages 1040 associated with the identified object carry the same 1041 "object_transport_id" value. 1043 The "fec_payload_id" identifies the attached NORM_DATA "payload" 1044 content. The size and format of the "fec_payload_id" field depends 1045 upon the FEC type indicated by the "fec_id" field. These formats are 1046 given in the descriptions of specific FEC schemes as described in the 1047 IETF FEC Basic Schemes document [25]. or additional FEC Scheme 1048 documents that may be defined. As an example, the format of the 1049 "fec_payload_id" format for Small Block, Systematic codes ("fec_id" = 1050 129) is given here: 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | source_block_number | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | source_block_len | encoding_symbol_id | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 Example FEC Payload ID Field ("fec_payload_id") Format 1061 for Small Block, Systematic Codes ("fec_id" = 129) 1063 In this example FEC payload identifier, the "source_block_number", 1064 "source_block_len", and "encoding_symbol_id" fields correspond to the 1065 "Source Block Number", "Source Block Length, and "Encoding Symbol ID" 1066 fields of the FEC Payload ID format given by the FEC Basic Schemes 1067 document [25]. for the Small Block Systematic FEC Scheme identified 1068 by a "fec_id" value of 129. The "source_block_number" identifies the 1069 coding block’s relative position with a NormObject. Note that, for 1070 NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may 1071 wrap for very long lived sessions. The "source_block_len" indicates 1072 the number of user data segments in the identified coding block. 1073 Given the "source_block_len" information of how many symbols of 1074 application data are contained in the block, the receiver can 1075 determine whether the attached segment is data or parity content and 1076 treat it appropriately. Some applications may dynamically "shorten" 1077 code blocks when the pending information content is not predictable 1078 (e.g. real-time message streams). In that case, the 1079 "source_block_len" value given for an "encoding_symbol_id" that 1080 contains FEC parity content SHALL take precedence over the 1081 "source_block_len" value provided for any packets containing source 1082 symbols. Also, the "source_block_len" value given for an ordinally 1083 higher "encoding_symbol_id" SHALL take precedence over the 1084 "source_block_len" given for prior encoding symbols. The reason for 1085 this is that the sender may only know the maximum source block length 1086 at the time is transmitting source symbols, but then subsequently 1087 "shorten" the code and then provide that last source symbol and/or 1088 encoding symbols with FEC parity content. The "encoding_symbol_id" 1089 identifies which specific symbol (segment) within the coding block 1090 the attached payload conveys. Depending upon the value of the 1091 "encoding_symbol_id" and the associated "source_block_len" parameters 1092 for the block, the symbol (segment) referenced may be a user data or 1093 an FEC parity segment. For systematic codes, encoding symbols 1094 numbered less than the source_block_len contain original application 1095 data while segments greater than or equal to source_block_len contain 1096 parity symbols calculated for the block. The concatenation of 1097 object_transport_id::fec_payload_id can be viewed as a unique 1098 transport protocol data unit identifier for the attached segment with 1099 respect to the NORM sender’s instance within a session. 1101 Additional FEC Object Transmission Information (as described in the 1102 FEC Building Block document [4]) is required to properly receive and 1103 decode NORM transport objects. This information MAY be provided as 1104 out-of-band session information. However, in some cases, it may be 1105 useful for the sender to include this information "in-band" to 1106 facilitate receiver operation with minimal preconfiguration. For 1107 this purpose, the NORM FEC Object Transmission Information Header 1108 Extension (EXT_FTI) is defined. This header extension MAY be applied 1109 to NORM_DATA and NORM_INFO messages to provide this necessary 1110 information. The format of the EXT_FTI consists of two parts, a 1111 general part that contains the size of the associated transport 1112 object and a portion that depends upon the FEC scheme being used. 1113 The "fec_id" field in NORM_DATA and NORM_INFO messages identifies the 1114 FEC scheme. The format of the EXT_FTI general part is given here. 1116 0 1 2 3 1117 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 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | het = 64 | hel = 4 | object_size (msb) | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | object_size (lsb) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | FEC Scheme specific content ... | 1125 FEC Object Transmission Information Header Extension (EXT_FTI) 1127 The header extension type "het" field value for the EXT_FTI header 1128 extension is 64. The header extension length "hel" value depends 1129 upon the format of the FTI for FEC code type identified by the 1130 "fec_id" field. 1132 The 48-bit "object_size" field indicates the total length of the 1133 object (in bytes) for the static object types of NORM_OBJECT_FILE and 1134 NORM_OBJECT_DATA. This information is used by receivers to determine 1135 storage requirements and/or allocate storage for the received object. 1136 Receivers with insufficient storage capability may wish to forego 1137 reliable reception (i.e., not NACK for) of the indicated object. In 1138 the case of objects of type NORM_OBJECT_STREAM, the "object_size" 1139 field is used by the sender to advertise the size of its stream 1140 buffer to the receiver group. In turn, the receivers SHOULD use this 1141 information to allocate a stream buffer for reception of 1142 corresponding size. 1144 As noted, the format of the extension depends upon the FEC code in 1145 use, but in general it SHOULD contain any required details on the FEC 1146 code in use (e.g., FEC Instance ID, etc.). As an example, the format 1147 of the EXT_FTI for small block systematic codes ("fec_id" = 129) is 1148 given here: 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | het = 64 | hel = 4 | object_size (msb) | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | object_size (lsb) | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | fec_instance_id | segment_size | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | fec_max_block_len | fec_num_parity | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 Example FEC Object Transmission Information Header Extension 1163 (EXT_FTI) for Small Block, Systematic Codes ("fec_id" = 129) 1165 In this example (for "fec_id" = 129), the "hel" field value is 4. 1166 The size of the EXT_FTI header extension may be different for other 1167 FEC schemes. 1169 The 48-bit "object_size" serves the purpose described previously. 1171 The "fec_instance_id" corresponds to the "FEC Instance ID" described 1172 in the FEC Building Block document [4]. In this case, the 1173 "fec_instance_id" is a value corresponding to the particular type of 1174 Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), 1175 Reed-Solomon GF(2^16), etc). The standardized assignment of FEC 1176 Instance ID values is described in [4]. The "segment_size" field 1177 indicates the sender’s current setting for maximum message payload 1178 content (in bytes). This allows receivers to allocate appropriate 1179 buffering resources and to determine other information in order to 1180 properly process received data messaging. Typically, FEC parity 1181 symbol segments will be of this size. 1183 The "fec_max_block_len" indicates the current maximum number of user 1184 data segments per FEC coding block to be used by the sender during 1185 the session. This allows receivers to allocate appropriate buffer 1186 space for buffering blocks transmitted by the sender. 1188 The "fec_num_parity" corresponds to the "maximum number of encoding 1189 symbols that can be generated for any source block" as described in 1190 for FEC Object Transmission Information for Small Block Systematic 1191 Codes in the FEC Building Block document [4]. For example, Reed- 1192 Solomon codes may be arbitrarily shortened to create different code 1193 variations for a given block length. In the case of Reed-Solomon 1194 (GF(2^8) and GF(2^16)) codes, this value indicates the maximum number 1195 of parity segments available from the sender for the coding blocks. 1196 This field MAY be interpreted differently for other systematic codes 1197 as they are defined. 1199 The payload portion of NORM_DATA messages includes source data or FEC 1200 encoded application content. Again, the content of this payload 1201 depends upon the FEC scheme being employed. Additionally, support 1202 for streaming using the NORM_OBJECT_STREAM type, necessitates some 1203 additional content in the payload. 1205 The "payload_len", "payload_msg_start", and "payload_offset" fields 1206 are present ONLY for transport objects of type NORM_OBJECT_STREAM. 1207 For senders employing systematic FEC encoding, these fields contain 1208 values that can be interpreted directly for NORM_DATA messages 1209 containing original application source data content. But, for 1210 NORM_DATA messages containing calculated parity content, these fields 1211 will contain values computed by FEC encoding of the 1212 "payload_msg_start", "payload_len" and "payload_offset" values of the 1213 NORM_DATA data segments for the corresponding FEC coding block and 1214 cannot be interpreted directly. The actual "payload_msg_start", 1215 "payload_len" and "payload_offset" values of missing data content can 1216 be determined upon decoding a FEC coding block. Note that these 1217 fields do NOT contribute to the value of the NORM_DATA "hdr_len" 1218 field. These fields are present only when the "flags" portion of the 1219 NORM_DATA message indicate the transport object is of type 1220 NORM_OBJECT_STREAM. 1222 The "payload_len" value, when non-zero, indicates the size, in bytes, 1223 of the source content contained in the "payload_data" field. If the 1224 "payload_len" value is equal to ZERO, this indicates that the 1225 "payload_msg_start" field should be alternatively interpreted as a 1226 stream control code. The only stream control code currently defined 1227 is NORM_STREAM_END = 0. This code indicates that the sender is 1228 terminating transmission of stream content at the corresponding 1229 position in the stream and the receiver should not expect content (or 1230 NACK for any content) following that position in the stream. Future 1231 versions of this specification may define additional stream control 1232 codes if necessary. 1234 When the "payload_len" value is non-zero, the "payload_msg_start" 1235 field, when it is set to a non-zero value, indicates that the 1236 associated "payload_data" content contains an application-defined 1237 message boundary (start-of-message). When such a message boundary is 1238 indicated, the first byte of an application-defined message, with 1239 respect to the "payload_data" field, will be found at an offset of 1240 "payload_msg_start - 1" bytes. Thus, if a NORM_OBJECT_STREAM 1241 NORM_DATA payload contains the start of an application message at the 1242 first byte of the "payload_data" field, the value of the 1243 "payload_msg_start" field will be ’1’. Again, if the value of the 1244 "payload_msg_start" field is ZERO, no message boundary is indicated. 1245 It is RECOMMENDED that NORM implementations provide sender stream 1246 applications with a capability to mark message boundaries in this 1247 manner. Similarly, the NORM receiver SHOULD enable the application 1248 to recover such message boundary information. This enables NORM 1249 receivers to "synchronize" with transmitted message stream content in 1250 a meaningful way (i.e., meaningful to the application) at any time, 1251 whether joining the session late, or departing the session and 1252 returning. 1254 and "payload_offset" fields indicate the size and relative position 1255 (within the stream) of the source content contained in the 1256 "payload_data" field. Note that for long-lived streams, the 1257 "payload_offset" field may wrap. 1259 The "payload_data" field contains the original application source or 1260 parity content for the symbol identified by the "fec_payload_id". 1261 The length of this field SHALL be limited to a maximum of the 1262 sender’s NormSegmentSize bytes as given in the FTI for the object. 1263 Note the length of this field for messages containing parity content 1264 will always be of length NormSegmentSize. When encoding data 1265 segments of varying sizes, the FEC encoder SHALL assume ZERO value 1266 padding for data segments with length less than the NormSegmentSize. 1267 It is RECOMMENDED that a sender’s NormSegmentSize generally be 1268 constant for the duration of a given sender’s term of participation 1269 in the session, but may possibly vary on a per-object basis. The 1270 NormSegmentSize is expected to be configurable by the sender 1271 application prior to session participation as needed for network 1272 topology maximum transmission unit (MTU) considerations. For IPv6, 1273 MTU discovery may be possibly leveraged at session startup to perform 1274 this configuration. The "payload_data" content may be delivered 1275 directly to the application for source symbols (when systematic FEC 1276 encoding is used) or upon decoding of the FEC block. For 1277 NORM_OBJECT_FILE and NORM_OBJECT_STREAM objects, the data segment 1278 length and offset can be calculated using the block paritioning 1279 algorithm described in the FEC Building Block document [4]. For 1280 NORM_OBJECT_STREAM objects, the length and offset is obtained from 1281 the segment’s corresponding "payload_len" and "payload_offset" 1282 fields. 1284 4.2.2. NORM_INFO Message 1286 The NORM_INFO message is used to convey OPTIONAL, application- 1287 defined, "out-of-band" context information for transmitted 1288 NormObjects. An example NORM_INFO use for bulk file transfer is to 1289 place MIME type information for the associated file, data, or stream 1290 object into the NORM_INFO payload. Receivers may use the NORM_INFO 1291 content to make a decision as whether to participate in reliable 1292 reception of the associated object. Each NormObject can have an 1293 independent unit of NORM_INFO associated with it. NORM_DATA messages 1294 contain a flag to indicate the availability of NORM_INFO for a given 1295 NormObject. NORM receivers may NACK for retransmission of NORM_INFO 1296 when they have not received it for a given NormObject. The size of 1297 the NORM_INFO content is limited to that of a single NormSegmentSize 1298 for the given sender. This atomic nature allows the NORM_INFO to be 1299 rapidly and efficiently repaired within the NORM reliable 1300 transmission process. 1302 When NORM_INFO content is available for a NormObject, the 1303 NORM_FLAG_INFO flag SHALL be set in NORM_DATA messages for the 1304 corresponding "object_transport_id" and the NORM_INFO message shall 1305 be transmitted as the first message for the NormObject. 1307 0 1 2 3 1308 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 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 |version| type=1| hdr_len | sequence | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | source_id | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | instance_id | grtt |backoff| gsize | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | flags | fec_id | object_transport_id | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | header_extensions (if applicable) | 1319 | ... | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | payload_data | 1322 | ... | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 NORM_INFO Message Format 1327 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1328 form the NORM Common Message Header as described in Section 4.1. The 1329 value of "hdr_len" field when no header extensions are present is 4. 1331 The "instance_id", "grtt", "backoff", "gsize", "flags", "fec_id", and 1332 "object_transport_id" fields carry the same information and serve the 1333 same purpose as with NORM_DATA messages. These values allow the 1334 receiver to prepare appropriate buffering, etc, for further 1335 transmissions from the sender when NORM_INFO is the first message 1336 received. 1338 As with NORM_DATA messages, the NORM FTI Header Extension (EXT_FTI) 1339 may be optionally applied to NORM_INFO messages. To conserve 1340 protocol overhead, some NORM implementations may wish to apply the 1341 EXT_FTI when used to NORM_INFO messages only and not to NORM_DATA 1342 messages. 1344 The NORM_INFO "payload_data" field contains sender application- 1345 defined content which can be used by receiver applications for 1346 various purposes as described above. 1348 4.2.3. NORM_CMD Messages 1350 NORM_CMD messages are transmitted by senders to perform a number of 1351 different protocol functions. This includes functions such as round- 1352 trip timing collection, congestion control functions, synchronization 1353 of sender/receiver repair "windows", and notification of sender 1354 status. A core set of NORM_CMD messages is enumerated. 1355 Additionally, a range of command types remain available for potential 1356 application-specific use. Some NORM_CMD types may have dynamic 1357 content attached. Any attached content will be limited to maximum 1358 length of the sender NormSegmentSize to retain the atomic nature of 1359 commands. All NORM_CMD messages begin with a common set of fields, 1360 after the usual NORM message common header. The standard NORM_CMD 1361 fields are: 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 |version| type=3| hdr_len | sequence | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | source_id | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | instance_id | grtt |backoff| gsize | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | flavor | | 1373 +-+-+-+-+-+-+-+-+ NORM_CMD Content + 1374 | ... | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 NORM_CMD Standard Fields 1379 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1380 form the NORM Common Message Header as described in Section 4.1. The 1381 value of the "hdr_len" field for NORM_CMD messages without header 1382 extensions present depends upon the "flavor" field. 1384 The "instance_id", "grtt", "backoff", and "gsize" fields provide the 1385 same information and serve the same purpose as with NORM_DATA and 1386 NORM_INFO messages. The "flavor" field indicates the type of command 1387 to follow. The remainder of the NORM_CMD message is dependent upon 1388 the command type ("flavor"). NORM command flavors include: 1390 +----------------------+--------+----------------------------------+ 1391 | Command | Flavor | Purpose | 1392 +----------------------+--------+----------------------------------+ 1393 |NORM_CMD(FLUSH) | 1 | Used to indicate sender | 1394 | | | temporary end-of-transmission. | 1395 | | | (Assists in robustly initiating | 1396 | | | outstanding repair requests from | 1397 | | | receivers). May also be | 1398 | | | optionally used to collect | 1399 | | | positive acknowledgment of | 1400 | | | reliable reception from subset | 1401 | | | of receivers. | 1402 +----------------------+--------+----------------------------------+ 1403 |NORM_CMD(EOT) | 2 | Used to indicate sender | 1404 | | | permanent end-of-transmission. | 1405 +----------------------+--------+----------------------------------+ 1406 |NORM_CMD(SQUELCH) | 3 | Used to advertise sender’s | 1407 | | | current repair window in | 1408 | | | response to out-of-range NACKs | 1409 | | | from receivers. | 1410 +----------------------+--------+----------------------------------+ 1411 |NORM_CMD(CC) | 4 | Used for GRTT measurement and | 1412 | | | collection of congestion control | 1413 | | | feedback. | 1414 +----------------------+--------+----------------------------------+ 1415 |NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender’s | 1416 | | | aggregated repair/feedback state | 1417 | | | for suppression of unicast | 1418 | | | feedback from receivers. | 1419 +----------------------+--------+----------------------------------+ 1420 |NORM_CMD(ACK_REQ) | 6 | Used to request application- | 1421 | | | defined positive acknowledgment | 1422 | | | from a list of receivers | 1423 | | | (OPTIONAL). | 1424 +----------------------+--------+----------------------------------+ 1425 |NORM_CMD(APPLICATION) | 7 | Used for application-defined | 1426 | | | purposes which may need to | 1427 | | | temporarily preempt data | 1428 | | | transmission (OPTIONAL). | 1429 +----------------------+--------+----------------------------------+ 1431 4.2.3.1. NORM_CMD(FLUSH) Message 1433 The NORM_CMD(FLUSH) command is sent when the sender reaches the end 1434 of all data content and pending repairs it has queued for 1435 transmission. This may indicate a temporary or permanent end of data 1436 transmission, but the sender is still willing to respond to repair 1437 requests. This command is repeated once per 2*GRTT to excite the 1438 receiver set for any outstanding repair requests up to and including 1439 the transmission point indicated within the NORM_CMD(FLUSH) message. 1440 The number of repeats is equal to NORM_ROBUST_FACTOR unless a list of 1441 receivers from which explicit positive acknowledgment is expected 1442 ("acking_node_list") is given. In that case, the "acking_node_list" 1443 is updated as acknowledgments are received and the NORM_CMD(FLUSH) is 1444 repeated according to the mechanism described in Section 5.5.3. The 1445 greater the NORM_ROBUST_FACTOR, the greater the probability that all 1446 applicable receivers will be excited for acknowledgment or repair 1447 requests (NACKs) _and_ that the corresponding NACKs are delivered to 1448 the sender. A default value of NORM_ROBUST_FACTOR equal to 20 is 1449 RECOMMENDED. If a NORM_NACK message interrupts the flush process, 1450 the sender SHALL re-initiate the flush process after any resulting 1451 repair transmissions are completed. 1453 Note that receivers also employ a timeout mechanism to self-initiate 1454 NACKing (if there are outstanding repair needs) when no messages of 1455 any type are received from a sender. This inactivity timeout is 1456 related to the NORM_CMD(FLUSH) and NORM_ROBUST_FACTOR and is 1457 specified in Section 5.3. Receivers SHALL self-initiate the NACK 1458 repair process when the inactivity has expired for a specific sender 1459 and the receiver has pending repairs needed from that sender. With a 1460 sufficiently large NORM_ROBUST_FACTOR value, data content is 1461 delivered with a high assurance of reliability. The penalty of a 1462 large NORM_ROBUST_FACTOR value is the potential transmission of 1463 excess NORM_CMD(FLUSH) messages and a longer inactivity timeout for 1464 receivers to self-initiate a terminal NACK process. 1466 For finite-size transport objects such as NORM_OBJECT_DATA and 1467 NORM_OBJECT_FILE, the flush process (if there are no further pending 1468 objects) occurs at the end of these objects. Thus, FEC repair 1469 information is always available for repairs in response to repair 1470 requests elicited by the flush command. However, for 1471 NORM_OBJECT_STREAM, the flush may occur at any time, including in the 1472 middle of an FEC coding block if systematic FEC codes are employed. 1473 In this case, the sender will not yet be able to provide FEC parity 1474 content for the concurrent coding block and will be limited to 1475 explicitly repairing the stream with source data content for that 1476 block. Applications that anticipate frequent flushing of stream 1477 content SHOULD be judicious in the selection of the FEC coding block 1478 size (i.e., do not use a very large coding block size if frequent 1479 flushing occurs). For example, a reliable multicast application 1480 transmitting an on-going series of intermittent, relatively small 1481 messages will need to trade-off using the NORM_OBJECT_DATA paradigm 1482 versus the NORM_OBJECT_STREAM paradigm with an appropriate FEC coding 1483 block size. This is analogous to application trade-offs for other 1484 transport protocols such as the selection of different TCP modes of 1485 operation such as "no delay", etc. 1487 0 1 2 3 1488 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 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 |version| type=3| hdr_len | sequence | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | source_id | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | instance_id | grtt |backoff| gsize | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | flavor = 1 | fec_id | object_transport_id | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | fec_payload_id | 1499 | ... | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | acking_node_list (if applicable) | 1502 | ... | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 NORM_CMD(FLUSH) Message Format 1507 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1508 form the NORM Common Message Header as described in Section 4.1. In 1509 addition to the NORM common message header and standard NORM_CMD 1510 fields, the NORM_CMD(FLUSH) message contains fields to identify the 1511 current status and logical transmit position of the sender. 1513 The "fec_id" field indicates the FEC type used for the flushing 1514 "object_transport_id" and implies the size and format of the 1515 "fec_payload_id" field. Note the "hdr_len" value for the 1516 NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id" 1517 field when no header extensions are present. 1519 The "object_transport_id" and "fec_payload_id" fields indicate the 1520 sender’s current logical "transmit position". These fields are 1521 interpreted in the same manner as in the NORM_DATA message type. 1522 Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check 1523 their completion state _through_ (including) this transmission 1524 position. If receivers have outstanding repair needs in this range, 1525 they SHALL initiate the NORM NACK Repair Process as described in 1526 Section 5.3. If receivers have no outstanding repair needs, no 1527 response to the NORM_CMD(FLUSH) is generated. 1529 For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers 1530 MUST request "explicit-only" repair of the identified 1531 "source_block_number" if the given "encoding_symbol_id" is less than 1532 the "source_block_len". This condition indicates the sender has not 1533 yet completed encoding the corresponding FEC block and parity content 1534 is not yet available. An "explicit-only" repair request consists of 1535 NACK content for the applicable "source_block_number" which does not 1536 include any requests for parity-based repair. This allows NORM 1537 sender applications to "flush" an ongoing stream of transmission when 1538 needed, even if in the middle of an FEC block. Once the sender 1539 resumes stream transmission and passes the end of the pending coding 1540 block, subsequent NACKs from receivers SHALL request parity-based 1541 repair as usual. Note that the use of a systematic FEC code is 1542 assumed here. It should also be noted that a sender has the option 1543 of arbitrarily shortening a given code block when such an application 1544 "flush" occurs. In this case, the receiver will request explicit 1545 repair, but the sender MAY provide FEC-based repair (parity segments) 1546 in response. These parity segments MUST contain the corrected 1547 "source_block_len" for the shortened block and that 1548 "source_block_len" associated with segments containing parity content 1549 SHALL overrride the previously advertised "source_block_len". 1550 Similarly, the "source_block_len" associated with the highest ordinal 1551 "encoding_symbol_id" shall take precedence over prior symbols when a 1552 difference (e.g., due to code shortening at the sender) occurs. 1553 Normal receiver NACK initiation and construction is discussed in 1554 detail in Section 5.3. The OPTIONAL "acking_node_list" field 1555 contains a list of NormNodeIds for receivers from which the sender is 1556 requesting explicit positive acknowledgment of reception up through 1557 the transmission point identified by the "object_transport_id" and 1558 "fec_payload_id" fields. The length of the list can be inferred from 1559 the length of the received NORM_CMD(FLUSH) message. When the 1560 "acking_node_list" is present, the lightweight positive 1561 acknowledgment process described in Section 5.5.3 SHALL be observed. 1563 4.2.3.2. NORM_CMD(EOT) Message 1565 The NORM_CMD(EOT) command is sent when the sender reaches permanent 1566 end-of-transmission with respect to the NormSession and will not 1567 respond to further repair requests. This allows receivers to 1568 gracefully reach closure of operation with this sender (without 1569 requiring any timeout) and free any resources that are no longer 1570 needed. The NORM_CMD(EOT) command SHOULD be sent with the same 1571 robust mechanism as used for NORM_CMD(FLUSH) commands to provide a 1572 high assurance of reception by the receiver set. 1574 0 1 2 3 1575 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 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 |version| type=3| hdr_len | sequence | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | source_id | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | instance_id | grtt |backoff| gsize | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 | flavor = 2 | reserved | 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 NORM_CMD(EOT) Message Format 1588 The value of the "hdr_len" field for NORM_CMD(EOT) messages without 1589 header extensions present is 4. The "reserved" field is reserved for 1590 future use and MUST be set to an all ZERO value. Receivers MUST 1591 ignore the "reserved" field. 1593 4.2.3.3. NORM_CMD(SQUELCH) Message 1595 The NORM_CMD(SQUELCH) command is transmitted in response to outdated 1596 or invalid NORM_NACK content received by the sender. Invalid 1597 NORM_NACK content consists of repair requests for NormObjects for 1598 which the sender is unable or unwilling to provide repair. This 1599 includes repair requests for outdated objects, aborted objects, or 1600 those objects which the sender previously transmitted marked with the 1601 NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what 1602 content is available for repair, thus serving as a description of the 1603 sender’s current "repair window". Receivers SHALL not generate 1604 repair requests for content identified as invalid by a 1605 NORM_CMD(SQUELCH). 1607 The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most. 1608 The NORM_CMD(SQUELCH) advertises the current "repair window" of the 1609 sender by identifying the earliest (lowest) transmission point for 1610 which it will provide repair, along with an encoded list of objects 1611 from that point forward that are no longer valid for repair. This 1612 mechanism allows the sender application to cancel or abort 1613 transmission and/or repair of specific previously enqueued objects. 1614 The list also contains the identifiers for any objects within the 1615 repair window that were sent with the NORM_FLAG_UNRELIABLE flag set. 1616 In normal conditions, it is expected the NORM_CMD(SQUELCH) will be 1617 needed infrequently, and generally only to provide a reference repair 1618 window for receivers who have fallen "out-of-sync" with the sender 1619 due to extremely poor network conditions. 1621 The starting point of the invalid NormObject list begins with the 1622 lowest invalid NormTransportId greater than the current "repair 1623 window" start from the invalid NACK(s) that prompted the generation 1624 of the squelch. The length of the list is limited by the sender’s 1625 NormSegmentSize. This allows the receivers to learn the status of 1626 the sender’s applicable object repair window with minimal 1627 transmission of NORM_CMD(SQUELCH) commands. The format of the 1628 NORM_CMD(SQUELCH) message is: 1630 0 1 2 3 1631 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 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 |version| type=3| hdr_len | sequence | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | source_id | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | instance_id | grtt |backoff| gsize | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | flavor = 3 | fec_id | object_transport_id | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | fec_payload_id | 1642 | ... | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | invalid_object_list | 1645 | ... | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 NORM_CMD(SQUELCH) Message Format 1650 In addition to the NORM common message header and standard NORM_CMD 1651 fields, the NORM_CMD(SQUELCH) message contains fields to identify the 1652 earliest logical transmit position of the sender’s current repair 1653 window and an "invalid object list" beginning with the index of the 1654 logically earliest invalid repair request from the offending NACK 1655 message which initiated the squelch transmission. The value of the 1656 "hdr_len" field when no extensions are present is 4 plus the size of 1657 the "fec_payload_id" field that is dependent upon the FEC scheme 1658 identified by the "fec_id" field. 1660 The "object_transport_id" and "fec_payload_id" fields are 1661 concatenated to indicate the beginning of the sender’s current repair 1662 window (i.e., the logically earliest point in its transmission 1663 history for which the sender can provide repair). The "fec_id" field 1664 implies the size and format of the "fec_payload_id" field. This 1665 serves as an advertisement of a "synchronization point" for receivers 1666 to request repair. Note, that while an "encoding_symbol_id" may be 1667 included in the "fec_payload_id" field, the sender’s repair window 1668 SHOULD be aligned on FEC coding block boundaries and thus the 1669 "encoding_symbol_id" SHOULD be zero. 1671 The "invalid_object_list" is a list of 16-bit NormTransportIds that, 1672 although they are within the range of the sender’s current repair 1673 window, are no longer available for repair from the sender. For 1674 example, a sender application may dequeue an out-of-date object even 1675 though it is still within the repair window. The total size of the 1676 "invalid_object_list" content is can be determined from the packet’s 1677 payload length and is limited to a maximum of the NormSegmentSize of 1678 the sender. Thus, for very large repair windows, it is possible that 1679 a single NORM_CMD(SQUELCH) message may not be capable of listing the 1680 entire set of invalid objects in the repair window. In this case, 1681 the sender SHALL ensure that the list begins with a NormObjectId that 1682 is greater than or equal to the lowest ordinal invalid NormObjectId 1683 from the NACK message(s) that prompted the NORM_CMD(SQUELCH) 1684 generation. The NormObjectIds in the "invalid_object_list" MUST be 1685 greater than the "object_transport_id" marking the beginning of the 1686 sender’s repair window. This insures convergence of the squelch 1687 process, even if multiple invalid NACK/ squelch iterations are 1688 required. This explicit description of invalid content within the 1689 sender’s current window allows the sender application (most notably 1690 for discrete "object" based transport) to arbitrarily invalidate 1691 (i.e., dequeue) portions of enqueued content (e.g., certain objects) 1692 for which it no longer wishes to provide reliable transport. 1694 4.2.3.4. NORM_CMD(CC) Message 1696 The NORM_CMD(CC) messages contains fields to enable sender-to- 1697 receiver group greatest round-trip time (GRTT) measurement and to 1698 excite the group for congestion control feedback. A baseline NORM 1699 congestion control scheme (NORM-CC), based on the TCP-Friendly 1700 Multicast Congestion Control (TFMCC) scheme of [5] is described in 1701 Section 5.5.2 of this document. The NORM_CMD(CC) message is usually 1702 transmitted as part of NORM-CC congestion control operation. A NORM 1703 header extension is defined below to be used with the NORM_CMD(CC) 1704 message to support NORM-CC operation. Different header extensions 1705 may be defined for the NORM_CMD(CC) (and/or other NORM messages as 1706 needed) to support alternative congestion control schemes in the 1707 future. If NORM is operated in a private network with congestion 1708 control operation disabled, the NORM_CMD(CC) message is then used for 1709 GRTT measurement only and may optionally be sent less frequently than 1710 with congestion control operation. 1712 0 1 2 3 1713 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 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 |version| type=3| hdr_len | sequence | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | source_id | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | instance_id | grtt |backoff| gsize | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | flavor = 4 | reserved | cc_sequence | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | send_time_sec | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | send_time_usec | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | header extensions (if applicable) | 1728 | ... | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | cc_node_list (if applicable) | 1731 | ... | 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 NORM_CMD(CC) Message Format 1736 The NORM common message header and standard NORM_CMD fields serve 1737 their usual purposes. The value of the "hdr_len" field when no 1738 header extensions are present is 6. 1740 The "reserved" field is for potential future use and MUST be set to 1741 ZERO in this version of the NORM protocol and its baseline NORM-CC 1742 congestion control scheme. It may be possible that alternative 1743 congestion control schemes may use the NORM_CMD(CC) message defined 1744 here and leverage the "reserved" field for scheme-specific purposes. 1746 The "cc_sequence" field is a sequence number applied by the sender. 1747 For NORM-CC operation, it is used to provide functionality equivalent 1748 to the "feedback round number" (fb_nr)described in [5]. The most 1749 recently received "cc_sequence" value is recorded by receivers and 1750 can be fed back to the sender in congestion control feedback 1751 generated by the receivers for that sender. The "cc_sequence" number 1752 can also be used in NORM implementations to assess how recently a 1753 receiver has received NORM_CMD(CC) probes from the sender. This can 1754 be useful instrumentation for complex or experimental multicast 1755 routing environments. 1757 The "send_time" field is a timestamp indicating the time that the 1758 NORM_CMD(CC) message was transmitted. This consists of a 64-bit 1759 field containing 32-bits with the time in seconds ("send_time_sec") 1760 and 32-bits with the time in microseconds ("send_time_usec") since 1761 some reference time the source maintains (usually 00:00:00, 1 January 1762 1970). The byte ordering of the fields is "Big Endian" network 1763 order. Receivers use this timestamp adjusted by the amount of delay 1764 from the time they received the NORM_CMD(CC) message to the time of 1765 their response as the "grtt_response" portion of NORM_ACK and 1766 NORM_NACK messages generated. This allows the sender to evaluate 1767 round-trip times to different receivers for congestion control and 1768 other (e.g., GRTT determination) purposes. 1770 To facilitate the baseline NORM-CC scheme described in Section 5.5.2, 1771 a NORM-CC Rate header extension (EXT_RATE) is defined to inform the 1772 group of the sender’s current transmission rate. This is used along 1773 with the loss detection "sequence" field of all NORM sender messages 1774 and the NORM_CMD(CC) GRTT collection process to support NORM-CC 1775 congestion control operation. The format of this header extension is 1776 as follows: 1778 0 1 2 3 1779 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 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | het = 128 | reserved | send_rate | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 NORM-CC Rate Header Extension Format (EXT_RATE) 1786 The "send_rate" field indicates the sender’s current transmission 1787 rate in bytes per second. The 16-bit "send_rate" field consists of 1788 12 bits of mantissa in the most significant portion and 4 bits of 1789 base 10 integer exponent (E) information in the least significant 1790 portion. The 12-bit mantissa portion of the field is scaled such 1791 that a base 10 mantissa (M) floating point value of 0.0 corresponds 1792 to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of 1793 the 16-bit "send_rate" field . Thus: 1795 send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E; 1797 For example, to represent a transmission rate of 256kbps (3.2e+04 1798 bytes per second), the lower 4 bits of the 16-bit field contain a 1799 value of 0x04 to represent the exponent (E) while the upper 12 bits 1800 contain a value of 0x51f (M) as determined from the equation given 1801 above: 1803 send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4; 1805 = (0x51f << 4) | 0x4 1807 = 0x51f4 1809 To decode the "send_rate" field, the following equation can be used: 1811 value = (send_rate >> 4) * (10/4096) * power(10, (send_rate & x000f)) 1813 Note the maximum transmission rate that can be represented by this 1814 scheme is approximately 9.99e+15 bytes per second. 1816 When this extension is present, a "cc_node_list" may be attached as 1817 the payload of the NORM_CMD(CC) message. The presence of this header 1818 extension also implies that NORM receivers should respond according 1819 to the procedures described in Section 5.5.2. The "cc_node_list" 1820 consists of a list of NormNodeIds and their associated congestion 1821 control status. This includes the current limiting receiver (CLR) 1822 node, any potential limiting receiver (PLR) nodes that have been 1823 identified, and some number of receivers for which congestion control 1824 status is being provided, most notably including the receivers’ 1825 current RTT measurement. The maximum length of the "cc_node_list" 1826 provides for at least the CLR and one other receiver, but may be 1827 configurable for more timely feedback to the group. The list length 1828 can be inferred from the length of the NORM_CMD(CC) message. 1830 Each item in the "cc_node_list" is in the following format: 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | cc_node_id | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | cc_flags | cc_rtt | cc_rate | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 Congestion Control Node List Item Format 1842 The "cc_node_id" is the NormNodeId of the receiver which the item 1843 represents. 1845 The "cc_flags" field contains flags indicating the congestion control 1846 status of the indicated receiver. The following flags are defined: 1848 +-------------------+-------+------------------------------------------+ 1849 | Flag | Value | Purpose | 1850 +-------------------+-------+------------------------------------------+ 1851 |NORM_FLAG_CC_CLR | 0x01 | Receiver is the current limiting | 1852 | | | receiver (CLR). | 1853 +-------------------+-------+------------------------------------------+ 1854 |NORM_FLAG_CC_PLR | 0x02 | Receiver is a potential limiting | 1855 | | | receiver (PLR). | 1856 +-------------------+-------+------------------------------------------+ 1857 |NORM_FLAG_CC_RTT | 0x04 | Receiver has measured RTT with respect | 1858 | | | to sender. | 1859 +-------------------+-------+------------------------------------------+ 1860 |NORM_FLAG_CC_START | 0x08 | Sender/receiver is in "slow start" phase | 1861 | | | of congestion control operation (i.e., | 1862 | | | The receiver has not yet detected any | 1863 | | | packet loss and the "cc_rate" field is | 1864 | | | the receiver’s actual measured receive | 1865 | | | rate). | 1866 +-------------------+-------+------------------------------------------+ 1867 |NORM_FLAG_CC_LEAVE | 0x10 | Receiver is imminently leaving the | 1868 | | | session and its feedback should not be | 1869 | | | considered in congestion control | 1870 | | | operation. | 1871 +-------------------+-------+------------------------------------------+ 1873 The "cc_rtt" contains a quantized representation of the RTT as 1874 measured by the sender with respect to the indicated receiver. This 1875 field is valid only if the NORM_FLAG_CC_RTT flag is set in the 1876 "cc_flags" field. This one byte field is a quantized representation 1877 of the RTT using the algorithm described in the NORM Building Block 1878 document [3]. The "cc_rate" field contains a representation of the 1879 receiver’s current calculated (during steady-state congestion control 1880 operation) or twice its measured (during the "slow start" phase) 1881 congestion control rate. This field is encoded and decoded using the 1882 same technique as described for the NORM_CMD(CC) "send_rate" field. 1884 4.2.3.5. NORM_CMD(REPAIR_ADV) Message 1886 The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise" 1887 its aggregated repair state from NORM_NACK messages accumulated 1888 during a repair cycle and/or congestion control feedback received. 1889 This message is sent only when the sender has received NORM_NACK 1890 and/or NORM_ACK(CC) (when congestion control is enabled) messages via 1891 unicast transmission instead of multicast. By "echoing" this 1892 information to the receiver set, suppression of feedback can be 1893 achieved even when receivers are unicasting that feedback instead of 1894 multicasting it among the group [17]. 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 |version| type=3| hdr_len | sequence | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | source_id | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | instance_id | grtt |backoff| gsize | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | flavor = 5 | flags | reserved | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | header extensions (if applicable) | 1908 | ... | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | repair_adv_payload | 1911 | ... | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 NORM_CMD(REPAIR_ADV) Message Format 1916 The "instance_id", "grtt", "backoff", "gsize", and "flavor" fields 1917 serve the same purpose as in other NORM_CMD messages. The value of 1918 the "hdr_len" field when no extensions are present is 4. 1920 The "flags" field provide information on the NORM_CMD(REPAIR_ADV) 1921 content. There is currently one NORM_CMD(REPAIR_ADV) flag defined: 1923 NORM_REPAIR_ADV_FLAG_LIMIT = 0x01 1925 This flag is set by the sender when it is unable to fit its full 1926 current repair state into a single NormSegmentSize. If this flag is 1927 set, receivers should limit their NACK response to generating NACK 1928 content only up through the maximum ordinal transmission position 1929 (objectId::fecPayloadId) included in the "repair_adv_content". 1931 When congestion control operation is enabled, a header extension may 1932 be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting 1933 (in terms of congestion control feedback suppression) congestion 1934 control response. This allows the NORM_CMD(REPAIR_ADV) message to 1935 suppress receiver congestion control responses as well as NACK 1936 feedback messages. The field is defined as a header extension so 1937 that alternative congestion control schemes may be used with NORM 1938 without revision to this document. A NORM-CC Feedback Header 1939 Extension (EXT_CC) is defined to encapsulate congestion control 1940 feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV) 1941 messages. If another congestion control technique (e.g., Pragmatic 1942 General Multicast Congestion Control (PGMCC) [26]) is used within a 1943 NORM implementation, an additional header extension MAY need to be 1944 defined encapsulate any required feedback content. The NORM-CC 1945 Feedback Header Extension format is: 1947 0 1 2 3 1948 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 1949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1950 | het = 3 | hel = 3 | cc_sequence | 1951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 | cc_flags | cc_rtt | cc_loss | 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | cc_rate | cc_reserved | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 NORM-CC Feedback Header Extension (EXT_CC) Format 1959 The "cc_sequence" field contains the current greatest "cc_sequence" 1960 value receivers have received in NORM_CMD(CC) messages from the 1961 sender. This information assists the sender in congestion control 1962 operation by providing an indicator of how current ("fresh") the 1963 receiver’s round-trip measurement reference time is and whether the 1964 receiver has been successfully receiving recent congestion control 1965 probes. For example, if it is apparent the receiver has not been 1966 receiving recent congestion control probes (and thus possibly other 1967 messages from the sender), the sender may choose to take congestion 1968 avoidance measures. For NORM_CMD(REPAIR_ADV) messages, the sender 1969 SHALL set the "cc_sequence" field value to the value set in the last 1970 NORM_CMD(CC) message sent. 1972 The "cc_flags" field contains bits representing the receiver’s state 1973 with respect to congestion control operation. The possible values 1974 for the "cc_flags" field are those specified for the NORM_CMD(CC) 1975 message node list item flags. These fields are used by receivers in 1976 controlling (suppressing as necessary) their congestion control 1977 feedback. For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT 1978 should be set only when all feedback messages received by the sender 1979 have the flag set. Similarly, the NORM_FLAG_CC_CLR or 1980 NORM_FLAG_CC_PLR should be set only when no feedback has been 1981 received from non-CLR or non-PLR receivers. And the 1982 NORM_FLAG_CC_LEAVE should be set only when all feedback messages the 1983 sender has received have this flag set. These heuristics for setting 1984 the flags in NORM_CMD(REPAIR_ADV) ensure the most effective 1985 suppression of receivers providing unicast feedback messages. 1987 The "cc_rtt" field SHALL be set to a default maximum value and the 1988 NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet 1989 received RTT measurement information. When a receiver has received 1990 RTT measurement information, it shall set the "cc_rtt" value 1991 accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags" 1992 field. For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the 1993 "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has 1994 measured from receivers for the current feedback round. 1996 The "cc_loss" field represents the receiver’s current packet loss 1997 fraction estimate for the indicated source. The loss fraction is a 1998 value from 0.0 to 1.0 corresponding to a range of zero to 100 percent 1999 packet loss. The 16-bit "cc_loss" value is calculated by the 2000 following formula: 2002 "cc_loss" = decimal_loss_fraction * 65535.0 2004 For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" 2005 field value to the largest non-CLR/non-PLR loss estimate it has 2006 received from receivers for the current feedback round. 2008 The "cc_rate" field represents the receivers current local congestion 2009 control rate. During "slow start", when the receiver has detected no 2010 loss, this value is set to twice the actual rate it has measured from 2011 the corresponding sender and the NORM_FLAG_CC_START is set in the 2012 "cc_flags’ field. Otherwise, the receiver calculates a congestion 2013 control rate based on its loss measurement and RTT measurement 2014 information (even if default) for the "cc_rate" field. For 2015 NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss" 2016 field value to the lowest non-CLR/non-PLR "cc_rate" report it has 2017 received from receivers for the current feedback round. 2019 The "cc_reserved" field is reserved for future NORM protocol use. 2020 Currently, senders SHALL set this field to ZERO, and receivers SHALL 2021 ignore the content of this field. 2023 The "repair_adv_payload" is in exactly the same form as the 2024 "nack_content" of NORM_NACK messages and can be processed by 2025 receivers for suppression purposes in the same manner, with the 2026 exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is 2027 set. 2029 4.2.3.6. NORM_CMD(ACK_REQ) Message 2031 The NORM_CMD(ACK_REQ) message is used by the sender to request 2032 acknowledgment from a specified list of receivers. This message is 2033 used in providing a lightweight positive acknowledgment mechanism 2034 that is OPTIONAL for use by the reliable multicast application. A 2035 range of acknowledgment request types is provided for use at the 2036 application’s discretion. Provision for application-defined, 2037 positively-acknowledged commands allows the application to 2038 automatically take advantage of transmission and round-trip timing 2039 information available to the NORM protocol. The details of the NORM 2040 positive acknowledgment process including transmission of the 2041 NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are 2042 described in Section 5.5.3. The format of the NORM_CMD(ACK_REQ) 2043 message is: 2045 0 1 2 3 2046 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 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 |version| type=3| hdr_len | sequence | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | source_id | 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 | instance_id | grtt |backoff| gsize | 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 | flavor = 6 | reserved | ack_type | ack_id | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 | acking_node_list | 2057 | ... | 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 NORM_CMD(ACK_REQ) Message Format 2062 The NORM common message header and standard NORM_CMD fields serve 2063 their usual purposes. The value of the "hdr_len" field for 2064 NORM_CMD(ACK_REQ) messages with no header extension present is 4. 2066 The "ack_type" field indicates the type of acknowledgment being 2067 requested and thus implies rules for how the receiver will treat this 2068 request. The following "ack_type" values are defined and are also 2069 used in NORM_ACK messages described later: 2071 +---------------------+--------+----------------------------------+ 2072 | ACK Type | Value | Purpose | 2073 +---------------------+--------+----------------------------------+ 2074 |NORM_ACK_CC | 1 | Used to identify NORM_ACK | 2075 | | | messages sent in response to | 2076 | | | NORM_CMD(CC) messages. | 2077 +---------------------+--------+----------------------------------+ 2078 |NORM_ACK_FLUSH | 2 | Used to identify NORM_ACK | 2079 | | | messages sent in response to | 2080 | | | NORM_CMD(FLUSH) messages. | 2081 +---------------------+--------+----------------------------------+ 2082 |NORM_ACK_RESERVED | 3-15 | Reserved for possible future | 2083 | | | NORM protocol use. | 2084 +---------------------+--------+----------------------------------+ 2085 |NORM_ACK_APPLICATION | 16-255 | Used at application’s | 2086 | | | discretion. | 2087 +---------------------+--------+----------------------------------+ 2089 The NORM_ACK_CC value is provided for use only in NORM_ACKs generated 2090 in response to the NORM_CMD(CC) messages used in congestion control 2091 operation. Similarly, the NORM_ACK_FLUSH is provided for use only in 2092 NORM_ACKs generated in response to applicable NORM_CMD(FLUSH) 2093 messages. NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC 2094 or NORM_ACK_FLUSH SHALL NOT be generated by the sender. 2096 The NORM_ACK_RESERVED range of "ack_type" values is provided for 2097 possible future NORM protocol use. 2099 The NORM_ACK_APPLICATION range of "ack_type" values is provided so 2100 that NORM applications may implement application-defined, positively- 2101 acknowledged commands that are able to leverage internal transmission 2102 and round-trip timing information available to the NORM protocol 2103 implementation. 2105 The "ack_id" provides a sequenced identifier for the given 2106 NORM_CMD(ACK_REQ) message. This "ack_id" is returned in NORM_ACK 2107 messages generated by the receivers so that the sender may associate 2108 the response with its corresponding request. 2110 The "reserved" field is reserved for possible future protocol use and 2111 SHALL be set to ZERO by senders and ignored by receivers. 2113 The "acking_node_list" field contains the NormNodeIds of the current 2114 NORM receivers that are desired to provide positive acknowledge 2115 (NORM_ACK) to this request. The packet payload length implies the 2116 length of the "acking_node_list" and its length is limited to the 2117 sender NormSegmentSize. The individual NormNodeId items are listed 2118 in network (Big Endian) byte order. If a receiver’s NormNodeId is 2119 included in the "acking_node_list", it SHALL schedule transmission of 2120 a NORM_ACK message as described in Section 5.5.3. 2122 4.2.3.7. NORM_CMD(APPLICATION) Message 2124 This command allows the NORM application to robustly transmit 2125 application-defined commands. The command message preempts any 2126 ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR 2127 times at a rate of once per 2*GRTT. This rate of repetition allows 2128 the application to observe any response (if that is the application’s 2129 purpose for the command) before it is repeated. Possible responses 2130 may include initiation of data transmission, other 2131 NORM_CMD(APPLICATION) messages, or even application-defined, 2132 positively-acknowledge commands from other NormSession participants. 2133 The transmission of these commands will preempt data transmission 2134 when they are scheduled and may be multiplexed with ongoing data 2135 transmission. This type of robustly transmitted command allows NORM 2136 applications to define a complete set of session control mechanisms 2137 with less state than the transfer of FEC encoded reliable content 2138 requires while taking advantage of NORM transmission and round-trip 2139 timing information. 2141 0 1 2 3 2142 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 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 |version| type=3| hdr_len | sequence | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | source_id | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | instance_id | grtt |backoff| gsize | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | flavor = 7 | reserved | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Application-Defined Content | 2153 | ... | 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 NORM_CMD(APPLICATION) Message Format 2158 The NORM common message header and NORM_CMD fields are interpreted as 2159 previously described. The value of the NORM_CMD(APPLICATION) 2160 "hdr_len" field when no header extensions are present is 4. 2162 The "Application-Defined Content" area contains information in a 2163 format at the discretion of the application. The size of this 2164 payload SHALL be limited to a maximum of the sender’s NormSegmentSize 2165 setting. 2167 4.3. Receiver Messages 2169 The NORM message types generated by participating receivers consist 2170 of NORM_NACK and NORM_ACK message types. NORM_NACK messages are sent 2171 to request repair of missing data content from sender transmission 2172 and NORM_ACK messages are generated in response to certain sender 2173 commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ). 2175 4.3.1. NORM_NACK Message 2177 The principal purpose of NORM_NACK messages is for receivers to 2178 request repair of sender content via selective, negative 2179 acknowledgment upon detection of incomplete data. NORM_NACK messages 2180 will be transmitted according to the rules of NORM_NACK generation 2181 and suppression described in Section 5.3. NORM_NACK messages also 2182 contain additional fields to provide feedback to the sender(s) for 2183 purposes of round-trip timing collection and congestion control. 2185 The payload of NORM_NACK messages contains one or more repair 2186 requests for different objects or portions of those objects. The 2187 NORM_NACK message format is as follows: 2189 0 1 2 3 2190 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 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 |version| type=4| hdr_len | sequence | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | source_id | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | server_id | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | instance_id | reserved | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 | grtt_response_sec | 2201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2202 | grtt_response_usec | 2203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2204 | header extensions (if applicable) | 2205 | ... | 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | nack_payload | 2208 | ... | 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 NORM_NACK Message Format 2213 The NORM common message header fields serve their usual purposes. 2214 The value of the "hdr_len" field for NORM_NACK messages without 2215 header extensions present is 6. 2217 The "server_id" field identifies the NORM sender to which the 2218 NORM_NACK message is destined. 2220 The "instance_id" field contains the current session identifier given 2221 by the sender identified by the "server_id" field in its sender 2222 messages. The sender SHOULD ignore feedback messages which contain 2223 an invalid "instance_id" value. 2225 The "grtt_response" fields contain an adjusted version of the 2226 timestamp from the most recently received NORM_CMD(CC) message for 2227 the indicated NORM sender. The format of the "grtt_response" is the 2228 same as the "send_time" field of the NORM_CMD(CC). The 2229 "grtt_response" value is _relative_ to the "send_time" the source 2230 provided with a corresponding NORM_CMD(CC) command. The receiver 2231 adjusts the source’s NORM_CMD(CC) "send_time" timestamp by adding the 2232 time delta from when the receiver received the NORM_CMD(CC) to when 2233 the NORM_NACK is transmitted in response to calculate the value in 2234 the "grtt_response" field. This is the "receive_to_response_delta" 2235 value used in the following formula: 2237 grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta 2239 The receiver SHALL set the "grtt_response" to a ZERO value, to 2240 indicate that it has not yet received a NORM_CMD(CC) message from the 2241 indicated sender and that the sender should ignore the 2242 "grtt_response" in this message. 2244 For NORM-CC operation, the NORM-CC Feedback Header Extension, as 2245 described in the NORM_CMD(REPAIR_ADV} message description, is added 2246 to NORM_NACK messages to provide feedback on the receivers current 2247 state with respect to congestion control operation. Note that 2248 alternative header extensions for congestion control feedback may be 2249 defined for alternative congestion control schemes for NORM use in 2250 the future. 2252 The "reserved" field is for potential future NORM use and SHALL be 2253 set to ZERO for this version of the protocol. 2255 The "nack_content" of the NORM_NACK message specifies the repair 2256 needs of the receiver with respect to the NORM sender indicated by 2257 the "server_id" field. The receiver constructs repair requests based 2258 on the NORM_DATA and/or NORM_INFO segments it requires from the 2259 sender in order to complete reliable reception up to the sender’s 2260 transmission position at the moment the receiver initiates the NACK 2261 Procedure as described in Section 5.3. A single NORM Repair Request 2262 consists of a list of items, ranges, and/or FEC coding block erasure 2263 counts for needed NORM_DATA and/or NORM_INFO content. Multiple 2264 repair requests may be concatenated within the "nack_payload" field 2265 of a NORM_NACK message. Note that a single NORM Repair Request can 2266 possibly include multiple "items", "ranges", or "erasure_counts". In 2267 turn, the "nack_payload" field may contain multiple repair requests. 2268 A single NORM Repair Request has the following format: 2270 0 1 2 3 2271 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 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | form | flags | length | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | repair_request_items | 2276 | ... | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 NORM Repair Request Format 2281 The "form" field indicates the type of repair request items given in 2282 the "repair_request_items" list. Possible values for the "form" 2283 field include: 2285 Form Value 2286 NORM_NACK_ITEMS 1 2287 NORM_NACK_RANGES 2 2288 NORM_NACK_ERASURES 3 2290 A "form" value of NORM_NACK_ITEMS indicates each repair request item 2291 in the "repair_request_items" list is to be treated as an individual 2292 request. A value of NORM_NACK_RANGES indicates that the 2293 "repair_request_items" list consists of pairs of repair request items 2294 that correspond to inclusive ranges of repair needs. And the 2295 NORM_NACK_ERASURES "form" indicates that the repair request items are 2296 to be treated individually and that the "encoding_symbol_id" portion 2297 of the "fec_payload_id" field of the repair request item (see below) 2298 is to be interpreted as an "erasure count" for the FEC coding block 2299 identified by the repair request item’s "source_block_number". 2301 The "flags" field is currently used to indicate the level of data 2302 content for which the repair request items apply (i.e., an individual 2303 segment, entire FEC coding block, or entire transport object). 2304 Possible flag values include: 2306 +------------------+-------+------------------------------------------+ 2307 | Flag | Value | Purpose | 2308 +------------------+-------+------------------------------------------+ 2309 |NORM_NACK_SEGMENT | 0x01 | Indicates the listed segment(s) or range | 2310 | | | of segments are required as repair. | 2311 +------------------+-------+------------------------------------------+ 2312 |NORM_NACK_BLOCK | 0x02 | Indicates the listed block(s) or range | 2313 | | | of blocks in entirety are required as | 2314 | | | repair. | 2315 +------------------+-------+------------------------------------------+ 2316 |NORM_NACK_INFO | 0x04 | Indicates that NORM_INFO is required as | 2317 | | | repair for the listed object(s). | 2318 +------------------+-------+------------------------------------------+ 2319 |NORM_NACK_OBJECT | 0x08 | Indicates the listed object(s) or range | 2320 | | | of objects in entirety are required as | 2321 | | | repair. | 2322 +------------------+-------+------------------------------------------+ 2324 When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and 2325 "fec_payload_id" fields are used to determine which sets or ranges of 2326 individual NORM_DATA segments are needed to repair content at the 2327 receiver. When the NORM_NACK_BLOCK flag is set, this indicates the 2328 receiver is completely missing the indicated coding block(s) and 2329 requires transmissions sufficient to repair the indicated block(s) in 2330 their entirety. When the NORM_NACK_INFO flag is set, this indicates 2331 the receiver is missing the NORM_INFO segment for the indicated 2332 "object_transport_id". Note the NORM_NACK_INFO may be set in 2333 combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or 2334 may be set alone. When the NORM_NACK_OBJECT flag is set, this 2335 indicates the receiver is missing the entire NormTransportObject 2336 referenced by the "object_transport_id". This also implicitly 2337 requests any available NORM_INFO for the NormObject, if applicable. 2338 The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT 2339 is set. 2341 The "length" field value is the length in bytes of the 2342 "repair_request_items" field. 2344 The "repair_request_items" field consists of a list of individual or 2345 range pairs of transport data unit identifiers in the following 2346 format. 2348 0 1 2 3 2349 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 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | fec_id | reserved | object_transport_id | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | fec_payload_id | 2354 | ... | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 NORM Repair Request Item Format 2359 The "fec_id" indicates the FEC type and can be used to determine the 2360 format of the "fec_payload_id" field. The "reserved" field is kept 2361 for possible future use and SHALL be set to a ZERO value and ignored 2362 by NORM nodes processing NACK content. 2364 The "object_transport_id" corresponds to the NormObject for which 2365 repair is being requested and the "fec_payload_id" identifies the 2366 specific FEC coding block and/or segment being requested. When the 2367 NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field 2368 is ignored. When the NORM_NACK_BLOCK flag is set, only the FEC code 2369 block identifier portion of the "fec_payload_id" is to be 2370 interpreted. 2372 The format of the "fec_payload_id" field depends upon the "fec_id" 2373 field value. 2375 When the receiver’s repair needs dictate that different forms (mixed 2376 ranges and/or individual items) or types (mixed specific segments 2377 and/or blocks or objects in entirety) are required to complete 2378 reliable transmission, multiple NORM Repair Requests with different 2379 "form" and or "flags" values can be concatenated within a single 2380 NORM_NACK message. Additionally, NORM receivers SHALL construct 2381 NORM_NACK messages with their repair requests in ordinal order with 2382 respect to "object_transport_id" and "fec_payload_id" values. The 2383 "nack_payload" size SHALL NOT exceed the NormSegmentSize for the 2384 sender to which the NORM_NACK is destined. 2386 NORM_NACK Content Examples: 2388 In these examples, a small block, systematic FEC code ("fec_id" = 2389 129) is assumed with a user data block length of 32 segments. In 2390 Example 1, a list of individual NORM_NACK_ITEMS repair requests is 2391 given. In Example 2, a list of NORM_NACK_RANGES requests _and_ a 2392 single NORM_NACK_ITEMS request are concatenated to illustrate the 2393 possible content of a NORM_NACK message. Note that FEC coding block 2394 erasure counts could also be provided in each case. However, the 2395 erasure counts are not really necessary since the sender can easily 2396 determine the erasure count while processing the NACK content. 2397 However, the erasure count option may be useful for operation with 2398 other FEC codes or for intermediate system purposes. 2400 Example 1: NORM_NACK "nack_payload" for: Object 12, Coding Block 3, 2401 Segments 2,5,8 2402 0 1 2 3 2403 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 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | form = 1 | flags = 0x01 | length = 36 | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | fec_id = 129 | reserved | object_transport_id = 12 | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | source_block_number = 3 | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | source_block_length = 32 | encoding_symbol_id = 2 | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | fec_id = 129 | reserved | object_transport_id = 12 | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | source_block_number = 3 | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | source_block_length = 32 | encoding_symbol_id = 5 | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 | fec_id = 129 | reserved | object_transport_id = 12 | 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | source_block_number = 3 | 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | source_block_length = 32 | encoding_symbol_id = 8 | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 Example 2: NORM_NACK "nack_payload" for: Object 18 Coding Block 6, 2426 Segments 5, 6, 7, 8, 9, 10; and Object 19 NORM_INFO and Coding Block 2427 1, segment 3 2428 0 1 2 3 2429 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 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | form = 2 | flags = 0x01 | length = 24 | 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 | fec_id = 129 | reserved | object_transport_id = 18 | 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2435 | source_block_number = 6 | 2436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2437 | source_block_length = 32 | encoding_symbol_id = 5 | 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | fec_id = 129 | reserved | object_transport_id = 18 | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | source_block_number = 6 | 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 | source_block_length = 32 | encoding_symbol_id = 10 | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | form = 1 | flags = 0x05 | length = 12 | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | fec_id = 129 | reserved | object_transport_id = 19 | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | source_block_number = 1 | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | source_block_length = 32 | encoding_symbol_id = 3 | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 4.3.2. NORM_ACK Message 2456 The NORM_ACK message is intended to be used primarily as part of NORM 2457 congestion control operation and round-trip timing measurement. As 2458 mentioned in the NORM_CMD(ACK_REQ) message description, the 2459 acknowledgment type NORM_ACK_CC is provided for this purpose. The 2460 generation of NORM_ACK(CC) messages for round-trip timing estimation 2461 and congestion-control operation is described in Sections 5.5.1 and 2462 5.5.2, respectively. However, some multicast applications may 2463 benefit from some limited form of positive acknowledgment for certain 2464 functions. A simple, scalable positive acknowledgment scheme is 2465 defined in Section 5.5.3 that can be leveraged by protocol 2466 implementations when appropriate. The NORM_CMD(FLUSH) may be used 2467 for OPTIONAL collection of positive acknowledgment of reliable 2468 reception to a certain "watermark" transmission point from specific 2469 receivers using this mechanism. The NORM_ACK type NORM_ACK_FLUSH is 2470 provided for this purpose and the format of the "nack_payload" for 2471 this acknowledgment type is given below. Beyond that, a range of 2472 application-defined "ack_type" values is provided for use at the NORM 2473 application’s discretion. Implementations making use of application- 2474 defined positive acknowledgments may also make use the "nack_payload" 2475 as needed, observing the constraint that the "nack_payload" field 2476 size be limited to a maximum of the NormSegmentSize for the sender to 2477 which the NORM_ACK is destined. 2479 0 1 2 3 2480 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 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 |version| type=5| hdr_len | sequence | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | source_id | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2486 | server_id | 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | instance_id | ack_type | ack_id | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | grtt_response_sec | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | grtt_response_usec | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | header extensions (if applicable) | 2495 | ... | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 | ack_payload (if applicable) | 2498 | ... | 2499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 NORM_ACK Message Format 2503 The NORM common message header fields serve their usual purposes. 2504 The value of the "hdr_len" field when no header extensions are 2505 present is 6. 2507 The "server_id", "instance_id", and "grtt_response" fields serve the 2508 same purpose as the corresponding fields in NORM_NACK messages. And 2509 header extensions may be applied to support congestion control 2510 feedback or other functions in the same manner. 2512 The "ack_type" field indicates the nature of the NORM_ACK message. 2513 This directly corresponds to the "ack_type" field of the 2514 NORM_CMD(ACK_REQ) message to which this acknowledgment applies. 2516 The "ack_id" field serves as a sequence number so that the sender can 2517 verify that a NORM_ACK message received actually applies to a current 2518 acknowledgment request. The "ack_id" field is not used in the case 2519 of the NORM_ACK_CC and NORM_ACK_FLUSH acknowledgment types. 2521 The "ack_payload" format is a function of the "ack_type". The 2522 NORM_ACK_CC message has no attached content. Only the NORM_ACK 2523 header applies. In the case of NORM_ACK_FLUSH, a specific 2524 "ack_payload" format is defined: 2526 0 1 2 3 2527 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 2528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2529 | fec_id | reserved | object_transport_id | 2530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 | fec_payload_id | 2532 | ... | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 NORM_ACK_FLUSH "ack_payload" Format 2537 The "object_transport_id" and "fec_payload_id" are used by the 2538 receiver to acknowledge applicable NORM_CMD(FLUSH) messages 2539 transmitted by the sender identified by the "server_id" field. 2541 The "ack_payload" of NORM_ACK messages for application-defined 2542 "ack_type" values is specific to the application but is limited in 2543 size to a maximum the NormSegmentSize of the sender referenced by the 2544 "server_id". 2546 4.4. General Purpose Messages 2548 Some additional message formats are defined for general purpose in 2549 NORM multicast sessions whether the participant is acting as a sender 2550 and/or receiver within the group. 2552 4.4.1. NORM_REPORT Message 2554 This is an optional message generated by NORM participants. This 2555 message could be used for periodic performance reports from receivers 2556 in experimental NORM implementations. The format of this message is 2557 currently undefined. Experimental NORM implementations may define 2558 NORM_REPORT formats as needed for test purposes. These report 2559 messages SHOULD be disabled for interoperability testing between 2560 different NORM implementations. 2562 5. Detailed Protocol Operation 2564 This section describes the detailed interactions of senders and 2565 receivers participating in a NORM session. A simple synopsis of 2566 protocol operation is given here: 2568 1) The sender periodically transmits NORM_CMD(CC) messages as 2569 needed to initialize and collect roundtrip timing and 2570 congestion control feedback from the receiver set. 2572 2) The sender transmits an ordinal set of NormObjects segmented 2573 in the form of NORM_DATA messages labeled with 2574 NormTransportIds and logically identified with FEC encoding 2575 block numbers and symbol identifiers. NORM_INFO messages 2576 may optionally precede the transmission of data content for 2577 NORM transport objects. 2579 3) As receivers detect missing content from the sender, they 2580 initiate repair requests with NORM_NACK messages. Note the 2581 receivers track the sender’s most recent 2582 objectId::fecPayloadId transmit position and NACK _only_ for 2583 content ordinally prior to that transmit position. The 2584 receivers schedule random backoff timeouts before generating 2585 NORM_NACK messages and wait an appropriate amount of time 2586 before repeating the NORM_NACK if their repair request is 2587 not satisfied. 2589 4) The sender aggregates repair requests from the receivers and 2590 logically "rewinds" its transmit position to send 2591 appropriate repair messages. The sender sends repairs for 2592 the earliest ordinal transmit position first and maintains 2593 this ordinal repair transmission sequence. Previously 2594 untransmitted FEC parity content for the applicable FEC 2595 coding block is used for repair transmissions to the 2596 greatest extent possible. If the sender exhausts its 2597 available FEC parity content on multiple repair cycles for 2598 the same coding block, it resorts to an explicit repair 2599 strategy (possibly using parity content) to complete 2600 repairs. (The use of explicit repair is expected to be an 2601 exception in general protocol operation, but the possibility 2602 does exist for extreme conditions). The sender immediately 2603 assumes transmission of new content once it has sent pending 2604 repairs. 2606 5) The sender transmits NORM_CMD(FLUSH) messages when it 2607 reaches the end of enqueued transmit content and pending 2608 repairs. Receivers respond to the NORM_CMD(FLUSH) messages 2609 with NORM_NACK transmissions (following the same suppression 2610 backoff timeout strategy as for data) if they require 2611 further repair. 2613 6) The sender transmissions are subject to rate control limits 2614 determined by congestion control mechanisms. In the 2615 baseline NORM-CC operation, each sender in a NormSession 2616 maintains its own independent congestion control state. 2617 Receivers provide congestion control feedback in NORM_NACK 2618 and NORM_ACK messages. NORM_ACK feedback for congestion 2619 control purposes is governed using a suppression mechanism 2620 similar to that for NORM_NACK messages. 2622 While this overall concept is relatively simple, there are details to 2623 each of these aspects that need to be addressed for successful, 2624 efficient, robust, and scalable NORM protocol operation. 2626 5.1. Sender Initialization and Transmission 2628 Upon startup, the NORM sender immediately begins sending NORM_CMD(CC) 2629 messages to collect round trip timing and other information from the 2630 potential group. If NORM-CC congestion control operation is enabled, 2631 the NORM-CC Rate header extension MUST be included in these messages. 2632 Congestion control operation SHALL be observed at all times when 2633 operating in the general Internet. Even if congestion control 2634 operation is disabled at the sender, it may be desirable to use the 2635 NORM_CMD(CC) messaging to collect feedback from the group using the 2636 baseline NORM-CC feedback mechanisms. This proactive feedback 2637 collection can be used to establish a GRTT estimate prior to data 2638 transmission and potential NACK operation. 2640 In some cases, applications may wish for the sender to also proceed 2641 with data transmission immediately. In other cases, the sender may 2642 wish to defer data transmission until it has received some feedback 2643 or request from the receiver set indicating that receivers are indeed 2644 present. Note, in some applications (e.g., web push), this 2645 indication may come out-of-band with respect to the multicast session 2646 via other means. As noted, the periodic transmission of NORM_CMD(CC) 2647 messages may precede actual data transmission in order to have an 2648 initial GRTT estimate. 2650 With inclusion of the OPTIONAL NORM FEC Object Transmission 2651 Information Header Extension (EXT_FTI), the NORM protocol sender 2652 message headers can contain all information necessary to prepare 2653 receivers for subsequent reliable reception. This includes FEC 2654 coding parameters, the sender NormSegmentSize, and other information. 2655 If this header extension is not used, it is presumed that receivers 2656 have received the FEC Object Transmission Information via other 2657 means. Additionally, applications may leverage the use of NORM_INFO 2658 messages associated with the session data objects in the session to 2659 provide application-specific context information for the session and 2660 data being transmitted. These mechanisms allow for operation with 2661 minimal pre-coordination among the senders and receivers. 2663 The NORM sender begins segmenting application-enqueued data into 2664 NORM_DATA segments and transmitting it to the group. For objects of 2665 type NORM_OBJECT_DATA and NORM_OBJECT_FILE, the segmentation 2666 algorithm described in FEC Building Block document. [4]. is 2667 RECOMMENDED. For objects of type NORM_OBJECT_STREAM, segmentation 2668 will typically be done into uniform FEC coding block sizes, with 2669 individual segment sizes controlled by the application, although in 2670 many cases, the application and NORM implementation should strive to 2671 produce full-sized (NormSegmentSize) segments when possible. The 2672 rate of transmission is controlled via congestion control mechanisms 2673 or is a fixed rate if desired for closed network operations. The 2674 receivers participating in the multicast group provide feedback to 2675 the sender as needed. When the sender reaches the end of data it has 2676 enqueued for transmission or any pending repairs, it transmits a 2677 series of NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT. 2678 Receivers may respond to these NORM_CMD(FLUSH) messages with 2679 additional repair requests. A protocol parameter 2680 "NORM_ROBUST_FACTOR" determines the number of flush messages sent. 2681 If receivers request repair, the repair is provided and flushing 2682 occurs again at the end of repair transmission. The sender may 2683 attach an OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing 2684 the NormNodeIds for receivers from which it expects explicit positive 2685 acknowledgment of reception. The NORM_CMD(FLUSH) message may be also 2686 used for this optional function any time prior to the end of data 2687 enqueued for transmission with the NORM_CMD(FLUSH) messages 2688 multiplexed with ongoing data transmissions. The OPTIONAL NORM 2689 positive acknowledgment procedure is described in Section 5.5.3. 2691 5.1.1. Object Segmentation Algorithm 2693 NORM senders and receivers MUST use a common algorithm for logically 2694 segmenting transport data into FEC encoding blocks and symbols so 2695 that appropriate NACKs can be constructed to request repair of 2696 missing data. NORM FEC coding blocks are comprised of multi-byte 2697 symbols (segments) that are transmitted in the payload of NORM_DATA 2698 messages. Each NORM_DATA message will contain one or more source or 2699 encoding symbol(s) identified by the "fec_payload_id" field and the 2700 NormSegmentSize sender parameter defines the maximum size (in bytes) 2701 of the "payload_data" field containing the content (a "segment"). 2702 The FEC encoding type and associated parameters govern the source 2703 block size (number of source symbols per coding block, etc.). NORM 2704 senders and receivers use these FEC parameters, along with the 2705 NormSegmentSize and transport object size to compute the source block 2706 structure for transport objects. These parameters are provided in 2707 the FEC Object Transmission Information for each object. The block 2708 partioning algorithm described in the FEC Building Block document [4] 2709 is RECOMMENDED for use to compute a source block structure such that 2710 all source blocks are as close to being equal length as possible. 2711 This helps avoid the performance disadvantages of "short" FEC blocks. 2712 Note this algorithm applies only to the statically-sized 2713 NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where 2714 the object size is fixed and predetermined. For NORM_OBJECT_STREAM 2715 objects, the object is segmented according to the maximum source 2716 block length given in the FEC Transmission Information, unless the 2717 FEC Payload ID indicates an alternative size for a given block. 2719 5.2. Receiver Initialization and Reception 2721 The NORM protocol is designed such that receivers may join and leave 2722 the group at will. However, some applications may be constrained 2723 such that receivers need to be members of the group prior to start of 2724 data transmission. NORM applications may use different policies to 2725 constrain the impact of new receivers joining the group in the middle 2726 of a session. For example, a useful implementation policy is for new 2727 receivers joining the group to limit or avoid repair requests for 2728 transport objects already in progress. The NORM sender 2729 implementation may wish to impose additional constraints to limit the 2730 ability of receivers to disrupt reliable multicast performance by 2731 joining, leaving, and rejoining the group often. Different receiver 2732 "join policies" may be appropriate for different applications and/or 2733 scenarios. For general purpose operation, a default policy where 2734 receivers are allowed to request repair only for coding blocks with a 2735 NormTransportId and FEC coding block number greater than or equal to 2736 the first non-repair NORM_DATA or NORM_INFO message received upon 2737 joining the group is RECOMMENDED. For objects of type 2738 NORM_OBJECT_STREAM it is RECOMMENDED that the join policy constrain 2739 receivers to start reliable reception at the current FEC coding block 2740 for which non-repair content is received. 2742 For typical operation, it is expected that NORM receivers will join a 2743 specified multicast group and/or listen on an specific port number 2744 for sender transmissions. As the NORM receiver receives NORM_DATA 2745 messages it will provide content to its application as appropriate. 2747 5.3. Receiver NACK Procedure 2749 When the receiver detects it is missing data from a sender’s NORM 2750 transmissions, it initiates its NACKing procedure. The NACKing 2751 procedure SHALL be initiated _only_ at FEC coding block boundaries, 2752 NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or 2753 upon an "inactivity" timeout when NORM_DATA or NORM_INFO 2754 transmissions are no longer received from a previously active sender. 2755 The RECOMMENDED value of such an inactivity timeout is: 2756 T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTTSender 2758 where the "GRTTsender" value corresponds to the GRTT estimate 2759 advertised in the "grtt" field of NORM sender messages. A minimum 2760 "T_inactivity" value of 1 second is RECOMMENDED. The NORM receiver 2761 SHOULD reset this inactivity timer and repeat NACK initiation upon 2762 timeout for up to NORM_ROBUST_FACTOR times or more depending upon the 2763 application’s need for persistence by its receivers. It is also 2764 important that receivers rescale the "T_inactivity" timeout as the 2765 sender’s advertised GRTT changes. 2767 The NACKing procedure begins with a random backoff timeout. The 2768 duration of the backoff timeout is chosen using the "RandomBackoff" 2769 algorithm described in the NORM Building Block document [3] using 2770 (Ksender*GRTTsender) for the "maxTime" parameter and the sender 2771 advertised group size (GSIZEsender) as the "groupSize" parameter. 2772 NORM senders provide values for GRTTsender, Ksender and GSIZEsender 2773 via the "grtt", "backoff", and "gsize" fields of transmitted 2774 messages. The GRTTsender value is determined by the sender based on 2775 feedback it has received from the group while the Ksender and 2776 GSIZEsender values may determined by application requirements and 2777 expectations or ancillary information. The backoff factor "Ksender" 2778 MUST be greater than one to provide for effective feedback 2779 suppression. A value of K = 4 is RECOMMENDED for the Any Source 2780 Multicast (ASM) model while a value of K = 6 is RECOMMENDED for 2781 Single Source Multicast (SSM) operation. 2783 Thus: 2785 T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender) 2787 To avoid the possibility of NACK implosion in the case of sender or 2788 network failure during SSM operation, the receiver SHALL 2789 automatically suppress its NACK and immediately enter the "holdoff" 2790 period described below when T_backoff is greater than 2791 (Ksender-1)*GRTTsender. Otherwise, the backoff period is entered and 2792 the receiver MUST accumulate external pending repair state from 2793 NORM_NACK messages and NORM_CMD(REPAIR_ADV) messages received. At 2794 the end of the backoff time, the receiver SHALL generate a NORM_NACK 2795 message only if the following conditions are met: 2797 1) The sender’s current transmit position (in terms of 2798 objectId::fecPayloadId) exceeds the earliest repair position 2799 of the receiver. 2801 2) The repair state accumulated from NORM_NACK and 2802 NORM_CMD(REPAIR_ADV) messages do not equal or supersede the 2803 receiver’s repair needs up to the sender transmission 2804 position at the time the NACK procedure (backoff timeout) 2805 was initiated. 2807 If these conditions are met, the receiver immediately generates a 2808 NORM_NACK message when the backoff timeout expires. Otherwise, the 2809 receiver’s NACK is considered to be "suppressed" and the message is 2810 not sent. At this time, the receiver begins a "holdoff" period 2811 during which it constrains itself to not reinitiate the NACKing 2812 process. The purpose of this timeout is to allow the sender worst- 2813 case time to respond to the repair needs before the receiver requests 2814 repair again. The value of this "holdoff" timeout (T_rcvrHoldoff) 2815 as described in [3] is: 2817 T_rcvrHoldoff =(Ksender+2)*GRTTsender 2819 The NORM_NACK message contains repair request content beginning with 2820 lowest ordinal repair position of the receiver up through the coding 2821 block prior to the most recently heard ordinal transmission position 2822 for the sender. If the size of the NORM_NACK content exceeds the 2823 sender’s NormSegmentSize, the NACK content is truncated so that the 2824 receiver only generates a single NORM_NACK message per NACK cycle for 2825 a given sender. In summary, a single NACK message is generated 2826 containing the receiver’s lowest ordinal repair needs. 2828 For each partially-received FEC coding block requiring repair, the 2829 receiver SHALL, on its _first_ repair attempt for the block, request 2830 the parity portion of the FEC coding block beginning with the lowest 2831 ordinal _parity_ "encoding_symbol_id" (i.e., "encoding_symbol_id" = 2832 "source_block_len") and request the number of FEC symbols 2833 corresponding to its data segment erasure count for the block. On 2834 _subsequent_ repair cycles for the same coding block, the receiver 2835 SHALL request only those repair symbols from the first set it has not 2836 yet received up to the remaining erasure count for that applicable 2837 coding block. Note that the sender may have provided other 2838 different, additional parity segments for other receivers that could 2839 also be used to satisfy the local receiver’s erasure-filling needs. 2840 In the case where the erasure count for a partially-received FEC 2841 coding block exceeds the maximum number of parity symbols available 2842 from the sender for the block (as indicated by the NORM_DATA 2843 "fec_num_parity" field), the receiver SHALL request all available 2844 parity segments plus the ordinally highest missing data segments 2845 required to satisfy its total erasure needs for the block. The goal 2846 of this strategy is for the overall receiver set to request a lowest 2847 common denominator set of repair symbols for a given FEC coding 2848 block. This allows the sender to construct the most efficient repair 2849 transmission segment set and enables effective NACK suppression among 2850 the receivers even with uncorrelated packet loss. This approach also 2851 requires no synchronization among the receiver set in their repair 2852 requests for the sender. 2854 For FEC coding blocks or NormObjects missed in their entirety, the 2855 NORM receiver constructs repair requests with NORM_NACK_BLOCK or 2856 NORM_NACK_OBJECT flags set as appropriate. The request for 2857 retransmission of NORM_INFO is accomplished by setting the 2858 NORM_NACK_INFO flag in a corresponding repair request. 2860 5.4. Sender NACK Processing and Response 2862 The principle goal of the sender is to make forward progress in the 2863 transmission of data its application has enqueued. However, the 2864 sender must occasionally "rewind" its logical transmission point to 2865 satisfy the repair needs of receivers who have NACKed. Aggregation 2866 of multiple NACKs is used to determine an optimal repair strategy 2867 when a NACK event occurs. Since receivers initiate the NACK process 2868 on coding block or object boundaries, there is some loose degree of 2869 synchronization of the repair process even when receivers experience 2870 uncorrelated data loss. 2872 5.4.1. Sender Repair State Aggregation 2874 When a sender is in its normal state of transmitting new data and 2875 receives a NACK, it begins a procedure to accumulate NACK repair 2876 state from NORM_NACK messages before beginning repair transmissions. 2877 Note that this period of aggregating repair state does _not_ 2878 interfere with its ongoing transmission of new data. 2880 As described in [3], the period of time during which the sender 2881 aggregates NORM_NACK messages is equal to: 2883 T_sndrAggregate = (Ksender+1)*GRTT 2885 where "Ksender" is the same backoff scaling value used by the 2886 receivers, and "GRTT" is the sender’s current estimate of the group’s 2887 greatest round-trip time. Note that for NORM unicast sessions the 2888 "T_sndrAggregate" time can be set to ZERO since there is only one 2889 receiver. Similarly, the "Ksender" value should be set to ZERO for 2890 NORM unicast sessions to minimize repair latency. 2892 When this period ends, the sender "rewinds" by incorporating the 2893 accumulated repair state into its pending transmission state and 2894 begins transmitting repair messages. After pending repair 2895 transmissions are completed, the sender continues with new 2896 transmissions of any enqueued data. Also, at this point in time, the 2897 sender begins a "holdoff" timeout during which time the sender 2898 constrains itself from initiating a new repair aggregation cycle, 2899 even if NORM_NACK messages arrive. As described in [3], the value of 2900 this sender "holdoff" period is: 2902 T_sndrHoldoff = (1*GRTT) 2904 If additional NORM_NACK messages are received during this sender 2905 "holdoff" period, the sender will immediately incorporate these "late 2906 messages" into its pending transmission state ONLY if the NACK 2907 content is ordinally greater than the sender’s current transmission 2908 position. This "holdoff" time allows worst case time for the sender 2909 to propagate its current transmission sequence position to the group, 2910 thus avoiding redundant repair transmissions. After the holdoff 2911 timeout expires, a new NACK accumulation period can be begun (upon 2912 arrival of a NACK) in concert with the pending repair and new data 2913 transmission. Recall that receivers are not to initiate the NACK 2914 repair process until the sender’s logical transmission position 2915 exceeds the lowest ordinal position of their repair needs. With the 2916 new NACK aggregation period, the sender repeats the same process of 2917 incorporating accumulated repair state into its transmission plan and 2918 subsequently "rewinding" to transmit the lowest ordinal repair data 2919 when the aggregation period expires. Again, this is conducted in 2920 concert with ongoing new data and/or pending repair transmissions. 2922 5.4.2. Sender FEC Repair Transmission Strategy 2924 The NORM sender should leverage transmission of FEC parity content 2925 for repair to the greatest extent possible. Recall that the 2926 receivers use a strategy to request a lowest common denominator of 2927 explicit repair (including parity content) in the formation of their 2928 NORM_NACK messages. Before falling back to explicitly satisfying 2929 different receivers’ repair needs, the sender can make use of the 2930 general erasure-filling capability of FEC-generated parity segments. 2931 The sender can determine the maximum erasure filling needs for 2932 individual FEC coding blocks from the NORM_NACK messages received 2933 during the repair aggregation period. Then, if the sender has a 2934 sufficient number (less than or equal to the maximum erasure count) 2935 of previously unsent parity segments available for the applicable 2936 coding blocks, the sender can transmit these in lieu of the specific 2937 packets the receiver set has requested. Only after exhausting its 2938 supply of "fresh" (unsent) parity segments for a given coding block 2939 should the sender resort to explicit transmission of the receiver 2940 set’s repair needs. In general, if a sufficiently powerful FEC code 2941 is used, the need for explicit repair will be an exception, and the 2942 fulfillment of reliable multicast can be accomplished quite 2943 efficiently. However, the ability to resort to explicit repair 2944 allows the protocol to be reliable under even very extreme 2945 circumstances. 2947 NORM_DATA messages sent as repair transmissions SHALL be flagged with 2948 the NORM_FLAG_REPAIR flag. This allows receivers to obey any 2949 policies that limit new receivers from joining the reliable 2950 transmission when only repair transmissions have been received. 2951 Additionally, the sender SHOULD additionally flag NORM_DATA 2952 transmissions sent as explicit repair with the NORM_FLAG_EXPLICIT 2953 flag. 2955 Although NORM end system receivers do not make use of the 2956 NORM_FLAG_EXPLICIT flag, this message transmission status could be 2957 leveraged by intermediate systems wishing to "assist" NORM protocol 2958 performance. If such systems are properly positioned with respect to 2959 reciprocal reverse-path multicast routing, they need to sub-cast only 2960 a sufficient count of non-explicit parity repairs to satisfy a 2961 multicast routing sub-tree’s erasure filling needs for a given FEC 2962 coding block. When the sender has resorted to explicit repair, then 2963 the intermediate systems should sub-cast all of the explicit repair 2964 packets to those portions of the routing tree still requiring repair 2965 for a given coding block. Note the intermediate systems will be 2966 required to conduct repair state accumulation for sub-routes in a 2967 manner similar to the sender’s repair state accumulation in order to 2968 have sufficient information to perform the sub-casting. 2969 Additionally, the intermediate systems could perform additional 2970 NORM_NACK suppression/aggregation as it conducts this repair state 2971 accumulation for NORM repair cycles. The detail of this type of 2972 operation are beyond the scope of this document, but this information 2973 is provided for possible future consideration. 2975 5.4.3. Sender NORM_CMD(SQUELCH) Generation 2977 If the sender receives a NORM_NACK message for repair of data it is 2978 no longer supporting, the sender generates a NORM_CMD(SQUELCH) 2979 message to advertise its repair window and squelch any receivers from 2980 additional NACKing of invalid data. The transmission rate of 2981 NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT. The 2982 "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH) 2983 message SHALL begin with the lowest "object_transport_id" from the 2984 invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH) 2985 transmission. Lower ordinal invalid "object_transport_ids" should be 2986 included only while the NORM_CMD(SQUELCH) payload is less than the 2987 sender’s NormSegmentSize parameter. 2989 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation 2991 When a NORM sender receives NORM_NACK messages from receivers via 2992 unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to 2993 advertise its accumulated repair state to the receiver set since the 2994 receiver set is not directly sharing their repair needs via multicast 2995 communication. A NORM sender implementation MAY use a separate port 2996 number from the NormSession port number as the source port for its 2997 transmissions. Thus NORM receivers can direct any _unicast_ feedback 2998 messages to this sender port number that is distinct from the 2999 "session" port number. Then, the NORM sender implementation can 3000 discriminate unicast feedback messages from multicast feedback 3001 messages when there is a mix of multicast and unicast feedback 3002 receivers. The NORM_CMD(REPAIR_ADV) message is multicast to the 3003 receiver set by the sender. The payload portion of this message has 3004 content in the same format as the NORM_NACK receiver message payload. 3005 Receivers are then able to perform feedback suppression in the same 3006 manner as with NORM_NACK messages directly received from other 3007 receivers. Note the sender does not merely retransmit NACK content 3008 it receives, but instead transmits a representation of its aggregated 3009 repair state. The transmission of NORM_CMD(REPAIR_ADV) messages are 3010 subject to the sender transmit rate limit and NormSegmentSize 3011 limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum 3012 size, receivers SHALL consider the maximum ordinal transmission 3013 position value embedded in the message as the senders "current" 3014 transmission position and implicitly suppress requests for ordinally 3015 higher repair. For congestion control operation, the sender may also 3016 need to provide information so that dynamic congestion control 3017 feedback can be suppressed as needed among receivers. This document 3018 specifies the NORM-CC Feedback Header Extension that is applied for 3019 baseline NORM-CC operation. If other congestion control mechanisms 3020 are used within a NORM implementation, other header extensions may be 3021 defined. Whatever content format is used for this purpose should 3022 ensure that maximum possible suppression state is conveyed to the 3023 receiver set. 3025 5.5. Additional Protocol Mechanisms 3027 In addition to the principal function of data content transmission 3028 and repair, there are some other protocol mechanisms that help NORM 3029 to adapt to network conditions and play fairly with other coexistent 3030 protocols. 3032 5.5.1. Greatest Round-trip Time Collection 3034 For NORM receivers to appropriately scale backoff timeouts and the 3035 senders to use proper corresponding timeouts, the participants must 3036 agree on a common timeout basis. Each NORM sender monitors the 3037 round-trip time of active receivers and determines the group greatest 3038 round-trip time (GRTT). The sender advertises this GRTT estimate in 3039 every message it transmits so that receivers have this value 3040 available for scaling their timers. To measure the current GRTT, the 3041 sender periodically sends NORM_CMD(CC) messages that contain a 3042 locally generated timestamp. Receivers are expected to record this 3043 timestamp along with the time the NORM_CMD(CC) message is received. 3044 Then, when the receivers generate feedback messages to the sender, an 3045 adjusted version of the sender timestamp is embedded in the feedback 3046 message (NORM_NACK or NORM_ACK). The adjustment adds the amount of 3047 time the receiver held the timestamp before generating its response. 3048 Upon receipt of this adjusted timestamp, the sender is able to 3049 calculate the round-trip time to that receiver. 3051 The round-trip time for each receiver is fed into an algorithm that 3052 weights and smoothes the values for a conservative estimate of the 3053 GRTT. The algorithm and methodology are described in the NORM 3054 Building Block document [3] in the section entitled "One-to-Many 3055 Sender GRTT Measurement". A conservative estimate helps feedback 3056 suppression at a small cost in overall protocol repair delay. The 3057 sender’s current estimate of GRTT is advertised in the "grtt" field 3058 found in all NORM sender messages. The advertised GRTT is also 3059 limited to a minimum of the nominal inter-packet transmission time 3060 given the sender’s current transmission rate and system clock 3061 granularity. The reason for this additional limit is to keep the 3062 receiver somewhat "event driven" by making sure the sender has had 3063 adequate time to generate any response to repair requests from 3064 receivers given transmit rate limitations due to congestion control 3065 or configuration. 3067 When the NORM-CC Rate header extension is present in NORM_CMD(CC) 3068 messages, the receivers respond to NORM_CMD(CC) messages as described 3069 in Section 5.5.2, "NORM Congestion Control Operation". The 3070 NORM_CMD(CC) messages are periodically generated by the sender as 3071 described for congestion control operation. This provides for 3072 proactive, but controlled, feedback from the group in the form of 3073 NORM_ACK messages. This provides for GRTT feedback even if no 3074 NORM_NACK messages are being sent. If operating without congestion 3075 control in a closed network, the NORM_CMD(CC) messages may be sent 3076 periodically without the NORM-CC Rate header extension. In this 3077 case, receivers will only provide GRTT measurement feedback when 3078 NORM_NACK messages are generated since no NORM_ACK messages are 3079 generated. In this case, the NORM_CMD(CC) messages may be sent less 3080 frequently, perhaps as little as once per minute, to conserve network 3081 capacity. Note that the NORM-CC Rate header extension may also be 3082 used proactively solicit RTT feedback from the receiver group per 3083 congestion control operation even though the sender may not be 3084 conducting congestion control rate adjustment. NORM operation 3085 without congestion control should be considered only in closed 3086 networks. 3088 5.5.2. NORM Congestion Control Operation 3090 This section describes baseline congestion control operation for the 3091 NORM protocol (NORM-CC). The supporting NORM message formats and 3092 approach described here are an adaptation of the equation-based TCP- 3093 Friendly Multicast Congestion Control (TFMCC) approach described in 3094 [5]. This congestion control scheme is REQUIRED for operation within 3095 the general Internet unless the NORM implementation is adapted to use 3096 another IETF-sanctioned reliable multicast congestion control 3097 mechanism (e.g., PGMCC [26]). With this TFMCC-based approach, the 3098 transmissions of NORM senders are controlled in a rate-based manner 3099 as opposed to window-based congestion control algorithms as in TCP. 3100 However, it is possible that the NORM protocol message set may 3101 alternatively be used to support a window-based multicast congestion 3102 control scheme such as PGMCC. The details of that alternative may be 3103 described separately or in a future revision of this document. In 3104 either case (rate-based TFMCC or window-based PGMCC), successful 3105 control of sender transmission depends upon collection of sender-to- 3106 receiver packet loss estimates and RTTs to identify the congestion 3107 control bottleneck path(s) within the multicast topology and adjust 3108 the sender rate accordingly. The receiver with loss and RTT 3109 estimates that correspond to the lowest resulting calculated 3110 transmission rate is identified as the "current limiting receiver" 3111 (CLR). In the case of a "tie" (where candidate CLRs are within 10% 3112 of the same calculated rate), the receiver with the largest RTT value 3113 SHOULD be designated as the CLR. 3115 As described in [27], a steady-state sender transmission rate, to be 3116 "friendly" with competing TCP flows can be calculated as: 3118 S 3119 Rsender = -------------------------------------------------------------- 3120 tRTT*(sqrt((2/3)*p) + 12 * sqrt((3/8)*p) * p * (1 + 32*(p^2))) 3122 where 3124 S = Nominal transmitted packet size. (In NORM, the "nominal" 3125 packet size can be determined by the sender as an 3126 exponentially weighted moving average (EWMA) of transmitted 3127 packet sizes to account for variable message sizes). 3129 tRTT = The RTT estimate of the current "current limiting receiver" 3130 (CLR). 3132 p = The loss event fraction of the CLR. 3134 To support congestion control feedback collection and operation, the 3135 NORM sender periodically transmits NORM_CMD(CC) command messages. 3136 NORM_CMD(CC) messages are multiplexed with NORM data and repair 3137 transmissions and serve several purposes: 3139 1) Stimulate explicit feedback from the general receiver set to 3140 collect congestion control information. 3142 2) Communicate state to the receiver set on the sender’s 3143 current congestion control status including details of the 3144 CLR. 3146 3) Initiate rapid (immediate) feedback from the CLR in order to 3147 closely track the dynamics of congestion control for that 3148 current "worst path" in the group multicast topology. 3150 The format of the NORM_CMD(CC) message is describe in Section 4.2.3 3151 of this document. The NORM_CMD(CC) message contains information to 3152 allow measurement of RTTs, to inform the group of the congestion 3153 control CLR, and to provide feedback of individual RTT measurements 3154 to the receivers in the group. The NORM_CMD(CC) also provides for 3155 exciting feedback from OPTIONAL "potential limiting receiver" (PLR) 3156 nodes that may be determined administratively or possibly 3157 algorithmically based on congestion control feedback. PLR nodes are 3158 receivers that have been identified to have potential for (perhaps 3159 soon) becoming the CLR and thus immediate, up-to-date feedback is 3160 beneficial for congestion control performance. The details of PLR 3161 selection are not discussed in this document. 3163 5.5.2.1. NORM_CMD(CC) Transmission 3165 The NORM_CMD(CC) message is transmitted periodically by the sender 3166 along with its normal data transmission. Note that the repeated 3167 transmission of NORM_CMD(CC) messages may be initiated some time 3168 before transmission of user data content at session startup. This 3169 may be done to collect some estimation of the current state of the 3170 multicast topology with respect to group and individual RTT and 3171 congestion control state. 3173 A NORM_CMD(CC) message is immediately transmitted at sender startup. 3174 The interval of subsequent NORM_CMD(CC) message transmission is 3175 determined as follows: 3177 1) By default, the interval is set according to the current 3178 sender GRTT estimate. A startup GRTT of 0.5 seconds is 3179 recommended when no feedback has yet been received from the 3180 group. 3182 2) Until a CLR has been identified (based on previous receiver 3183 feedback) or when no data transmission is pending, the 3184 NORM_CMD(CC) interval is doubled up from its current 3185 interval to a maximum of once per 30 seconds. This results 3186 in a low duty cycle for NORM_CMD(CC) probing when no CLR is 3187 identified or there is no pending data to transmit. T}.sp 3188 3) T{ When a CLR has been identified (based on receiver 3189 feedback) and data transmission is pending, the probing 3190 interval is set to the RTT between the sender and the CLR 3191 (RTT_clr). 3193 4) Additionally, when the data transmission rate is low with 3194 respect to the RTT_clr interval used for probing, the 3195 implementation should ensure that no more than one 3196 NORM_CMD(CC) message is sent per NORM_DATA message when 3197 there is data pending transmission. This ensures that the 3198 transmission of this control message is not done to the 3199 exclusion of user data transmission. 3201 The NORM_CMD(CC) "cc_sequence" field is incremented with each 3202 transmission of a NORM_CMD(CC) command. The greatest "cc_sequence" 3203 recently received by receivers is included in their feedback to the 3204 sender. This allows the sender to determine the "age" of feedback to 3205 assist in congestion avoidance. 3207 The NORM-CC Rate Header Extension is applied to the NORM_CMD(CC) 3208 message and the sender advertises its current transmission rate in 3209 the "send_rate" field. The rate information is used by receivers to 3210 initialize loss estimation during congestion control startup or 3211 restart. 3213 The "cc_node_list" contains a list of entries identifying receivers 3214 and their current congestion control state (status "flags", "rtt" and 3215 "loss" estimates). The list may be empty if the sender has not yet 3216 received any feedback from the group. If the sender has received 3217 feedback, the list will minimally contain an entry identifying the 3218 CLR. A NORM_FLAG_CC_CLR flag value is provided for the "cc_flags" 3219 field to identify the CLR entry. It is RECOMMENDED that the CLR 3220 entry be the first in the list for implementation efficiency. 3221 Additional entries in the list are used to provide sender-measured 3222 individual RTT estimates to receivers in the group. The number of 3223 additional entries in this list is dependent upon the percentage of 3224 control traffic the sender application is willing to send with 3225 respect to user data message transmissions. More entries in the list 3226 may allow the sender to be more responsive to congestion control 3227 dynamics. The length of the list may be dynamically determined 3228 according to the current transmission rate and scheduling of 3229 NORM_CMD(CC) messages. The maximum length of the list corresponds to 3230 the sender’s NormSegmentSize parameter for the session. The 3231 inclusion of additional entries in the list based on receiver 3232 feedback are prioritized with following rules: 3234 1) Receivers that have not yet been provided a RTT measurement 3235 get first priority. Of these, those with the greatest loss 3236 fraction receive precedence for list inclusion. 3238 2) Secondly, receivers that have previously been provided a RTT 3239 measurement are included with receivers yielding the lowest 3240 calculated congestion rate getting precedence. 3242 There are "cc_flag" values in addition to NORM_FLAG_CC_CLR that are 3243 used for other congestion control functions. The NORM_FLAG_CC_PLR 3244 flag value is used to mark additional receivers from that the sender 3245 would like to have immediate, non-suppressed feedback. These may be 3246 receivers that the sender algorithmically identified as potential 3247 future CLRs or that have been pre-configured as potential congestion 3248 control points in the network. The NORM_FLAG_CC_RTT indicates the 3249 validity of the "cc_rtt" field for the associated receiver node. 3250 Normally, this flag will be set since the receivers in the list will 3251 typically be receivers from which the sender has received feedback. 3252 However, in the case that the NORM sender has been pre-configured 3253 with a set of PLR nodes, feedback from those receivers may not yet 3254 have been collected and thus the "cc_rtt" field does not contain a 3255 valid value when this flag is not set. Similarly, a value of ZERO 3256 for the "cc_rate" field here should be treated as an invalid value 3257 and be ignored for the purposes of feedback suppression, etc. 3259 5.5.2.2. NORM_CMD(CC) Feedback Response 3261 Receivers explicitly respond to NORM_CMD(CC) messages in the form of 3262 a NORM_ACK(RTT) message. The goal of the congestion control feedback 3263 is to determine the receivers with the lowest congestion control 3264 rates. Receivers that are marked as CLR or PLR nodes in the 3265 NORM_CMD(CC) "cc_node_list" immediately provide feedback in the form 3266 of a NORM_ACK to this message. When a NORM_CMD(CC) is received, non- 3267 CLR or non-PLR nodes initiate random feedback backoff timeouts 3268 similar to that used when the receiver initiates a repair cycle (see 3269 Section 5.3) in response to detection of data loss. The backoff 3270 timeout for the congestion control response is generated as follows: 3272 T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender) 3274 The "RandomBackoff()" algorithm provides a truncated exponentially 3275 distributed random number and is described in the NORM Building Block 3276 document [3]. The same backoff factor K = Ksender MAY be used as 3277 with NORM_NACK suppression. However, in cases where the application 3278 purposefully specifies a very small Ksender backoff factor to 3279 minimize the NACK repair process latency (trading off group size 3280 scalability), it is RECOMMENDED that a larger backoff factor for 3281 congestion control feedback is maintained, since there may often be a 3282 larger volume of congestion control feedback than NACKs in many cases 3283 and some congestion control feedback latency may be tolerable where 3284 reliable delivery latency is not. As previously noted, a backoff 3285 factor value of K = 4 is generally recommended for ASM operation and 3286 K = 6 for SSM operation. A receiver SHALL cancel the backoff timeout 3287 and thus its pending transmission of a NORM_ACK(RTT) message under 3288 the following conditions: 3290 1) The receiver generates another feedback message (NORM_NACK 3291 or other NORM_ACK) before the congestion control feedback 3292 timeout expires (these messages will convey the current 3293 congestion control feedback information), 3295 2) A NORM_CMD(CC) or other receiver feedback with an ordinally 3296 greater "cc_sequence" field value is received before the 3297 congestion control feedback timeout expires (this is similar 3298 to the TFMCC feedback round number), 3300 3) When the T_backoff is greater than 1*GRTTsender. This 3301 prevents NACK implosion in the event of sender or network 3302 failure, 3304 4) "Suppressing" congestion control feedback is heard from 3305 another receiver (in a NORM_ACK or NORM_NACK) or via a 3306 NORM_CMD(REPAIR_ADV) message from the sender. The local 3307 receiver’s feedback is "suppressed" if the rate of the 3308 competing feedback (Rfb) is sufficiently close to or less 3309 than the local receiver’s calculated rate (Rcalc). The 3310 local receiver’s feedback is canceled when: 3312 Rcalc > (0.9 * Rfb) 3314 Also note receivers that have not yet received an RTT 3315 measurement from the sender are suppressed only by other 3316 receivers that have not yet measured RTT. Additionally, 3317 receivers whose RTT estimate has "aged" considerably (i.e., 3318 they haven’t been included in the NORM_CMD(CC) 3319 "cc_node_list" in a long time) may wish to compete as a 3320 receiver with no prior RTT measurement after some long term 3321 expiration period. 3323 When the backoff timer expires, the receiver SHALL generate a 3324 NORM_ACK(RTT) message to provide feedback to the sender and group. 3325 This message may be multicast to the group for most effective 3326 suppression in ASM topologies or unicast to the sender depending upon 3327 how the NORM protocol is deployed and configured. 3329 Whenever any feedback is generated (including this NORM_ACK(RTT) 3330 message), receivers include an adjusted version of the sender 3331 timestamp from the most recently received NORM_CMD(CC) message and 3332 the "cc_sequence" value from that command in the applicable NORM_ACK 3333 or NORM_NACK message fields. For NORM-CC operation, any generated 3334 feedback message SHALL also contain the NORM-CC Feedback header 3335 extension. The receiver provides its current "cc_rate" estimate, 3336 "cc_loss" estimate, "cc_rtt" if known, and any applicable "cc_flags" 3337 via this header extension. 3339 During slow start (when the receiver has not yet detected loss from 3340 the sender), the receiver uses a value equal to two times its 3341 measured rate from the sender in the "cc_rate" field. For steady- 3342 state congestion control operation, the receiver "cc_rate" value is 3343 from the equation-based value using its current loss event estimate 3344 and sender<->receiver RTT information. (The GRTT is used when the 3345 receiver has not yet measured its individual RTT). 3347 The "cc_loss" field value reflects the receiver’s current loss event 3348 estimate with respect to the sender in question. 3350 When the receiver has a valid individual RTT measurement, it SHALL 3351 include this value in the "cc_rtt" field. The NORM_FLAG_CC_RTT MUST 3352 be set when the "cc_rtt" field is valid. 3354 After a congestion control feedback message is generated or when the 3355 feedback is suppressed, a non-CLR receiver begins a "holdoff" timeout 3356 period during which it will restrain itself from providing congestion 3357 control feedback, even if NORM_CMD(CC) messages are received from the 3358 sender (unless the receive becomes marked as a CLR or PLR node). The 3359 value of this holdoff timeout (T_ccHoldoff) period is: 3361 T_ccHoldoff = (K*GRTT) 3363 Thus, non-CLR receivers are constrained to providing explicit 3364 congestion control feedback once per K*GRTT intervals. Note, 3365 however, that as the session progresses, different receivers will be 3366 responding to different NORM_CMD(CC) messages and there will be 3367 relatively continuous feedback of congestion control information 3368 while the sender is active. 3370 5.5.2.3. Congestion Control Rate Adjustment 3372 During steady-state operation, the sender will directly adjust its 3373 transmission rate to the rate indicated by the feedback from its 3374 currently selected CLR. As noted in [24], the estimation of 3375 parameters (loss and RTT) for the CLR will generally constrain the 3376 rate changes possible within acceptable bounds. For rate increases, 3377 the sender SHALL observe a maximum rate of increase of one packet per 3378 RTT at all times during steady-state operation. 3380 The sender processes congestion control feedback from the receivers 3381 and selects the CLR based on the lowest rate receiver. Receiver 3382 rates are either determined directly from the slow start "cc_rate" 3383 provided by the receiver in the NORM-CC Feedback header extension or 3384 by performing the equation-based calculation using individual RTT and 3385 loss estimates ("cc_loss") as feedback is received. 3387 The sender can calculate a current RTT for a receiver (RTT_rcvrNew) 3388 using the "grtt_response" timestamp included in feedback messages. 3389 When the "cc_rtt" value in a response is not valid, the sender simply 3390 uses this RTT_rcvrNew value as the receiver’s current RTT (RTT_rcvr). 3391 For non-CLR and non-PLR receivers, the sender can use the "cc_rtt" 3392 value provided in the NORM-CC Feedback header extension as the 3393 receiver’s previous RTT measurement (RTT_rcvrPrev) to smooth 3394 according to: 3396 RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew 3398 For CLR receivers where feedback is received more regularly, the 3399 sender SHOULD maintain a more smoothed RTT estimate upon new feedback 3400 from the CLR where: 3402 RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew 3404 "RTT_clrNew" is the new RTT calculated from the timestamp in the 3405 feedback message received from the CLR. The RTT_clr is initialized 3406 to RTT_clrNew on the first feedback message received. Note that the 3407 same procedure is observed by the sender for PLR receivers and that 3408 if a PLR is "promoted" to CLR status, the smoothed estimate can be 3409 continued. 3411 There are some additional periods besides steady-state operation that 3412 need to be considered in NORM-CC operation. These periods are: 3414 1) during session startup, 3416 2) when no feedback is received from the CLR, and 3418 3) when the sender has a break in data transmission. 3420 During session startup, the congestion control operation SHALL 3421 observe a "slow start" procedure to quickly approach its fair 3422 bandwidth share. An initial sender startup rate is assumed where: 3424 Rinitial = MIN(NormSegmentSize / GRTT, NormSegmentSize) bytes/second. 3426 The rate is increased only when feedback is received from the 3427 receiver set. The "slow start" phase proceeds until any receiver 3428 provides feedback indicating that loss has occurred. Rate increase 3429 during slow start is applied as: 3431 Rnew = Rrecv_min 3433 where "Rrecv_min" is the minimum reported receiver rate in the 3434 "cc_rate" field of congestion control feedback messages received from 3435 the group. Note that during "slow start", receivers use two times 3436 their measured rate from the sender in the "cc_rate" field of their 3437 feedback. Rate increase adjustment is limited to once per GRTT 3438 during slow start. 3440 If the CLR or any receiver intends to leave the group, it will set 3441 the NORM_FLAG_CC_LEAVE in its congestion control feedback message as 3442 an indication that the sender should not select it as the CLR. When 3443 the CLR changes to a lower rate receiver, the sender should 3444 immediately adjust to the new lower rate. The sender is limited to 3445 increasing its rate at one additional packet per RTT towards any new, 3446 higher CLR rate. 3448 The sender should also track the "age" of the feedback it has 3449 received from the CLR by comparing its current "cc_sequence" value 3450 (Seq_sender) to the last "cc_sequence" value received from the CLR 3451 (Seq_clr). As the "age" of the CLR feedback increases with no new 3452 feedback, the sender SHALL begin reducing its rate once per RTT_clr 3453 as a congestion avoidance measure. The following algorithm is used 3454 to determine the decrease in sender rate (Rsender bytes/sec) as the 3455 CLR feedback, unexpectedly, excessively ages: 3457 Age = Seq_sender - Seq_clr; 3458 if (Age > 4) Rsender = Rsender * 0.5; 3460 This rate reduction is limited to the lower bound on NORM 3461 transmission rate. After NORM_ROBUST_FACTOR consecutive NORM_CMD(CC) 3462 rounds without any feedback from the CLR, the sender SHOULD assume 3463 the CLR has left the group and pick the receiver with the next lowest 3464 rate as the new CLR. Note this assumes that the sender does not have 3465 explicit knowledge that the CLR intentionally left the group. If no 3466 receiver feedback is received, the sender MAY wish to withhold 3467 further transmissions of NORM_DATA segments and maintain NORM_CMD(CC) 3468 transmissions only until feedback is detected. After such a CLR 3469 timeout, the sender will be transmitting with a minimal rate and 3470 should return to slow start as described here for a break in data 3471 transmission. 3473 When the sender has a break in its data transmission, it can continue 3474 to probe the group with NORM_CMD(CC) messages to maintain RTT 3475 collection from the group. This will enable the sender to quickly 3476 determine an appropriate CLR upon data transmission restart. 3477 However, the sender should exponentially reduce its target rate to be 3478 used for transmission restart as time since the break elapses. The 3479 target rate SHOULD be recalculated once per RTT_clr as: 3481 Rsender = Rsender * 0.5; 3483 If the minimum NORM rate is reached, the sender should set the 3484 NORM_FLAG_START flag in its NORM_CMD(CC) messages upon restart and 3485 the group should observer "slow start" congestion control procedures 3486 until any receiver experiences a new loss event. 3488 5.5.3. NORM Positive Acknowledgment Procedure 3490 NORM provides options for the source application to request positive 3491 acknowledgment (ACK) of NORM_CMD(FLUSH) and NORM_CMD(ACK_REQ) 3492 messages from members of the group. There are some specific 3493 acknowledgment requests defined for the NORM protocol and a range of 3494 acknowledgment request types that are left to be defined by the 3495 application. One predefined acknowledgment type is the 3496 NORM_ACK_FLUSH type. This acknowledgment is used to determine if 3497 receivers have achieved completion of reliable reception up through a 3498 specific logical transmission point with respect to the sender’s 3499 sequence of transmission. The NORM_ACK_FLUSH acknowledgment may be 3500 used to assist in application flow control when the sender has 3501 information on a portion of the receiver set. Another predefined 3502 acknowledgment type is NORM_ACK(CC), which is used to explicitly 3503 provide congestion control feedback in response to NORM_CMD(CC) 3504 messages transmitted by the sender for NORM-CC operation. Note the 3505 NORM_ACK(CC) response does NOT follow the positive acknowledgment 3506 procedure described here. The NORM_CMD(ACK_REQ) and NORM_ACK 3507 messages contain an "ack_type" field to identify the type of 3508 acknowledgment requested and provided. A range of "ack_type" values 3509 is provided for application-defined use. While the application is 3510 responsible for initiating the acknowledgment request and interprets 3511 application-defined "ack_type" values, the acknowledgment procedure 3512 SHOULD be conducted within the protocol implementation to take 3513 advantage of timing and transmission scheduling information available 3514 to the NORM transport. 3516 The NORM positive acknowledgment procedure uses polling by the sender 3517 to query the receiver group for response. Note this polling 3518 procedure is not intended to scale to very large receiver groups, but 3519 could be used in large group setting to query a critical subset of 3520 the group. Either the NORM_CMD(ACK_REQ), or when applicable, the 3521 NORM_CMD(FLUSH) message is used for polling and contains a list of 3522 NormNodeIds for receivers that should respond to the command. The 3523 list of receivers providing acknowledgment is determined by the 3524 source application with "a priori" knowledge of participating nodes 3525 or via some other application-level mechanism. 3527 The ACK process is initiated by the sender that generates 3528 NORM_CMD(FLUSH) or NORM_CMD(ACK_REQ) messages in periodic "rounds". 3529 For NORM_ACK_FLUSH requests, the NORM_CMD(FLUSH) contain a 3530 "object_transport_id" and "fec_payload_id" denoting the watermark 3531 transmission point for which acknowledgment is requested. This 3532 watermark transmission point is "echoed" in the corresponding fields 3533 of the NORM_ACK(FLUSH) message sent by the receiver in response. 3534 NORM_CMD(ACK_REQ) messages contain an "ack_id" field which is 3535 similarly "echoed" in response so that the sender may match the 3536 response to the appropriate request. 3538 In response to the NORM_CMD(ACK_REQ), the listed receivers randomly 3539 spread NORM_ACK messages uniformly in time over a window of (1*GRTT). 3540 These NORM_ACK messages are typically unicast to the sender. (Note 3541 that NORM_ACK(CC) messages SHALL be multicast or unicast in the same 3542 manner as NORM_NACK messages). 3544 The ACK process is self-limiting and avoids ACK implosion in that: 3546 1) Only a single NORM_CMD(ACK_REQ) message is generated once per 3547 (2*GRTT), and, 3549 2) The size of the "acking_node_list" of NormNodeIds from which 3550 acknowledgment is requested is limited to a maximum of the 3551 sender NormSegmentSize setting per round of the positive 3552 acknowledgment process. 3554 Because the size of the included list is limited to the sender’s 3555 NormSegmentSize setting, multiple NORM_CMD(ACK_REQ) rounds may be 3556 required to achieve responses from all receivers specified. The 3557 content of the attached NormNodeId list will be dynamically updated 3558 as this process progresses and NORM_ACK responses are received from 3559 the specified receiver set. As the sender receives valid responses 3560 (i.e., matching watermark point or "ack_id") from receivers, it SHALL 3561 eliminate those receivers from the subsequent NORM_CMD(ACK_REQ) 3562 message "acking_node_list" and add in any pending receiver 3563 NormNodeIds while keeping within the NormSegmentSize limitation of 3564 the list size. Each receiver is queried a maximum number of times 3565 (NORM_ROBUST_FACTOR, by default). Receivers not responding within 3566 this number of repeated requests are removed from the payload list to 3567 make room for other potential receivers pending acknowledgment. The 3568 transmission of the NORM_CMD(ACK_REQ) is repeated until no further 3569 responses are required or until the repeat threshold is exceeded for 3570 all pending receivers. The transmission of NORM_CMD(ACK_REQ) or 3571 NORM_CMD(FLUSH) messages to conduct the positive acknowledgment 3572 process is multiplexed with ongoing sender data transmissions. 3573 However, the NORM_CMD(FLUSH) positive acknowledgment process may be 3574 interrupted in response to negative acknowledgment repair requests 3575 (NACKs) received from receivers during the acknowledgment period. 3576 The NORM_CMD(FLUSH) positive acknowledgment process is restarted for 3577 receivers pending acknowledgment once any the repairs have been 3578 transmitted. 3580 In the case of NORM_CMD(FLUSH) commands with an attached 3581 "acking_node_list", receivers will not ACK until they have received 3582 complete transmission of all data up to and including the given 3583 watermark transmission point. All receivers SHALL interpret the 3584 watermark point provided in the request NACK for repairs if needed as 3585 for NORM_CMD(FLUSH) commands with no attached "acking_node_list". 3587 5.5.4. Group Size Estimate 3589 NORM sender messages contain a "gsize" field that is a representation 3590 of the group size and is used in scaling random backoff timer ranges. 3591 The use of the group size estimate within the NORM protocol does not 3592 require a precise estimation and works reasonably well if the 3593 estimate is within an order of magnitude of the actual group size. 3594 By default, the NORM sender group size estimate may be 3595 administratively configured. Also, given the expected scalability of 3596 the NORM protocol for general use, a default value of 10,000 is 3597 RECOMMENDED for use as the group size estimate. 3599 It is possible that group size may be algorithmically approximated 3600 from the volume of congestion control feedback messages which follow 3601 the exponentially weighted random backoff. However, the 3602 specification of such an algorithm is currently beyond the scope of 3603 this document. 3605 6. Security Considerations 3607 The same security considerations that apply to the NORM, TFMCC, and 3608 FEC Building Blocks also apply to the NORM protocol. In addition to 3609 vulnerabilities that any IP and IP multicast protocol implementation 3610 may be generally subject to, the NACK-based feedback of NORM may be 3611 exploited by replay attacks which force the NORM sender to 3612 unnecessarily transmit repair information. This MAY be addressed by 3613 network layer IP security implementations that guard against this 3614 potential security exploitation. The NORM protocol is compatible 3615 with the use of the IP security (IPsec) architecture described in 3616 [6]. and the IPSec Encapsulating Security Payload (ESP) protocol or 3617 Authentication Header (AF) extension MAY be used to secure IP packets 3618 transmitted by NORM participants. 3620 Alternatively, a header extension may be applied to the NORM protocol 3621 to provide authentication of NORM messages. For this purpose the 3622 EXT_AUTH header extension (HET = 1) is defined. The format of this 3623 header extension and its processing is outside the scope of this 3624 document and is to be communicated out-of-band as part of the session 3625 description. It is possible that an EXT_AUTH implementation of MAY 3626 also provide for encryption of NORM message payloads as well as 3627 authentication. The use of this approach as compared to IPSec can 3628 allow for header compression techniques to be applied jointly to IP 3629 and NORM protocol headers. In cases where security analysis deems 3630 that encryption of NORM protocol header content is beneficial or 3631 necessary, the aforementioned use of IPSec ESP may be more 3632 appropriate. If EXT_AUTH is present, whatever packet authentication 3633 checks that can be performed immediately upon reception of the packet 3634 SHOULD be performed before accepting the packet and performing any 3635 congestion control-related action on it. Some packet authentication 3636 schemes impose a delay of several seconds between when a packet is 3637 received and when the packet is fully authenticated. Any congestion 3638 control related action that is appropriate MUST NOT be postponed by 3639 any such full packet authentication. Consideration SHOULD also be 3640 given to the potential for replay-attacks that would transplant 3641 authenticated packets from one NORM session to another to disrupt 3642 service. To avoid this potential, unique keys SHOULD be used on a 3643 per-session basis or NORM sender nodes SHOULD use unique 3644 "instance_id" identifiers that are managed as part of the security 3645 association for the sessions. 3647 It is RECOMMENDED that such security mechanisms be used when 3648 available. It should be noted that NORM participants can use the 3649 "sequence" field from the NORM Common Message Header to detect replay 3650 attacks. This can be accomplished if the NORM sender is willing to 3651 maintain state on receivers which are NACKing. A cache of such 3652 receiver state can be used to provide protection against NACK replay 3653 attacks. NORM receivers SHOULD also also maintain similar state for 3654 protection against possible replay of other receiver messages in ASM 3655 operation as well. For example, a receiver could be suppressed from 3656 providing NACK or congestion control feedback by replay of certain 3657 receiver messages. For these reasons, authentication of NORM 3658 messages (e.g., via IPSec) is RECOMMENDED for protection against 3659 similar attacks that might use fabricated messages. Also, encryption 3660 of messages to provide confidientiality of application data and 3661 protect privacy of users MAY also be applied using IPSec or similar 3662 mechanisms. When any such cryptographic measures are used, it is 3663 RECOMMENDED that an approach such as described in the Group Domain of 3664 Interpretation (GDOI) [28], Multimedia Internet KEYing (MIKEY) [29] 3665 or Group Secure Association Key Management Protocol (GSAKMP) [30] 3666 specifications for automated key management is applied. 3668 It is also important to note that while NORM does leverage FEC-based 3669 repair for scalability, this does not alone guarantee integrity of 3670 received data. Application-level integrity-checking of data content 3671 is highly RECOMMENDED. 3673 6.1. Baseline Secure NORM Operation 3675 This section describes a baseline mode of secure NORM protocol 3676 operation based on application of the IPSec security protocol. This 3677 approach is documented here to provide a reference, interoperable 3678 secure mode of operation. However, additional approaches to NORM 3679 security, including other forms of IPSec application, MAY be 3680 specified in the future. For example, the use of the EXT_AUTH header 3681 extension could enable NORM-specific authentication or security 3682 encapsulation headers similar to those of IPSec to be specified and 3683 inserted into the NORM protocol message headers. This would allow 3684 header compression techniques to be applied to IP and NORM protocol 3685 headers when needed in a similar fashion to that of RTP [22] and as 3686 preserved in the specification for Secure Real Time Protocol (SRTP) 3687 [23]. The baseline approach described is applicable to NORM 3688 operation configured for SSM (or SSM-like) operation where there is a 3689 single sender and the receivers are providing unicast feedback. This 3690 form of NORM operation allows for IPSec to be used with a manageable 3691 number of security associations (SA). 3693 6.1.1. IPSec Approach 3695 For NORM one-to-many SSM operation with unicast feedback from 3696 receivers, each node SHALL be configured with two transport mode 3697 IPSec security associations and corresponding Security Policy 3698 Database (SDP) entries. One entry will be used for sender-to-group 3699 multicast packet authentication and optionally encryption while the 3700 other entry will be used to provide security for the unicast feedback 3701 messaging from the receiver(s) to the sender. 3703 The NORM sender SHALL use an IPSec SA configured for ESP protocol [7] 3704 operation with the option for data origination authentication 3705 enabled. It is also RECOMMENDED that this IPSec ESP SA be also 3706 configured to provide confidentiality protection for IP packets 3707 containing NORM protocol messages. This is suggested to make the 3708 realization of complex replay attacks much more difficult. The 3709 encryption key for this SA SHALL be preplaced at the sender and 3710 receiver(s) prior to NORM protocol operation. Use of automated key 3711 management is RECOMMENDED as a rekey SHALL be required prior to 3712 expiration of the sequence space for the SA. This is necessary so 3713 that receivers may use the built-in IPSec replay attack protection 3714 possible for an IPSec SA with a single source (the NORM sender). 3715 Thus the receivers SHALL enable replay attack protection for this SA 3716 used to secure NORM sender traffic. An IPSec SPD entry MUST be 3717 configured to process outbound packets to the session (destination) 3718 address and UDP port number of the applicable (NormSession). 3720 The NORM receiver(s) MUST be configured with the SA and SPD entry to 3721 properly process the IPSec-secured packets from the sender. The NORM 3722 receiver(s) SHALL also use a common, second IPSec SA (common Security 3723 Parameter Index (SPI) and encryption key) configured for ESP 3724 operation with the option for data origination authentication 3725 enabled. Similar to the NORM sender, is is RECOMMENDED this IPSec 3726 ESP SA be also configured to provide confidentiality protection for 3727 IP packets containing NORM protocol messages. The receivers MUST 3728 have an IPSec SPD entry configured to process outbound NORM/UDP 3729 packets directed to the NORM sender source address and port number 3730 using this second SA. As noted for NORM unicast feedback, the 3731 sender’s transmission port number SHOULD be distinct from the 3732 multicast session port number to allow discrimination between unicast 3733 and multicast feedback messages when access to the IP destination 3734 address is not possible (e.g., a user-space NORM implementation). 3735 For processing of packets from receivers, the NORM sender SHALL be 3736 configured with this common, second SA (and the corresponding SPD 3737 entry needed) in order to properly process messages from the 3738 receiver. Note that built-in IPSec replay attack protection for this 3739 second SA at the sender MUST be disabled. 3741 Multiple receivers using a common IPSec SA for traffic directed to 3742 the NORM sender (i.e., many-to-one) prevents the use of built-in 3743 IPSec replay attack protection by the NORM sender with current IPSec 3744 implementations. So, to support a fully secure mode of operation, 3745 the NORM sender implementation MUST provide replay attack protection 3746 based upon the "sequence" field of NORM protocol messages from 3747 receivers. This can be accomplished with high assurance of security, 3748 even with the limited size (16-bits) of this field, because 3750 1) NORM receiver NACK and non-CLR ACK feedback messages are 3751 sparse. 3753 2) The more frequent NORM ACK feedback from CLR or PLR nodes 3754 are only a small set of receivers for which the sender must 3755 keep more persistent replay attack state. 3757 3) NORM NACK feedback messages that precede the sender’s 3758 current repair window do not significantly impact protocol 3759 operation (generation of NORM_CMD(SQUELCH) is limited) and 3760 could be in fact ignored. This means the sender can prune 3761 any replay attack state for receivers that precede the 3762 current repair window. 3764 4) NORM ACK messages correspond to either a specific sender 3765 "ack_id", the sender "cc_sequence" for ACKs sent in response 3766 to NORM_CMD(CC), or the sender’s current repair window in 3767 the case of ACKs sent in response to NORM_CMD(FLUSH). Thus, 3768 the sender can prune any replay attack state for receivers 3769 that precede the current applicable sequence or repair 3770 window space. 3772 Note that use of ESP confidentiality, as RECOMMENDED, for secure NORM 3773 protocol operation makes it more difficult for adversaries to conduct 3774 effective replay attacks. Additionally, it should be noted that a 3775 NORM sender implementation with access to the full ESP protocol 3776 header could also use the ESP sequence information to make this form 3777 of replay attack protection even more robust. The design of this 3778 baseline security approach for NORM intentionally places any more 3779 complex processing state or processing (e.g. replay attack protection 3780 given multiple receivers) at the NORM sender since NORM receiver 3781 implementations may need to have a more "light-weight" realization in 3782 many cases. 3784 This baseline approach can be used for NORM protocol sessions with 3785 multiple senders if the SA pairs described are established for each 3786 sender. For small-sized groups, it is even possible that many-to- 3787 many (ASM) IPSec configuration could be achieved where each 3788 participant uses a unique SA (with a unique SPI). This does not 3789 scale to larger group sizes given the complex set of SA and SPD 3790 entries each participant would need to maintain. 3792 It is anticipated in early deployments of this baseline approach to 3793 NORM security that key management will be conducted out-of-band with 3794 respect to NORM protocol operation. In the case of one-to-many NORM 3795 operation, it is possible that receivers may retrieve keying 3796 information from a central server as needed or otherwise conduct 3797 group key updates with a similar centralized approach. However, it 3798 may be possible with some key management schemes for rekey messages 3799 to be transmitted to the group as a message or transport object 3800 within the NORM reliable transfer session. Similarly, for group-wise 3801 communication sessions it is possible that potential group 3802 participants may request keying and/or rekeying as part of NORM 3803 communications. Additional specification is necessary to define an 3804 in-band key managment scheme for NORM sessions perhaps using the 3805 mechanisms of the automated group key management specifications cited 3806 in this document. 3808 6.1.2. IPSec Requirements 3810 In order to implement this secure mode of NORM protocol operation, 3811 the following IPSec capabilities are required. 3813 6.1.2.1. Selectors 3815 The implementation MUST be able to use the source address, 3816 destination address, protocol (UDP), and UDP port numbers as 3817 selectors in the SPD. 3819 6.1.2.2. Mode 3821 IPSec in transport mode MUST be supported. The use of IPSec 3822 processing for secure NORM traffic SHOULD also be "required" such 3823 that unauthenticated packets are not received by the NORM protocol 3824 implementation. [6]. 3826 6.1.2.3. Key Management 3828 An automated key management scheme for group key distribution and 3829 rekeying such as GDOI [28], GSAKMP [30], or MIKEY [29] SHOULD be 3830 used. Relatively short-lived NORM sessions MAY be able to use Manual 3831 Keying with a single, preplaced key, particularly if Extended 3832 Sequence Numbering (ESN) [7] is available in the IPSec implementation 3833 used. It should also be noted that it may be possible for key update 3834 messages (e.g., the GDOI GROUPKEY-PUSH message) to be included in the 3835 NORM application reliable data transmission if appropriate interfaces 3836 were available between the NORM application and the key management 3837 daemon. 3839 6.1.2.4. Security Policy 3841 Receivers SHOULD accept connections only from the designated, 3842 authorized sender(s). It is expected that appropriate key management 3843 will provide encryption keys only to receivers authorized to 3844 participate in a designated session. The approach outlined here 3845 allows receiver sets to be controlled on a per-sender basis. 3847 6.1.2.5. Authentication and Encryption 3849 Large NORM group sizes will necessitate some form of key management 3850 that does rely upon shared secrets. The GDOI and GSAKMP protocols 3851 mentioned here allow for certificate-based authentication. These 3852 certificates SHOULD use IP addresses for authentication although it 3853 may alternatively possible to have authentication associated with 3854 pre-assigned NormNodeId values. However, it is likely that available 3855 group key management implementations will not be NORM-specific. 3857 6.1.2.6. Availability 3859 The IPSec requirements profile outlined here is commonly available on 3860 many potential NORM hosts. The principal issue is that configuration 3861 and operation of IPSec typically requires privileged user 3862 authorization. Automated key management implementations are 3863 typically configured with the privileges necessary to effect system 3864 IPSec configuration needed. 3866 7. IANA Considerations 3868 Header extension identifiers for the NORM protocol are subject to 3869 IANA registration. Additionally, building blocks components used by 3870 this NORM Protocol specification may introduce additional IANA 3871 considerations. In particular, the FEC Building Block used by NORM 3872 does require IANA registration of the FEC codecs used. The 3873 registration instructions for FEC codecs are provided in [4]. 3875 7.1. 3877 This document defines a name-space for NORM Header Extensions named: 3878 ietf:rmt:norm:extensions 3880 These values represent extended header fields that allow the protocol 3881 functionality to be expanded to include additional optional features 3882 and operating modes. The values that can be assigned within the 3883 "ietf:rmt:norm:extension" name-space are numeric indexes in the range 3884 {0, 255}, boundaries included. Values in the range {0,127} indicate 3885 variable length extended header fields while values in the range 3886 {128,255} indicate extension of a fixed 4-byte length. NORM header 3887 extension indentifier value assignment requests are granted on a 3888 "Specification Required" basis as defined in [8]. Additional header 3889 extension specifications MUST include a description of protocol 3890 actions to be taken when the the extended header is encountered by a 3891 protocol implementation not supporting that specific option. For 3892 example, it may be possible for protocol implementations to ignore 3893 unknown header extensions in many cases. 3895 This specification registers the following NORM Header Extension 3896 types in namespace "ietf:rmt:norm:extensions": 3898 +------+-----------+-----------------------------------------------+ 3899 |Value | Name | Reference | 3900 +------+-----------+-----------------------------------------------+ 3901 | 1 | EXT_AUTH | This specification | 3902 +------+-----------+-----------------------------------------------+ 3903 | 3 | EXT_CC | This specification | 3904 +------+-----------+-----------------------------------------------+ 3905 | 64 | EXT_FTI | This specification | 3906 +------+-----------+-----------------------------------------------+ 3907 | 128 | EXT_RATE | This specification | 3908 +------+-----------+-----------------------------------------------+ 3910 8. Suggested Use 3912 The present NORM protocol is seen as useful tool for the reliable 3913 data transfer over generic IP multicast services. It is not the 3914 intention of the authors to suggest it is suitable for supporting all 3915 envisioned multicast reliability requirements. NORM provides a 3916 simple and flexible framework for multicast applications with a 3917 degree of concern for network traffic implosion and protocol overhead 3918 efficiency. NORM-like protocols have been successfully demonstrated 3919 within the MBone for bulk data dissemination applications, including 3920 weather satellite compressed imagery updates servicing a large group 3921 of receivers and a generic web content reliable "push" application. 3923 In addition, this framework approach has some design features making 3924 it attractive for bulk transfer in asymmetric and wireless 3925 internetwork applications. NORM is capable of successfully operating 3926 independent of network structure and in environments with high packet 3927 loss, delay, and misordering. Hybrid proactive/reactive FEC-based 3928 repairing improve protocol performance in some multicast scenarios. 3929 A sender-only repair approach often makes additional engineering 3930 sense in asymmetric networks. NORM’s unicast feedback capability may 3931 be suitable for use in asymmetric networks or in networks where only 3932 unidirectional multicast routing/delivery service exists. Asymmetric 3933 architectures supporting multicast delivery are likely to make up an 3934 important portion of the future Internet structure (e.g., 3935 DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer 3936 will be an important capability for servicing large groups of 3937 subscribed receivers. 3939 9. Changes from RFC3940 3941 This section lists the changes between the Experimental version of 3942 this specification, [10], and this version: 3944 1) Removal of the NORM_FLAG_MSG_START for NORM_OBJECT_STREAM, 3945 replacing it with the "payload_msg_start" field in the FEC- 3946 encoded preamble of the NORM_OBJECT_STREAM NORM_DATA payload, 3948 2) Definition of IANA namespace for header extension assignment, 3950 3) Removal of file blocking scheme description that is now 3951 specified in the FEC Building Block document [4], 3953 4) Removal of restriction of NORM receiver feedback message rate 3954 to local NORM sender rate (this caused congestion control 3955 failures in high speed operation and the extremely low 3956 feedback rate of the NORM protocol as compared to TCP avoids 3957 any resultant impact to the network [31]), 3959 5) Correction of errors in some message format descriptions, and 3961 6) Correction of inconsistency in specification of the inactivity 3962 timeout. 3964 7) Addition of IPSec secure mode description with IPSec 3965 requirements. 3967 8) Clarification of interpretation of "Source Block Length" when 3968 FEC codes are arbitrarily shortened by the sender. 3970 10. Acknowledgments (and these are not Negative) 3972 The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh, 3973 Toni Paila, Michael Luby, and Joerg Widmer for their valuable input 3974 and comments on this document. The authors would also like to thank 3975 the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for 3976 their support in development of this specification, and Sally Floyd 3977 for her early input into this document. 3979 11. References 3981 11.1. Normative References 3983 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3984 Levels", BCP 14, RFC 2119, March 1997. 3986 [2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 3987 1112, August 1989. 3989 [3] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Multicast 3990 Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb- 3991 norm-revised-04, July 2007. 3993 [4] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction 3994 (FEC) Building Block", RFC 5052, August 2007. 3996 [5] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion 3997 Control (TFMCC) Protocol Specification", RFC 4654, August 2006. 3999 [6] S. Kent and K. Seo, "Security Architecture for the Internet 4000 Protocol", RFC 4301, December 2005. 4002 [7] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303, 4003 December 2005. 4005 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 4006 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 4008 11.2. Informative References 4010 [9] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable 4011 Multicast Transport (RMT) Building Blocks and Protocol Instantiation 4012 documents", RFC 3269, April 2002. 4013 [10] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative- 4014 Acknowledgement (NACK)-Oriented Reliable Multicast (NORM) Protocol", 4015 RFC 3940, November 2004. 4017 [11] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session 4018 Description Protocol", RFC 4566, July 2006. 4020 [12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement 4021 Protocol", RFC 2974, October 2000. 4023 [13] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender- 4024 Initiated and Receiver-Initiated Reliable Multicast Protocols", In 4025 Proc. INFOCOM, San Francisco CA, October 1993. 4027 [14] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and 4028 J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable 4029 Multicast", RFC 3453, December 2002. 4031 [15] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol 4032 (MDP) Toolkit", Proc. IEEE MILCOM 99, October 1999. 4034 [16] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", 4035 Proc. IEEE INFOCOMM, p. 964, March/April 1998. 4037 [17] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented 4038 Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October 4039 2002. 4041 [18] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. 4042 Dissertation, Stanford University, Department of Computer Science, 4043 Stanford, California, August 2001. 4045 [19] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity 4046 Retransmission with Channel Estimation", IEEE GLOBECOMM 98’, 4047 September 1998. 4049 [20] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., 4050 and M. Luby, "Reliable Multicast Transport Building Blocks for One- 4051 to-Many Bulk-Data Transfer", RFC 3048, January 2001. 4053 [21] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF 4054 Criteria for Evaluating Reliable Multicast Transport and Application 4055 Protocols", RFC 2357, June 1998. 4057 [22] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 4058 "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 4059 3550, July 2003. 4061 [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4062 Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 4063 2004. 4065 [24] J. Widmer and M. Handley, "Extending Equation-Based Congestion 4066 Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, 4067 August 2001. 4069 [25] Watson, M., "Basic Forward Error Correction (FEC) Schemes", 4070 Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-04, 4071 November 2007. 4073 [26] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast 4074 Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August 4075 2000. 4077 [27] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP 4078 Throughput: A Simple Model and its Empirical Validation", Proc ACM 4079 SIGCOMM 1998. 4081 [28] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group 4082 Domain of Interpretation", RFC 3547, July 2003. 4084 [29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 4085 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. 4087 [30] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: 4088 Group Secure Association Key Management Protocol", RFC 4535, June 4089 2006. 4091 [31] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism 4092 for NACK-Oriented Reliable Multicast Congestion Control", IEEE 4093 GLOBECOMM 2001, November 2001. 4095 12. Authors’ Addresses 4097 Brian Adamson 4098 Naval Research Laboratory 4099 Washington, DC, USA, 20375 4101 EMail: adamson@itd.nrl.navy.mil 4103 Carsten Bormann 4104 Universitaet Bremen TZI 4105 Postfach 330440 4106 D-28334 Bremen, Germany 4108 EMail: cabo@tzi.org 4110 Mark Handley 4111 Department of Computer Science 4112 University College London 4113 Gower Street 4114 London 4115 WC1E 6BT 4116 UK 4118 EMail: M.Handley@cs.ucl.ac.uk 4120 Joe Macker 4121 Naval Research Laboratory 4122 Washington, DC, USA, 20375 4124 EMail: macker@itd.nrl.navy.mil 4126 13. Full Copyright Statement 4128 Copyright (C) The IETF Trust (2008). 4130 This document is subject to the rights, licenses and restrictions 4131 contained in BCP 78, and except as set forth therein, the authors 4132 retain all their rights. 4134 This document and the information contained herein are provided on an 4135 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4136 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4137 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4138 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4139 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4140 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4142 Intellectual Property 4144 The IETF takes no position regarding the validity or scope of any 4145 Intellectual Property Rights or other rights that might be claimed to 4146 pertain to the implementation or use of the technology described in 4147 this document or the extent to which any license under such rights 4148 might or might not be available; nor does it represent that it has 4149 made any independent effort to identify any such rights. Information 4150 on the procedures with respect to rights in RFC documents can be 4151 found in BCP 78 and BCP 79. 4153 Copies of IPR disclosures made to the IETF Secretariat and any 4154 assurances of licenses to be made available, or the result of an 4155 attempt made to obtain a general license or permission for the use of 4156 such proprietary rights by implementers or users of this 4157 specification can be obtained from the IETF on-line IPR repository at 4158 http://www.ietf.org/ipr. 4160 The IETF invites any interested party to bring to its attention any 4161 copyrights, patents or patent applications, or other proprietary 4162 rights that may cover technology that may be required to implement 4163 this standard. Please address the information to the IETF at ietf- 4164 ipr@ietf.org. 4166 Acknowledgement 4168 Funding for the RFC Editor function is currently provided by the 4169 Internet Society.