idnits 2.17.1 draft-ietf-rmt-pi-norm-revised-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 3, 2009) is 5440 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) ** Downref: Normative reference to an Experimental RFC: RFC 4654 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Adamson 3 Internet-Draft Naval Research Laboratory 4 Obsoletes: 3940 (if approved) C. Bormann 5 Intended status: Standards Track Universitaet Bremen TZI 6 Expires: December 5, 2009 M. Handley 7 University College London 8 J. Macker 9 Naval Research Laboratory 10 June 3, 2009 12 NACK-Oriented Reliable Multicast Transport Protocol 13 draft-ietf-rmt-pi-norm-revised-13 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on December 5, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document describes the messages and procedures of the Negative- 61 ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. 62 This protocol can provide end-to-end reliable transport of bulk data 63 objects or streams over generic IP multicast routing and forwarding 64 services. NORM uses a selective, negative acknowledgment mechanism 65 for transport reliability and offers additional protocol mechanisms 66 to allow for operation with minimal a priori coordination among 67 senders and receivers. A congestion control scheme is specified to 68 allow the NORM protocol to fairly share available network bandwidth 69 with other transport protocols such as Transmission Control Protocol 70 (TCP). It is capable of operating with both reciprocal multicast 71 routing among senders and receivers and with asymmetric connectivity 72 (possibly a unicast return path) between the senders and receivers. 73 The protocol offers a number of features to allow different types of 74 applications or possibly other higher level transport protocols to 75 utilize its service in different ways. The protocol leverages the 76 use of FEC-based repair and other IETF Reliable Multicast Transport 77 (RMT) building blocks in its design. This document obsoletes RFC 78 3940. 80 Table of Contents 82 1. Introduction and Applicability . . . . . . . . . . . . . . . . 5 83 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 84 1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 6 85 1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 8 86 1.4. Environmental Requirements and Considerations . . . . . . 9 87 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9 88 2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 11 89 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 13 90 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . 13 91 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 92 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.1. NORM Common Message Header and Extensions . . . . . . . . 16 94 4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 19 95 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 19 96 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 29 97 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 30 98 4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 48 99 4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . 48 100 4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 54 101 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 56 102 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 56 103 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 56 104 5.1. Sender Initialization and Transmission . . . . . . . . . . 58 105 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 59 106 5.2. Receiver Initialization and Reception . . . . . . . . . . 60 107 5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 61 108 5.4. Sender NACK Processing and Response . . . . . . . . . . . 63 109 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 63 110 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 64 111 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 65 112 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 66 113 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66 114 5.5.1. Group Round-trip Time (GRTT) Collection . . . . . . . 66 115 5.5.2. NORM Congestion Control Operation . . . . . . . . . . 68 116 5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 76 117 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 78 118 6. Configurable Elements . . . . . . . . . . . . . . . . . . . . 78 119 7. Security Considerations . . . . . . . . . . . . . . . . . . . 81 120 7.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 83 121 7.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 83 122 7.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 85 123 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 124 8.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 87 125 8.1.1. NORM Header Extension Types . . . . . . . . . . . . . 87 126 8.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 88 127 8.1.3. NORM_CMD Message Sub-types . . . . . . . . . . . . . . 88 129 9. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 89 130 10. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 90 131 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91 132 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 91 133 12.1. Normative References . . . . . . . . . . . . . . . . . . . 91 134 12.2. Informative References . . . . . . . . . . . . . . . . . . 92 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 93 137 1. Introduction and Applicability 139 The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) 140 protocol can provide reliable transport of data from one or more 141 sender(s) to a group of receivers over an IP multicast network. The 142 primary design goals of NORM are to provide efficient, scalable, and 143 robust bulk data (e.g., computer files, transmission of persistent 144 data) transfer across possibly heterogeneous IP networks and 145 topologies. The NORM protocol design provides support for 146 distributed multicast session participation with minimal coordination 147 among senders and receivers. NORM allows senders and receivers to 148 dynamically join and leave multicast sessions at will with minimal 149 overhead for control information and timing synchronization among 150 participants. To accommodate this capability, NORM protocol message 151 headers contain some common information allowing receivers to easily 152 synchronize to senders throughout the lifetime of a reliable 153 multicast session. NORM is self-adapting to a wide range of dynamic 154 network conditions with little or no pre-configuration. The protocol 155 is tolerant of inaccurate timing estimations or lossy conditions that 156 can occur in many networks including mobile and wireless. The 157 protocol can also converge and maintain efficient operation even in 158 situations of heavy packet loss and large queuing or transmission 159 delays. This document obsoletes the Experimental RFC 3940 160 specification. 162 This document is a product of the IETF RMT working group and follows 163 the guidelines provided in the Author Guidelines for Reliable 164 Multicast Transport (RMT) Building Blocks and Protocol Instantiation 165 documents [RFC3269]. 167 Statement of Intent 169 This memo contains the definitions necessary to fully specify a 170 Reliable Multicast Transport protocol in accordance with the criteria 171 of IETF Criteria for Evaluating Reliable Multicast Transport and 172 Application Protocols [RFC2357]. The NORM specification described in 173 this document was previously published in the "Experimental Category" 174 [RFC3940]. It was the stated intent of the RMT working group to re- 175 submit this specifications as an IETF Proposed Standard in due 176 course. This Proposed Standard specification is thus based on RFC 177 3940 and has been updated according to accumulated experience and 178 growing protocol maturity since the publication of RFC 3940. Said 179 experience applies both to this specification itself and to 180 congestion control strategies related to the use of this 181 specification. The differences between RFC 3940 and this document 182 are listed in Section 10. 184 1.1. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 1.2. NORM Data Delivery Service Model 192 A NORM protocol instance (NormSession) is defined within the context 193 of participants communicating connectionless (e.g., Internet Protocol 194 (IP) or User Datagram Protocol (UDP)) packets over a network using 195 pre-determined addresses and host port numbers. Generally, the 196 participants exchange packets using an IP multicast group address, 197 but unicast transport MAY also be established or applied as an 198 adjunct to multicast delivery. In the case of multicast, the 199 participating NormNodes will communicate using a common IP multicast 200 group address and port number chosen via means outside the context of 201 the given NormSession. Other existing IETF data format and protocol 202 standards MAY be applied to describe and convey the necessary a 203 priori information for a specific NormSession (e.g., Session 204 Description Protocol (SDP) [RFC4566], Session Announcement Protocol 205 (SAP) [RFC2974], etc.). 207 The NORM protocol design is principally driven by the assumption of a 208 single sender transmitting bulk data content to a group of receivers. 209 However, the protocol MAY operate with multiple senders within the 210 context of a single NormSession. In initial implementations of this 211 protocol, it is anticipated multiple senders will transmit 212 independent of one another and receivers will maintain state as 213 necessary for each sender. In future versions of NORM, it is 214 possible some aspects of protocol operation (e.g., round-trip time 215 collection) will provide for alternate modes allowing more efficient 216 performance for applications requiring multiple senders. 218 NORM provides for three types of bulk data content objects 219 (NormObjects) to be reliably transported. These types include: 221 1. static computer memory data content ("NORM_OBJECT_DATA" type), 223 2. computer storage files ("NORM_OBJECT_FILE" type), and 225 3. non-finite streams of continuous data content 226 ("NORM_OBJECT_STREAM" type). 228 The distinction between "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE" is 229 simply to provide a hint to receivers in NormSessions serving 230 multiple types of content as to what type of storage to allocate for 231 received content (i.e., memory or file storage). Other than that 232 distinction, the two are identical, providing for reliable transport 233 of finite (but potentially very large) units of content. These 234 static data and file services are anticipated to be useful for 235 multicast-based cache applications with the ability to reliably 236 provide transmission of large quantities of static data. Other types 237 of static data/file delivery services might make use of these 238 transport object types, too. The use of the "NORM_OBJECT_STREAM" 239 type is at the application's discretion and could be used to carry 240 static data or file content also. The NORM reliable stream service 241 opens up additional possibilities such as serialized reliable 242 messaging or other unbounded, perhaps dynamically produced content. 243 The "NORM_OBJECT_STREAM" provides for reliable transport analogous to 244 that of the Transmission Control Protocol (TCP), although NORM 245 receivers will be able to begin receiving stream content at any point 246 in time. The applicability of this feature will depend upon the 247 application. 249 The NORM protocol also allows for a small amount of out-of-band data 250 (sent as "NORM_INFO" messages) to be attached to the data content 251 objects transmitted by the sender. This readily-available out-of- 252 band data allows multicast receivers to quickly and efficiently 253 determine the nature of the corresponding data, file, or stream bulk 254 content being transmitted. This allows application-level control of 255 the receiver node's participation in the current transport activity. 256 This also allows the protocol to be flexible with minimal pre- 257 coordination among senders and receivers. The "NORM_INFO" content is 258 atomic in that its size MUST fit into the payload portion of a single 259 NORM message. 261 NORM does NOT provide for global or application-level identification 262 of data content within in its message headers. Note the "NORM_INFO" 263 out-of-band data mechanism can be leveraged by the application for 264 this purpose if desired, or identification can alternatively be 265 embedded within the data content. NORM does identify transmitted 266 content (NormObjects) with transport identifiers that are applicable 267 only while the sender is transmitting and/or repairing the given 268 object. These transport data content identifiers (NormTransportIds) 269 are assigned in a monotonically increasing fashion by each NORM 270 sender during the course of a NormSession. Participants, including 271 senders, in NORM protocol sessions are also identified with unique 272 identifiers (NormNodeIds). Each sender maintains its NormTransportId 273 assignments independently and thus individual NormObjects can be 274 uniquely identified during transport by concatenation of the session- 275 unique sender identifier (NormNodeId) and the assigned 276 NormTransportId. The NormTransportIds are assigned from a large, but 277 fixed, numeric space in increasing order and will be reassigned 278 during long-lived sessions. The NORM protocol provides mechanisms so 279 the sender application can terminate transmission of data content and 280 inform the group of this in an efficient manner. Other similar 281 protocol control mechanisms (e.g., session termination, receiver 282 synchronization, etc.) are specified so reliable multicast 283 application variants can realize different, complete bulk transfer 284 communication models to meet their goals. 286 To summarize, the NORM protocol provides reliable transport of 287 different types of data content (including potentially mixed types). 288 The senders enqueue and transmit bulk content in the form of static 289 data or files and/or non-finite, ongoing stream types. NORM senders 290 provide for repair transmission of data and/or FEC content in 291 response to NACK messages received from the receiver group. 292 Mechanisms for out-of-band information and other transport control 293 mechanisms are specified for use by applications to form complete 294 reliable multicast solutions for different purposes. 296 1.3. NORM Scalability 298 Group communication scalability requirements lead to adaptation of 299 negative acknowledgment (NACK) based protocol schemes when feedback 300 for reliability is needed [RmComparison]. NORM is a protocol 301 centered around the use of selective NACKs to request repairs of 302 missing data. NORM provides for the use of packet-level forward 303 error correction (FEC) techniques for efficient multicast repair and 304 OPTIONAL proactive transmission robustness [RFC3453]. FEC-based 305 repair can be used to greatly reduce the quantity of reliable 306 multicast repair requests and repair transmissions [MdpToolkit] in a 307 NACK-oriented protocol. The principal factor in NORM scalability is 308 the volume of feedback traffic generated by the receiver set to 309 facilitate reliability and congestion control. NORM uses 310 probabilistic suppression of redundant feedback based on 311 exponentially distributed random backoff timers. The performance of 312 this type of suppression relative to other techniques is described in 313 [McastFeedback]. NORM dynamically measures the group's round-trip 314 timing status to set its suppression and other protocol timers. This 315 allows NORM to scale well while maintaining reliable data delivery 316 transport with low latency relative to the network topology over 317 which it is operating. 319 Feedback messages can be either multicast to the group at large or 320 sent via unicast routing to the sender. In the case of unicast 321 feedback, the sender relays the feedback state to the group to 322 facilitate feedback suppression. In typical Internet environments, 323 the NORM protocol will readily scale to group sizes on the order of 324 tens of thousands of receivers. A study of the quantity of feedback 325 for this type of protocol is described in [NormFeedback]. NORM is 326 able to operate with a smaller amount of feedback than a single TCP 327 connection, even with relatively large numbers of receivers. Thus, 328 depending upon the network topology, it is possible for NORM to scale 329 to larger group sizes. With respect to computer resource usage, the 330 NORM protocol does not need state to be kept on all receivers in the 331 group. NORM senders maintain state only for receivers providing 332 explicit congestion control feedback. However, NORM receivers need 333 to maintain state for each active sender. This can constrain the 334 number of simultaneous senders in some uses of NORM. 336 1.4. Environmental Requirements and Considerations 338 All of the environmental requirements and considerations that apply 339 to the Multicast NACK Building Block [RFC5401], FEC Building Block 340 [RFC5052], and TCP-Friendly Multicast Congestion Control (TFMCC) 341 Building Block [RFC4654] also apply to the NORM protocol. 343 The NORM protocol SHALL be capable of operating in an end-to-end 344 fashion with no assistance from intermediate systems beyond basic IP 345 multicast group management, routing, and forwarding services. While 346 the techniques utilized in NORM are principally applicable to flat, 347 end-to-end IP multicast topologies, they could also be applied in the 348 sub-levels of hierarchical (e.g., tree-based) multicast distribution 349 if so desired. NORM can make use of reciprocal (among senders and 350 receivers) multicast communication under the Any-Source Multicast 351 (ASM) model defined in Host Extensions for IP Multicasting [RFC1112], 352 but SHALL also be capable of scalable operation in asymmetric 353 topologies such as Source-Specific Multicast (SSM) [RFC4607] where 354 only unicast routing service is available from the receivers to the 355 sender(s). 357 NORM is compatible with IPv4 and IPv6. Additionally, NORM can be 358 used with networks employing Network Address Translation (NAT) 359 providing the NAT device supports IP multicast and/or can cache UDP 360 traffic source port numbers for remapping feedback traffic from 361 receivers to the sender(s). 363 2. Architecture Definition 365 A NormSession is comprised of participants (NormNodes) acting as 366 senders and/or receivers. NORM senders transmit data content in the 367 form of NormObjects to the session destination address and the NORM 368 receivers attempt to reliably receive the transmitted content using 369 negative acknowledgments to request repair. Each NormNode within a 370 NormSession is assumed to have a preselected unique 32-bit identifier 371 (NormNodeId). NormNodes MUST have uniquely assigned identifiers 372 within a single NormSession to distinguish between possible multiple 373 senders and to distinguish feedback information from different 374 receivers. There are two reserved NormNodeId values. A value of 375 "0x00000000" is considered an invalid NormNodeId ("NORM_NODE_NONE") 376 and a value of "0xffffffff" is a "wild card" NormNodeId 377 ("NORM_NODE_ANY"). While the protocol does not preclude multiple 378 sender nodes concurrently transmitting within the context of a single 379 NORM session (i.e., many- to-many operation), any type of interactive 380 coordination among NORM senders is assumed to be controlled by the 381 application or higher protocol layer. There are some OPTIONAL 382 mechanisms specified in this document that can be leveraged for such 383 application layer coordination. 385 As previously noted, NORM allows for reliable transmission of three 386 different basic types of data content. The first type is 387 "NORM_OBJECT_DATA", that is used for static, persistent blocks of 388 data content maintained in the sender's application memory storage. 389 The second type is "NORM_OBJECT_FILE", that corresponds to data 390 stored in the sender's non-volatile file system. The 391 "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE" types both represent 392 NormObjects of finite but potentially very large size. The third 393 type of data content is "NORM_OBJECT_STREAM", that corresponds to an 394 ongoing transmission of undefined length. This is analogous to the 395 reliable stream service provide by TCP for unicast data transport. 396 The format of the stream content is application-defined and can be 397 "byte" or "message" oriented. The NORM protocol provides for 398 "flushing" of the stream to expedite delivery or possibly enforce 399 application message boundaries. NORM protocol implementations MAY 400 offer either (or both) in-order delivery of the stream data to the 401 receive application or out-of-order (more immediate) delivery of 402 received segments of the stream to the receiver application. In 403 either case, NORM sender and receiver implementations provide 404 buffering to facilitate repair of the stream as it is transported. 406 All NormObjects are logically segmented into FEC coding blocks and 407 symbols for transmission by the sender. In NORM, an FEC encoding 408 symbol directly corresponds to the payload of "NORM_DATA" messages or 409 "segment". Note that when systematic FEC codes are used, the payload 410 of "NORM_DATA" messages sent for the first portion of a FEC encoding 411 block are source symbols (actual segments of original user data), 412 while the remaining symbols for the block consist of parity symbols 413 generated by FEC encoding. These parity symbols are generally sent 414 in response to repair requests, but some number MAY be sent 415 proactively at the end each encoding block to increase the robustness 416 of transmission. When non-systematic FEC codes are used, all symbols 417 sent consist of FEC encoding parity content. In this case, the 418 receiver needs to receive a sufficient number of symbols to 419 reconstruct (via FEC decoding) the original user data for the given 420 block. 422 Transmitted NormObjects are temporarily yet uniquely identified 423 within the NormSession context using the given sender's NormNodeId, 424 NormInstanceId, and a temporary NormTransportId. Depending upon the 425 implementation, individual NORM senders can manage their 426 NormInstanceIds independently, or a common NormInstanceId could be 427 agreed upon for all participating nodes within a session if needed as 428 a session identifier. NORM NormTransportId data content identifiers 429 are sender-assigned and applicable and valid only during a 430 NormObject's actual transport (i.e., for as long as the sender is 431 transmitting and providing repair of the indicated NormObject). For 432 a long-lived session, the NormTransportId field can wrap and 433 previously-used identifiers will be re-used. Note that globally 434 unique identification of transported data content is not provided by 435 NORM and, if necessary, is expected to be managed by the NORM 436 application. The individual segments or symbols of the NormObject 437 are further identified with FEC payload identifiers that include 438 coding block and symbol identifiers. These are discussed in detail 439 later in this document. 441 2.1. Protocol Operation Overview 443 A NORM sender primarily generates messages of type "NORM_DATA". 444 These messages carry original data segments or FEC symbols and repair 445 segments/symbols for the bulk data/file or stream NormObjects being 446 transferred. By default, redundant FEC symbols are sent only in 447 response to receiver repair requests (NACKs) and thus normally little 448 or no additional transmission overhead is imposed due to FEC 449 encoding. However, the NORM implementation MAY be configured to 450 proactively transmit some amount of redundant FEC symbols along with 451 the original content to potentially enhance performance (e.g., 452 improved delay) at the cost of additional transmission overhead. 453 This configuration is sensible for certain network conditions and can 454 allow for robust, asymmetric multicast (e.g., unidirectional routing, 455 satellite, cable) [FecHybrid] with reduced receiver feedback, or, in 456 some cases, no feedback. 458 A sender message of type "NORM_INFO" is also defined and is used to 459 carry OPTIONAL out-of-band context information for a given transport 460 object. A single "NORM_INFO" message can be associated with a 461 NormObject. Because of its atomic nature, missing "NORM_INFO" 462 messages can be NACKed and repaired with a slightly lower delay 463 process than NORM's general FEC-encoded data content. The 464 "NORM_INFO" message can serve special purposes for some bulk 465 transfer, reliable multicast applications where receivers join the 466 group mid-stream and need to ascertain contextual information on the 467 current content being transmitted. The NACK process for "NORM_INFO" 468 will be described later. When the "NORM_INFO" message type is used, 469 its transmission SHOULD precede transmission of any "NORM_DATA" 470 message for the associated NormObject. 472 The sender also generates messages of type "NORM_CMD" to assist in 473 certain protocol operations such as congestion control, end-of- 474 transmission flushing, group round trip time (GRTT) estimation, 475 receiver synchronization, and OPTIONAL positive acknowledgment 476 requests or application defined commands. The transmission of 477 "NORM_CMD" messages from the sender is accomplished by one of three 478 different procedures. These procedures are: single, best effort 479 unreliable transmission of the command; repeated redundant 480 transmissions of the command; and positively-acknowledged commands. 481 The transmission technique used for a given command depends upon the 482 function of the command. Several core commands are defined for basic 483 protocol operation. Additionally, implementations MAY wish to 484 consider providing the OPTIONAL application-defined commands that can 485 take advantage of the transmission methodologies available for 486 commands. This allows for application-level session management 487 mechanisms that can make use of information available to the 488 underlying NORM protocol engine (e.g., round-trip timing, 489 transmission rate, etc.). A notable distinction between "NORM_DATA" 490 message and some "NORM_CMD" message transmissions is that typically a 491 receiver will need to allocate resources to manage reliable reception 492 when "NORM_DATA" messages are received. However some "NORM_CMD" 493 messages are completely atomic and no specific reliability 494 (buffering) state needs to be kept. Thus, for session management or 495 other purposes it is possible that even participants acting 496 principally as data receivers MAY transmit "NORM_CMD" messages. 497 However, it is RECOMMENDED that this is not done within the context 498 of the NORM multicast session unless congestion control is addressed. 499 For example, many receiver nodes transmitting "NORM_CMD" messages 500 simultaneously can cause congestion for the destination(s). 502 All sender transmissions are subject to rate control governed by a 503 peak transmission rate set for each participant by the application. 504 This can be used to limit the quantity of multicast data transmitted 505 by the group. When NORM's congestion control algorithm is enabled 506 the rate for senders is automatically adjusted. In some networks, it 507 is desirable to establish minimum and maximum bounds for the rate 508 adjustment depending upon the application even when dynamic 509 congestion control is enabled. However, in the case of the general 510 Internet, congestion control policy SHALL be observed that is 511 compatible with coexistent TCP flows. 513 NORM receivers generate messages of type "NORM_NACK" or "NORM_ACK" in 514 response to transmissions of data and commands from a sender. The 515 "NORM_NACK" messages are generated to request repair of detected data 516 transmission losses. Receivers generally detect losses by tracking 517 the sequence of transmission from a sender. Sequencing information 518 is embedded in the transmitted data packets and end-of-transmission 519 commands from the sender. "NORM_ACK" messages are generated in 520 response to certain commands transmitted by the sender. In the 521 general (and most scalable) protocol mode, "NORM_ACK" messages are 522 sent only in response to congestion control commands from the sender. 523 The feedback volume of these congestion control "NORM_ACK" messages 524 is controlled using the same timer-based probabilistic suppression 525 techniques as for "NORM_NACK" messages to avoid feedback implosion. 526 In order to meet potential application requirements for positive 527 acknowledgment from receivers, other "NORM_ACK" messages are defined 528 and available for use. 530 2.2. Protocol Building Blocks 532 The operation of the NORM protocol is based primarily upon the 533 concepts presented in the Multicast NACK Building Block [RFC5401] 534 document. This includes the basic NORM architecture and the data 535 transmission, repair, and feedback strategies discussed in that 536 document. The reliable multicast building block approach, as 537 described in Reliable Multicast Transport Building Blocks for One-to- 538 Many Bulk-Data Transfer [RFC3048], is applied in creating the full 539 NORM protocol instantiation. NORM also makes use of the parity-based 540 encoding techniques for repair messaging and added transmission 541 robustness as described in The Use of Forward Error Correction (FEC) 542 in Reliable Multicast [RFC3453]. NORM uses the FEC Payload ID as 543 specified by the FEC Building Block document [RFC5052]. 544 Additionally, for congestion control, this document fully specifies a 545 baseline congestion control mechanism (NORM-CC) based on the TCP- 546 Friendly Multicast Congestion Control (TFMCC) scheme[TfmccPaper], 547 [RFC4654]. 549 2.3. Design Tradeoffs 551 While the various features of NORM provide some measure of general 552 purpose utility, it is important to emphasize the understanding that 553 "no one size fits all" in the reliable multicast transport arena. 554 There are numerous engineering trade-offs involved in reliable 555 multicast transport design and this necessitates an increased 556 awareness of application and network architecture considerations. 557 Performance requirements affecting design can include: group size, 558 heterogeneity (e.g., capacity and/or delay), asymmetric delivery, 559 data ordering, delivery delay, group dynamics, mobility, congestion 560 control, and transport across low capacity connections. NORM 561 contains various parameters to accommodate many of these differing 562 requirements. The NORM protocol and its mechanisms MAY be applied in 563 multicast applications outside of bulk data transfer, but there is an 564 assumed model of bulk transfer transport service that drives the 565 trade-offs that determine the scalability and performance described 566 in this document. 568 The ability of NORM to provide reliable data delivery is also 569 governed by any buffer constraints of the sender and receiver 570 applications. NORM protocol implementations SHOULD operate with the 571 greatest efficiency and robustness possible within application- 572 defined buffer constraints. Buffer requirements for reliability, as 573 always, are a function of the delay-bandwidth product of the network 574 topology. NORM performs best when allowed more buffering resources 575 than typical point-to-point transport protocols. This is because 576 NORM feedback suppression is based upon randomly-delayed 577 transmissions from the receiver set, rather than immediately 578 transmitted feedback. There are definitive trade-offs between buffer 579 utilization, group size scalability, and efficiency of performance. 580 Large buffer sizes allow the NORM protocol to perform most 581 efficiently in large delay-bandwidth topologies and allow for longer 582 feedback suppression backoff timeouts. This yields improved group 583 size scalability. NORM can operate with reduced buffering but at a 584 cost of decreased efficiency (lower relative goodput) and reduced 585 group size scalability. 587 3. Conformance Statement 589 This RMT Protocol Instantiation document, in conjunction with the 590 Multicast Negative-Acknowledgment (NACK) [RFC5401] and Forward Error 591 Correction (FEC) [RFC5052] Building Blocks, completely specifies a 592 working reliable multicast transport protocol that conforms to the 593 requirements described in RFC 2357. 595 This document specifies the following message types and mechanisms 596 that are REQUIRED in complying NORM protocol implementations: 598 +------------------------+------------------------------------------+ 599 | Message Type | Purpose | 600 +------------------------+------------------------------------------+ 601 | "NORM_DATA" | Sender message for application data | 602 | | transmission. Implementations MUST | 603 | | support at least one of the | 604 | | "NORM_OBJECT_DATA", "NORM_OBJECT_FILE", | 605 | | or "NORM_OBJECT_STREAM" delivery | 606 | | services. The use of the NORM FEC | 607 | | Object Transmission Information header | 608 | | extension is OPTIONAL with "NORM_DATA" | 609 | | messages. | 610 | "NORM_CMD(FLUSH)" | Sender command to excite receivers for | 611 | | repair requests in lieu of ongoing | 612 | | "NORM_DATA" transmissions. Note the use | 613 | | of the "NORM_CMD(FLUSH)" for positive | 614 | | acknowledgment of data receipt is | 615 | | OPTIONAL. | 616 | "NORM_CMD(SQUELCH)" | Sender command to advertise its current | 617 | | valid repair window in response to | 618 | | invalid requests for repair. | 619 | "NORM_CMD(REPAIR_ADV)" | Sender command to advertise current | 620 | | repair (and congestion control state) to | 621 | | group when unicast feedback messages are | 622 | | detected. Used to control/suppress | 623 | | excessive receiver feedback in | 624 | | asymmetric multicast topologies. | 625 | "NORM_CMD(CC)" | Sender command used in collection of | 626 | | round trip timing and congestion control | 627 | | status from group (this is OPTIONAL if | 628 | | alternative congestion control mechanism | 629 | | and round trip timing collection is | 630 | | used). | 631 | "NORM_NACK" | Receiver message used to request repair | 632 | | of missing transmitted content. | 633 | "NORM_ACK" | Receiver message used to proactively | 634 | | provide feedback for congestion control | 635 | | purposes. Also used with the OPTIONAL | 636 | | NORM Positive Acknowledgment Process. | 637 +------------------------+------------------------------------------+ 639 This document also describes the following message types and 640 associated mechanisms that are OPTIONAL for complying NORM protocol 641 implementations: 643 +-------------------------+-----------------------------------------+ 644 | Message Type | Purpose | 645 +-------------------------+-----------------------------------------+ 646 | "NORM_INFO" | Sender message for providing ancillary | 647 | | context information associated with | 648 | | NORM transport objects. The use of the | 649 | | NORM FEC Object Transmission | 650 | | Information header extension is | 651 | | OPTIONAL with "NORM_INFO" messages. | 652 | "NORM_CMD(EOT)" | Sender command to indicate it has | 653 | | reached end-of-transmission and will no | 654 | | longer respond to repair requests. | 655 | "NORM_CMD(ACK_REQ)" | Sender command to support | 656 | | application-defined, positively | 657 | | acknowledged commands sent outside of | 658 | | the context of the bulk data content | 659 | | being transmitted. The NORM Positive | 660 | | Acknowledgment Procedure associated | 661 | | with this message type is OPTIONAL. | 662 | "NORM_CMD(APPLICATION)" | Sender command containing | 663 | | application-defined commands sent | 664 | | outside of the context of the bulk data | 665 | | content being transmitted. | 666 | "NORM_REPORT" | Optional message type reserved for | 667 | | experimental implementations of the | 668 | | NORM protocol. | 669 +-------------------------+-----------------------------------------+ 671 4. Message Formats 673 There are two primary classes of NORM messages (see Section 2.1): 674 sender messages and receiver messages. "NORM_CMD", "NORM_INFO", and 675 "NORM_DATA" message types are generated by senders of data content, 676 and "NORM_NACK" and "NORM_ACK" messages generated by receivers within 677 a NormSession. Sender messages SHALL be governed by congestion 678 control for Internet use. For session management or other purposes, 679 receivers can also employ "NORM_CMD" message transmissions. The 680 principal rationale for distinguishing sender and receiver messages 681 is that receivers will typically need to allocate resources to 682 support reliable reception from sender(s) and NORM sender messages 683 are subject to congestion control. NORM receivers MAY employ the 684 "NORM_CMD" message type for application-defined purposes but it is 685 RECOMMENDED that congestion control and feedback implosion issues be 686 addressed. Additionally, an auxiliary message type of "NORM_REPORT" 687 is also provided for experimental purposes. This section describes 688 the message formats used by the NORM protocol. These messages and 689 their fields are referenced in the detailed functional description of 690 the NORM protocol given in Section 5. Individual NORM messages are 691 compatible with the Maximum Transmission Unit (MTU) limitations of 692 encapsulating Internet protocols including IPv4, IPv6, and UDP. The 693 current NORM protocol specification assumes UDP encapsulation and 694 leverages the transport features of UDP. The NORM messages are 695 independent of network addresses and can be used in IPv4 and IPv6 696 networks. 698 4.1. NORM Common Message Header and Extensions 700 There are some common message fields contained in all NORM message 701 types. Additionally, a header extension mechanism is defined to 702 expand the functionality of the NORM protocol without revision to 703 this document. All NORM protocol messages begin with a common header 704 with information fields as follows: 705 0 1 2 3 706 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 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 |version| type | hdr_len | sequence | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | source_id | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 NORM Common Message Header Format 715 The "version" field is a 4-bit value indicating the protocol version 716 number. NORM implementations SHOULD ignore received messages with 717 version numbers different from their own. This number is intended to 718 indicate and distinguish upgrades of the protocol that are non- 719 interoperable. The NORM version number for this specification is 1. 721 The message "type" field is a 4-bit value indicating the NORM 722 protocol message type. These types are defined as follows: 724 +------------------+------------------+ 725 | Message | Value | 726 +------------------+------------------+ 727 | "NORM_INFO" | 1 | 728 | "NORM_DATA" | 2 | 729 | "NORM_CMD" | 3 | 730 | "NORM_NACK" | 4 | 731 | "NORM_ACK" | 5 | 732 | "NORM_REPORT" | 6 | 733 +------------------+------------------+ 735 The 8-bit "hdr_len" field indicates the number of 32-bit words that 736 comprise the given message's header portion. This is used to 737 facilitate addition of header extensions. The presence of header 738 extensions are implied when the "hdr_len" value is greater than the 739 base value for the given message "type". 741 The "sequence" field is a 16-bit value that is set by the message 742 originator. The "sequence" field serves two separate purposes, 743 depending upon the message type: 745 1. NORM senders MUST set the "sequence" field of sender messages 746 ("NORM_INFO", "NORM_DATA", and "NORM_CMD") so that receivers can 747 monitor the "sequence" value to maintain an estimate of packet 748 loss that can be used for congestion control purposes (See 749 Section 5.5.2 for a detailed description of NORM Congestion 750 Control operation). A monotonically-increasing sequence number 751 space MUST be maintained to mark NORM sender messages in this 752 way. Note that this "sequence" number is explicitly NOT used in 753 NORM as part of its reliability procedures. The NORM object and 754 FEC payload identifiers are used to detect missing content for 755 reliable transfer purposes. 757 2. NORM receivers SHOULD set the "sequence" field to support 758 protection from message replay attacks of "NORM_NACK" or 759 "NORM_NACK" messages. Note that, depending upon configuration, 760 NORM feedback messages are sent to the session multicast address 761 or the unicast address[es] of the active NORM sender[s]. Thus, a 762 separate, monotonically-increasing sequence number space MUST be 763 maintained for each destination address to which the NORM 764 receiver is transmitting feedback messages. 766 Note that these two separate purposes necessitate the maintenance of 767 separate sequence spaces to support the functions described here. 768 And, in the case of NORM receivers, additional sequence spaces are 769 needed when feedback messages are sent to the sender unicast 770 address[es] instead of the session address. 772 The "source_id" field is a 32-bit value that uniquely identifies the 773 node that sent the message within the context of a single 774 NormSession. This value is termed the NORM node identifier 775 (NormNodeId) and unique NormNodeId identifiers MUST be assigned 776 within a single NormSession. In some cases, use of the host IPv4 777 address or a hash of an address can suffice, but alternative 778 methodologies for assignment and potential collision resolution of 779 node identifiers within a multicast session SHOULD be considered. 780 For example, the techniques for managing the 32-bit "synchronization 781 source" (SSRC) identifiers defined in the Real-Time Protocol (RTP) 782 specification [RFC3550] are applicable for use with NORM node 783 identifiers. In most deployments of the NORM protocol to date, the 784 NormNodeId assignments are administratively configured. 786 NORM Header Extensions 788 When header extensions are applied, they follow the message type's 789 base header and precede any payload portion. There are two formats 790 for header extensions, both of which begin with an 8-bit "het" 791 (header extension type) field. One format is provided for variable- 792 length extensions with "het" values in the range from 0 through 127. 793 The other format is for fixed length (one 32-bit word) extensions 794 with "het" values in the range from 128 through 255. 796 For variable-length extensions, the value of the "hel" field is the 797 length of the entire header extension, expressed in multiples of 32- 798 bit words. The "hel" field MUST be present for variable-length 799 extensions ("het" between 0 and 127) and MUST NOT be present for 800 fixed-length extensions ("het" between 128 and 255). 802 The formats of the variable-length and fixed-length header extensions 803 are given, respectively, here: 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | het <=127 | hel | | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 809 | Header Extension Content | 810 | ... | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 NORM Variable Length Header Extension Format 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | het >=128 | reserved | Header Extension Content | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 NORM Fixed Length (32-bit) Header Extension Format 823 The "Header Extension Content" portion of the header extension is 824 defined for each extension type. Some header extensions are defined 825 within this document for NORM baseline FEC and congestion control 826 operations. 828 4.2. Sender Messages 830 NORM sender messages include the "NORM_DATA" type, the "NORM_INFO" 831 type, and the "NORM_CMD" type. "NORM_DATA" and "NORM_INFO" messages 832 contain application data content while "NORM_CMD" messages are used 833 for various protocol control functions. 835 4.2.1. NORM_DATA Message 837 The "NORM_DATA" message is generally the predominant type transmitted 838 by NORM senders. These messages are used to encapsulate segmented 839 data content for objects of type "NORM_OBJECT_DATA", 840 "NORM_OBJECT_FILE", and "NORM_OBJECT_STREAM". "NORM_DATA" messages 841 contain original or FEC-encoded application data content. 843 The format of "NORM_DATA" messages is comprised of three logical 844 portions: 1) a fixed-format "NORM_DATA" header portion, 2) a FEC 845 Payload ID portion with a format dependent upon the FEC encoding 846 used, and 3) a payload portion containing source or encoded 847 application data content. Note for objects of type 848 "NORM_OBJECT_STREAM", the payload portion contains additional fields 849 used to appropriately recover stream content. NORM implementations 850 MAY also extend the "NORM_DATA" header to include a FEC Object 851 Transmission Information (EXT_FTI) header extension. This allows 852 NORM receivers to automatically allocate resources and properly 853 perform FEC decoding without the need for pre-configuration or out- 854 of-band information. 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 |version| type=2| hdr_len | sequence | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | source_id | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | instance_id | grtt |backoff| gsize | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | flags | fec_id | object_transport_id | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | fec_payload_id | 867 | ... | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | header_extensions (if applicable) | 870 | ... | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | payload_len* | payload_msg_start* | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | payload_offset* | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | payload_data* | 877 | ... | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 NORM_DATA Message Format 882 *IMPORTANT NOTE: The "payload_len", "payload_msg_start" and 883 "payload_offset" fields are present only for objects of type 884 "NORM_OBJECT_STREAM". These fields, as with the entire payload, are 885 subject to any FEC encoding used. Thus, when systematic FEC codes 886 are used, these values can be directly interpreted only for packets 887 containing source symbols while packets containing FEC parity content 888 need decoding before these fields can be interpreted. 890 The "version", "type", "hdr_len", "sequence", and "source_id" fields 891 form the NORM Common Message Header as described in Section 4.1. The 892 value of the "NORM_DATA" "type" field is 2. The "NORM_DATA" base 893 "hdr_len" value is 4 (i.e. 4 32-bit words) plus the size of the 894 "fec_payload_id" field. The "fec_payload_id" field size depends upon 895 the FEC encoding type referenced by the "fec_id" field. For example, 896 when small block, systematic codes are used, a "fec_id" value of 129 897 is indicated and the size of the "fec_payload_id" is two 32-bit 898 words. In this case the "NORM_DATA" base "hdr_len" value is 6. The 899 cumulative size of any header extensions applied is added into the 900 "hdr_len" field. 902 The "instance_id" field contains a value generated by the sender to 903 uniquely identify its current instance of participation in the 904 NormSession. This allows receivers to detect when senders have 905 perhaps left and rejoined a session in progress. When a sender 906 (identified by its "source_id") is detected to have a new 907 "instance_id", the NORM receivers SHOULD drop their previous state on 908 the sender and begin reception anew, or at least treat this 909 "instance" as a new, separate sender. 911 The "grtt" field contains a non-linear quantized representation of 912 the sender's current estimate of group round-trip time 913 ("GRTT_sender") (this is also referred to as "R_max" in 914 [TfmccPaper]). This value is used to control timing of the NACK 915 repair process and other aspects of protocol operation as described 916 in this document. Normally, the advertised "grtt" value will 917 correspond to what the sender has measured based on feedback from the 918 group, but, at low transmission rates, the advertised "grtt" SHALL be 919 set to "MAX(grttMeasured, NormSegmentSize/senderRate)" where the 920 "NormSegmentSize" is sender's segment size in bytes and the 921 "senderRate" is the sender's current transmission rate in bytes per 922 second. The algorithm for encoding and decoding this field is 923 described in the Multicast NACK Building Block [RFC5401]. 925 The "backoff" field value is used by receivers to determine the 926 maximum backoff timer value used in the timer-based NORM NACK 927 feedback suppression. This 4-bit field supports values from 0-15 928 that is multiplied by "GRTT_sender" to determine the maximum backoff 929 timeout. The "backoff" field informs the receivers of the sender's 930 backoff factor parameter ("K_sender"). Recommended values and their 931 use are described in the NORM receiver NACK procedure description in 932 Section 5.3. 934 The "gsize" field contains a representation of the sender's current 935 estimate of group size ("GSIZE_sender"). This 4-bit field can 936 roughly represent values from ten to 500 million where the most 937 significant bit value of 0 or 1 represents a mantissa of 1 or 5, 938 respectively and the three least significant bits incremented by one 939 represent a base 10 exponent (order of magnitude). For examples, a 940 field value of "0x0" represents 1.0e+01 (10), a value of "0x8" 941 represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02 (100), 942 and a value of "0xf" represents 5.0e+08. For NORM feedback 943 suppression purposes, the group size does not need to be represented 944 with a high degree of precision. The group size MAY even be 945 estimated somewhat conservatively (i.e., overestimated) to maintain 946 low levels of feedback traffic. A default group size estimate of 947 10,000 ("gsize" = 0x3) is RECOMMENDED for general purpose reliable 948 multicast applications using the NORM protocol. 950 The "flags" field contains a number of different binary flags 951 providing information and hints for the receiver to appropriately 952 handle the identified object. Defined flags in this field include: 954 +------------------------+-------+----------------------------------+ 955 | Flag | Value | Purpose | 956 +------------------------+-------+----------------------------------+ 957 | "NORM_FLAG_REPAIR" | 0x01 | Indicates message is a repair | 958 | | | transmission | 959 | "NORM_FLAG_EXPLICIT" | 0x02 | Indicates a repair segment | 960 | | | intended to meet a specific | 961 | | | receiver erasure, as compared to | 962 | | | parity segments provided by the | 963 | | | sender for general purpose (with | 964 | | | respect to an FEC coding block) | 965 | | | erasure filling. | 966 | "NORM_FLAG_INFO" | 0x04 | Indicates availability of | 967 | | | "NORM_INFO" for object. | 968 | "NORM_FLAG_UNRELIABLE" | 0x08 | Indicates that repair | 969 | | | transmissions for the specified | 970 | | | object will be unavailable | 971 | | | (One-shot, best effort | 972 | | | transmission). | 973 | "NORM_FLAG_FILE" | 0x10 | Indicates object is file-based | 974 | | | data (hint to use disk storage | 975 | | | for reception). | 976 | "NORM_FLAG_STREAM" | 0x20 | Indicates object is of type | 977 | | | "NORM_OBJECT_STREAM". | 978 +------------------------+-------+----------------------------------+ 980 "NORM_FLAG_REPAIR" is set when the associated message is a repair 981 transmission. This information can be used by receivers to help 982 observe a join policy where it is desired that newly joining 983 receivers only begin participating in the NACK process upon receipt 984 of new (non-repair) data content. "NORM_FLAG_EXPLICIT" is used to 985 mark repair messages sent when the data sender has exhausted its 986 ability to provide "fresh" (not previously transmitted) parity 987 segments as repair. This flag could possibly be used by intermediate 988 systems implementing functionality to control sub-casting of repair 989 content to different legs of a reliable multicast topology with 990 disparate repair needs. "NORM_FLAG_INFO" is set only when OPTIONAL 991 "NORM_INFO" content is actually available for the associated object. 992 Thus, receivers will NACK for retransmission of "NORM_INFO" only when 993 it is available for a given object. "NORM_FLAG_UNRELIABLE" is set 994 when the sender wishes to transmit an object with only "best effort" 995 delivery and will not supply repair transmissions for the object. 996 NORM receivers SHOULD NOT execute repair requests for objects marked 997 with the "NORM_FLAG_UNRELIABLE" flag. There are cases where 998 receivers can inadvertently request repair of such objects when all 999 segments (or info content) for those objects are not received (i.e., 1000 a gap in the "object_transport_id" sequence is noted). In this case, 1001 the sender SHALL invoke the "NORM_CMD(SQUELCH)" process as described 1002 in Section 4.2.3. 1004 "NORM_FLAG_FILE" can be set as a hint from the sender that the 1005 associated object SHOULD be stored in non-volatile storage. 1006 "NORM_FLAG_STREAM" is set when the identified object is of type 1007 "NORM_OBJECT_STREAM". The presence of "NORM_FLAG_STREAM" overrides 1008 that of "NORM_FLAG_FILE" with respect to interpretation of object 1009 size and the format of "NORM_DATA" messages. 1011 The "fec_id" field corresponds to the FEC Encoding Identifier 1012 described in the FEC Building Block document [RFC5052]. The "fec_id" 1013 value implies the format of the "fec_payload_id" field and, coupled 1014 with FEC Object Transmission Information, the procedures to decode 1015 FEC encoded content. Small block, systematic codes ("fec_id" = 129) 1016 are expected to be used for most NORM purposes and systematic FEC 1017 codes are RECOMMENDED for most efficient performance of 1018 "NORM_OBJECT_STREAM" transport. 1020 The "object_transport_id" field is a monotonically and incrementally 1021 increasing value assigned by the sender to NormObjects being 1022 transmitted. Transmissions and repair requests related to that 1023 object use the same "object_transport_id" value. For sessions of 1024 very long or indefinite duration, the "object_transport_id" field 1025 will wrap and be repeated, but it is presumed that the 16-bit field 1026 size provides a sufficient sequence space to avoid object confusion 1027 amongst receivers and sources (i.e., receivers SHOULD re-synchronize 1028 with a server when receiving object sequence identifiers sufficiently 1029 out-of-range with the current state kept for a given source). During 1030 the course of its transmission within a NORM session, an object is 1031 uniquely identified by the concatenation of the sender "source_id" 1032 and the given "object_transport_id". Note that "NORM_INFO" messages 1033 associated with the identified object carry the same 1034 "object_transport_id" value. 1036 The "fec_payload_id" identifies the attached "NORM_DATA" "payload" 1037 content. The size and format of the "fec_payload_id" field depends 1038 upon the FEC type indicated by the "fec_id" field. These formats are 1039 given in the descriptions of specific FEC schemes such as those 1040 described in the FEC Basic Schemes [RFC5445] specification or in 1041 other FEC Schemes. As an example, the format of the "fec_payload_id" 1042 format for Small Block, Systematic codes ("fec_id" = 129) from theFEC 1043 Basic Schemes [RFC5445] specification is given here: 1044 0 1 2 3 1045 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 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | source_block_number | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | source_block_len | encoding_symbol_id | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 Example: FEC Payload Id Format for 'fec_id' = 129 1054 In this example FEC payload identifier, the "source_block_number", 1055 "source_block_len", and "encoding_symbol_id" fields correspond to the 1056 "Source Block Number", "Source Block Length, and "Encoding Symbol ID" 1057 fields of the FEC Payload ID format for Small Block Systematic FEC 1058 Schemes identified by a "fec_id" value of 129 as specified by the FEC 1059 Basic Schemes [RFC5445] specification. The "source_block_number" 1060 identifies the coding block's relative position with a NormObject. 1061 Note that, for NormObjects of type "NORM_OBJECT_STREAM", the 1062 "source_block_number" will wrap for very long lived sessions. The 1063 "source_block_len" indicates the number of user data segments in the 1064 identified coding block. Given the "source_block_len" information of 1065 how many symbols of application data are contained in the block, the 1066 receiver can determine whether the attached segment is data or parity 1067 content and treat it appropriately. Applications MAY dynamically 1068 "shorten" code blocks when the pending information content is not 1069 predictable (e.g. real-time message streams). In that case, the 1070 "source_block_len" value given for an "encoding_symbol_id" that 1071 contains FEC parity content SHALL take precedence over the 1072 "source_block_len" value provided for any packets containing source 1073 symbols. Also, the "source_block_len" value given for an ordinally 1074 higher "encoding_symbol_id" SHALL take precedence over the 1075 "source_block_len" given for prior encoding symbols. The reason for 1076 this is that the sender will only know the maximum source block 1077 length at the time is transmitting source symbols, but then 1078 subsequently "shorten" the code and then provide that last source 1079 symbol and/or encoding symbols with FEC parity content. The 1080 "encoding_symbol_id" identifies which specific symbol (segment) 1081 within the coding block the attached payload conveys. Depending upon 1082 the value of the "encoding_symbol_id" and the associated 1083 "source_block_len" parameters for the block, the symbol (segment) 1084 referenced will be a user data or an FEC parity segment. For 1085 systematic codes, encoding symbols numbered less than the 1086 "source_block_len" contain original application data while segments 1087 greater than or equal to "source_block_len" contain parity symbols 1088 calculated for the block. The concatenation of 1089 "object_transport_id::fec_payload_id" can be viewed as a unique 1090 transport protocol data unit identifier for the attached segment with 1091 respect to the NORM sender's instance within a session. 1093 Additional FEC Object Transmission Information (FTI) (as described in 1094 the FEC Building Block [RFC5052]) is needed to properly receive and 1095 decode NORM transport objects. This information MAY be provided as 1096 out-of-band session information. In some cases, it will be useful 1097 for the sender to include this information "in-band" to facilitate 1098 receiver operation with minimal pre-configuration. For this purpose, 1099 the NORM FEC Object Transmission Information Header Extension 1100 (EXT_FTI) is defined. This header extension MAY be applied to 1101 "NORM_DATA" and "NORM_INFO" messages to provide this necessary 1102 information. The format of the EXT_FTI consists of two parts, a 1103 general part that contains the size of the associated transport 1104 object and a portion that depends upon the FEC scheme being used. 1105 The "fec_id" field in "NORM_DATA" and "NORM_INFO" messages identifies 1106 the FEC scheme. The format of the EXT_FTI general part is given 1107 here. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | het = 64 | hel = 4 | object_size (msb) | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | object_size (lsb) | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | FEC Scheme specific content ... | 1118 EXT_FTI Header Extension General Portion Format 1120 The header extension type "het" field value for the EXT_FTI header 1121 extension is 64. The header extension length "hel" value depends 1122 upon the format of the FTI for encoding type identified by the 1123 "fec_id" field. 1125 The 48-bit "object_size" field indicates the total length of the 1126 object (in bytes) for the static object types of "NORM_OBJECT_FILE" 1127 and "NORM_OBJECT_DATA". This information is used by receivers to 1128 determine storage requirements and/or allocate storage for the 1129 received object. Receivers with insufficient storage capability 1130 might wish to forego reliable reception (i.e., not NACK for) of the 1131 indicated object. In the case of objects of type 1132 "NORM_OBJECT_STREAM", the "object_size" field is used by the sender 1133 to advertise the size of its stream buffer to the receiver group. In 1134 turn, the receivers SHOULD use this information to allocate a stream 1135 buffer for reception of corresponding size. 1137 As noted, the format of the extension depends upon the FEC code in 1138 use, but in general it contains any necessary details on the code in 1139 use (e.g., FEC Instance ID, etc.). As an example, the format of the 1140 EXT_FTI for small block systematic codes ("fec_id" = 129) is given 1141 here: 1142 0 1 2 3 1143 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 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | het = 64 | hel = 4 | object_size (msb) | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | object_size (lsb) | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | fec_instance_id | segment_size | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | fec_max_block_len | fec_num_parity | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 Example: EXT_FTI Header Extension Format for 'fec_id' = 129 1156 In this example (for "fec_id" = 129), the "hel" field value is 4. 1157 The size of the EXT_FTI header extension will possibly be different 1158 for other FEC schemes. 1160 The 48-bit "object_size" serves the purpose described previously. 1162 The "fec_instance_id" corresponds to the "FEC Instance ID" described 1163 in the FEC Building Block [RFC5052]. In this case, the 1164 "fec_instance_id" is a value corresponding to the particular type of 1165 Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), 1166 Reed-Solomon GF(2^16), etc). The standardized assignment of FEC 1167 Instance ID values is described in RFC 5052. 1169 The "segment_size" field indicates the sender's current setting for 1170 maximum message payload content (in bytes). This allows receivers to 1171 allocate appropriate buffering resources and to determine other 1172 information in order to properly process received data messaging. 1173 Typically, FEC parity symbol segments will be of this size. 1175 The "fec_max_block_len" indicates the current maximum number of user 1176 data segments per FEC coding block to be used by the sender during 1177 the session. This allows receivers to allocate appropriate buffer 1178 space for buffering blocks transmitted by the sender. 1180 The "fec_num_parity" corresponds to the "maximum number of encoding 1181 symbols that can be generated for any source block" as described in 1182 for FEC Object Transmission Information for Small Block Systematic 1183 Codes in the FEC Building Block [RFC5052]. For example, Reed-Solomon 1184 codes can be arbitrarily shortened to create different code 1185 variations for a given block length. In the case of Reed-Solomon 1186 (GF(2^8) and GF(2^16)) codes, this value indicates the maximum number 1187 of parity segments available from the sender for the coding blocks. 1188 This field MAY be interpreted differently for other systematic codes 1189 as they are defined. 1191 The payload portion of "NORM_DATA" messages includes source data or 1192 FEC encoded application content. The content of this payload depends 1193 upon the FEC scheme being employed, and support for streaming using 1194 the "NORM_OBJECT_STREAM" type, when applicable, necessitates some 1195 additional content in the payload. 1197 The "payload_len", "payload_msg_start", and "payload_offset" fields 1198 are present only for transport objects of type "NORM_OBJECT_STREAM". 1199 These REQUIRED fields allow senders to arbitrarily vary the size of 1200 "NORM_DATA" payload segments for streams. This allows applications 1201 to flush transmitted streams as needed to meet unique streaming 1202 requirements. For objects of types "NORM_OBJECT_FILE" and 1203 "NORM_OBJECT_DATA", these fields are unnecessary since the receiver 1204 can calculate the payload length and offset information from the 1205 "fec_payload_id" using the REQUIRED block partitioning algorithm 1206 described in the FEC Building Block [RFC5052]. When systematic FEC 1207 codes (e.g., "fec_id" = 129) are used, the "payload_len", 1208 "payload_msg_start", and "payload_offset" fields contain actual 1209 payload_data length, message start index (or stream control code), 1210 and byte offset values for the associated application stream data 1211 segment (the remainder of the "payload_data" field content) for those 1212 "NORM_DATA" messages containing source data symbols. In "NORM_DATA" 1213 messages that contain FEC parity content, these fields do not contain 1214 values that can be directly interpreted, but instead are values 1215 computed from FEC encoding the "payload_len", "payload_msg_start", 1216 and "payload_offset" fields for the source data segments of the 1217 corresponding coding block. The actual "payload_msg_start", 1218 "payload_len" and "payload_offset" values of missing data content can 1219 be determined upon decoding a FEC coding block. Note that these 1220 fields do NOT contribute to the value of the "NORM_DATA" "hdr_len" 1221 field. These fields are present only when the "flags" portion of the 1222 "NORM_DATA" message indicate the transport object is of type 1223 "NORM_OBJECT_STREAM". 1225 The "payload_len" value, when non-zero, indicates the length (in 1226 bytes) of the source content contained in the associated 1227 "payload_data" field. However, when the "payload_len" value is equal 1228 to "ZERO", this indicates that the "payload_msg_start" field be 1229 alternatively interpreted as a "stream_control_code". The only 1230 "stream_control_code" value defined is "NORM_STREAM_END = 0". The 1231 "NORM_STREAM_END" code indicates that the sender is terminating 1232 transmission of stream content at the corresponding position in the 1233 stream and the receiver MUST NOT expect content (or request repair 1234 for any content) following that position in the stream. Additional 1235 specifications MAY extend the functionality of the NORM stream 1236 transport mode by defining additional stream control codes. These 1237 control codes are delivered to the recipient application reliably, 1238 in-order with respect to the streamed application data content. 1240 The "payload_msg_start" field serves one of two exclusive purposes. 1241 When the "payload_len" value is non-zero, the "payload_msg_start" 1242 field, when also set to a non-zero value, indicates that the 1243 associated "payload_data" content contains an application-defined 1244 message boundary (start-of-message). When such a message boundary is 1245 indicated, the first byte of an application-defined message, with 1246 respect to the "payload_data" field, will be found at an offset of 1247 "payload_msg_start - 1" bytes. Thus, if a "NORM_DATA" payload for a 1248 "NORM_OBJECT_STREAM" contains the start of an application message at 1249 the first byte of the "payload_data" field, the value of the 1250 "payload_msg_start" field will be '1'. NORM implementations SHOULD 1251 provide sender stream applications with a capability to mark message 1252 boundaries in this manner. Similarly, the NORM receiver 1253 implementation SHOULD enable the application to recover such message 1254 boundary information. This enables NORM receivers to "synchronize" 1255 reliable reception of transmitted message stream content in a 1256 meaningful way (i.e., meaningful to the application) at any time, 1257 whether joining a session already in progress, or departing the 1258 session and returning. Note that if the value of the 1259 "payload_msg_start" field is "ZERO", no message boundary is present. 1260 The "payload_msg_start" value will always be less than or equal to 1261 the "payload_len" value except for the special case of "payload_len = 1262 0", that indicates the "payload_msg_start" field be instead 1263 interpreted as a "stream_control_code" 1265 The "payload_offset" field indicates the relative byte position (from 1266 the sender stream transmission start) of the source content contained 1267 in the "payload_data" field. Note that for long-lived streams, the 1268 "payload_offset" field will wrap. 1270 The "payload_data" field contains the original application source or 1271 parity content for the symbol identified by the "fec_payload_id". 1272 The length of this field SHALL be limited to a maximum of the 1273 sender's NormSegmentSize bytes as given in the FTI for the object. 1274 Note the length of this field for messages containing parity content 1275 will always be of length NormSegmentSize. When encoding data 1276 segments of varying sizes, the FEC encoder SHALL assume "ZERO" value 1277 padding for data segments with length less than the NormSegmentSize. 1279 It is RECOMMENDED that a sender's NormSegmentSize generally be 1280 constant for the duration of a given sender's term of participation 1281 in the session, but can possibly vary on a per-object basis. The 1282 NormSegmentSize SHOULD be configurable by the sender application 1283 prior to session participation as needed for network topology MTU 1284 considerations. For IPv6, MTU discovery MAY be possibly leveraged at 1285 session startup to perform this configuration. The "payload_data" 1286 content MAY be delivered directly to the application for source 1287 symbols (when systematic FEC encoding is used) or upon decoding of 1288 the FEC block. For "NORM_OBJECT_FILE" and "NORM_OBJECT_STREAM" 1289 objects, the data segment length and offset can be calculated using 1290 the block partitioning algorithm described in the FEC Building Block 1291 [RFC5052]. For "NORM_OBJECT_STREAM" objects, the length and offset 1292 is obtained from the segment's corresponding embedded "payload_len" 1293 and "payload_offset" fields. 1295 4.2.2. NORM_INFO Message 1297 The "NORM_INFO" message is used to convey OPTIONAL, application- 1298 defined, out-of-band context information for transmitted NormObjects. 1299 An example "NORM_INFO" use for bulk file transfer is to place MIME 1300 type information for the associated file, data, or stream object into 1301 the "NORM_INFO" payload. Receivers could then use the "NORM_INFO" 1302 content to make a decision as whether to participate in reliable 1303 reception of the associated object. Each NormObject can have an 1304 independent unit of "NORM_INFO" associated with it. "NORM_DATA" 1305 messages contain a flag to indicate the availability of "NORM_INFO" 1306 for a given NormObject. NORM receivers will NACK for retransmission 1307 of "NORM_INFO" when they have not received it for a given NormObject. 1308 The size of the "NORM_INFO" content is limited to that of a single 1309 NormSegmentSize for the given sender. This atomic nature allows the 1310 "NORM_INFO" to be rapidly and efficiently repaired within the NORM 1311 reliable transmission process. 1313 When "NORM_INFO" content is available for a NormObject, the 1314 NORM_FLAG_INFO flag SHALL be set in "NORM_DATA" messages for the 1315 corresponding "object_transport_id" and the "NORM_INFO" message SHALL 1316 be transmitted as the first message for the NormObject. 1318 0 1 2 3 1319 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 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 |version| type=1| hdr_len | sequence | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | source_id | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | instance_id | grtt |backoff| gsize | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | flags | fec_id | object_transport_id | 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 | header_extensions (if applicable) | 1330 | ... | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | payload_data | 1333 | ... | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 NORM_INFO Message Format 1338 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1339 form the NORM Common Message Header as described in Section 4.1. The 1340 value of "hdr_len" field when no header extensions are present is 4. 1342 The "instance_id", "grtt", "backoff", "gsize", "flags", "fec_id", and 1343 "object_transport_id" fields carry the same information and serve the 1344 same purpose as with "NORM_DATA" messages. These values allow the 1345 receiver to prepare appropriate buffering, etc, for further 1346 transmissions from the sender when "NORM_INFO" is the first message 1347 received. 1349 As with "NORM_DATA" messages, the NORM FTI Header Extension (EXT_FTI) 1350 MAY be optionally applied to "NORM_INFO" messages. To conserve 1351 protocol overhead, NORM implementations MAY apply the EXT_FTI when 1352 used to "NORM_INFO" messages only and not to "NORM_DATA" messages. 1354 The "NORM_INFO" "payload_data" field contains sender application- 1355 defined content that can be used by receiver applications for various 1356 purposes as described above. 1358 4.2.3. NORM_CMD Messages 1360 "NORM_CMD" messages are transmitted by senders to perform a number of 1361 different protocol functions. This includes functions such as round- 1362 trip timing collection, congestion control functions, synchronization 1363 of sender/receiver repair "windows", and notification of sender 1364 status. A core set of "NORM_CMD" messages is enumerated. 1365 Additionally, a range of command types remain available for potential 1366 application-specific use. Some "NORM_CMD" types can have dynamic 1367 content attached. Any attached content will be limited to maximum 1368 length of the sender NormSegmentSize to retain the atomic nature of 1369 commands. All "NORM_CMD" messages begin with a common set of fields, 1370 after the usual NORM message common header. The standard "NORM_CMD" 1371 fields are: 1372 0 1 2 3 1373 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 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 |version| type=3| hdr_len | sequence | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1377 | source_id | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 | instance_id | grtt |backoff| gsize | 1380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1381 | sub-type | | 1382 +-+-+-+-+-+-+-+-+ NORM_CMD Content + 1383 | ... | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 NORM_CMD Standard Fields 1388 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1389 form the NORM Common Message Header as described in Section 4.1. The 1390 value of the "hdr_len" field for "NORM_CMD" messages without header 1391 extensions present depends upon the "sub-type" field. 1393 The "instance_id", "grtt", "backoff", and "gsize" fields provide the 1394 same information and serve the same purpose as with "NORM_DATA" and 1395 "NORM_INFO" messages. The "sub-type" field indicates the type of 1396 command to follow. The remainder of the "NORM_CMD" message is 1397 dependent upon the command sub-type. NORM command sub-types include: 1399 +-------------------------+----------+------------------------------+ 1400 | Command | Sub-type | Purpose | 1401 +-------------------------+----------+------------------------------+ 1402 | "NORM_CMD(FLUSH)" | 1 | Used to indicate sender | 1403 | | | temporary | 1404 | | | end-of-transmission. | 1405 | | | (Assists in robustly | 1406 | | | initiating outstanding | 1407 | | | repair requests from | 1408 | | | receivers). May also be | 1409 | | | optionally used to collect | 1410 | | | positive acknowledgment of | 1411 | | | reliable reception from | 1412 | | | subset of receivers. | 1413 | "NORM_CMD(EOT)" | 2 | Used to indicate sender | 1414 | | | permanent | 1415 | | | end-of-transmission. | 1416 | "NORM_CMD(SQUELCH)" | 3 | Used to advertise sender's | 1417 | | | current repair window in | 1418 | | | response to out-of-range | 1419 | | | NACKs from receivers. | 1420 | "NORM_CMD(CC)" | 4 | Used for GRTT measurement | 1421 | | | and collection of congestion | 1422 | | | control feedback. | 1423 | "NORM_CMD(REPAIR_ADV)" | 5 | Used to advertise sender's | 1424 | | | aggregated repair/feedback | 1425 | | | state for suppression of | 1426 | | | unicast feedback from | 1427 | | | receivers. | 1428 | "NORM_CMD(ACK_REQ)" | 6 | Used to request | 1429 | | | application-defined positive | 1430 | | | acknowledgment from a list | 1431 | | | of receivers (OPTIONAL). | 1432 | "NORM_CMD(APPLICATION)" | 7 | Used for application-defined | 1433 | | | purposes that need to | 1434 | | | temporarily preempt or | 1435 | | | supplement data transmission | 1436 | | | (OPTIONAL). | 1437 +-------------------------+----------+------------------------------+ 1439 4.2.3.1. NORM_CMD(FLUSH) Message 1441 The "NORM_CMD(FLUSH)" command is sent when the sender reaches the end 1442 of all data content and pending repairs it has queued for 1443 transmission. This can indicate either a temporary or permanent end 1444 of data transmission, but the sender is still willing to respond to 1445 repair requests. This command is repeated once per "2*GRTT_sender" 1446 to excite the receiver set for any outstanding repair requests up to 1447 and including the transmission point indicated within the 1448 "NORM_CMD(FLUSH)" message. The number of repeats is equal to 1449 "NORM_ROBUST_FACTOR" unless a list of receivers from which explicit 1450 positive acknowledgment is expected ("acking_node_list") is given. 1451 In that case, the "acking_node_list" is updated as acknowledgments 1452 are received and the "NORM_CMD(FLUSH)" is repeated according to the 1453 mechanism described in Section 5.5.3. The greater the 1454 "NORM_ROBUST_FACTOR", the greater the probability that all applicable 1455 receivers will be excited for acknowledgment or repair requests 1456 (NACKs) AND that the corresponding NACKs are delivered to the sender. 1457 A default value of "NORM_ROBUST_FACTOR" equal to 20 is RECOMMENDED. 1458 If a "NORM_NACK" message interrupts the flush process, the sender 1459 SHALL re-initiate the flush process after any resulting repair 1460 transmissions are completed. 1462 Note that receivers also employ a timeout mechanism to self-initiate 1463 NACKing (if there are outstanding repair needs) when no messages of 1464 any type are received from a sender. This inactivity timeout is 1465 related to the "NORM_CMD(FLUSH)" and "NORM_ROBUST_FACTOR" and is 1466 specified in Section 5.3. Receivers SHALL self-initiate the NACK 1467 repair process when the inactivity timeout has expired for a specific 1468 sender and the receiver has pending repairs needed from that sender. 1469 With a sufficiently large "NORM_ROBUST_FACTOR" value, data content is 1470 delivered with a high assurance of reliability. The penalty of a 1471 large "NORM_ROBUST_FACTOR" value is the potential transmission of 1472 excess "NORM_CMD(FLUSH)" messages and a longer inactivity timeout for 1473 receivers to self-initiate a terminal NACK process. 1475 For finite-size transport objects such as "NORM_OBJECT_DATA" and 1476 "NORM_OBJECT_FILE", the flush process (if there are no further 1477 pending objects) occurs at the end of these objects. Thus, FEC 1478 repair information is always available for repairs in response to 1479 repair requests elicited by the flush command. However, for 1480 "NORM_OBJECT_STREAM", the flush can occur at any time, including in 1481 the middle of an FEC coding block if systematic FEC codes are 1482 employed. In this case, the sender will not yet be able to provide 1483 FEC parity content for the concurrent coding block and will be 1484 limited to explicitly repairing the stream with source data content 1485 for that block. Applications that anticipate frequent flushing of 1486 stream content SHOULD be judicious in the selection of the FEC coding 1487 block size (i.e., do not use a very large coding block size if 1488 frequent flushing occurs). For example, a reliable multicast 1489 application transmitting an on-going series of intermittent, 1490 relatively small messages will need to trade-off using the 1491 "NORM_OBJECT_DATA" paradigm versus the "NORM_OBJECT_STREAM" paradigm 1492 with an appropriate FEC coding block size. This is analogous to 1493 application trade-offs for other transport protocols such as the 1494 selection of different TCP modes of operation such as "no delay", 1495 etc. 1497 0 1 2 3 1498 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 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 |version| type=3| hdr_len | sequence | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | source_id | 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | instance_id | grtt |backoff| gsize | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | sub-type = 1 | fec_id | object_transport_id | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | fec_payload_id | 1509 | ... | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | acking_node_list (if applicable) | 1512 | ... | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 NORM_CMD(FLUSH) Message Format 1517 The "version", "type", "hdr_len", "sequence", and "source_id" fields 1518 form the NORM Common Message Header as described in Section 4.1. In 1519 addition to the NORM common message header and standard "NORM_CMD" 1520 fields, the "NORM_CMD(FLUSH)" message contains fields to identify the 1521 current status and logical transmit position of the sender. 1523 The "fec_id" field indicates the FEC type used for the flushing 1524 "object_transport_id" and implies the size and format of the 1525 "fec_payload_id" field. Note the "hdr_len" value for the 1526 "NORM_CMD(FLUSH)" message is 4 plus the size of the "fec_payload_id" 1527 field when no header extensions are present. 1529 The "object_transport_id" and "fec_payload_id" fields indicate the 1530 sender's current logical "transmit position". These fields are 1531 interpreted in the same manner as in the "NORM_DATA" message type. 1532 Upon receipt of the "NORM_CMD(FLUSH)", receivers are expected to 1533 check their completion state THROUGH (including) this transmission 1534 position. If receivers have outstanding repair needs in this range, 1535 they SHALL initiate the NORM NACK Repair Process as described in 1536 Section 5.3. If receivers have no outstanding repair needs, no 1537 response to the "NORM_CMD(FLUSH)" is generated. 1539 For "NORM_OBJECT_STREAM" objects using systematic FEC codes, 1540 receivers MUST request "explicit-only" repair of the identified 1541 "source_block_number" if the given "encoding_symbol_id" is less than 1542 the "source_block_len". This condition indicates the sender has not 1543 yet completed encoding the corresponding FEC block and parity content 1544 is not yet available. An "explicit-only" repair request consists of 1545 NACK content for the applicable "source_block_number" that does not 1546 include any requests for parity-based repair. This allows NORM 1547 sender applications to "flush" an ongoing stream of transmission when 1548 needed, even if in the middle of an FEC block. Once the sender 1549 resumes stream transmission and passes the end of the pending coding 1550 block, subsequent NACKs from receivers SHALL request parity-based 1551 repair as usual. Note that the use of a systematic FEC code is 1552 assumed here. Note that a sender has the option of arbitrarily 1553 shortening a given code block when such an application "flush" 1554 occurs. In this case, the receiver will request explicit repair, but 1555 the sender MAY provide FEC-based repair (parity segments) in 1556 response. These parity segments MUST contain the corrected 1557 "source_block_len" for the shortened block and that 1558 "source_block_len" associated with segments containing parity content 1559 SHALL override the previously advertised "source_block_len". 1560 Similarly, the "source_block_len" associated with the highest ordinal 1561 "encoding_symbol_id" SHALL take precedence over prior symbols when a 1562 difference (e.g., due to code shortening at the sender) occurs. 1563 Normal receiver NACK initiation and construction is discussed in 1564 detail in Section 5.3. 1566 The OPTIONAL "acking_node_list" field contains a list of NormNodeIds 1567 for receivers from which the sender is requesting explicit positive 1568 acknowledgment of reception up through the transmission point 1569 identified by the "object_transport_id" and "fec_payload_id" fields. 1570 The length of the list can be inferred from the length of the 1571 received "NORM_CMD(FLUSH)" message. When the "acking_node_list" is 1572 present, the lightweight positive acknowledgment process described in 1573 Section 5.5.3 SHALL be observed. 1575 4.2.3.2. NORM_CMD(EOT) Message 1577 The "NORM_CMD(EOT)" command is sent when the sender reaches permanent 1578 end-of-transmission with respect to the NormSession and will not 1579 respond to further repair requests. This allows receivers to 1580 gracefully reach closure of operation with this sender (without 1581 requiring any timeout) and free any resources that are no longer 1582 needed. The "NORM_CMD(EOT)" command SHOULD be sent with the same 1583 robust mechanism as used for "NORM_CMD(FLUSH)" commands to provide a 1584 high assurance of reception by the receiver set. 1586 0 1 2 3 1587 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 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 |version| type=3| hdr_len | sequence | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | source_id | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | instance_id | grtt |backoff| gsize | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | sub-type = 2 | reserved | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 NORM_CMD(EOT) Message Format 1600 The value of the "hdr_len" field for "NORM_CMD(EOT)" messages without 1601 header extensions present is 4. The "reserved" field is reserved for 1602 future use and MUST be set to an all "ZERO" value. Receivers MUST 1603 ignore the "reserved" field. 1605 4.2.3.3. NORM_CMD(SQUELCH) Message 1607 The "NORM_CMD(SQUELCH)" command is transmitted in response to 1608 outdated or invalid "NORM_NACK" content received by the sender. 1609 Invalid "NORM_NACK" content consists of repair requests for 1610 NormObjects for which the sender is unable or unwilling to provide 1611 repair. This includes repair requests for outdated objects, aborted 1612 objects, or those objects that the sender previously transmitted 1613 marked with the "NORM_FLAG_UNRELIABLE" flag. This command indicates 1614 to receivers what content is available for repair, thus serving as a 1615 description of the sender's current "repair window". Receivers SHALL 1616 NOT generate repair requests for content identified as invalid by a 1617 "NORM_CMD(SQUELCH)". 1619 The "NORM_CMD(SQUELCH)" command is sent once per "2*GRTT_sender" at 1620 the most. The "NORM_CMD(SQUELCH)" advertises the current "repair 1621 window" of the sender by identifying the earliest (lowest) 1622 transmission point for which it will provide repair, along with an 1623 encoded list of objects from that point forward that are no longer 1624 valid for repair. This mechanism allows the sender application to 1625 cancel or abort transmission and/or repair of specific previously 1626 enqueued objects. The list also contains the identifiers for any 1627 objects within the repair window that were sent with the 1628 "NORM_FLAG_UNRELIABLE" flag set. In normal conditions, the 1629 "NORM_CMD(SQUELCH)" will be needed infrequently, and generally only 1630 to provide a reference repair window for receivers who have fallen 1631 "out-of-sync" with the sender due to extremely poor network 1632 conditions. 1634 The starting point of the invalid NormObject list begins with the 1635 lowest invalid NormTransportId greater than the current "repair 1636 window" start from the invalid NACK(s) that prompted the generation 1637 of the squelch. The length of the list is limited by the sender's 1638 NormSegmentSize. This allows the receivers to learn the status of 1639 the sender's applicable object repair window with minimal 1640 transmission of "NORM_CMD(SQUELCH)" commands. The format of the 1641 "NORM_CMD(SQUELCH)" message is: 1642 0 1 2 3 1643 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 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 |version| type=3| hdr_len | sequence | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | source_id | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | instance_id | grtt |backoff| gsize | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | sub-type = 3 | fec_id | object_transport_id | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 | fec_payload_id | 1654 | ... | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | invalid_object_list | 1657 | ... | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 NORM_CMD(SQUELCH) Message Format 1662 In addition to the NORM common message header and standard "NORM_CMD" 1663 fields, the "NORM_CMD(SQUELCH)" message contains fields to identify 1664 the earliest logical transmit position of the sender's current repair 1665 window and an "invalid_object_list" beginning with the index of the 1666 logically earliest invalid repair request from the offending NACK 1667 message that initiated the "NORM_CMD(SQUELCH)" transmission. The 1668 value of the "hdr_len" field when no extensions are present is 4 plus 1669 the size of the "fec_payload_id" field that is dependent upon the FEC 1670 scheme identified by the "fec_id" field. 1672 The "object_transport_id" and "fec_payload_id" fields are 1673 concatenated to indicate the beginning of the sender's current repair 1674 window (i.e., the logically earliest point in its transmission 1675 history for which the sender can provide repair). The "fec_id" field 1676 implies the size and format of the "fec_payload_id" field. This 1677 serves as an advertisement of a "synchronization" point for receivers 1678 to request repair. Note, that while an "encoding_symbol_id" MAY be 1679 included in the "fec_payload_id" field, the sender's repair window 1680 SHOULD be aligned on FEC coding block boundaries and thus the 1681 "encoding_symbol_id" SHOULD be zero. 1683 The "invalid_object_list" is a list of 16-bit NormTransportIds that, 1684 although they are within the range of the sender's current repair 1685 window, are no longer available for repair from the sender. For 1686 example, a sender application MAY dequeue an out-of-date object even 1687 though it is still within the repair window. The total size of the 1688 "invalid_object_list" content is can be determined from the packet's 1689 payload length and is limited to a maximum of the NormSegmentSize of 1690 the sender. Thus, for very large repair windows, it is possible that 1691 a single "NORM_CMD(SQUELCH)" message cannot include the entire set of 1692 invalid objects in the repair window. In this case, the sender SHALL 1693 ensure that the list begins with a NormObjectId that is greater than 1694 or equal to the lowest ordinal invalid NormObjectId from the NACK 1695 message(s) that prompted the "NORM_CMD(SQUELCH)" generation. The 1696 NormObjectIds in the "invalid_object_list" MUST be ordinally greater 1697 than the "object_transport_id" marking the beginning of the sender's 1698 repair window. This insures convergence of the squelch process, even 1699 if multiple invalid NACK/ squelch iterations are required. This 1700 explicit description of invalid content within the sender's current 1701 window allows the sender application (most notably for discrete 1702 object transport) to arbitrarily invalidate (i.e., dequeue) portions 1703 of enqueued content (e.g., certain objects) for which it no longer 1704 wishes to provide reliable transport. 1706 4.2.3.4. NORM_CMD(CC) Message 1708 The "NORM_CMD(CC)" messages contains fields to enable sender-to-group 1709 GRTT measurement and to excite the group for congestion control 1710 feedback. A baseline NORM congestion control scheme (NORM-CC), based 1711 on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme of 1712 RFC 4654 is fully specified in Section 5.5.2 of this document. The 1713 "NORM_CMD(CC)" message is usually transmitted as part of NORM-CC 1714 congestion control operation. A NORM header extension is defined 1715 below to be used with the "NORM_CMD(CC)" message to support NORM-CC 1716 operation. Different header extensions MAY be defined for the 1717 "NORM_CMD(CC)" (and/or other NORM messages as needed) to support 1718 alternative congestion control schemes in the future. If NORM is 1719 operated in a network where resources are explicitly dedicated to the 1720 NORM session and therefore congestion control operation is disabled, 1721 the "NORM_CMD(CC)" message is then used solely for GRTT measurement 1722 and MAY be sent less frequently than with congestion control 1723 operation. 1725 0 1 2 3 1726 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 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 |version| type=3| hdr_len | sequence | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | source_id | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | instance_id | grtt |backoff| gsize | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | sub-type = 4 | reserved | cc_sequence | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | send_time_sec | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | send_time_usec | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | header extensions (if applicable) | 1741 | ... | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | cc_node_list (if applicable) | 1744 | ... | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 NORM_CMD(CC) Message Format 1749 The NORM common message header and standard "NORM_CMD" fields serve 1750 their usual purposes. The value of the "hdr_len" field when no 1751 header extensions are present is 6. 1753 The "reserved" field is for potential future use and MUST be set to 1754 "ZERO" in this version of the NORM protocol and its baseline NORM-CC 1755 congestion control scheme. It is possible for alternative congestion 1756 control schemes to use the "NORM_CMD(CC)" message defined here and 1757 leverage the "reserved" field for scheme-specific purposes. 1759 The "cc_sequence" field is a sequence number applied by the sender. 1760 For NORM-CC operation, it is used to provide functionality equivalent 1761 to the "feedback round number" ("fb_nr") described in RFC 4654. The 1762 most recently received "cc_sequence" value is recorded by receivers 1763 and can be fed back to the sender in congestion control feedback 1764 generated by the receivers for that sender. The "cc_sequence" number 1765 can also be used in NORM implementations to assess how recently a 1766 receiver has received "NORM_CMD(CC)" probes from the sender. This 1767 can be useful instrumentation for complex or experimental multicast 1768 routing environments. 1770 The "send_time" field is a timestamp indicating the time that the 1771 "NORM_CMD(CC)" message was transmitted. This consists of a 64-bit 1772 field containing 32-bits with the time in seconds ("send_time_sec") 1773 and 32-bits with the time in microseconds ("send_time_usec") since 1774 some reference time the source maintains (usually 00:00:00, 1 January 1775 1970). The byte ordering of the fields is "Big Endian" network 1776 order. Receivers use this timestamp adjusted by the amount of delay 1777 from the time they received the "NORM_CMD(CC)" message to the time of 1778 their response as the "grtt_response" portion of "NORM_ACK" and 1779 "NORM_NACK" messages generated. This allows the sender to evaluate 1780 round-trip times to different receivers for congestion control and 1781 other (e.g., GRTT determination) purposes. 1783 To facilitate the baseline NORM-CC scheme described in Section 5.5.2, 1784 a NORM-CC Rate header extension (EXT_RATE) is defined to inform the 1785 group of the sender's current transmission rate. This is used along 1786 with the loss detection "sequence" field of all NORM sender messages 1787 and the "NORM_CMD(CC)" GRTT collection process to support NORM-CC 1788 congestion control operation. The format of this header extension is 1789 as follows: 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | het = 128 | reserved | send_rate | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 The "send_rate" field indicates the sender's current transmission 1797 rate in bytes per second. The 16-bit "send_rate" field consists of 1798 12 bits of mantissa in the most significant portion and 4 bits of 1799 base 10 integer exponent (E) information in the least significant 1800 portion. The 12-bit mantissa portion of the field is scaled such 1801 that a base 10 mantissa (M) floating point value of 0.0 corresponds 1802 to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of 1803 the 16-bit "send_rate" field. Thus: 1805 send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E; 1807 For example, to represent a transmission rate of 256kbps (3.2e+04 1808 bytes per second), the lower 4 bits of the 16-bit field contain a 1809 value of 0x04 to represent the exponent (E) while the upper 12 bits 1810 contain a value of 0x51f (M) as determined from the equation given 1811 above: 1812 send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4; 1813 = (0x51f << 4) | 0x4 1814 = 0x51f4 1816 To decode the "send_rate" field, the following equation can be used: 1817 value = (send_rate >> 4) * (10/4096) * power(10, (send_rate & x000f)) 1819 Note the maximum transmission rate that can be represented by this 1820 scheme is approximately 9.99e+15 bytes per second. 1822 When this extension is present, a "cc_node_list" might be attached as 1823 the payload of the "NORM_CMD(CC)" message. The presence of this 1824 header extension also implies that NORM receivers MUST respond 1825 according to the procedures described in Section 5.5.2. 1827 The "cc_node_list" consists of a list of NormNodeIds and their 1828 associated congestion control status. This includes the current 1829 limiting receiver (CLR) node, any potential limiting receiver (PLR) 1830 nodes that have been identified, and some number of receivers for 1831 which congestion control status is being provided, most notably 1832 including the receivers' current RTT measurement. The maximum length 1833 of the "cc_node_list" provides for at least the CLR and one other 1834 receiver, but can be increased for more timely feedback to the group. 1835 The list length can be inferred from the length of the "NORM_CMD(CC)" 1836 message. 1838 Each item in the "cc_node_list" is in the following format: 1839 0 1 2 3 1840 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 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | cc_node_id | 1843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 | cc_flags | cc_rtt | cc_rate | 1845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 The "cc_node_id" is the NormNodeId of the receiver the item 1848 represents. 1850 The "cc_flags" field contains flags indicating the congestion control 1851 status of the indicated receiver. The following flags are defined: 1853 +----------------------+-------+------------------------------------+ 1854 | Flag | Value | Purpose | 1855 +----------------------+-------+------------------------------------+ 1856 | "NORM_FLAG_CC_CLR" | 0x01 | Receiver is the current limiting | 1857 | | | receiver (CLR). | 1858 | "NORM_FLAG_CC_PLR" | 0x02 | Receiver is a potential limiting | 1859 | | | receiver (PLR). | 1860 | "NORM_FLAG_CC_RTT" | 0x04 | Receiver has measured RTT with | 1861 | | | respect to sender. | 1862 | "NORM_FLAG_CC_START" | 0x08 | Sender/receiver is in "slow start" | 1863 | | | phase of congestion control | 1864 | | | operation (i.e., The receiver has | 1865 | | | not yet detected any packet loss | 1866 | | | and the "cc_rate" field is the | 1867 | | | receiver's actual measured receive | 1868 | | | rate). | 1869 | "NORM_FLAG_CC_LEAVE" | 0x10 | Receiver is imminently leaving the | 1870 | | | session and its feedback SHOULD | 1871 | | | not be considered in congestion | 1872 | | | control operation. | 1873 +----------------------+-------+------------------------------------+ 1875 The "cc_rtt" contains a quantized representation of the RTT as 1876 measured by the sender with respect to the indicated receiver. This 1877 field is valid only if the "NORM_FLAG_CC_RTT" flag is set in the 1878 "cc_flags" field. This one byte field is a quantized representation 1879 of the RTT using the algorithm described in the Multicast NACK 1880 Building Block [RFC5401]. 1882 The "cc_rate" field contains a representation of the receiver's 1883 current calculated (during steady-state congestion control operation) 1884 or twice its measured (during the slow start phase) congestion 1885 control rate. This field is encoded and decoded using the same 1886 technique as described for the "NORM_CMD(CC)" "send_rate" field. 1888 4.2.3.5. NORM_CMD(REPAIR_ADV) Message 1890 The "NORM_CMD(REPAIR_ADV)" message is used by the sender to 1891 "advertise" its aggregated repair state from "NORM_NACK" messages 1892 accumulated during a repair cycle and/or congestion control feedback 1893 received. This message is sent only when the sender has received 1894 "NORM_NACK" and/or "NORM_ACK(CC)" (when congestion control is 1895 enabled) messages via unicast transmission instead of multicast. By 1896 relaying this information to the receiver set, suppression of 1897 feedback can be achieved even when receivers are unicasting that 1898 feedback instead of multicasting it among the group [NormFeedback]. 1899 0 1 2 3 1900 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 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 |version| type=3| hdr_len | sequence | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | source_id | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | instance_id | grtt |backoff| gsize | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | sub-type = 5 | flags | reserved | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | header extensions (if applicable) | 1911 | ... | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 | repair_adv_payload | 1914 | ... | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 NORM_CMD(REPAIR_ADV) Message Format 1918 The "instance_id", "grtt", "backoff", "gsize", and "sub-type" fields 1919 serve the same purpose as in other "NORM_CMD" messages. The value of 1920 the "hdr_len" field when no extensions are present is 4. 1922 The "flags" field provide information on the "NORM_CMD(REPAIR_ADV)" 1923 content. There is currently one "NORM_CMD(REPAIR_ADV)" flag defined: 1924 NORM_REPAIR_ADV_FLAG_LIMIT = 0x01 1926 This flag is set by the sender when it is unable to fit its full 1927 current repair state into a single NormSegmentSize. If this flag is 1928 set, receivers SHALL limit their NACK response to generating NACK 1929 content only up through the maximum ordinal transmission position 1930 (objectId::fecPayloadId) included in the "repair_adv_content". 1932 When congestion control operation is enabled, a header extension 1933 SHOULD be applied to the "NORM_CMD(REPAIR_ADV)" representing the most 1934 limiting (in terms of congestion control feedback suppression) 1935 congestion control response. This allows the "NORM_CMD(REPAIR_ADV)" 1936 message to suppress receiver congestion control responses as well as 1937 NACK feedback messages. The field is defined as a header extension 1938 so that alternative congestion control schemes can be used for NORM 1939 without revision to this document. A NORM-CC Feedback Header 1940 Extension (EXT_CC) is defined to encapsulate congestion control 1941 feedback within "NORM_NACK", "NORM_ACK", and "NORM_CMD(REPAIR_ADV)" 1942 messages. If another congestion control technique (e.g., Pragmatic 1943 General Multicast Congestion Control (PGMCC) [PgmccPaper]) is used 1944 within a NORM implementation, an additional header extension MAY need 1945 to be defined encapsulate any required feedback content. The NORM-CC 1946 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 The "cc_sequence" field contains the current greatest "cc_sequence" 1958 value receivers have received in "NORM_CMD(CC)" messages from the 1959 sender. This information assists the sender in congestion control 1960 operation by providing an indicator of how current ("fresh") the 1961 receiver's round-trip measurement reference time is and whether the 1962 receiver has been successfully receiving recent congestion control 1963 probes. For example, if it is apparent the receiver has not been 1964 receiving recent congestion control probes (and thus possibly other 1965 messages from the sender), the sender SHOULD choose to take 1966 congestion avoidance measures. For "NORM_CMD(REPAIR_ADV)" messages, 1967 the sender SHALL set the "cc_sequence" field value to the value set 1968 in the last "NORM_CMD(CC)" message sent. 1970 The "cc_flags" field contains bits representing the receiver's state 1971 with respect to congestion control operation. The possible values 1972 for the "cc_flags" field are those specified for the "NORM_CMD(CC)" 1973 message node list item flags. These fields are used by receivers in 1974 controlling (suppressing as necessary) their congestion control 1975 feedback. For "NORM_CMD(REPAIR_ADV)" messages, the 1976 "NORM_FLAG_CC_RTT" SHALL be set only when all feedback messages 1977 received by the sender have the flag set. Similarly, the 1978 "NORM_FLAG_CC_CLR" or "NORM_FLAG_CC_PLR" SHALL be set only when no 1979 feedback has been received from non-CLR or non-PLR receivers. And 1980 the "NORM_FLAG_CC_LEAVE" SHALL be set only when all feedback messages 1981 the sender has received have this flag set. These heuristics for 1982 setting the flags in "NORM_CMD(REPAIR_ADV)" ensure the most effective 1983 suppression of receivers providing unicast feedback messages. 1985 The "cc_rtt" field SHALL be set to a default maximum value and the 1986 "NORM_FLAG_CC_RTT" flag SHALL be cleared when no receiver has yet 1987 received RTT measurement information. When a receiver has received 1988 RTT measurement information, it SHALL set the "cc_rtt" value 1989 accordingly and set the "NORM_FLAG_CC_RTT" flag in the "cc_flags" 1990 field. For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the 1991 "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has 1992 measured from receivers for the current feedback round. 1994 The "cc_loss" field represents the receiver's current packet loss 1995 fraction estimate for the indicated source. The loss fraction is a 1996 value from 0.0 to 1.0 corresponding to a range of zero to 100 percent 1997 packet loss. The 16-bit "cc_loss" value is calculated by the 1998 following formula: 2000 "cc_loss" = floor(decimal_loss_fraction * 65535.0) 2002 For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the 2003 "cc_loss" field value to the largest non-CLR/non-PLR loss estimate it 2004 has received from receivers for the current feedback round. 2006 The "cc_rate" field represents the receivers current local congestion 2007 control rate. During "slow start", when the receiver has detected no 2008 loss, this value is set to twice the actual rate it has measured from 2009 the corresponding sender and the "NORM_FLAG_CC_START" is set in the 2010 "cc_flags' field. Otherwise, the receiver calculates a congestion 2011 control rate based on its loss measurement and RTT measurement 2012 information (even if default) for the "cc_rate" field. For 2013 "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the "cc_loss" 2014 field value to the lowest non-CLR/non-PLR "cc_rate" report it has 2015 received from receivers for the current feedback round. 2017 The "cc_reserved" field is reserved for future NORM protocol use. 2018 Currently, senders SHALL set this field to "ZERO", and receivers 2019 SHALL ignore the content of this field. 2021 The "repair_adv_payload" is in exactly the same form as the 2022 "nack_content" of "NORM_NACK" messages and can be processed by 2023 receivers for suppression purposes in the same manner, with the 2024 exception of the condition when the "NORM_REPAIR_ADV_FLAG_LIMIT" is 2025 set. 2027 4.2.3.6. NORM_CMD(ACK_REQ) Message 2029 The "NORM_CMD(ACK_REQ)" message is used by the sender to request 2030 acknowledgment from a specified list of receivers. This message is 2031 used in providing a lightweight positive acknowledgment mechanism 2032 that is OPTIONAL for use by the reliable multicast application. A 2033 range of acknowledgment request types is provided for use at the 2034 application's discretion. Provision for application-defined, 2035 positively-acknowledged commands allows the application to 2036 automatically take advantage of transmission and round-trip timing 2037 information available to the NORM protocol. The details of the NORM 2038 positive acknowledgment process including transmission of the 2039 "NORM_CMD(ACK_REQ)" messages and the receiver response ("NORM_ACK") 2040 are described in Section 5.5.3. The format of the 2041 "NORM_CMD(ACK_REQ)" message is: 2042 0 1 2 3 2043 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 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 |version| type=3| hdr_len | sequence | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | source_id | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | instance_id | grtt |backoff| gsize | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | sub-type = 6 | reserved | ack_type | ack_id | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | acking_node_list | 2054 | ... | 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 NORM_CMD(ACK_REQ) Message Format 2059 The NORM common message header and standard "NORM_CMD" fields serve 2060 their usual purposes. The value of the "hdr_len" field for 2061 "NORM_CMD(ACK_REQ)" messages with no header extension present is 4. 2063 The "ack_type" field indicates the type of acknowledgment being 2064 requested and thus implies rules for how the receiver will treat this 2065 request. The following "ack_type" values are defined and are also 2066 used in "NORM_ACK" messages described later: 2068 +------------------------+------------+-----------------------------+ 2069 | ACK Type | Value | Purpose | 2070 +------------------------+------------+-----------------------------+ 2071 | "NORM_ACK_CC" | 1 | Used to identify "NORM_ACK" | 2072 | | | messages sent in response | 2073 | | | to "NORM_CMD(CC)" messages. | 2074 | "NORM_ACK_FLUSH" | 2 | Used to identify "NORM_ACK" | 2075 | | | messages sent in response | 2076 | | | to "NORM_CMD(FLUSH)" | 2077 | | | messages. | 2078 | "NORM_ACK_RESERVED" | 3-15 | Reserved for possible | 2079 | | | future NORM protocol use. | 2080 | "NORM_ACK_APPLICATION" | 16-255 | Used at application's | 2081 | | | discretion. | 2082 +------------------------+------------+-----------------------------+ 2084 The "NORM_ACK_CC" value is provided for use only in "NORM_ACKs" 2085 generated in response to the "NORM_CMD(CC)" messages used in 2086 congestion control operation. Similarly, the "NORM_ACK_FLUSH" is 2087 provided for use only in "NORM_ACKs" generated in response to 2088 applicable "NORM_CMD(FLUSH)" messages. "NORM_CMD"(ACK_REQ) messages 2089 with "ack_type" of "NORM_ACK_CC" or "NORM_ACK_FLUSH" SHALL NOT be 2090 generated by the sender. 2092 The "NORM_ACK_RESERVED" range of "ack_type" values is provided for 2093 possible future NORM protocol use. 2095 The "NORM_ACK_APPLICATION" range of "ack_type" values is provided so 2096 that NORM applications can implement application-defined, positively- 2097 acknowledged commands that are able to leverage internal transmission 2098 and round-trip timing information available to the NORM protocol 2099 implementation. 2101 The "ack_id" provides a sequenced identifier for the given 2102 "NORM_CMD(ACK_REQ)" message. This "ack_id" is returned in "NORM_ACK" 2103 messages generated by the receivers so that the sender can associate 2104 the response with its corresponding request. 2106 The "reserved" field is reserved for possible future protocol use and 2107 SHALL be set to "ZERO" by senders and ignored by receivers. 2109 The "acking_node_list" field contains the NormNodeIds of the current 2110 NORM receivers that are desired to provide positive acknowledge 2111 ("NORM_ACK") to this request. The packet payload length implies the 2112 length of the "acking_node_list" and its length is limited to the 2113 sender NormSegmentSize. The individual NormNodeId items are listed 2114 in network (Big Endian) byte order. If a receiver's NormNodeId is 2115 included in the "acking_node_list", it SHALL schedule transmission of 2116 a "NORM_ACK" message as described in Section 5.5.3. 2118 4.2.3.7. NORM_CMD(APPLICATION) Message 2120 This command allows the NORM application to robustly transmit 2121 application-defined commands. The command message preempts any 2122 ongoing data transmission and is repeated up to "NORM_ROBUST_FACTOR" 2123 times at a rate of once per "2*GRTT_sender". This rate of repetition 2124 allows the application to observe any response (if that is the 2125 application's purpose for the command) before it is repeated. 2126 Possible responses can include initiation of data transmission, other 2127 "NORM_CMD(APPLICATION)" messages, or even application-defined, 2128 positively-acknowledge commands from other NormSession participants. 2129 The transmission of these commands will preempt data transmission 2130 when they are scheduled and can be multiplexed with ongoing data 2131 transmission. This type of robustly transmitted command allows NORM 2132 applications to define a complete set of session control mechanisms 2133 with less state than the transfer of FEC encoded reliable content 2134 needs while taking advantage of NORM transmission and round-trip 2135 timing information. 2136 0 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 |version| type=3| hdr_len | sequence | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | source_id | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | instance_id | grtt |backoff| gsize | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 | sub-type = 7 | reserved | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | Application-Defined Content | 2148 | ... | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 NORM_CMD(APPLICATION) Message Format 2153 The NORM common message header and "NORM_CMD" fields are interpreted 2154 as previously described. The value of the "NORM_CMD(APPLICATION)" 2155 "hdr_len" field when no header extensions are present is 4. 2157 The "Application-Defined Content" area contains information in a 2158 format at the discretion of the application. The size of this 2159 payload SHALL be limited to a maximum of the sender's NormSegmentSize 2160 setting. Upon reception, the NORM protocol implementation SHALL 2161 deliver the content to the receiver application. Note that any 2162 detection of duplicate reception of a "NORM_CMD(APPLICATION)" message 2163 is the responsibility of the application. 2165 4.3. Receiver Messages 2167 The NORM message types generated by participating receivers consist 2168 of the "NORM_NACK" and "NORM_ACK" message types. "NORM_NACK" 2169 messages are sent to request repair of missing data content from 2170 sender transmission and "NORM_ACK" messages are generated in response 2171 to certain sender commands including "NORM_CMD(CC)" and 2172 "NORM_CMD(ACK_REQ)". 2174 4.3.1. NORM_NACK Message 2176 The principal purpose of "NORM_NACK" messages is for receivers to 2177 request repair of sender content via selective, negative 2178 acknowledgment upon detection of incomplete data. "NORM_NACK" 2179 messages will be transmitted according to the rules of "NORM_NACK" 2180 generation and suppression described in Section 5.3. "NORM_NACK" 2181 messages also contain additional fields to provide feedback to the 2182 sender(s) for purposes of round-trip timing collection and congestion 2183 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 containing an 2223 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 2232 the time delta from when the receiver received the "NORM_CMD(CC)" to 2233 when the "NORM_NACK" is transmitted in response to calculate the 2234 value in the "grtt_response" field. This is the 2235 "receive_to_response_delta" value used in the following formula: 2236 grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta 2238 The receiver SHALL set the "grtt_response" to a "ZERO" value, to 2239 indicate it has not yet received a "NORM_CMD(CC)" message from the 2240 indicated sender and the sender MUST ignore the "grtt_response" in 2241 this message. 2243 For NORM-CC operation, the NORM-CC Feedback Header Extension, as 2244 described in the "NORM_CMD(REPAIR_ADV}" message description, is added 2245 to "NORM_NACK" messages to provide feedback on the receivers current 2246 state with respect to congestion control operation. Alternative 2247 header extensions for congestion control feedback MAY be defined for 2248 alternative congestion control schemes for NORM use in the future. 2250 The "reserved" field is for potential future NORM use and SHALL be 2251 set to "ZERO" for this version of the protocol. 2253 The "nack_payload" of the "NORM_NACK" message specifies the repair 2254 needs of the receiver with respect to the NORM sender indicated by 2255 the "server_id" field. The receiver constructs repair requests based 2256 on the "NORM_DATA" and/or "NORM_INFO" segments it needs from the 2257 sender to complete reliable reception up to the sender's transmission 2258 position at the moment the receiver initiates the NACK Procedure as 2259 described in Section 5.3. A single NORM Repair Request consists of a 2260 list of items, ranges, and/or FEC coding block erasure counts for 2261 needed "NORM_DATA" and/or "NORM_INFO" content. Multiple repair 2262 requests can be concatenated within the "nack_payload" field of a 2263 "NORM_NACK" message. A single NORM Repair Request can possibly 2264 include multiple "items", "ranges", or "erasure_counts". In turn, 2265 the "nack_payload" field MAY contain multiple repair requests. A 2266 single NORM Repair Request has the following format: 2267 0 1 2 3 2268 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 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | form | flags | length | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | repair_request_items | 2273 | ... | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 NORM Repair Request Format 2278 The "form" field indicates the type of repair request items given in 2279 the "repair_request_items" list. Possible values for the "form" 2280 field include: 2282 +----------------------+-------+ 2283 | Form | Value | 2284 +----------------------+-------+ 2285 | "NORM_NACK_ITEMS" | 1 | 2286 | "NORM_NACK_RANGES" | 2 | 2287 | "NORM_NACK_ERASURES" | 3 | 2288 +----------------------+-------+ 2290 A "form" value of "NORM_NACK_ITEMS" indicates each repair request 2291 item in the "repair_request_items" list is to be treated as an 2292 individual request. A value of "NORM_NACK_RANGES" indicates the 2293 "repair_request_items" list consists of pairs of repair request items 2294 corresponding to the inclusive ranges of repair needs. And the 2295 "NORM_NACK_ERASURES" "form" indicates the repair request items are to 2296 be treated individually and the "encoding_symbol_id" portion of the 2297 "fec_payload_id" field of the repair request item (see below) is to 2298 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 | 2310 | | | range of segments needed as repair. | 2311 | "NORM_NACK_BLOCK" | 0x02 | Indicates the listed block(s) or | 2312 | | | range of blocks in entirety are | 2313 | | | needed as repair. | 2314 | "NORM_NACK_INFO" | 0x04 | Indicates "NORM_INFO" is needed as | 2315 | | | repair for the listed object(s). | 2316 | "NORM_NACK_OBJECT" | 0x08 | Indicates the listed object(s) or | 2317 | | | range of objects in entirety are | 2318 | | | needed as repair. | 2319 +---------------------+-------+-------------------------------------+ 2321 When the "NORM_NACK_SEGMENT" flag is set, the "object_transport_id" 2322 and "fec_payload_id" fields are used to determine which sets or 2323 ranges of individual "NORM_DATA" segments are needed to repair 2324 content at the receiver. When the "NORM_NACK_BLOCK" flag is set, 2325 this indicates the receiver is completely missing the indicated 2326 coding block(s) and transmissions sufficient to repair the indicated 2327 block(s) in their entirety are needed. When the "NORM_NACK_INFO" 2328 flag is set, this indicates the receiver is missing the "NORM_INFO" 2329 segment for the indicated "object_transport_id". Note the 2330 "NORM_NACK_INFO" can be set in combination with the "NORM_NACK_BLOCK" 2331 or "NORM_NACK_SEGMENT" flags, or can be set alone. When the 2332 "NORM_NACK_OBJECT" flag is set, this indicates the receiver is 2333 missing the entire NormTransportObject referenced by the 2334 "object_transport_id". This also implicitly requests any available 2335 "NORM_INFO" for the NormObject, if applicable. The "fec_payload_id" 2336 field is ignored when the flag "NORM_NACK_OBJECT" is set. 2338 The "length" field value is the length in bytes of the 2339 "repair_request_items" field. 2341 The "repair_request_items" field consists of a list of individual or 2342 range pairs of transport data unit identifiers in the following 2343 format. 2344 0 1 2 3 2345 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 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | fec_id | reserved | object_transport_id | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | fec_payload_id | 2350 | ... | 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 NORM Repair Request Item Format 2355 The "fec_id" indicates the FEC type and can be used to determine the 2356 format of the "fec_payload_id" field. The "reserved" field is kept 2357 for possible future use and SHALL be set to a "ZERO" value and 2358 ignored by NORM nodes processing NACK content. 2360 The "object_transport_id" corresponds to the NormObject for which 2361 repair is being requested and the "fec_payload_id" identifies the 2362 specific FEC coding block and/or segment being requested. When the 2363 "NORM_NACK_OBJECT" flag is set, the value of the "fec_payload_id" 2364 field is ignored. When the "NORM_NACK_BLOCK" flag is set, only the 2365 FEC code block identifier portion of the "fec_payload_id" is to be 2366 interpreted. 2368 The format of the "fec_payload_id" field depends upon the "fec_id" 2369 field value. 2371 When the receiver's repair needs dictate that different forms (mixed 2372 ranges and/or individual items) or types (mixed specific segments 2373 and/or blocks or objects in entirety) are needed to complete reliable 2374 transmission, multiple NORM Repair Requests with different "form" and 2375 or "flags" values can be concatenated within a single "NORM_NACK" 2376 message. Additionally, NORM receivers SHALL construct "NORM_NACK" 2377 messages with their repair requests in ordinal order with respect to 2378 "object_transport_id" and "fec_payload_id" values. The 2379 "nack_payload" size SHALL NOT exceed the NormSegmentSize for the 2380 sender to which the "NORM_NACK" is destined. 2382 NORM_NACK Content Examples: 2384 In these examples, a small block, systematic FEC code ("fec_id" = 2385 129) is assumed with a user data block length of 32 segments. In 2386 Example 1, a list of individual "NORM_NACK_ITEMS" repair requests is 2387 given. In Example 2, a list of "NORM_NACK_RANGES" requests AND a 2388 single "NORM_NACK_ITEMS" request are concatenated to illustrate the 2389 possible content of a "NORM_NACK" message. Note that FEC coding 2390 block erasure counts could also be provided in each case. However, 2391 the erasure counts are not really necessary since the sender can 2392 easily determine the erasure count while processing the NACK content. 2393 However, the erasure count option can be useful for operation with 2394 other FEC codes or for intermediate system purposes. 2396 Example 1: "NORM_NACK" "nack_payload" for: Object 12, Coding Block 3, 2397 Segments 2,5,and 8 2398 0 1 2 3 2399 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 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | form = 1 | flags = 0x01 | length = 36 | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | fec_id = 129 | reserved | object_transport_id = 12 | 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 | source_block_number = 3 | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 | source_block_length = 32 | encoding_symbol_id = 2 | 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | fec_id = 129 | reserved | object_transport_id = 12 | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | source_block_number = 3 | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | source_block_length = 32 | encoding_symbol_id = 5 | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | fec_id = 129 | reserved | object_transport_id = 12 | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | source_block_number = 3 | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 | source_block_length = 32 | encoding_symbol_id = 8 | 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 Example 2: "NORM_NACK" "nack_payload" for: Object 18, Coding Block 6, 2423 Segments 5, 6, 7, 8, 9, 10; and Object 19 "NORM_INFO" and Coding 2424 Block 1, segment 3 2425 0 1 2 3 2426 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 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | form = 2 | flags = 0x01 | length = 24 | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | fec_id = 129 | reserved | object_transport_id = 18 | 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 | source_block_number = 6 | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | source_block_length = 32 | encoding_symbol_id = 5 | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | fec_id = 129 | reserved | object_transport_id = 18 | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | source_block_number = 6 | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | source_block_length = 32 | encoding_symbol_id = 10 | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 | form = 1 | flags = 0x05 | length = 12 | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | fec_id = 129 | reserved | object_transport_id = 19 | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | source_block_number = 1 | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | source_block_length = 32 | encoding_symbol_id = 3 | 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 4.3.2. NORM_ACK Message 2453 The "NORM_ACK" message is intended to be used primarily as part of 2454 NORM congestion control operation and round-trip timing measurement. 2455 The acknowledgment type "NORM_ACK_CC" is provided for this purpose as 2456 described in the "NORM_CMD(ACK_REQ)" message description. The 2457 generation of "NORM_ACK(CC)" messages for round-trip timing 2458 estimation and congestion-control operation is described in 2459 Section 5.5.1 and Section 5.5.2, respectively. However, some 2460 multicast applications can benefit from some limited form of positive 2461 acknowledgment for certain functions. A simple, scalable positive 2462 acknowledgment scheme is defined in Section 5.5.3 that can be 2463 leveraged by protocol implementations when appropriate. The 2464 "NORM_CMD(FLUSH)" can also be used for OPTIONAL collection of 2465 positive acknowledgment of reliable reception to a certain 2466 "watermark" transmission point from specific receivers using this 2467 mechanism. The "NORM_ACK" type "NORM_ACK_FLUSH" is provided for this 2468 purpose and the format of the "nack_payload" for this acknowledgment 2469 type is given below. Beyond that, a range of application-defined 2470 "ack_type" values is provided for use at the NORM application's 2471 discretion. Implementations making use of application-defined 2472 positive acknowledgments MAY also make use the "nack_payload" as 2473 needed, observing the constraint that the "nack_payload" field size 2474 be limited to a maximum of the NormSegmentSize for the sender to 2475 which the "NORM_ACK" is destined. 2476 0 1 2 3 2477 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 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 |version| type=5| hdr_len | sequence | 2480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2481 | source_id | 2482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 | server_id | 2484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2485 | instance_id | ack_type | ack_id | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | grtt_response_sec | 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | grtt_response_usec | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | header extensions (if applicable) | 2492 | ... | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | ack_payload (if applicable) | 2495 | ... | 2496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2498 NORM_ACK Message Format 2500 The NORM common message header fields serve their usual purposes. 2501 The value of the "hdr_len" field when no header extensions are 2502 present is 6. 2504 The "server_id", "instance_id", and "grtt_response" fields serve the 2505 same purpose as the corresponding fields in "NORM_NACK" messages. 2506 And header extensions can be applied to support congestion control 2507 feedback or other functions in the same manner. 2509 The "ack_type" field indicates the nature of the "NORM_ACK" message. 2510 This directly corresponds to the "ack_type" field of the 2511 "NORM_CMD(ACK_REQ)" message to which this acknowledgment applies. 2513 The "ack_id" field serves as a sequence number so the sender can 2514 verify a received "NORM_ACK" message actually applies to a current 2515 acknowledgment request. The "ack_id" field is not used in the case 2516 of the "NORM_ACK_CC" and "NORM_ACK_FLUSH" acknowledgment types. 2518 The "ack_payload" format is a function of the "ack_type". The 2519 "NORM_ACK_CC" message has no attached content. Only the "NORM_ACK" 2520 header applies. In the case of "NORM_ACK_FLUSH", a specific 2521 "ack_payload" format is defined: 2522 0 1 2 3 2523 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 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | fec_id | reserved | object_transport_id | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | fec_payload_id | 2528 | ... | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 The "object_transport_id" and "fec_payload_id" are used by the 2532 receiver to acknowledge applicable "NORM_CMD(FLUSH)" messages 2533 transmitted by the sender identified by the "server_id" field. 2535 The "ack_payload" of "NORM_ACK" messages for application-defined 2536 "ack_type" values is specific to the application but is limited in 2537 size to a maximum the NormSegmentSize of the sender referenced by the 2538 "server_id". 2540 4.4. General Purpose Messages 2542 Some additional message formats are defined for general purpose in 2543 NORM multicast sessions whether the participant is acting as a sender 2544 and/or receiver within the group. 2546 4.4.1. NORM_REPORT Message 2548 This is an OPTIONAL message generated by NORM participants. This 2549 message can be used for periodic performance reports from receivers 2550 in experimental NORM implementations. The format of this message is 2551 currently undefined. Experimental NORM implementations MAY define 2552 "NORM_REPORT" formats as needed for test purposes. These report 2553 messages SHOULD be disabled for interoperability testing between 2554 different compliant NORM implementations. 2556 5. Detailed Protocol Operation 2558 This section describes the detailed interactions of senders and 2559 receivers participating in a NORM session. A simple synopsis of 2560 protocol operation is given here: 2562 1. The sender periodically transmits "NORM_CMD(CC)" messages as 2563 needed to initialize and collect round-trip timing and congestion 2564 control feedback from the receiver set. 2566 2. The sender transmits an ordinal set of NormObjects segmented in 2567 the form of "NORM_DATA" messages labeled with NormTransportIds 2568 and logically identified with FEC encoding block numbers and 2569 symbol identifiers. "When applicable, NORM_INFO" messages MAY 2570 optionally precede the transmission of data content for NORM 2571 transport objects. 2573 3. As receivers detect missing content from the sender, they 2574 initiate repair requests with "NORM_NACK" messages. The 2575 receivers track the sender's most recent objectId::fecPayloadId 2576 transmit position and NACK only for content that is ordinally 2577 prior to that current transmit position. The receivers schedule 2578 random backoff timeouts before generating "NORM_NACK" messages 2579 and wait an appropriate amount of time before repeating the 2580 "NORM_NACK" if their repair request is not satisfied. 2582 4. The sender aggregates repair requests from the receivers and 2583 logically "rewinds" its transmit position to send appropriate 2584 repair messages. The sender sends repairs for the earliest 2585 ordinal transmit position first and maintains this ordinal repair 2586 transmission sequence. FEC parity content not previously 2587 transmitted for the applicable FEC coding block is used for 2588 repair transmissions to the greatest extent possible. If the 2589 sender exhausts its available FEC parity content on multiple 2590 repair cycles for the same coding block, it resorts to an 2591 explicit repair strategy (possibly using parity content) to 2592 complete repairs. (The use of explicit repair is an exception in 2593 general protocol operation, but the possibility does exist for 2594 extreme conditions). The sender immediately assumes transmission 2595 of new content once it has sent pending repairs. 2597 5. The sender transmits "NORM_CMD(FLUSH)" messages when it reaches 2598 the end of enqueued transmit content and pending repairs. 2599 Receivers respond to the "NORM_CMD(FLUSH)" messages with 2600 "NORM_NACK" transmissions (following the same suppression backoff 2601 timeout strategy as for data) if they need further repair. 2603 6. The sender transmissions are subject to rate control limits 2604 determined by congestion control mechanisms. In the baseline 2605 NORM-CC operation, each sender in a NormSession maintains its own 2606 independent congestion control state. Receivers provide 2607 congestion control feedback in "NORM_NACK" and "NORM_ACK" 2608 messages. "NORM_ACK" feedback for congestion control purposes is 2609 governed using a suppression mechanism similar to that for 2610 "NORM_NACK" messages. 2612 While this overall concept is relatively simple, there are details to 2613 each of these aspects that need to be addressed for successful, 2614 efficient, robust, and scalable NORM protocol operation. 2616 5.1. Sender Initialization and Transmission 2618 Upon startup, the NORM sender immediately begins sending 2619 "NORM_CMD(CC)" messages to collect round trip timing and other 2620 information from the potential group. If NORM-CC congestion control 2621 operation is enabled, the NORM-CC Rate header extension MUST be 2622 included in these messages. Congestion control operation SHALL be 2623 observed at all times when not operating using dedicated resources, 2624 like in the general Internet. Even if congestion control operation 2625 is disabled at the sender, it can be desirable to use the 2626 "NORM_CMD(CC)" messaging to collect feedback from the group using the 2627 baseline NORM-CC feedback mechanisms. This proactive feedback 2628 collection can be used to establish a GRTT estimate prior to data 2629 transmission and potential NACK operation. 2631 In some cases, applications might need the sender to also proceed 2632 with data transmission immediately. In other cases, the sender might 2633 wish to defer data transmission until it has received some feedback 2634 or request from the receiver set indicating receivers are indeed 2635 present. Note, in some applications (e.g., web push), this 2636 indication MAY come out-of-band with respect to the multicast session 2637 via other means. As noted, the periodic transmission of 2638 "NORM_CMD(CC)" messages MAY precede actual data transmission in order 2639 to have an initial GRTT estimate. 2641 With inclusion of the OPTIONAL NORM FEC Object Transmission 2642 Information Header Extension (EXT_FTI), the NORM protocol sender 2643 message headers can contain all information necessary to prepare 2644 receivers for subsequent reliable reception. This includes FEC 2645 coding parameters, the sender NormSegmentSize, and other information. 2646 If this header extension is not used, it is presumed receivers have 2647 received the FEC Object Transmission Information via other means. 2648 Additionally, applications MAY leverage the use of "NORM_INFO" 2649 messages associated with the session data objects in the session to 2650 provide application-specific context information for the session and 2651 data being transmitted. These mechanisms allow for operation with 2652 minimal pre-coordination among the senders and receivers. 2654 The NORM sender begins segmenting application-enqueued data into 2655 "NORM_DATA" segments and transmitting it to the group. For objects 2656 of type "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE", the segmentation 2657 algorithm described in FEC Building Block [RFC5052] is RECOMMENDED. 2658 For objects of type "NORM_OBJECT_STREAM", segmentation will typically 2659 be into uniform FEC coding block sizes, with individual segment sizes 2660 controlled by the application. In most cases, the application and 2661 NORM implementation SHOULD strive to produce full-sized 2662 ("NormSegmentSize") segments when possible. The rate of transmission 2663 is controlled via congestion control mechanisms or is a fixed rate if 2664 desired for closed network operations. The receivers participating 2665 in the multicast group provide feedback to the sender as needed. 2666 When the sender reaches the end of data it has enqueued for 2667 transmission or any pending repairs, it transmits a series of 2668 "NORM_CMD(FLUSH)" messages at a rate of one per "2*GRTT_sender". 2669 Similar to end of each transmitted FEC coding block during 2670 transmission, receivers SHALL respond to these "NORM_CMD(FLUSH)" 2671 messages with additional repair requests as needed. A protocol 2672 parameter ""NORM_ROBUST_FACTOR"" determines the number of flush 2673 messages sent. If receivers request repair, the repair is provided 2674 and flushing occurs again at the end of repair transmission. The 2675 sender MAY attach an OPTIONAL "acking_node_list" to "NORM_CMD(FLUSH)" 2676 containing the NormNodeIds for receivers from which it expects 2677 explicit positive acknowledgment of reception. The "NORM_CMD(FLUSH)" 2678 message MAY be also used for this OPTIONAL purpose any time prior to 2679 the end of data enqueued for transmission with the "NORM_CMD(FLUSH)" 2680 messages multiplexed with ongoing data transmissions. The OPTIONAL 2681 NORM positive acknowledgment procedure is described in Section 5.5.3. 2683 5.1.1. Object Segmentation Algorithm 2685 NORM senders and receivers MUST use a common algorithm for logically 2686 segmenting transport data into FEC encoding blocks and symbols so 2687 appropriate NACKs can be constructed to request repair of missing 2688 data. NORM FEC coding blocks are comprised of multi-byte symbols 2689 (segments) transmitted in the payload of "NORM_DATA" messages. Each 2690 "NORM_DATA" message will contain one or more source or encoding 2691 symbol(s) identified by the "fec_payload_id" field and the 2692 NormSegmentSize sender parameter defines the maximum size (in bytes) 2693 of the "payload_data" field containing the content (a "segment"). 2694 The FEC encoding type and associated parameters govern the source 2695 block size (number of source symbols per coding block, etc.). NORM 2696 senders and receivers use these FEC parameters, along with the 2697 NormSegmentSize and transport object size to compute the source block 2698 structure for transport objects. These parameters are provided in 2699 the FEC Object Transmission Information for each object. The block 2700 partitioning algorithm described in the FEC Building Block [RFC5052] 2701 is RECOMMENDED for use to compute a source block structure such that 2702 all source blocks are as close to being equal length as possible. 2703 This helps avoid the performance disadvantages of "short" FEC blocks. 2704 Note this algorithm applies only to the statically-sized 2705 "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE" transport object types 2706 where the object size is fixed and predetermined. For 2707 "NORM_OBJECT_STREAM" objects, the object is segmented according to 2708 the maximum source block length given in the FEC Transmission 2709 Information, unless the FEC Payload ID indicates an alternative size 2710 for a given block. 2712 5.2. Receiver Initialization and Reception 2714 For typical operation, NORM receivers will join a specified multicast 2715 group and listen on an specific port number for sender transmissions. 2716 As the NORM receiver receives "NORM_DATA" messages it will establish 2717 buffering state and provide content to its application as appropriate 2718 for the given data type. The NORM protocol allows receivers to join 2719 and leave the group at will although some applications might need 2720 receivers to be members of the group prior to start of data 2721 transmission. Thus, different NORM applications MAY use different 2722 policies to constrain the impact of new receivers joining the group 2723 in the middle of a session. For example, a useful implementation 2724 policy is for new receivers joining the group to limit or avoid 2725 repair requests for transport objects already in progress. The NORM 2726 sender implementation MAY impose additional constraints to limit the 2727 ability of receivers to disrupt reliable multicast performance by 2728 joining, leaving, and rejoining the group often. Different receiver 2729 "join policies" might be appropriate for different applications 2730 and/or scenarios. For general purpose operation, a default policy 2731 where receivers are allowed to request repair only for coding blocks 2732 with a NormTransportId and FEC coding block number greater than or 2733 equal to the first non-repair "NORM_DATA" or "NORM_INFO" message 2734 received upon joining the group is RECOMMENDED. For objects of type 2735 "NORM_OBJECT_STREAM" it is RECOMMENDED the join policy constrain 2736 receivers to start reliable reception at the current FEC coding block 2737 for which non-repair content is received. 2739 In some deployments, different multicast receivers might have 2740 differing quality of network connectivity. Some receivers may suffer 2741 significantly poorer performance with very limited goodput due to low 2742 connection rate or substantial packet loss. Similar to the "join 2743 policies" described above, a NORM sender implementation MAY choose to 2744 enforce different "service policies" to perhaps exclude exceptionally 2745 poor-performing (or otherwise badly-behaving) receivers from the 2746 group. The sender implementation could choose to ignore NACKs from 2747 such receivers and/or force advancement of its logical "repair 2748 window" (i.e. enforcing a minimal level of service) and use the 2749 "NORM_CMD(SQUELCH)" message to advise those poor performers of its 2750 advance. Note in some cases, the application may need to support the 2751 "weakest member" regardless of the time needed to achieve reliable 2752 delivery. When implemented, the protocol instantiation SHOULD expose 2753 controls to the set of "join" and/or "service" policies available to 2754 support the needs of different applications. 2756 5.3. Receiver NACK Procedure 2758 When the receiver detects it is missing data from a sender's NORM 2759 transmissions, it initiates its NACKing procedure. The NACKing 2760 procedure SHALL be initiated only at FEC coding block boundaries, 2761 NormObject boundaries, upon receipt of a "NORM_CMD(FLUSH)" message, 2762 or upon an "inactivity" timeout when "NORM_DATA" or "NORM_INFO" 2763 transmissions are no longer received from a previously active sender. 2764 The RECOMMENDED value of such an inactivity timeout is: 2765 T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender 2767 where the ""GRTT_sender"" value corresponds to the GRTT estimate 2768 advertised in the "grtt" field of NORM sender messages. A minimum 2769 ""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver 2770 SHOULD reset this inactivity timer and repeat NACK initiation upon 2771 timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon 2772 the application's need for persistence by its receivers. It is also 2773 important receivers rescale the ""T_inactivity"" timeout as the 2774 sender's advertised GRTT changes. 2776 The NACKing procedure begins with a random backoff timeout. The 2777 duration of the backoff timeout is chosen using the "RandomBackoff" 2778 algorithm described in the Multicast NACK Building Block [RFC5401] 2779 using ("K_sender*GRTT_sender") for the "maxTime" parameter and the 2780 sender advertised group size ("GSIZEsender") as the "groupSize" 2781 parameter. NORM senders provide values for "GRTT_sender", "K_sender" 2782 and "GSIZE_sender" via the "grtt", "backoff", and "gsize" fields of 2783 transmitted messages. The "GRTT_sender" value is determined by the 2784 sender based on feedback it has received from the group while the 2785 "K_sender" and "GSIZE_sender" values can be determined by application 2786 requirements and expectations or ancillary information. The backoff 2787 factor ""K_sender"" MUST be greater than "one" to provide for 2788 effective feedback suppression. A value of "K_sender = 4" is 2789 RECOMMENDED for the Any Source Multicast (ASM) model while a value of 2790 "K_sender = 6" is RECOMMENDED for Single Source Multicast (SSM) 2791 operation. 2793 Thus: 2794 T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender) 2796 To avoid the possibility of NACK implosion in the case of sender or 2797 network failure during SSM operation, the receiver SHALL 2798 automatically suppress its NACK and immediately enter the "holdoff" 2799 period described below when "T_backoff" is greater than 2800 "(K_sender-1)*GRTT_sender". Otherwise, the backoff period is entered 2801 and the receiver MUST accumulate external pending repair state from 2802 "NORM_NACK" messages and "NORM_CMD(REPAIR_ADV)" messages received. 2803 At the end of the backoff time, the receiver SHALL generate a 2804 "NORM_NACK" message only if the following conditions are met: 2806 1. The sender's current transmit position (in terms of objectId:: 2807 fecPayloadId) exceeds the earliest repair position of the 2808 receiver. 2810 2. The repair state accumulated from "NORM_NACK" and 2811 "NORM_CMD(REPAIR_ADV)" messages do not equal or supersede the 2812 receiver's repair needs up to the sender transmission position at 2813 the time the NACK procedure (backoff timeout) was initiated. 2815 If these conditions are met, the receiver immediately generates a 2816 "NORM_NACK" message when the backoff timeout expires. Otherwise, the 2817 receiver's NACK is considered to be "suppressed" and the message is 2818 not sent. At this time, the receiver begins a "holdoff" period 2819 during which it constrains itself to not re-initiate the NACKing 2820 process. The purpose of this timeout is to allow the sender worst- 2821 case time to respond to the repair needs before the receiver requests 2822 repair again. The value of this "holdoff" timeout ("T_rcvrHoldoff") 2823 as described in [RFC5401] is: 2824 T_rcvrHoldoff =(K_sender+2)*GRTT_sender 2826 The "NORM_NACK" message contains repair request content beginning 2827 with lowest ordinal repair position of the receiver up through the 2828 coding block prior to the most recently heard ordinal transmission 2829 position for the sender. If the size of the "NORM_NACK" content 2830 exceeds the sender's NormSegmentSize, the NACK content is truncated 2831 so the receiver only generates a single "NORM_NACK" message per NACK 2832 cycle for a given sender. In summary, a single NACK message is 2833 generated containing the receiver's lowest ordinal repair needs. 2835 For each partially-received FEC coding block requiring repair, the 2836 receiver SHALL, on its FIRST repair attempt for the block, request 2837 the parity portion of the FEC coding block beginning with the lowest 2838 ordinal parity "encoding_symbol_id" (i.e., "encoding_symbol_id" = 2839 "source_block_len") and request the number of FEC symbols 2840 corresponding to its data segment erasure count for the block. On 2841 subsequent repair cycles for the same coding block, the receiver 2842 SHALL request only those repair symbols from the first set it has not 2843 yet received up to the remaining erasure count for that applicable 2844 coding block. Note the sender might have transmitted other 2845 different, additional parity segments for other receivers that could 2846 also be used to satisfy the local receiver's erasure-filling needs. 2847 In the case where the erasure count for a partially-received FEC 2848 coding block exceeds the maximum number of parity symbols available 2849 from the sender for the block (as indicated by the "NORM_DATA" 2850 "fec_num_parity" field), the receiver SHALL request all available 2851 parity segments plus the ordinally highest missing data segments 2852 needed to satisfy its total erasure needs for the block. The goal of 2853 this strategy is for the overall receiver set to request a lowest 2854 common denominator set of repair symbols for a given FEC coding 2855 block. This allows the sender to construct the most efficient repair 2856 transmission segment set and enables effective NACK suppression among 2857 the receivers even with uncorrelated packet loss. This approach also 2858 does not demand synchronization among the receiver set in their 2859 repair requests for the sender. 2861 For FEC coding blocks or NormObjects missed in their entirety, the 2862 NORM receiver constructs repair requests with "NORM_NACK_BLOCK" or 2863 "NORM_NACK_OBJECT" flags set as appropriate. The request for 2864 retransmission of "NORM_INFO" is accomplished by setting the 2865 "NORM_NACK_INFO" flag in a corresponding repair request. 2867 5.4. Sender NACK Processing and Response 2869 The principle goal of the sender is to make forward progress in the 2870 transmission of data its application has enqueued. However, the 2871 sender will need to occasionally "rewind" its logical transmission 2872 point to satisfy the repair needs of receivers who have NACKed. 2873 Aggregation of multiple NACKs is used to determine an optimal repair 2874 strategy when a NACK event occurs. Since receivers initiate the NACK 2875 process on coding block or object boundaries, there is some loose 2876 degree of synchronization of the repair process even when receivers 2877 experience uncorrelated data loss. 2879 5.4.1. Sender Repair State Aggregation 2881 When a sender is in its normal state of transmitting new data and 2882 receives a NACK, it begins a procedure to accumulate NACK repair 2883 state from "NORM_NACK" messages before beginning repair 2884 transmissions. Note this period of aggregating repair state does NOT 2885 interfere with its ongoing transmission of new data. 2887 As described in [RFC5401], the period of time during which the sender 2888 aggregates "NORM_NACK" messages is equal to: 2889 T_sndrAggregate = (K_sender + 1) * GRTT_sender 2891 where ""K_sender"" is the backoff scaling value advertised to the 2892 receivers, and "GRTT_sender" is the sender's current estimate of the 2893 group's greatest round-trip time. Note, for NORM unicast sessions, 2894 the ""T_sndrAggregate"" time can be set to "ZERO" since there is only 2895 one receiver. Similarly, the ""K_sender"" value SHOULD be set to 2896 "ZERO" for NORM unicast sessions to minimize repair latency. 2898 When this period ends, the sender "rewinds" by incorporating the 2899 accumulated repair state into its pending transmission state and 2900 begins transmitting repair messages. After pending repair 2901 transmissions are completed, the sender continues with new 2902 transmissions of any enqueued data. Also, at this point in time, the 2903 sender begins a "holdoff" timeout during which time the sender 2904 constrains itself from initiating a new repair aggregation cycle, 2905 even if "NORM_NACK" messages arrive. As described in [RFC5401], the 2906 value of this sender "holdoff" period is: 2907 T_sndrHoldoff = (1 * GRTT_sender) 2909 If additional "NORM_NACK" messages are received during this sender 2910 "holdoff" period, the sender will immediately incorporate these late- 2911 arriving messages into its pending transmission state if, and only 2912 if, the NACK content is ordinally greater than the sender's current 2913 transmission position. This "holdoff" time allows worst case time 2914 for the sender to propagate its current transmission sequence 2915 position to the group, thus avoiding redundant repair transmissions. 2916 After the holdoff timeout expires, a new NACK accumulation period can 2917 be begun (upon arrival of a NACK) in concert with the pending repair 2918 and new data transmission. Recall receivers are not to initiate the 2919 NACK repair process until the sender's logical transmission position 2920 exceeds the lowest ordinal position of their repair needs. With the 2921 new NACK aggregation period, the sender repeats the same process of 2922 incorporating accumulated repair state into its transmission plan and 2923 subsequently "rewinding" to transmit the lowest ordinal repair data 2924 when the aggregation period expires. Again, this is conducted in 2925 concert with ongoing new data and/or pending repair transmissions. 2927 5.4.2. Sender FEC Repair Transmission Strategy 2929 The NORM sender SHOULD leverage transmission of FEC parity content 2930 for repair to the greatest extent possible. Recall that receivers 2931 use a strategy to request a lowest common denominator of explicit 2932 repair (including parity content) in the formation of their 2933 "NORM_NACK" messages. Before falling back to explicitly satisfying 2934 different receivers' repair needs, the sender can make use of the 2935 general erasure-filling capability of FEC-generated parity segments. 2936 The sender can determine the maximum erasure filling needs for 2937 individual FEC coding blocks from the "NORM_NACK" messages received 2938 during the repair aggregation period. Then, if the sender has a 2939 sufficient number (less than or equal to the maximum erasure count) 2940 of previously unsent parity segments available for the applicable 2941 coding blocks, the sender can transmit these in lieu of the specific 2942 packets the receiver set has requested. The sender SHOULD NOT resort 2943 to explicit transmission of the receiver set's repair needs until 2944 after exhausting its supply of "fresh" (unsent) parity segments for a 2945 given coding block. In general, if a sufficiently powerful FEC code 2946 is used, the need for explicit repair will be an exception, and the 2947 fulfillment of reliable multicast can be accomplished quite 2948 efficiently. However, the ability to resort to explicit repair 2949 allows the protocol to be continue to operate under even very extreme 2950 circumstances. 2952 "NORM_DATA" messages sent as repair transmissions SHALL be flagged 2953 with the "NORM_FLAG_REPAIR" flag. This allows receivers to obey any 2954 policies limiting new receivers from joining the reliable 2955 transmission when only repair transmissions have been received. 2956 Additionally, the sender SHOULD additionally flag "NORM_DATA" 2957 transmissions sent as explicit repair with the "NORM_FLAG_EXPLICIT" 2958 flag. 2960 Although NORM end system receivers do not make use of the 2961 "NORM_FLAG_EXPLICIT" flag, this message transmission status could be 2962 leveraged by intermediate systems wishing to "assist" NORM protocol 2963 performance. If such systems are properly positioned with respect to 2964 reciprocal reverse-path multicast routing, they need to sub-cast only 2965 a sufficient count of non-explicit parity repairs to satisfy a 2966 multicast routing sub-tree's erasure filling needs for a given FEC 2967 coding block. When the sender has resorted to explicit repair, then 2968 the intermediate systems SHOULD sub-cast all of the explicit repair 2969 packets to those portions of the routing tree still requiring repair 2970 for a given coding block. Note the intermediate systems will need to 2971 conduct repair state accumulation for sub-routes in a manner similar 2972 to the sender's repair state accumulation in order to have sufficient 2973 information to perform the sub-casting. Additionally, the 2974 intermediate systems could perform additional "NORM_NACK" 2975 suppression/aggregation as it conducts this repair state accumulation 2976 for NORM repair cycles. The detail of this type of operation are 2977 beyond the scope of this document, but this information is provided 2978 for possible future consideration. 2980 5.4.3. Sender NORM_CMD(SQUELCH) Generation 2982 If the sender receives a "NORM_NACK" message for repair of data it is 2983 no longer supporting, the sender generates a "NORM_CMD(SQUELCH)" 2984 message to advertise its repair window and squelch any receivers from 2985 additional NACKing of invalid data. The transmission rate of 2986 "NORM_CMD(SQUELCH)" messages is limited to once per "2*GRTT_sender". 2987 The "invalid_object_list" (if applicable) of the "NORM_CMD(SQUELCH)" 2988 message SHALL begin with the lowest "object_transport_id" from the 2989 invalid "NORM_NACK" messages received since the last 2990 "NORM_CMD(SQUELCH)" transmission. The list includes as many lower 2991 ordinal invalid "object_transport_ids" that can fit for the 2992 "NORM_CMD(SQUELCH)" payload size to less than or equal to the 2993 sender's NormSegmentSize parameter. 2995 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation 2997 When a NORM sender receives "NORM_NACK" messages from receivers via 2998 unicast transmission, it uses "NORM_CMD(REPAIR_ADV)" messages to 2999 advertise its accumulated repair state to the receiver set since the 3000 receiver set is not directly sharing their repair needs via multicast 3001 communication. A NORM sender implementation MAY use a separate port 3002 number from the NormSession port number as the source port for its 3003 transmissions. Thus NORM receivers can direct any unicast feedback 3004 messages to this separate sender port number, distinct from the NORM 3005 session (or destination) port number. Then, the NORM sender 3006 implementation can discriminate unicast feedback messages from 3007 multicast feedback messages when there is a mix of multicast and 3008 unicast feedback receivers. The "NORM_CMD(REPAIR_ADV)" message is 3009 multicast to the receiver set by the sender. The payload portion of 3010 this message has content in the same format as the "NORM_NACK" 3011 receiver message payload. Receivers are then able to perform 3012 feedback suppression in the same manner as with "NORM_NACK" messages 3013 directly received from other receivers. Note the sender does not 3014 merely retransmit NACK content it receives, but instead transmits a 3015 representation of its aggregated repair state. The transmission of 3016 "NORM_CMD(REPAIR_ADV)" messages are subject to the sender transmit 3017 rate limit and NormSegmentSize limitation. When the 3018 "NORM_CMD(REPAIR_ADV)" message is of maximum size, receivers SHALL 3019 consider the maximum ordinal transmission position value embedded in 3020 the message as the senders current transmission position and 3021 implicitly suppress requests for ordinally higher repair. For 3022 congestion control operation, the sender will also need to provide 3023 any information needed so dynamic congestion control feedback can be 3024 suppressed among receivers. This document specifies the NORM-CC 3025 Feedback Header Extension that is applied for baseline NORM-CC 3026 operation. If other congestion control mechanisms are used within a 3027 NORM implementation, other header extensions MAY be defined. 3028 Whatever content format is used for this purpose SHOULD ensure that 3029 maximum possible suppression state is conveyed to the receiver set. 3031 5.5. Additional Protocol Mechanisms 3033 In addition to the principal function of data content transmission 3034 and repair, there are some other protocol mechanisms to help NORM to 3035 adapt to network conditions and play fairly with other coexistent 3036 protocols. 3038 5.5.1. Group Round-trip Time (GRTT) Collection 3040 For NORM receivers to appropriately scale backoff timeouts and the 3041 senders to use proper corresponding timeouts, the participants need 3042 to use a common timeout basis. Each NORM sender monitors the round- 3043 trip time of active receivers and determines the greatest group 3044 round-trip time. The sender advertises this GRTT estimate in every 3045 message it transmits so receivers have this value available for 3046 scaling their timers. To measure the current GRTT, the sender 3047 periodically sends "NORM_CMD(CC)" messages containing a locally 3048 generated timestamp. Receivers are expected to record this timestamp 3049 along with the time the "NORM_CMD(CC)" message is received. Then, 3050 when the receivers generate feedback messages to the sender, an 3051 adjusted version of the sender timestamp is embedded in the feedback 3052 message ("NORM_NACK" or "NORM_ACK"). The adjustment adds the amount 3053 of time the receiver held the timestamp before generating its 3054 response. Upon receipt of this adjusted timestamp, the sender is 3055 able to calculate the round-trip time to that receiver. 3057 The round-trip time for each receiver is fed into an algorithm that 3058 weights and smoothes the values for a conservative estimate of the 3059 GRTT. The algorithm and methodology are described in the Multicast 3060 NACK Building Block [RFC5401] in the section entitled "One-to-Many 3061 Sender GRTT Measurement". A conservative estimate helps guarantee 3062 feedback suppression at a small cost in overall protocol repair 3063 delay. The sender's current estimate of GRTT is advertised in the 3064 "grtt" field found in all NORM sender messages. The advertised GRTT 3065 is also limited to a minimum of the nominal inter-packet transmission 3066 time given the sender's current transmission rate and system clock 3067 granularity. The reason for this additional limit is to keep the 3068 receiver somewhat event-driven by making sure the sender has had 3069 adequate time to generate any response to repair requests from 3070 receivers given transmit rate limitations due to congestion control 3071 or configuration. 3073 When the NORM-CC Rate header extension is present in "NORM_CMD(CC)" 3074 messages, the receivers respond to "NORM_CMD(CC)" messages as 3075 described in Section 5.5.2, "NORM Congestion Control Operation". The 3076 "NORM_CMD(CC)" messages are periodically generated by the sender as 3077 described for congestion control operation. This provides for 3078 proactive, but controlled, feedback from the group in the form of 3079 "NORM_ACK" messages. This provides for GRTT feedback even if no 3080 "NORM_NACK" messages are being sent. If operating without congestion 3081 control in a closed network, the "NORM_CMD(CC)" messages MAY be sent 3082 periodically without the NORM-CC Rate header extension. In this 3083 case, receivers will only provide GRTT measurement feedback when 3084 "NORM_NACK" messages are generated since no "NORM_ACK" messages are 3085 generated. In this case, the "NORM_CMD(CC)" messages MAY be sent 3086 less frequently, perhaps as little as once per minute, to conserve 3087 network capacity. Note the NORM-CC Rate header extension MAY also be 3088 used to proactively solicit RTT feedback from the receiver group per 3089 congestion control operation even when the sender is not conducting 3090 congestion control rate adjustment. NORM operation without 3091 congestion control SHOULD be considered only in closed networks. 3093 5.5.2. NORM Congestion Control Operation 3095 This section describes baseline congestion control operation for the 3096 NORM protocol (NORM-CC). The supporting NORM message formats and 3097 approach described here are an adaptation of the equation-based TCP- 3098 Friendly Multicast Congestion Control (TFMCC) approach[RFC4654]. 3099 This congestion control scheme is REQUIRED for operation within the 3100 general Internet unless the NORM implementation is adapted to use 3101 another IETF-sanctioned reliable multicast congestion control 3102 mechanism. With this TFMCC-based approach, the transmissions of NORM 3103 senders are controlled in a rate-based manner as opposed to window- 3104 based congestion control algorithms as in TCP. However, it is 3105 possible the NORM protocol message set MAY alternatively be used to 3106 support a window-based multicast congestion control scheme such as 3107 PGMCC. The details of such an alternative MAY be described 3108 separately or in a future revision of this document. In either case 3109 (rate-based TFMCC or window-based PGMCC), successful control of 3110 sender transmission depends upon collection of sender-to-receiver 3111 packet loss estimates and RTTs to identify the congestion control 3112 bottleneck path(s) within the multicast topology and adjust the 3113 sender rate accordingly. The receiver with loss and RTT estimates 3114 corresponding to the lowest resulting calculated transmission rate is 3115 identified as the "current limiting receiver" (CLR). In the case of 3116 a tie (where candidate CLRs are within 10% of the same calculated 3117 rate), the receiver with the largest RTT value SHOULD be designated 3118 as the CLR. 3120 As described in [TcpModel], a steady-state sender transmission rate, 3121 to be "friendly" with competing TCP flows can be calculated as: 3122 S 3123 Rsender = ---------------------------------------------------------- 3124 T_rtt*(sqrt((2/3)*p) + 12*sqrt((3/8)*p) * p * (1 + 32*(p^2))) 3126 where 3128 "S" = nominal transmitted packet size. (In NORM, the "nominal" 3129 packet size can be determined by the sender as an exponentially 3130 weighted moving average (EWMA) of transmitted packet sizes to account 3131 for variable message sizes). 3133 "T_rtt" = RTT estimate of the current "current limiting receiver" 3134 (CLR). 3136 "p" = loss event fraction of the CLR. 3138 To support congestion control feedback collection and operation, the 3139 NORM sender periodically transmits "NORM_CMD(CC)" command messages. 3140 "NORM_CMD(CC)" messages are multiplexed with NORM data and repair 3141 transmissions and serve several purposes: 3143 1. Stimulate explicit feedback from the general receiver set to 3144 collect congestion control information. 3146 2. Communicate state to the receiver set on the sender's current 3147 congestion control status including details of the CLR. 3149 3. Initiate rapid (immediate) feedback from the CLR in order to 3150 closely track the dynamics of congestion control for the current 3151 worst path in the group multicast topology. 3153 The format of the "NORM_CMD(CC)" message is described in 3154 Section 4.2.3 of this document. The "NORM_CMD(CC)" message contains 3155 information to allow measurement of RTTs, to inform the group of the 3156 congestion control CLR, and to provide feedback of individual RTT 3157 measurements to the receivers in the group. The "NORM_CMD(CC)" also 3158 provides for exciting feedback from OPTIONAL "potential limiting 3159 receiver" (PLR) nodes that might be determined administratively or 3160 possibly algorithmically based upon congestion control feedback. PLR 3161 nodes are receivers that have been identified to have potential for 3162 (perhaps soon) becoming the CLR and thus immediate, up-to-date 3163 feedback is beneficial for congestion control performance. The PLR 3164 list MAY be populated with a small number of receivers the sender 3165 identifies as approaching the CLR loss and delay conditions based on 3166 feedback from the group. 3168 5.5.2.1. NORM_CMD(CC) Transmission 3170 The "NORM_CMD(CC)" message is transmitted periodically by the sender 3171 along with its normal data transmission. Note the repeated 3172 transmission of "NORM_CMD(CC)" messages MAY be initiated some time 3173 before transmission of user data content at session startup. This 3174 can be done to collect some estimation of the current state of the 3175 multicast topology with respect to group and individual RTT and 3176 congestion control state. 3178 A "NORM_CMD(CC)" message is immediately transmitted at sender 3179 startup. The interval of subsequent "NORM_CMD(CC)" message 3180 transmission is determined as follows: 3182 1. By default, the interval is set according to the current sender 3183 GRTT estimate. A startup initial value of "GRTT_sender = 0.5" 3184 seconds is RECOMMENDED when no feedback has yet been received 3185 from the group. 3187 2. Until a CLR has been identified (based on previous receiver 3188 feedback) or when no data transmission is pending, the 3189 "NORM_CMD(CC)" interval is doubled up from its current interval 3190 to a maximum of once per 30 seconds. This results in a low duty 3191 cycle for "NORM_CMD(CC)" probing when no CLR is identified or 3192 there is no pending data to transmit. 3194 3. When a CLR has been identified (based on receiver feedback) and 3195 data transmission is pending, the probing interval is set to the 3196 RTT between the sender and the CLR ("RTT_clr"). 3198 4. Additionally, when the data transmission rate is low with respect 3199 to the "RTT_clr" interval used for probing, the implementation 3200 SHOULD ensure no more than one "NORM_CMD(CC)" message is sent per 3201 "NORM_DATA" message when there is data pending transmission. 3202 This ensures the transmission of this control message is not done 3203 to the exclusion of user data transmission. 3205 The "NORM_CMD(CC)" "cc_sequence" field is incremented with each 3206 transmission of a "NORM_CMD(CC)" command. The greatest "cc_sequence" 3207 recently received by receivers is included in their feedback to the 3208 sender. This allows the sender to determine the age of feedback to 3209 assist in congestion avoidance. 3211 The NORM-CC Rate Header Extension is applied to the "NORM_CMD(CC)" 3212 message and the sender advertises its current transmission rate in 3213 the "send_rate" field. The rate information is used by receivers to 3214 initialize loss estimation during congestion control startup or 3215 restart. 3217 The "cc_node_list" contains a list of entries identifying receivers 3218 and their current congestion control state (status "flags", "rtt" and 3219 "loss" estimates). The list will be empty if the sender has not yet 3220 received any feedback from the group. If the sender has received 3221 feedback, the list will minimally contain an entry identifying the 3222 CLR. A "NORM_FLAG_CC_CLR" flag value is provided for the "cc_flags" 3223 field to identify the CLR entry. It is RECOMMENDED the CLR entry be 3224 the first in the list for implementation efficiency. Additional 3225 entries in the list are used to provide sender-measured individual 3226 RTT estimates to receivers in the group. The number of additional 3227 entries in this list is dependent upon the percentage of control 3228 traffic the sender application is willing to send with respect to 3229 user data message transmissions. More entries in the list will allow 3230 the sender to be more responsive to congestion control dynamics. The 3231 length of the list can be dynamically determined according to the 3232 current transmission rate and scheduling of "NORM_CMD(CC)" messages. 3233 The maximum length of the list corresponds to the sender's 3234 NormSegmentSize parameter for the session. The inclusion of 3235 additional entries in the list based on receiver feedback are 3236 prioritized with following rules: 3238 1. Receivers that have not yet been provided a RTT measurement get 3239 first priority. Of these, those with the greatest loss fraction 3240 receive precedence for list inclusion. 3242 2. Secondly, receivers that have previously been provided a RTT 3243 measurement are included with receivers yielding the lowest 3244 calculated congestion rate getting precedence. 3246 There are "cc_flag" values in addition to "NORM_FLAG_CC_CLR" used for 3247 other congestion control functions. The "NORM_FLAG_CC_PLR" flag 3248 value is used to mark additional receivers from which the sender 3249 would like to have immediate, non-suppressed feedback. These can be 3250 receivers the sender algorithmically identified as potential future 3251 CLRs or have been pre-configured as potential congestion control 3252 points in the network. The "NORM_FLAG_CC_RTT" indicates the validity 3253 of the "cc_rtt" field for the associated receiver node. Normally, 3254 this flag will be set since the receivers in the list will typically 3255 be receivers from which the sender has received feedback. However, 3256 in the case the NORM sender has been pre-configured with a set of PLR 3257 nodes, feedback from those receivers might not have yet been 3258 collected and thus the "cc_rtt" field does not contain a valid value 3259 when this flag is not set. Similarly, a value of "ZERO" for the 3260 "cc_rate" field here MUST be treated as an invalid value and be 3261 ignored for the purposes of feedback suppression, etc. 3263 5.5.2.2. NORM_CMD(CC) Feedback Response 3265 Receivers explicitly respond to "NORM_CMD(CC)" messages in the form 3266 of a "NORM_ACK(RTT)" message. The goal of the congestion control 3267 feedback is to determine the receivers with the lowest congestion 3268 control rates. Receivers marked as CLR or PLR nodes in the 3269 "NORM_CMD(CC)" "cc_node_list" immediately provide feedback in the 3270 form of a "NORM_ACK" to this message. When a "NORM_CMD(CC)" is 3271 received, non-CLR or non-PLR nodes initiate random feedback backoff 3272 timeouts similar to that used when the receiver initiates a repair 3273 cycle (see Section 5.3) in response to detection of data loss. The 3274 backoff timeout for the congestion control response is generated as 3275 follows: 3276 T_backoff = RandomBackoff(K_backoff * GRTT_sender, GSIZE_sender) 3278 The ""RandomBackoff()"" algorithm provides a truncated exponentially 3279 distributed random number and is described in the Multicast NACK 3280 Building Block [RFC5401]. The same backoff factor, "K_backoff = 3281 K_sender", as used with " NORM_NACK" suppression is generally 3282 RECOMMENDED. However, in cases where the application purposefully 3283 specifies a very small "K_sender" backoff factor to minimize the NACK 3284 repair process latency (trading off group size scalability), it is 3285 RECOMMENDED a larger backoff factor for congestion control feedback 3286 be maintained, since there can be a larger volume of congestion 3287 control feedback than NACKs in many cases and some congestion control 3288 feedback latency might be tolerable where reliable delivery latency 3289 is not. As previously noted, a backoff factor value of "K_sender = 3290 4" is generally RECOMMENDED for ASM operation and "K_sender = 6" for 3291 SSM operation. A receiver SHALL cancel the backoff timeout and thus 3292 its pending transmission of a "NORM_ACK(RTT)" message under the 3293 following conditions: 3295 1. The receiver generates another feedback message ("NORM_NACK" or 3296 other "NORM_ACK") before the congestion control feedback timeout 3297 expires (these messages will convey the current congestion 3298 control feedback information), 3300 2. A "NORM_CMD(CC)" or other receiver feedback with an ordinally 3301 greater "cc_sequence" field value is received before the 3302 congestion control feedback timeout expires (this is similar to 3303 the TFMCC feedback round number), 3305 3. When the "T_backoff" is greater than "1*GRTT_sender". This 3306 prevents NACK implosion in the event of sender or network 3307 failure, 3309 4. "Suppressing" congestion control feedback is heard from another 3310 receiver (in a "NORM_ACK" or "NORM_NACK") or via a 3311 "NORM_CMD(REPAIR_ADV)" message from the sender. The local 3312 receiver's feedback is "suppressed" if the rate of the competing 3313 feedback ("Rfb") is sufficiently close to or less than the local 3314 receiver's calculated rate ("Rcalc"). The local receiver's 3315 feedback is canceled when "Rcalc > (0.9 * Rfb)". Also note 3316 receivers that have not yet received an RTT measurement from the 3317 sender are suppressed only by other receivers that have not yet 3318 measured RTT. Additionally, receivers whose RTT estimate has 3319 aged considerably (i.e., they haven't been included in the 3320 "NORM_CMD(CC)" "cc_node_list" in a long time) might wish to 3321 compete as a receiver with no prior RTT measurement after some 3322 long term expiration period. 3324 When the backoff timer expires, the receiver SHALL generate a 3325 "NORM_ACK(RTT)" message to provide feedback to the sender and group. 3326 This message MAY be multicast to the group for most effective 3327 suppression in ASM topologies or unicast to the sender depending upon 3328 how the NORM protocol is deployed and configured. 3330 Whenever any feedback is generated (including this "NORM_ACK(RTT)" 3331 message), receivers include an adjusted version of the sender 3332 timestamp from the most recently received "NORM_CMD(CC)" message and 3333 its "cc_sequence" value in the corresponding "NORM_ACK" or 3334 "NORM_NACK" message fields. For NORM-CC operation, any generated 3335 feedback message SHALL also contain the NORM-CC Feedback header 3336 extension. The receiver provides its current "cc_rate" estimate, 3337 "cc_loss" estimate, "cc_rtt" if known, and any applicable "cc_flags" 3338 via this header extension. 3340 During slow start (when the receiver has not yet detected loss from 3341 the sender), the receiver uses a value equal to two times its 3342 measured rate from the sender in the "cc_rate" field. For steady- 3343 state congestion control operation, the receiver "cc_rate" value is 3344 from the equation-based value using its current loss event estimate 3345 and sender<->receiver RTT information. (The "GRTT_sender" is used 3346 when the receiver has not yet measured its individual RTT). 3348 The "cc_loss" field value reflects the receiver's current loss event 3349 estimate with respect to the sender in question. 3351 When the receiver has a valid individual RTT measurement, it SHALL 3352 include this value in the "cc_rtt" field. The "NORM_FLAG_CC_RTT" 3353 MUST be set when the "cc_rtt" field is valid. 3355 After a congestion control feedback message is generated or when the 3356 feedback is suppressed, a non-CLR receiver begins a "holdoff" timeout 3357 period during which it will restrain itself from providing congestion 3358 control feedback, even if "NORM_CMD(CC)" messages are received from 3359 the sender (unless the receive becomes marked as a CLR or PLR node). 3360 The value of this holdoff timeout ("T_ccHoldoff") period is: 3361 T_ccHoldoff = (K_sender * GRTT_sender) 3363 Thus, non-CLR receivers are constrained to providing explicit 3364 congestion control feedback once per "K_sender*GRTT_sender" 3365 intervals. However, as the session progresses, different receivers 3366 will be responding to different "NORM_CMD(CC)" messages and there 3367 will be relatively continuous feedback of congestion control 3368 information 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 [TfmccPaper], 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 3391 ("RTT_rcvr"). For non-CLR and non-PLR receivers, the sender can use 3392 the "cc_rtt" value provided in the NORM-CC Feedback header extension 3393 as the receiver's previous RTT measurement ("RTT_rcvrPrev") to smooth 3394 according to: 3395 RTT_rcvr = 0.5 * RTT_rcvrPrev + 0.5 * RTT_rcvrNew 3397 For CLR receivers where feedback is received more regularly, the 3398 sender SHOULD maintain a more smoothed RTT estimate upon new feedback 3399 from the CLR where: 3400 RTT_clr = 0.9 * RTT_clr + 0.1 * RTT_clrNew 3402 ""RTT_clrNew"" is the new RTT calculated from the timestamp in the 3403 feedback message received from the CLR. The "RTT_clr" is initialized 3404 to "RTT_clrNew" on the first feedback message received. Note the 3405 same procedure is observed by the sender for PLR receivers, and if a 3406 PLR is "promoted" to CLR status, the smoothed estimate can be 3407 continued. 3409 There are some additional periods besides steady-state operation to 3410 be considered in NORM-CC operation. These periods are: 3412 1. during session startup, 3414 2. when no feedback is received from the CLR, and 3416 3. when the sender has a break in data transmission. 3418 During session startup, the congestion control operation SHALL 3419 observe a "slow start" procedure to quickly approach its fair 3420 bandwidth share. An initial sender startup rate is assumed where: 3421 Rinit = MIN(NormSegmentSize/GRTT_sender, NormSegmentSize) bytes/sec 3423 The rate is increased only when feedback is received from the 3424 receiver set. The "slow start" phase proceeds until any receiver 3425 provides feedback indicating loss has occurred. Rate increase during 3426 slow start is applied as: 3427 Rnew = Rrecv_min 3429 where "Rrecv_min" is the minimum reported receiver rate in the 3430 "cc_rate" field of congestion control feedback messages received from 3431 the group. Note during slow start, receivers use two times their 3432 measured rate from the sender in the "cc_rate" field of their 3433 feedback. Rate increase adjustment is limited to once per GRTT 3434 during slow start. 3436 If the CLR or any receiver intends to leave the group, it will set 3437 the "NORM_FLAG_CC_LEAVE" in its congestion control feedback message 3438 as an indication the sender SHOULD NOT select it as the CLR. When 3439 the CLR changes to a lower rate receiver, the sender SHOULD 3440 immediately adjust to the new lower rate. The sender is limited to 3441 increasing its rate at one additional packet per RTT towards any new, 3442 higher CLR rate. 3444 The sender SHOULD also track the age of the feedback it has received 3445 from the CLR by comparing its current "cc_sequence" value 3446 ("Seq_sender") to the last "cc_sequence" value received from the CLR 3447 ("Seq_clr"). As the age of the CLR feedback increases with no new 3448 feedback, the sender SHALL begin reducing its rate once per "RTT_clr" 3449 as a congestion avoidance measure. The following algorithm is used 3450 to determine the decrease in sender rate (Rsender bytes/sec) as the 3451 CLR feedback, unexpectedly, excessively ages: 3452 Age = Seq_sender - Seq_clr; 3453 if (Age > 4) Rsender = Rsender * 0.5; 3455 This rate reduction is limited to the lower bound on NORM 3456 transmission rate. After "NORM_ROBUST_FACTOR" consecutive 3457 "NORM_CMD(CC)" rounds without any feedback from the CLR, the sender 3458 SHOULD assume the CLR has left the group and pick the receiver with 3459 the next lowest rate as the new CLR. Note this assumes the sender 3460 does not have explicit knowledge the CLR intentionally left the 3461 group. If no receiver feedback is received, the sender MAY wish to 3462 withhold further transmissions of "NORM_DATA" segments and maintain 3463 "NORM_CMD(CC)" transmissions only until feedback is detected. After 3464 such a CLR timeout, the sender will be transmitting with a minimal 3465 rate and SHOULD return to slow start as described here for a break in 3466 data transmission. 3468 When the sender has a break in its data transmission, it can continue 3469 to probe the group with "NORM_CMD(CC)" messages to maintain RTT 3470 collection from the group. This will enable the sender to quickly 3471 determine an appropriate CLR upon data transmission restart. 3472 However, the sender SHOULD exponentially reduce its target rate to be 3473 used for transmission restart as time since the break elapses. The 3474 target rate SHOULD be recalculated once per "RTT_clr" as: 3475 Rsender = Rsender * 0.5; 3477 If the minimum NORM rate is reached, the sender SHOULD set the 3478 "NORM_FLAG_START" flag in its "NORM_CMD(CC)" messages upon restart 3479 and the group SHOULD observe slow start congestion control procedures 3480 until any receiver experiences a new loss event. 3482 5.5.3. NORM Positive Acknowledgment Procedure 3484 NORM provides options for the source application to request positive 3485 acknowledgment (ACK) of "NORM_CMD(FLUSH)" and "NORM_CMD(ACK_REQ)" 3486 messages from members of the group. There are some specific 3487 acknowledgment requests defined for the NORM protocol and a range of 3488 acknowledgment request types left to be defined by the application. 3489 One predefined acknowledgment type is the "NORM_ACK_FLUSH" type. 3490 This acknowledgment is used to determine if receivers have achieved 3491 completion of reliable reception up through a specific logical 3492 transmission point with respect to the sender's sequence of 3493 transmission. The "NORM_ACK_FLUSH" acknowledgment MAY be used to 3494 assist in application flow control when the sender has information on 3495 a portion of the receiver set. Another predefined acknowledgment 3496 type is "NORM_ACK(CC)" used to explicitly provide congestion control 3497 feedback in response to "NORM_CMD(CC)" messages transmitted by the 3498 sender for NORM-CC operation. Note the "NORM_ACK(CC)" response does 3499 NOT follow the positive acknowledgment procedure described here. The 3500 "NORM_CMD(ACK_REQ)" and "NORM_ACK" messages contain an "ack_type" 3501 field to identify the type of acknowledgment requested and provided. 3502 A range of "ack_type" values is provided for application-defined use. 3503 While the application is responsible for initiating the 3504 acknowledgment request and interprets application-defined "ack_type" 3505 values, the acknowledgment procedure SHOULD be conducted within the 3506 protocol implementation to take advantage of timing and transmission 3507 scheduling information available to the NORM transport. 3509 The NORM positive acknowledgment procedure uses polling by the sender 3510 to query the receiver group for response. Note this polling 3511 procedure is not intended to scale to very large receiver groups, but 3512 could be used in large group setting to query a critical subset of 3513 the group. Either the "NORM_CMD(ACK_REQ)", or when applicable, the 3514 "NORM_CMD(FLUSH)" message is used for polling and contains a list of 3515 NormNodeIds of the receivers expected to respond to the command. The 3516 list of receivers providing acknowledgment is determined by the 3517 source application with a priori knowledge of participating nodes or 3518 via some other application-level mechanism. 3520 The ACK process is initiated by the sender generating 3521 "NORM_CMD(FLUSH)" or "NORM_CMD(ACK_REQ)" messages in periodic rounds. 3522 For "NORM_ACK_FLUSH" requests, the "NORM_CMD(FLUSH)" contain a 3523 "object_transport_id" and "fec_payload_id" denoting the watermark 3524 transmission point for which acknowledgment is requested. This 3525 watermark transmission point is echoed in the corresponding fields of 3526 the "NORM_ACK(FLUSH)" message sent by the receiver in response. 3527 "NORM_CMD(ACK_REQ)" messages contain an "ack_id" field that is 3528 similarly echoed in response so the sender can match the response to 3529 the appropriate request. 3531 In response to the "NORM_CMD(ACK_REQ)", the listed receivers 3532 randomly, with a uniform distribution, transmit "NORM_ACK" messages 3533 over a time window of ("1*GRTT_sender"). These "NORM_ACK" messages 3534 are typically unicast to the sender. (Note "NORM_ACK(CC)" messages 3535 SHALL be multicast or unicast in the same manner as "NORM_NACK" 3536 messages). 3538 The ACK process is self-limiting and avoids ACK implosion because: 3540 1. Only a single "NORM_CMD(ACK_REQ)" message is generated once per 3541 ("2*GRTT_sender"), and, 3543 2. The size of the "acking_node_list" of NormNodeIds from which 3544 acknowledgment is requested is limited to a maximum of the sender 3545 NormSegmentSize setting per round of the positive acknowledgment 3546 process. 3548 Because the size of the included list is limited to the sender's 3549 NormSegmentSize setting, multiple "NORM_CMD(ACK_REQ)" rounds will 3550 sometimes be necessary to achieve responses from all receivers 3551 specified. The content of the attached NormNodeId list will be 3552 dynamically updated as this process progresses and "NORM_ACK" 3553 responses are received from the specified receiver set. As the 3554 sender receives valid responses (i.e., matching watermark point or 3555 "ack_id") from receivers, it SHALL eliminate those receivers from the 3556 subsequent "NORM_CMD(ACK_REQ)" message "acking_node_list" and add in 3557 any pending receiver NormNodeIds while keeping within the 3558 NormSegmentSize limitation of the list size. Each receiver is 3559 queried a maximum number of times ("NORM_ROBUST_FACTOR", by default). 3560 Receivers not responding within this number of repeated requests are 3561 removed from the payload list to make room for other potential 3562 receivers pending acknowledgment. The transmission of the 3563 "NORM_CMD(ACK_REQ)" is repeated until no further responses are needed 3564 or until the repeat threshold is exceeded for all pending receivers. 3565 The transmission of "NORM_CMD(ACK_REQ)" or "NORM_CMD(FLUSH)" messages 3566 to conduct the positive acknowledgment process is multiplexed with 3567 ongoing sender data transmissions. However, the "NORM_CMD(FLUSH)" 3568 positive acknowledgment process MAY be interrupted in response to 3569 negative acknowledgment repair requests (NACKs) received from 3570 receivers during the acknowledgment period. The "NORM_CMD(FLUSH)" 3571 positive acknowledgment process is restarted for receivers pending 3572 acknowledgment once any the repairs have been transmitted. 3574 In the case of "NORM_CMD(FLUSH)" commands with an attached 3575 "acking_node_list", receivers will not ACK until they have received 3576 complete transmission of all data up to and including the given 3577 watermark transmission point. All receivers SHALL interpret the 3578 watermark point provided in the request NACK for repairs if needed as 3579 for "NORM_CMD(FLUSH)" commands with no attached "acking_node_list". 3581 5.5.4. Group Size Estimate 3583 NORM sender messages contain a "gsize" field that is a representation 3584 of the group size and is used in scaling random backoff timer ranges. 3585 The use of the group size estimate within the NORM protocol does not 3586 demand a precise estimation and works reasonably well if the estimate 3587 is within an order of magnitude of the actual group size. By 3588 default, the NORM sender group size estimate MAY be administratively 3589 configured. Also, given the expected scalability of the NORM 3590 protocol for general use, a default value of 10,000 is RECOMMENDED 3591 for use as the group size estimate. It is also possible the group 3592 size MAY be algorithmically approximated from the volume of 3593 congestion control feedback messages based on the exponentially 3594 weighted random backoff. However, the specification of such an 3595 algorithm is currently beyond the scope of this document. 3597 6. Configurable Elements 3599 The NORM protocol supports a modest number of configurable parameters 3600 that control operation. Most of these need only be set at NORM 3601 sender(s) and the configuration information is communicated to the 3602 receiver set in NORM header and/or header extension fields. A 3603 notable exception to this is the "NORM_ROBUST_FACTOR" that is 3604 presumed to be a common value preset among senders and receivers for 3605 a given NORM session. The following table summarizes these 3606 configurable elements: 3608 +----------------------+--------------------------------------------+ 3609 | Configurable Element | Purpose | 3610 +----------------------+--------------------------------------------+ 3611 | Sender Initial GRTT | Sender's Initial estimate of greatest | 3612 | Estimate | group round trip time. Affects timing of | 3613 | ("GRTT_sender") | feedback suppression and sender command | 3614 | | transmissions at sender startup. | 3615 | Backoff Factor | Sender's scaling factor used for | 3616 | ("K_sender") | timer-based feedback suppression. | 3617 | Group Size Estimate | Sender's rough estimate of receiver group | 3618 | ("GSIZE_sender") | size used in generation of random feedback | 3619 | | backoff timeout. | 3620 | "NORM_ROBUST_FACTOR" | Integer factor determining how | 3621 | | persistently (i.e. robust) senders | 3622 | | transmit repeated control messages and | 3623 | | receivers self-initiate timeout-based | 3624 | | NACKing in absence of sender activity. | 3625 | FEC Type ("fec_id") | Sender FEC encoding type. | 3626 | Sender segment size | Maximum size (in bytes) of the payload | 3627 | ("NormSegmentSize") | portion of "NORM_DATA" and other messages. | 3628 | NormNodeId | Unique identifiers pre-assigned to all | 3629 | | NORM session participants. | 3630 +----------------------+--------------------------------------------+ 3632 The sender-controlled GRTT estimate (referred to as "GRTT_sender" in 3633 this document) is used to set and scale various timers associated 3634 with NORM protocol operation. During steady-state operation, the 3635 sender probes the receiver set, adapts to the group round trip timing 3636 state, and advertises its estimate to the receiver set in "grtt" 3637 field of relevant NORM protocol messages. However, an initial value 3638 must be assumed at sender startup. A large initial estimate is 3639 conservative and safer with regards to preventing feedback implosion 3640 and starting up congestion control operation, but requires the sender 3641 and receivers to allocate more buffering resources for a given 3642 transmission rate (i.e. larger effective delay*bandwidth product) to 3643 maintain efficient operation. A default initial value of 3644 "GRTT_sender = 0.5" seconds is RECOMMENDED. 3646 The sender-controlled Backoff Factor (referred to a "K_sender" in 3647 this document) is used to scale protocol timers and contributes to 3648 the generation of the random backoff timeout value that facilitates 3649 timer-based feedback suppression. The sender advertises its 3650 configured Backoff Factor to the receiver set in the "backoff" field 3651 of applicable NORM messages and thus no receiver configuration is 3652 necessary. For ASM operation a default value of "K_sender = 4" is 3653 RECOMMENDED while for SSM operation a default value of "K_sender = 6" 3654 is RECOMMENDED. 3656 The sender estimate of session Group Size (referred to as 3657 "GSIZE_sender" in this document) also plays a role in the random 3658 selection of feedback suppression timeout values. The sender 3659 advertises its configured Group Size estimate to the receiver set in 3660 the "gsize" field of applicable NORM messages and thus no receiver 3661 configuration is necessary. Only a rough estimate (i.e. "order-of- 3662 magnitude") is needed for effective feedback suppression and a 3663 default value of "GSIZE_sender = 10,000" is RECOMMENDED as a 3664 conservative estimate for most uses. 3666 The "NORM_ROBUST_FACTOR" is an integer parameter that determines how 3667 persistently NORM senders transmit control message ("NORM_CMD" 3668 messages) such as end-of-transmission flushing, OPTIONAL positive 3669 acknowledgement requests, etc. Additionally, the receivers use their 3670 knowledge of "NORM_ROBUST_FACTOR" to determine when to consider a 3671 NORM sender inactive and MAY use the factor in determining how 3672 persistently to self-initiate repeated NACK repair requests upon such 3673 timeouts. This parameter is NOT communication in NORM protocol 3674 message headers and is presumed to be preset to a consistent value 3675 among sender and receivers for a given NORM session. A default value 3676 of "NORM_ROBUST_FACTOR = 20" is RECOMMENDED. 3678 Another NORM sender configuration element is the FEC Type used to 3679 encode "NORM_DATA" message content. The FEC type is communicated 3680 from the sender to the receiver set in the "fec_id" field of relevant 3681 NORM message headers. The "fec_id" value corresponds to an IANA- 3682 assigned value identifying the FEC encoding type as described in the 3683 FEC Building Block [RFC5052]. Typically, a sender SHOULD use a 3684 consistent FEC encoding for its participation in a session to simply 3685 receiver state allocation and maintenance, but it implementations MAY 3686 vary the FEC encoding type on a per-object basis if necessary. 3688 The sender NormSegmentSize setting determines the maximum size of the 3689 payload portion of "NORM_DATA" and other messages that the sender 3690 transmits. Additionally the payload size of feedback messages from 3691 receivers to a given sender is limited to that sender's 3692 NormSegmentSize. The NormSegmentSize SHOULD be configured to be 3693 compatible with expected network MTU limitations, given the added 3694 overhead of NORM, UDP, and IP protocol message headers. 3695 Additionally, MTU Discovery MAY be employed by the sender to 3696 determine an appropriate NormSegmentSize. The NormSegmentSize for a 3697 given sender can be determined by receivers from the FEC Object 3698 Transmission Information (FTI) provided either in applied EXT_FTI 3699 header extensions or pre-configured session information. 3701 Although it is not technically a configurable element, the receivers 3702 MUST have FEC Object Transmission Information for transmitted 3703 NormObjects to properly buffer, decode, and reassemble the original 3704 content. For loosely organized NORM protocol sessions, the sender 3705 MAY apply the "EXT_FTI" Header Extension to "NORM_DATA" and 3706 "NORM_INFO" (if applicable) messages so that receivers can get this 3707 information without prior coordination. An implementation MAY also 3708 apply the "EXT_FTI" only to "NORM_INFO" messages for reduced 3709 overhead. Or, finally, applications MAY also provide the FTI out-of- 3710 band prior to sender transmission. 3712 Each participant in a NORM protocol session MUST be configured with a 3713 unique NormNodeId value. The NormNodeId value is used by receivers 3714 to identify the sender to which their NACK or other feedback messages 3715 are addressed and senders use the NormNodeId to differentiate 3716 receivers for purposes of congestion control and OPTIONAL positive 3717 acknowledgement collection. Assignment of unique NormNodeId values 3718 can be done via a priori coordination and/or use of a deconfliction 3719 mechanism external to the NORM protocol itself. The values of 3720 "NORM_NODE_NONE = 0x00000000" and "NORM_NODE_ANY = 0xffffffff" are 3721 reserved and MUST NOT be assigned to NORM participants. 3723 7. Security Considerations 3725 The same security considerations that apply to the Multicast NACK 3726 [RFC5401], TFMCC [RFC4654], and FEC [RFC5052] Building Blocks also 3727 apply to the NORM protocol. In addition to the vulnerabilities to 3728 which any IP and IP multicast protocol implementation are subject, 3729 malicious hosts might engage in excessive NACKing in an attempt to 3730 prevent the NORM sender(s) from making forward progress in reliable 3731 transmission. Receiver "join" and "service" policy enforcement as 3732 described in Section 5.2 can be applied if such activity is detected. 3733 The use of cryptographic authentication and/or confidentiality 3734 measures can be used to provide a more effective degree of protection 3735 from objectionable transmissions from unauthorized hosts. But in 3736 some cases, even with authentication, the NACK-based feedback of NORM 3737 can be exploited by replay attacks forcing the NORM sender to 3738 unnecessarily transmit repair information. This MAY be addressed in 3739 part with network layer IP security implementations that guard 3740 against this potential security exploitation or alternatively with a 3741 security mechanism using the "EXT_AUTH" header extension for similar 3742 purposes. Such security mechanisms SHOULD be deployed and used when 3743 available. 3745 The NORM protocol is compatible with the use of IP security (IPsec) 3746 [RFC4301] and the IPsec Encapsulating Security Payload (ESP) protocol 3747 or Authentication Header (AF) extension can be used to secure IP 3748 packets transmitted by NORM participants. A baseline approach to 3749 secure NORM operation using IPsec is described below. Compliant 3750 implementations of this specification are REQUIRED to be compatible 3751 with IPsec usage as described in Section 7.1. 3753 Additionally, the "EXT_AUTH" header extension (HET = 1) is reserved 3754 for use by security mechanisms to provide an alternative form of 3755 authentication and/or encryption of NORM messages. The format of 3756 this header extension and its processing is outside the scope of this 3757 document and is to be communicated out-of-band as part of the session 3758 description. It is possible an "EXT_AUTH" implementation of MAY also 3759 provide for encryption of NORM message payloads as well as 3760 authentication. The use of this approach as compared to IPsec can 3761 allow for header compression techniques to be applied jointly to IP 3762 and NORM protocol headers. In cases where security analysis deems 3763 encryption of NORM protocol header content is beneficial or 3764 necessary, the aforementioned use of IPsec ESP might be more 3765 appropriate. If "EXT_AUTH" is present, whatever packet 3766 authentication checks that can be performed immediately upon 3767 reception of the packet MUST be performed before accepting the packet 3768 and performing any congestion control-related action on it. Some 3769 packet authentication schemes impose a delay of several seconds 3770 between when a packet is received and when the packet can be fully 3771 authenticated. Any appropriate congestion control related action 3772 MUST NOT be postponed by any such full packet authentication (i.e. 3773 authentication mechanisms MUST NOT result in poor congestion control 3774 behavior). 3776 Consideration MUST also be given to the potential for replay-attacks 3777 that would transplant authenticated packets from one NORM session to 3778 another to disrupt service. To avoid this potential, unique keys 3779 SHOULD be assigned on a per-session basis or NORM sender nodes SHOULD 3780 be configured to use unique "instance_id" identifiers managed as part 3781 of the security association for the sessions. 3783 Note NORM implementations can use the "sequence" field from the NORM 3784 Common Message Header to detect replay attacks. This can be 3785 accomplished if the NORM sender maintains state on actively NACKing 3786 receivers. A cache of such receiver state can be used to provide 3787 protection against NACK replay attacks. NORM receivers MUST also 3788 maintain similar state for protection against possible replay of 3789 other receiver messages in ASM operation as well. For example, a 3790 receiver could be suppressed from providing NACK or congestion 3791 control feedback by replay of certain receiver messages. For these 3792 reasons, authentication of NORM messages (e.g., via IPsec) SHOULD be 3793 applied for protection against similar attacks that use fabricated 3794 messages. Also, encryption of messages to provide confidentiality of 3795 application data and protect privacy of users MAY also be applied 3796 using IPsec or similar mechanisms. 3798 When applicable security measures are used, automated key management 3799 mechanisms such as those described in the Group Domain of 3800 Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY) 3801 [RFC3830] or Group Secure Association Key Management Protocol 3802 (GSAKMP) [RFC4535] specifications SHOULD be applied. 3804 While NORM does leverage FEC-based repair for scalability, this alone 3805 does not guarantee integrity of received data. Application-level 3806 integrity-checking of received data content is highly RECOMMENDED. 3808 7.1. Baseline Secure NORM Operation 3810 This section describes a baseline mode of secure NORM protocol 3811 operation based on application of the IPsec security protocol. This 3812 approach is documented here to provide a reference, interoperable 3813 secure mode of operation. Additional approaches to NORM security, 3814 including other forms of IPsec application, MAY be specified in the 3815 future. For example, the use of the EXT_AUTH header extension could 3816 enable NORM-specific authentication or security encapsulation headers 3817 similar to those of IPsec to be specified and inserted into the NORM 3818 protocol message headers. This would allow header compression 3819 techniques to be applied to IP and NORM protocol headers when needed 3820 in a similar fashion to RTP [RFC3550] and as preserved in the 3821 specification for Secure Real Time Protocol (SRTP) [RFC3711]. 3823 The baseline approach described is applicable to NORM operation 3824 configured for SSM (or SSM-like) operation where there is a single 3825 sender and the receivers are providing unicast feedback. This form 3826 of NORM operation allows for IPsec to be used with a manageable 3827 number of security associations (SA). 3829 7.1.1. IPsec Approach 3831 For NORM one-to-many SSM operation with unicast feedback from 3832 receivers, each node SHALL be configured with two transport mode 3833 IPsec security associations and corresponding Security Policy 3834 Database (SPD) entries. One entry will be used for sender-to-group 3835 multicast packet authentication and optionally encryption while the 3836 other entry will be used to provide security for the unicast feedback 3837 messaging from the receiver(s) to the sender. 3839 The NORM sender SHALL use an IPsec SA configured for ESP protocol 3840 [RFC4303] operation with the option for data origination 3841 authentication enabled. It is also RECOMMENDED this IPsec ESP SA be 3842 also configured to provide confidentiality protection for IP packets 3843 containing NORM protocol messages. This is suggested to make the 3844 realization of complex replay attacks much more difficult. The 3845 encryption key for this SA SHALL be preplaced at the sender and 3846 receiver(s) prior to NORM protocol operation. Use of automated key 3847 management is RECOMMENDED as a rekey SHALL be REQUIRED prior to 3848 expiration of the sequence space for the SA. This is necessary so 3849 receivers can use the built-in IPsec replay attack protection 3850 possible for an IPsec SA with a single source (the NORM sender). 3851 Thus the receivers SHALL enable replay attack protection for this SA 3852 used to secure NORM sender traffic. An IPsec SPD entry MUST be 3853 configured to process outbound packets to the session (destination) 3854 address and UDP port number of the applicable (NormSession). 3856 The NORM receiver(s) MUST be configured with the SA and SPD entry to 3857 properly process the IPsec-secured packets from the sender. The NORM 3858 receiver(s) SHALL also use a common, second IPsec SA (common Security 3859 Parameter Index (SPI) and encryption key) configured for ESP 3860 operation with the option for data origination authentication 3861 enabled. Similar to the NORM sender, is RECOMMENDED this IPsec ESP 3862 SA be also configured to provide confidentiality protection for IP 3863 packets containing NORM protocol messages. The receivers MUST have 3864 an IPsec SPD entry configured to process outbound NORM/UDP packets 3865 directed to the NORM sender source address and port number using this 3866 second SA. To support NORM unicast feedback, the sender's 3867 transmission port number SHOULD be selected to be distinct from the 3868 multicast session port number to allow discrimination between unicast 3869 and multicast feedback messages when access to the IP destination 3870 address is not possible (e.g., a user-space NORM implementation). 3871 For processing of packets from receivers, the NORM sender SHALL be 3872 configured with this common, second SA (and the corresponding SPD 3873 entry needed) in order to properly process messages from the 3874 receiver. 3876 Multiple receivers using a common IPsec SA for traffic directed to 3877 the NORM sender (i.e., many-to-one) typically prevents the use of 3878 built-in IPsec replay attack protection by the NORM sender with 3879 current IPsec implementations. Thus the built-in IPsec replay attack 3880 protection for this second SA at the sender MUST be disabled unless 3881 the particular IPsec implementation manages its replay protection on 3882 a per-source basis. So, to support a fully secure mode of operation, 3883 the NORM sender implementation MUST provide replay attack protection 3884 based upon the "sequence" field of NORM protocol messages from 3885 receivers. This can be accomplished with high assurance of security, 3886 even with the limited size (16-bits) of this field, because 3888 1. NORM receiver NACK and non-CLR ACK feedback messages are sparse. 3890 2. The more frequent "NORM_ACK" feedback from CLR or PLR nodes are 3891 only a small set of receivers for which the sender needs to keep 3892 more persistent replay attack state. 3894 3. "NORM_NACK" feedback messages preceding the sender's current 3895 repair window do not significantly impact protocol operation 3896 (generation of "NORM_CMD(SQUELCH)" is limited) and could be in 3897 fact ignored. This means the sender can prune any replay attack 3898 state that precedes the current repair window. 3900 4. "NORM_ACK" messages correspond to either a specific sender 3901 "ack_id", the sender "cc_sequence" for ACKs sent in response to 3902 "NORM_CMD(CC)", or the sender's current repair window in the case 3903 of ACKs sent in response to "NORM_CMD(FLUSH)". Thus, the sender 3904 can prune any replay attack state for receivers that precede the 3905 current applicable sequence or repair window space. 3907 The use of ESP confidentiality for secure NORM protocol operation 3908 makes it more difficult for adversaries to conduct any form of replay 3909 attacks. Additionally, a NORM sender implementation with access to 3910 the full ESP protocol header could also use the ESP sequence 3911 information to make replay attack protection even more robust by 3912 maintaining per-source sequence state. The design of this baseline 3913 security approach for NORM intentionally places any more complex 3914 processing state or processing (e.g. replay attack protection given 3915 multiple receivers) at the NORM sender since NORM receiver 3916 implementations might often need to be less complex. 3918 This baseline approach can be used for NORM protocol sessions with 3919 multiple senders if the SA pairs described are established for each 3920 sender. For small-sized groups, it is even possible many-to-many 3921 (ASM) IPsec configuration could be achieved where each participant 3922 uses a unique SA (with a unique SPI). This does not scale to larger 3923 group sizes given the complex set of SA and SPD entries each 3924 participant would need to maintain. 3926 It is anticipated in early deployments of this baseline approach to 3927 NORM security that key management will be conducted out-of-band with 3928 respect to NORM protocol operation. In the case of one-to-many NORM 3929 operation, it is possible receivers will retrieve keying information 3930 from a central server as needed or otherwise conduct group key 3931 updates with a similar centralized approach. Alternatively, it is 3932 possible with some key management schemes for rekey messages to be 3933 transmitted to the group as a message or transport object within the 3934 NORM reliable transfer session. Similarly, for group-wise 3935 communication sessions it is possible for potential group 3936 participants to request keying and/or rekeying as part of NORM 3937 communications. Additional specification is necessary to define an 3938 in-band key management scheme for NORM sessions perhaps using the 3939 mechanisms of the automated group key management specifications cited 3940 in this document. 3942 7.1.2. IPsec Requirements 3944 In order to implement this secure mode of NORM protocol operation, 3945 the following IPsec capabilities are REQUIRED. 3947 7.1.2.1. Selectors 3949 The implementation MUST be able to use the source address, 3950 destination address, protocol (UDP), and UDP port numbers as 3951 selectors in the SPD. 3953 7.1.2.2. Mode 3955 IPsec in transport mode MUST be supported. The use of IPsec 3956 [RFC4301] processing for secure NORM traffic MUST be configured such 3957 that unauthenticated packets are not received by the NORM protocol 3958 implementation. 3960 7.1.2.3. Key Management 3962 An automated key management scheme for group key distribution and 3963 rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] 3964 is RECOMMENDED for use. Relatively short-lived NORM sessions MAY be 3965 able to use Manual Keying with a single, preplaced key, particularly 3966 if Extended Sequence Numbering (ESN) [RFC4303] is available in the 3967 IPsec implementation used. Note it is possible for key update 3968 messages (e.g., the GDOI GROUPKEY-PUSH message) to be included as 3969 part of the NORM application reliable data transmission if 3970 appropriate interfaces are available between the NORM application and 3971 the key management daemon. 3973 7.1.2.4. Security Policy 3975 Receivers MUST accept protocol messages only from the designated, 3976 authorized sender(s). Appropriate key management will provide 3977 encryption keys only to receivers authorized to participate in a 3978 designated session. The approach outlined here allows receiver sets 3979 to be controlled on a per-sender basis. 3981 7.1.2.5. Authentication and Encryption 3983 Large NORM group sizes will necessitate some form of key management 3984 that does rely upon shared secrets. The GDOI and GSAKMP protocols 3985 mentioned here allow for certificate-based authentication. It is 3986 RECOMMENDED these certificates use IP addresses for authentication. 3988 7.1.2.6. Availability 3990 The IPsec requirements profile outlined here is commonly available on 3991 many potential NORM hosts. Configuration and operation of IPsec 3992 typically requires privileged user authorization. Automated key 3993 management implementations are typically configured with the 3994 privileges necessary to effect system IPsec configuration needed. 3996 8. IANA Considerations 3998 Values of NORM Header Extension Types, Stream Control Codes, and 3999 "NORM_CMD" message sub-types are subject to IANA registration. They 4000 are in the registry named "Reliable Multicast Transport (RMT) NORM 4001 Protocol Parameters" located at time of publication at: 4003 http://www.iana.org/assignments/norm-parameters 4005 Note the reliable multicast building block components used by this 4006 specification also have their respective IANA considerations and 4007 those documents SHOULD be consulted accordingly. In particular, the 4008 FEC Building Block used by NORM does REQUIRE IANA registration of the 4009 FEC codecs used. The registration instructions for FEC codecs are 4010 provided in RFC 5052. It is possible additional extensions of the 4011 NORM protocol might be specified in the future (e.g., additional NORM 4012 message types) and additional registries be established at that time 4013 with appropriate IETF standards action. 4015 8.1. Explicit IANA Assignment Guidelines 4017 This document introduces three registries for the NORM Header 4018 Extension Types, Stream Control Codes and "NORM_CMD" Message sub- 4019 types. This section describes explicit IANA assignment guidelines 4020 for each of these. 4022 8.1.1. NORM Header Extension Types 4024 This document defines a registry for NORM Header Extensions named 4025 "NORM Header Extension Types". 4027 The NORM Header Extension Type field is an 8-bit value. The values 4028 of this field identify extended header content allowing the protocol 4029 functionality to be expanded to include additional features and 4030 operating modes. The values that can be assigned within the "NORM 4031 Header Extensions" registry are numeric indexes in the range {0, 4032 255}, boundaries included. Values in the range {0,127} indicate 4033 variable length extended header fields while values in the range 4034 {128,255} indicate extensions of a fixed 4-byte length. This 4035 specification registers the following NORM Header Extension Types: 4037 +-------+------------+--------------------+ 4038 | Value | Name | Reference | 4039 +-------+------------+--------------------+ 4040 | 1 | "EXT_AUTH" | This specification | 4041 | 3 | "EXT_CC" | This specification | 4042 | 64 | "EXT_FTI" | This specification | 4043 | 128 | "EXT_RATE" | This specification | 4044 +-------+------------+--------------------+ 4046 Requests for assignment of additional NORM Header Extension Type 4047 values are granted on a "Specification Required" basis as defined by 4048 IANA Guidelines [RFC5226]. Any such header extension specifications 4049 MUST include a description of protocol actions to be taken when the 4050 extension type is encountered by a protocol implementation not 4051 supporting that specific option. For example, it is often possible 4052 for protocol implementations to ignore unknown header extensions. 4054 8.1.2. NORM Stream Control Codes 4056 This document defines a registry for NORM Stream Control Codes named 4057 "NORM Stream Control Codes". 4059 NORM Stream Control Codes are 16-bit values that can be inserted 4060 within a "NORM_OBJECT_STREAM" delivery object to convey sequenced, 4061 out-of-band (with respect to the stream data) control signaling 4062 applicable to the referenced stream object. These control codes are 4063 to be delivered to the application or protocol implementation with 4064 reliable delivery, in-order with respect to the their inserted 4065 position within the stream. This specification registers the 4066 following NORM Stream Control Code: 4068 +-------+-------------------+--------------------+ 4069 | Value | Name | Reference | 4070 +-------+-------------------+--------------------+ 4071 | 0 | "NORM_STREAM_END" | This specification | 4072 +-------+-------------------+--------------------+ 4074 Additional NORM Stream Control Code value assignment requests are 4075 granted on a "Specification Required" basis as defined by IANA 4076 Guidelines [RFC5226]. The full 16-bit space outside of the value 4077 assigned in this specification are available for future assignment. 4078 In addition to describing the control code's expected interpretation, 4079 such specifications MUST include a description of protocol actions to 4080 be taken when the control code is encountered by a protocol 4081 implementation not supporting that specific option. 4083 8.1.3. NORM_CMD Message Sub-types 4085 This document defines a registry for "NORM_CMD" message sub-types 4086 named "NORM Command Message Sub-types". 4088 The "NORM_CMD" message "sub-type" field is an 8-bit value with valid 4089 values in the range of 1-255. Note the value 0 is reserved to 4090 indicate an invalid "NORM_CMD" message sub-type. The current 4091 specification defines a number of "NORM_CMD" message sub-types 4092 senders can use to signal the receivers in various aspects of NORM 4093 protocol operation. This specification registers the following 4094 "NORM_CMD" Message Sub-types: 4096 +-------+-------------------------+--------------------+ 4097 | Value | Name | Reference | 4098 +-------+-------------------------+--------------------+ 4099 | 0 | reserved | This specification | 4100 | 1 | "NORM_CMD(FLUSH)" | This specification | 4101 | 2 | "NORM_CMD(EOT)" | This specification | 4102 | 3 | "NORM_CMD(SQUELCH)" | This specification | 4103 | 4 | "NORM_CMD(CC)" | This specification | 4104 | 5 | "NORM_CMD(REPAIR_ADV)" | This specification | 4105 | 6 | "NORM_CMD(ACK_REQ)" | This specification | 4106 | 7 | "NORM_CMD(APPLICATION)" | This specification | 4107 +-------+-------------------------+--------------------+ 4109 Future specifications extending NORM MAY define additional "NORM_CMD" 4110 messages to enhance protocol functionality. "NORM_CMD" message sub- 4111 type value assignment requests are granted on a "Specification 4112 Required" basis as defined by IANA Guidelines [RFC5226]. In addition 4113 to describing the command sub-type's expected interpretation, 4114 specifications MUST include a description of protocol actions to be 4115 taken when the command is encountered by a protocol implementation 4116 not supporting that specific option. 4118 This specification already defines an "application-defined" 4119 "NORM_CMD" message sub-type for use at the discretion of individual 4120 applications using NORM for transport. These "application-defined" 4121 commands are suitable for many application-specific purposes and do 4122 not involve standards action. In any case, such additional messages 4123 SHALL be subject to the same congestion control constraints as the 4124 existing NORM sender message set. 4126 9. Suggested Use 4128 The present NORM protocol is seen as useful tool for the reliable 4129 data transfer over generic IP multicast services. It is not the 4130 intention of the authors to suggest it is suitable for supporting all 4131 envisioned multicast reliability requirements. NORM provides a 4132 simple and flexible framework for multicast applications with a 4133 degree of concern for network traffic implosion and protocol overhead 4134 efficiency. NORM-like protocols have been successfully demonstrated 4135 within the MBone for bulk data dissemination applications, including 4136 weather satellite compressed imagery updates servicing a large group 4137 of receivers and a generic web content reliable "push" application. 4139 In addition, this framework approach has some design features making 4140 it attractive for bulk transfer in asymmetric and wireless 4141 internetwork applications. NORM is capable of successfully operating 4142 independent of network structure and in environments with high packet 4143 loss, delay, and out-of-order delivery. Hybrid proactive/reactive 4144 FEC-based repairing improve protocol performance in some multicast 4145 scenarios. A sender-only repair approach often makes additional 4146 engineering sense in asymmetric networks. NORM's unicast feedback 4147 capability is suitable for use in asymmetric networks or in networks 4148 where only unidirectional multicast routing/delivery service exists. 4149 Asymmetric architectures supporting multicast delivery are likely to 4150 make up an important portion of the future Internet structure (e.g., 4151 direct broadcast satellite (DBS) or cable and public-switched 4152 telephone network (PSTN) hybrids, etc) and efficient, reliable bulk 4153 data transfer will be an important capability for servicing large 4154 groups of subscribed receivers. 4156 10. Changes from RFC3940 4158 This section lists the changes between the Experimental version of 4159 this specification, RFC 3940, and this version: 4161 1. Removal of the "NORM_FLAG_MSG_START" for "NORM_OBJECT_STREAM", 4162 replacing it with the "payload_msg_start" field in the FEC- 4163 encoded preamble of the "NORM_OBJECT_STREAM NORM_DATA" payload, 4165 2. Definition of IANA registry for header extension and other 4166 assignments, 4168 3. Removal of file blocking scheme description now specified in the 4169 FEC Building Block document [RFC5052], 4171 4. Removal of restriction of NORM receiver feedback message rate to 4172 local NORM sender rate (This caused congestion control failures 4173 in high speed operation. The extremely low feedback rate of the 4174 NORM protocol as compared to TCP avoids any resultant impact to 4175 the network as shown in [Mdpcc]), 4177 5. Correction of errors in some message format descriptions, and 4179 6. Correction of inconsistency in specification of the inactivity 4180 timeout. 4182 7. Addition of IPsec secure mode description with IPsec 4183 requirements. 4185 8. Addition of the EXT_AUTH header extension definition. 4187 9. Clarification of interpretation of "Source Block Length" when FEC 4188 codes are arbitrarily shortened by the sender. 4190 11. Acknowledgments 4192 (and these are not Negative) 4194 The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh, 4195 Toni Paila, Michael Luby, and Joerg Widmer for their valuable input 4196 and comments on this document. The authors would also like to thank 4197 the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for 4198 their support in development of this specification, and Sally Floyd 4199 for her early input into this document. 4201 12. References 4203 12.1. Normative References 4205 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 4206 RFC 1112, August 1989. 4208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4209 Requirement Levels", BCP 14, RFC 2119, March 1997. 4211 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 4212 Internet Protocol", RFC 4301, December 2005. 4214 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 4215 RFC 4303, December 2005. 4217 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 4218 IP", RFC 4607, August 2006. 4220 [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast 4221 Congestion Control (TFMCC): Protocol Specification", 4222 RFC 4654, August 2006. 4224 [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error 4225 Correction (FEC) Building Block", RFC 5052, August 2007. 4227 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 4228 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 4229 May 2008. 4231 [RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker, 4232 "Multicast Negative-Acknowledgment (NACK) Building 4233 Blocks", RFC 5401, November 2008. 4235 12.2. Informative References 4237 [FecHybrid] 4238 Gossink, D. and J. Macker, "Reliable Multicast and 4239 Integrated Parity Retransmission with Channel Estimation", 4240 IEEE Globecomm , 1998. 4242 [McastFeedback] 4243 Nonnenmacher, J. and E. Biersack, "Optimal Multicast 4244 Feedback", IEEE INFOCOM, p. 964, March/April 1998. 4246 [MdpToolkit] 4247 Macker, J. and B. Adamson, "The Multicast Dissemination 4248 Protocol (MDP) Toolkit", Proc. IEEE MILCOM , October 1999. 4250 [Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based 4251 Mechanism for NACK-Oriented Reliable Multicast Congestion 4252 Control", Proc. IEEE GLOBECOMM , November 2001. 4254 [NormFeedback] 4255 Adamson, B. and J. Macker, "Quantitative Prediction of 4256 NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE 4257 MILCOM , October 2002. 4259 [PgmccPaper] 4260 Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast 4261 Congestion Control Scheme", ACM SIGCOMM , August 2000. 4263 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 4264 Criteria for Evaluating Reliable Multicast Transport and 4265 Application Protocols", RFC 2357, June 1998. 4267 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 4268 Announcement Protocol", RFC 2974, October 2000. 4270 [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., 4271 Floyd, S., and M. Luby, "Reliable Multicast Transport 4272 Building Blocks for One-to-Many Bulk-Data Transfer", 4273 RFC 3048, January 2001. 4275 [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for 4276 Reliable Multicast Transport (RMT) Building Blocks and 4277 Protocol Instantiation documents", RFC 3269, April 2002. 4279 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 4280 M., and J. Crowcroft, "The Use of Forward Error Correction 4281 (FEC) in Reliable Multicast", RFC 3453, December 2002. 4283 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 4284 Group Domain of Interpretation", RFC 3547, July 2003. 4286 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4287 Jacobson, "RTP: A Transport Protocol for Real-Time 4288 Applications", STD 64, RFC 3550, July 2003. 4290 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4291 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4292 RFC 3711, March 2004. 4294 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 4295 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 4296 August 2004. 4298 [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, 4299 "Negative-acknowledgment (NACK)-Oriented Reliable 4300 Multicast (NORM) Protocol", RFC 3940, November 2004. 4302 [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, 4303 "GSAKMP: Group Secure Association Key Management 4304 Protocol", RFC 4535, June 2006. 4306 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4307 Description Protocol", RFC 4566, July 2006. 4309 [RFC5445] Watson, M., "Basic Forward Error Correction (FEC) 4310 Schemes", RFC 5445, March 2009. 4312 [RmComparison] 4313 Pingali, S., Towsley, D., and J. Kurose, "A Comparison of 4314 Sender-Initiated and Receiver-Initiated Reliable Multicast 4315 Protocols", Proc. INFOCOMM, San Francisco CA, 4316 October 1993. 4318 [TcpModel] 4319 Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, 4320 "Modeling TCP Throughput: A Simple Model and its Empirical 4321 Validation", ACM SIGCOMM , 1998. 4323 [TfmccPaper] 4324 Widmer, J. and M. Handley, "Extending Equation-Based 4325 Congestion Control to Multicast Applications", ACM 4326 SIGCOMM , August 2001. 4328 Authors' Addresses 4330 Brian Adamson 4331 Naval Research Laboratory 4332 Washington, DC 20375 4333 USA 4335 Email: adamson@itd.nrl.navy.mil 4337 Carsten Bormann 4338 Universitaet Bremen TZI 4339 Postfach 330440 4340 D-28334 Bremen 4341 Germany 4343 Email: cabo@tzi.org 4345 Mark Handley 4346 University College London 4347 Gower Street 4348 London WC1E 6BT 4349 UK 4351 Email: M.Handley@cs.ucl.ac.uk 4353 Joe Macker 4354 Naval Research Laboratory 4355 Washington, DC 20375 4356 USA 4358 Email: macker@itd.nrl.navy.mil