idnits 2.17.1 draft-ietf-rmt-bb-gra-signalling-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** There are 64 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: This document and translations of it MAY be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation MAY be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself MAY NOT be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 January 2003) is 7759 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force RMT WG 2 INTERNET-DRAFT Tony Speakman/Cisco 3 draft-ietf-rmt-bb-gra-signalling-01.txt Lorenzo Vicisano/Cisco 4 21 January 2003 5 Expires: July 2003 7 Reliable Multicast Transport Building Block 8 Generic Router Assist - Signalling Protocol Specification 10 Status of this Document 12 This document is an Internet-Draft and is subject to all provisions of 13 Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is a product of the IETF RMT WG. Comments should be 31 addressed to the authors or to the WG's mailing list at rmt@ietf.org. 33 To the extent that it applies, this document is in conformance with the 34 requirements of Section 2.1 of RFC3269. 36 Lexical Conventions 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC2119. 42 ^L 43 Abstract 45 This draft specifies the signalling protocol to be implemented 46 in both end systems and network elements to activate built-in 47 GRA functionality in network elements. It specifies this 48 protocol specifically in the context of UDP as well as 49 generally in the context of prospective (reliable multicast) 50 transport protocols for IP. 52 ^L 54 Table of Contents 56 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 57 2. Definitions . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Applicability . . . . . . . . . . . . . . . . . . . . . 5 59 4. Rationale . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Functionality . . . . . . . . . . . . . . . . . . . . . 7 61 5.1. Headers. . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1.1. Header Format in the Context of UDP . . . . . . . 8 63 5.1.2. Header Format in the Context of an RMT. . . . . . 9 64 5.1.3. Header Contents . . . . . . . . . . . . . . . . . 10 65 5.2. Procedures . . . . . . . . . . . . . . . . . . . . . 11 66 5.2.1. Network Elements. . . . . . . . . . . . . . . . . 11 67 5.2.2. End Systems . . . . . . . . . . . . . . . . . . . 13 68 6. Constraints on GRA Function Specifications. . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . 16 70 8. Requirements from other Building Blocks . . . . . . . . 16 71 9. Codepoint Considerations. . . . . . . . . . . . . . . . 17 72 10. IANA Considerations. . . . . . . . . . . . . . . . . . 17 73 11. Definitions. . . . . . . . . . . . . . . . . . . . . . 17 74 12. Expired Drafts . . . . . . . . . . . . . . . . . . . . 19 76 ^L 78 1. Introduction 80 Generic Router Assist (GRA), a transport-independent mechanism for 81 providing transport protocols with access to network-element-based 82 functionality, is comprised of several components including at least a 83 signalling protocol at both the network and transport layers within 84 which to encode GRA identifiers and operands; a specification and 85 encoding of GRA functions within the network elements themselves to 86 provide pre-defined GRA functions; a per-transport-session upstream-GRA- 87 neighbour discovery mechanism; implosion control procedures to adapt to 88 the effects of changing receiver populations and changes in multicast 89 routing; and a control protocol for managing the disposition of network- 90 element-based GRA functionality both within individual network elements 91 and within individual transport sessions. 93 The utility and applicability of GRA are sufficiently wide that it makes 94 sense first to define a base signalling protocol, particularly in the 95 context of UDP, which will permit sufficient development to usefully 96 narrow the requirements on GRA so that a general specification of GRA 97 functionality and control can be undertaken. In the process, this 98 signalling protocol can also be proven and evolved. 100 To that end, this draft specifies the GRA signalling protocol to be used 101 in the context of UDP or in the context of a prospective (reliable 102 multicast) transport for IP (an RMT) to activate built-in GRA 103 functionality in network elements. For the moment, that built-in 104 functionality will be specified in separate drafts, known as GRA 105 function specifications, each of which will specify specific GRA headers 106 and the network-element-based GRA services associated with those headers 107 required to implement a given function. This draft specifies only the 108 mechanisms by which GRA headers are delivered to built-in GRA functions. 110 2. Definitions 112 The definitions of the following terms for the purposes of this document 113 are are provided in Section 11. 115 Distribution Tree Direct Path Suppression 116 Upstream Reverse Path Elimination 117 Downstream Direct GRA Packet Aggregation 118 GRA Packet Reverse GRA Packets Accumulation 119 GRA Hop 120 GRA Neighbours 122 ^L 123 3. Applicability 125 The model assumed here is that GRA may be implemented in some fraction 126 of the network elements in a source-specific multicast distribution 127 tree, that those GRA-capable network elements may discover their 128 upstream GRA neighbours through transport-session-specific announcements 129 flowing down the distribution tree, that there are pre-defined GRA 130 functions in those network elements, and that the source and the 131 receivers in the transport session direct GRA packets into the 132 distribution tree. Those packets are detected by network elements and 133 processed according to established GRA functions the specifications of 134 which determine, amongst other things, the subsequent fate of the 135 packet. 137 Each GRA function specification defines a related group of one or more 138 GRA headers that may be borne by a subset of the session's packets 139 together with the GRA services to be applied to those headers to provide 140 some feature to a session. A GRA function specification defines exactly 141 one GRA service for each GRA header, and the services must be related to 142 each other (typically through shared state) such that their joint action 143 results in a single coherent function. 145 GRA packets are recognized as such during unicast or multicast 146 forwarding, and are processed according to the appropriate GRA function 147 specification. 149 The GRA header is parsed to identify the session to which the packet 150 belongs and the applicable GRA function for that session, if any. Each 151 GRA packet matches at most one GRA function and at most one GRA service 152 in that GRA function; GRA packets that fail to match any GRA function at 153 a network element are forwarded normally. 155 The processing defined by the GRA service associated with the GRA 156 function is then carried out, using the values from the GRA header and 157 the state associated with the GRA service. When GRA processing 158 concludes successfully, the packet is either discarded or forwarded, as 159 specified by the selected GRA service. There are two forwarding 160 functions: multicast forwarding on a group of interfaces or unicast 161 forwarding to a network-layer destination. 163 GRA includes a capability for GRA-capable network elements to return GRA 164 packets from a receiver back to a source on the reverse of the path from 165 the source to the receiver. Any GRA function that specifies the use of 166 this capability must provide a per-transport-session upstream-GRA- 167 neighbour discovery service that permits GRA-capable network elements to 168 associate any given transport session identifier with an upstream GRA 169 neighbour. 171 ^L 172 Note that GRA functions can only be applied within a single transport 173 session. The coordination of GRA functions across multiple transport 174 sessions is not accommodated here. 176 The impact of GRA on forwarding path bandwidth will be related directly 177 to the the number of sessions using GRA, to the fraction of GRA packets 178 in each session, and to the state and processing complexity defined in 179 GRA function specifications. The constraints specified in this document 180 on GRA usage in general and on GRA function specifications in particular 181 are intended to mandate the lowest possible upper bounds on these 182 parameters while still providing a useful level of network-element-based 183 functionality. 185 4. Rationale 187 The justification for providing GRA functionality lies in the 188 observation that , at least for IP multicast, a distribution tree 189 represents a distributed repository of information about the 190 corresponding multicast session as a whole (such as loss, delay, 191 topology, and membership information) which, when subjected to 192 distributed processing in the network itself, may yield results which 193 can be used by sources, receivers, and network elements themselves to 194 significantly enrich both the efficiency and the intelligence of the 195 operation of the session. 197 The definition of the GRA signalling protocol specified here is 198 sufficiently general to be applied to any prospective UDP-based 199 application protocol or any RMT for IP that is designed to make use of 200 GRA. Such a protocol may simply insert a GRA header in the transport 201 header of some subset of packets in a session for those packets to be 202 processed by network-element-based GRA functions. For RMTs, GRA 203 functionality is defined entirely in terms of the network layer header 204 and the GRA header and so is completely transport-layer independent. 205 For UDP applications, GRA functionality is defined entirely in terms of 206 the network layer header, the UDP header, and the GRA header and so is 207 completely application-layer independent. Network-element-based GRA 208 functionality can thus be applied with identical semantics across 209 different UDP applications or RMTs. 211 Given its network-layer, hop-by-hop mechanics, the definition of GRA 212 signalling specified here does not overlap with functionality provided 213 by any other reliable multicast building block. 215 ^L 216 5. Functionality 218 The operation of the GRA signalling protocol is specified here in terms 219 of the format of GRA headers and procedures for processing those headers 220 in network elements. 222 In the context of this document, the direct path is the path taken by a 223 packet from a source to a receiver as determined by IP routing. The 224 reverse path is the path taken by a packet from a receiver to a source 225 as it is forwarded through the sequence of upstream GRA neighbours 226 between the receiver and the source. Direct GRA packets are GRA packets 227 being forwarded by IP routing on the direct path. Reverse GRA packets 228 are GRA packets being forwarded GRA-hop-by-GRA-hop on the reverse path. 230 5.1. Headers 232 The GRA header is best conceived of as augmenting the transport header 233 and must be available at any layer in the communications stack at which 234 the transport header (the application header in the case of UDP) is also 235 available. 237 GRA packets intended for interpretation in network elements must bear a 238 network layer indication that the GRA header is present. A new IP 239 option will be created specifically to signal the presence of the GRA 240 header at the network layer. 242 GRA headers may be used in packets without this network layer indication 243 for the purposes of purely end-to-end GRA-related exchanges within a 244 session. 246 GRA packets must also bear a transport layer indication that the GRA 247 header is present since IP options are not typically available above the 248 network layer. The method for detecting the presence of the GRA header 249 at the transport layer is based upon the G-bit (defined below) being set 250 in the common portion of the GRA header which, when present, must 251 immediately follow the network header. 253 NOTA BENE: A UDP application or an RMT must specify its own 254 application or transport headers, respectively, such that the 255 value of the bit in this same location in their own headers is 256 always zero. 258 For UDP, direct GRA packets can be associated with a globally unique 259 transport session based upon the IP address information and the UDP port 260 information. Reverse GRA packets must also be associated with the 261 globally unique transport session to which they refer, and while, at 262 least for UDP, port information is typically available in the transport 264 ^L 265 header, the required IP address information is not available from the IP 266 header since it will be addressed to a GRA neighbour. 268 Consequently, for reverse GRA packets, this information must be recorded 269 inside the GRA headers of reverse GRA packets to provide unambiguous 270 transport session identification. Since these IP address fields will 271 only be present in reverse GRA packets, a direct/reverse discriminator 272 has been provided in the common portion of the GRA header. The same 273 transport session identification scheme applies to RMTs with the 274 difference that an NLA-scoped host session identifier is carried 275 directly in the GRA header in place of "borrowing" port information from 276 the transport. 278 Note also that in reverse packets, the destination address is further 279 required in case the reverse GRA packet is to be subject to multicast 280 forwarding as part of the corresponding GRA function definition such as 281 in the case of a suppression service. 283 The operand field may be one of two types: it may consist of a fixed 284 number of fixed-format operands, or a variable number of variable-format 285 operands. While variable operands may provide a degree of feature 286 flexibility, the overhead associated with parsing variable operand lists 287 may tax the time constraints on forwarding-time processing of GRA, so a 288 fixed-operand/variable-operand discriminator has been provided in the 289 common portion of the GRA header so that network elements can 290 efficiently detect more complex GRA headers and make an early 291 determination as to how to handle them. 293 ^L 294 5.1.1. Header Format in the Context of UDP 296 A GRA header in the context of UDP must be formatted as follows: 298 IP HEADER including the IP GRA OPTION 300 UDP HEADER 301 ................................................................. 302 . Source Port . Destination Port . 303 ................................................................. 304 . Check Sum . TPDU Length . 305 ................................................................. 307 The common portion of the GRA header: 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |G|R|V|-|-|-|V N| Header Length | Function ID | Instance # | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ... followed immediately, in reverse GRA packets only, 315 by transport-session-identifying IP address information: 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 317 | Network Layer Source (IP) Address ... | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 319 | Network Layer Destination (IP Multicast Group) Address ... | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 322 ... followed immediately by the GRA-function-specific operand portion 323 of the GRA header: 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 325 | Operands ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 328 ... followed immediately by the APDU. 330 Figure 1 - GRA Header Format in the Context of UDP 332 ^L 333 5.1.2. Header Format in the Context of an RMT 335 A GRA header in the context of an RMT must be formatted as follows: 337 IP HEADER including the IP GRA OPTION 339 The common portion of the GRA header: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | NLA-scoped host session identifier(s) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 |G|R|V|-|-|-|V N| Header Length | Function ID | Instance # | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 ... followed immediately, in reverse GRA packets only, 349 by transport-session-identifying IP address information: 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 351 | Network Layer Source (IP) Address ... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 353 | Network Layer Destination (IP Multicast Group) Address ... | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 356 ... followed immediately by the GRA-function-specific operand portion 357 of the GRA header: 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 359 | Operands ... | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 362 ... followed immediately by the TPDU. 364 Figure 2 - GRA Header Format in the Context of an RMT 366 5.1.3. Header Contents 368 NLA-Scoped Host Session Identifier (HSI) 369 For RMTs, the logical equivalent of the UDP source and destination 370 ports. 372 G-bit 373 MUST be set. Signals the presence of a prepended GRA header to UDP 374 applications expecting APDUs after the UDP header or to RMTs 375 expecting TPDUs after the IP header. 377 R-bit 378 Clear on direct GRA packets, set on Reverse GRA packets. 380 ^L 382 V-bit 383 Clear on fixed-operand GRA packet, set on Variable-operand GRA 384 packets. 386 VN-bits 387 GRA Version Number, 0x0 in this instance. 389 Header Length 390 Total length of the GRA header in longwords. 392 Function ID (GFID) 393 The GFID is the name of the transport-session-specific instance of 394 the GRA function to be used to process the GRA header. 396 GFID Instance Number (GFIN) 397 The GFIN is the session-specific instance number of the GRA function 398 to be used to process the GRA header. 400 Source IP Address 402 Destination IP (Multicast Group) Address 403 Reverse GRA packets must bear the network-layer addresses of the 404 source and destination for the identification of the transport 405 session within which the GRA packets are to be processed. 407 Note that while these addresses are rendered here as IPv4 addresses, 408 their actual format in the context of UDP or a given RMT is 409 determined by the network layer protocol in which UDP or the RMT is 410 operating. 412 Operands 413 The operands (including a GSID; see below) as defined for one of the 414 GRA services in the GRA function specification for the given GFID. 416 5.2. Procedures 418 5.2.1. Network Elements 420 Network elements that explicitly detect the IP GRA option (TBD) in a 421 packet must then locate and parse the GRA header first to determine the 422 packet's admissibility and second to determine its handling. The GRA 423 header is always located directly following the network header, but 424 network elements must make a transport-protocol-specific determination 425 of its format which will be as specified in Figure 1 for UDP and as 426 specified in Figure 2 for all other transport protocols. 428 ^L 429 NOTA BENE: There's a strong assumption here that network 430 elements do IP option detection BEFORE they make any 431 determinations based on the destination network layer address 432 in the general forwarding path. 434 If the G-bit is not set, the network element must discard the packet. 436 If the packet is a reverse GRA unicast packet, the network element must 437 determine whether the packet bears a destination address addressing the 438 network element itself. If a reverse GRA unicast packet is not 439 addressed to the network element itself, it must continue to be 440 processed just as if the IP GRA option had NOT been detected. 442 If a reverse GRA unicast packet is addressed to the network element 443 itself, the network element must first correct for potential unicast 444 routing asymmetries. In particular, since a reverse GRA unicast packet 445 may traverse a non-contiguous GRA hop and therefore arrive at the 446 upstream GRA neighbour on other than the interface to which it was 447 addressed, the packet must, upon receipt, be reassociated by the network 448 element with the interface to which it was addressed. Note that the 449 destination address check is essential since reverse packets are seen 450 not just by the GRA neighbour to which they are unicast but by any 451 intervening GRA capable routers as well (due to the IP GRA option). 453 Network elements must then verify that they have corresponding 454 definitions for the version number and the GFID. Packets that fail this 455 verification must continue to be processed just as if the IP GRA option 456 had NOT been detected. 458 Admissibility is further determined by matching the source and 459 destination addresses (found in the IP header in the case of direct GRA 460 packets and inside the GRA header in the case of reverse GRA packets), 461 and the GFID (and possibly the incoming interface) against any local 462 access lists protecting access to GRA functionality. Packets blocked by 463 such lists must continue to be processed just as if the IP GRA option 464 had NOT been detected. 466 For packets passed by such lists, the GRA function corresponding to the 467 GFID must be invoked and passed the packet itself as well as the 468 identity of the incoming interface. 470 The network element may make local determinations on the processing 471 priority of such GRA packets based on any local conditions or any 472 attributes of the GRA packet itself. More specifically, a network 473 element is not constrained to order GRA packets relative to non-GRA 474 packets in any way. Network elements must, however, process admissible 475 GRA packets matching a particular (transport-session-scoped) GFID in 476 relative order. 478 ^L 479 All further processing of a GRA packet is GRA-function-specific as 480 defined by the GRA function specification for the GFID. In particular, 481 it is incumbent upon the GRA function to determine the ultimate fate of 482 the packet itself. 484 Network elements must provide a multicast forwarding service which 485 permits selective forwarding on a specified subset of the interfaces on 486 a multicast route. 488 5.2.2. End Systems 490 End systems are defined for the purposes of this section as either host- 491 resident UDP applications or RMT stacks. 493 End systems originating GRA packets must format them as specified in 494 Figure 1 for UDP applications and as specified in Figure 2 for all other 495 transport protocols. The underlying network layers of these end systems 496 must provide the ability to selectively add the IP GRA option to GRA 497 packets submitted for transmission by these end systems. 499 Upon receipt, end systems must explicitly detect the presence of a GRA 500 header in a packet based on the state of the G-bit and must then locate 501 and parse the GRA header first to determine the packet's admissibility 502 and second to determine its handling. Note that the location of the G- 503 bit depends on whether the end system is a UDP application or an RMT. 505 End systems must then verify that they have corresponding definitions 506 for the version number and the GFID. Packets that fail this 507 verification must continue to be processed ignoring the GRA header 508 altogether. 510 All further processing of a GRA packet is GRA-function-specific as 511 defined by the GRA function specification for the GFID. 513 6. Constraints on GRA Function Specifications 515 General constraints on GRA function specifications are described here 516 since those constraints stem primarily from consideration of the 517 processing environment in the forwarding path of a network element. 518 Individual GRA function specifications must adhere to the constraints 519 stated here, and these constraints may be expanded in light of any 520 irrational exuberance detected in GRA function specifications 521 themselves. 523 ^L 524 Static and dynamic GRA functions 525 The lower half of the GFID space is reserved for static, well-known GRA 526 function specifications. The upper half of the GFID space is reserved 527 for dynamic, proprietary GRA function specifications when it becomes 528 possible to define these through a GRA control protocol. Thus the upper 529 half of the GFID space is scoped by the transport session. 531 Maximum number of GRA services 532 No more than 8 GRA services may be defined for a single GRA function. 533 The definition of the GRA service identifier (GSID) is a matter purely 534 local to the GRA function specification except to say that GSIDs must be 535 encoded in the operand portion of the GRA header. 537 GRA neighbour discovery service 538 If a GRA function specifies a GRA service for reverse packets, it must 539 also specify a GRA service for GRA neighbour discovery in the session. 540 Such a GRA service may also be used as a general session information 541 service to provide any other session-specific parameters required by the 542 GRA function. 544 Packet Access 545 The GRA header MUST be self-contained. That is, all parameters required 546 by a given GRA service MUST be provided in the GRA header itself other 547 than those provided in the network header (the UDP header in the case of 548 UDP applications). More specifically, there is no capability defined 549 for GRA to specify operands by offset into the packet. This may 550 necessitate duplicating information carried elsewhere in the packet. 551 Note that when a GRA header is present, an RMT is free to refer to the 552 GRA header for values that normally would be carried elsewhere in the 553 transport header (e.g. the HSI). 555 Packet Modification 556 A GRA packet may not be modified in any way by a network element other 557 than to write to the GRA header and then only in the same format in 558 which the header was received. GRA specifies no packet encapsulation or 559 packet decapsulation capabilities. In addition, this constraint 560 precludes packet accumulation. 562 Packet Generation 563 GRA Function specifications may specify the generation and forwarding of 564 a packet consisting only of a GRA header defined by the GRA function 565 specification and derived from the copy of a received GRA header. These 566 packets may be used for delayed or periodic GRA-related events in the 568 ^L 569 session. 571 Fixed and Variable Operands 572 An implementation of GRA must support GRA headers with either a fixed 573 number of operands in fixed formats, or a variable number of operands in 574 variable formats. Fixed format GRA headers should be used in GRA 575 service specifications where forwarding-time processing performance is 576 the priority. Variable format GRA headers should be used in GRA service 577 specifications where syntactic flexibility is the priority. Variable 578 format GRA headers must be self-describing to the extent that the type, 579 length, and value of all operands can be determined dynamically. While 580 variable-format operands may vary across GRA packets, they may not vary 581 from the format established for a given packet by its originator. 583 Operands Semantics 584 While operands may represent a whole range of meaningful (to the 585 transport) attributes, they are not interpreted by GRA in other than the 586 context of the operators of each type supported by GRA. That is, the 587 numerical and relational operators treat operands as unsigned integers, 588 and the logical operators treat operands as bit fields (e.g. for the 589 purposes of aggregation). 591 Designated KEY Operand 592 A GRA function specification may define a single distinguished operand, 593 up to 32 bits in length, to be a key for the purposes of indexing sub- 594 service-specific state. 596 GRA Function State 597 A GRA function specification may specify up to 8 GRA-function-local 598 variables, 8 GRA-function-local timers, and 1 interface list (where an 599 interface list may record no more interfaces than are recorded on the 600 multicast route corresponding to the session). 602 GRA Service State 603 For each GRA service, a GRA function specification may specify up to 8 604 GRA-service-local variables, 8 GRA-service-local timers, storage for 1 605 full copy of the GRA header defined by the GRA service, and 1 GRA- 606 service-local interface list. GRA header copies are intended for such 607 functions as delayed forwarding and elimination. 609 Keyed GRA Service State 610 For each instance of a key, a GRA service specification may specify up 612 ^L 613 to 8 sub-service-local variables, 8 sub-service-local timers, storage 614 for 1 full copy of the GRA header defined by the GRA service, and 1 sub- 615 service-local interface list. 617 Forwarding Functions 618 A GRA service specification may specify unicast and or multicast 619 forwarding for a received GRA packet or for a GRA packet generated by 620 the GRA service and consisting only of the GRA header defined by the GRA 621 service. Unicast forwarding may be to an arbitrary unicast destination. 622 Multicast forwarding may only be to the multicast group corresponding to 623 the multicast distribution tree for the session possibly augmented by an 624 interface list for the purposes of selective forwarding. 626 Bandwidth 627 GRA is not intended for use on data packets involved in a transport's 628 basic data conveyance function. Rather, it is intended for control and 629 exception processing within a session. Neither the frequency of GRA 630 packets nor their total data rate within a session may be more than 5% 631 in the steady state. 633 7. Security Considerations 635 Until a GRA control protocol can be defined to securely configure and 636 manage access to GRA functionality in network elements, network elements 637 must restrict access to GRA functionality through positive access lists 638 explicitly configured to permit access by the source/destination/GFID 639 triplet (and possibly by interface as well) where these addresses are 640 found in the IP header in the case of direct GRA packets and inside the 641 GRA header in the case of reverse GRA packets. 643 When and where available, GRA will rely on general mechanisms for 644 receiver access control and for source and receiver authentication 645 rather than mandating its own. 647 8. Requirements from other Building Blocks 649 The only aspect of GRA functionality not completely defined by GRA 650 function specifications is the number of separate instances of the 651 application of a given GRA function within a session as represented by 652 the GFIN. The expectation is that only one instance is typically 653 required. In any case, a UDP application or an RMT must not specify the 654 use of more than 8 instances of a given GFID. 656 ^L 657 9. Codepoint Considerations 659 (This section is in compliance with RFC3269) 661 10. IANA Considerations 663 As part of defining the new IP GRA option, an new IP option type will be 664 requested from IANA. 666 It is further proposed here that the GFID name space be under IANA 667 administration. 669 11. Definitions 671 The definitions in this section apply throughout this document. 673 Distribution Tree 674 The multicast distribution tree of network elements defined by 675 network-layer multicast routing information for a given multicast 676 transport session rooted at a single root network element (at the 677 host that is the source of the data in the transport session), and 678 fanning out (possibly through transit network elements) to one or 679 more leaf network elements (at the hosts that are the receivers of 680 the data in the transport session). 682 Downstream 683 In the direction away from the source and toward receivers. 685 Upstream 686 In the direction away from receivers and toward the source. 688 GRA packet 689 A packet bearing a GRA header. 691 GRA hop 692 The single logical hop between any two GRA-capable network elements 693 adjacent (in a strictly upstream/downstream sense) to each other in 694 the distribution tree (i.e., not separated in the distribution tree 695 by any other GRA-capable network element). 697 ^L 699 GRA Neighbours 700 Two GRA-capable network elements separated by a single GRA hop. 702 Direct Path 703 The path taken by a packet from a source to a receiver as determined 704 by IP routing 706 Reverse Path 707 The path taken by a packet from a receiver to a source as it is 708 forwarded through the sequence of upstream GRA neighbours between the 709 receiver and the source. 711 Direct GRA Packets 712 GRA packets being forwarded by IP routing on the direct path. 714 Reverse GRA Packets 715 GRA packets being forwarded GRA-hop-by-GRA-hop on the reverse path. 717 Suppression 718 Potential transmitters of some packet refrain from the transmission 719 of that packet because they detect its duplicate. 721 Elimination 722 A potential forwarder of some packet refrains from forwarding that 723 packet because it has a record of already having forwarded a 724 duplicate of that packet. 726 Aggregation 727 Multiple identically sized operands are combined in a bit-wise 728 fashion that results in a compositely encoded operand of the same 729 size. 731 Accumulation 732 Multiple operands are concatenated together to form an operand list 733 whose length is greater than length of any of the constituent 734 operands. 736 ^L 738 12. Expired Drafts 740 Two expired Internet Drafts, one an architecture spec of sorts, the 741 other a functional spec of sorts, may be of interest to the reader and 742 can be found at: 743 http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-rmt-gra- 744 arch-02.txt 745 http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-rmt-gra- 746 fspec-00.txt 748 A set of slides elaborating on the functional spec can be found at: 749 http://www.ietf.org/proceedings/01aug/slides/rmt-2.pdf 751 Authors' Addresses 753 Tony Speakman 754 speakman@cisco.com 756 Lorenzo Vicisano 757 lorenzo@cisco.com 759 ^L 761 Full Copyright Statement 763 Copyright (C) The Internet Society (2002). All Rights Reserved. 765 This document and translations of it MAY be copied and furnished to 766 others, and derivative works that comment on or otherwise explain it or 767 assist in its implementation MAY be prepared, copied, published and 768 distributed, in whole or in part, without restriction of any kind, 769 provided that the above copyright notice and this paragraph are included 770 on all such copies and derivative works. However, this document itself 771 MAY NOT be modified in any way, such as by removing the copyright notice 772 or references to the Internet Society or other Internet organizations, 773 except as needed for the purpose of developing Internet standards in 774 which case the procedures for copyrights defined in the Internet 775 Standards process must be followed, or as required to translate it into 776 languages other than English. 778 The limited permissions granted above are perpetual and will not be 779 revoked by the Internet Society or its successors or assigns. 781 This document and the information contained herein is provided on an "AS 782 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 783 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 784 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 785 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 786 FITNESS FOR A PARTICULAR PURPOSE."