idnits 2.17.1 draft-ietf-tuba-host-clnp-multicas-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 40 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 601: '... 1100 0110 (THIS CODE MAY CHANGE)...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 339 has weird spacing: '... nature than ...' == Line 669 has weird spacing: '...address uses ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1237' is defined on line 1918, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Deering91' ** Obsolete normative reference: RFC 1237 (Obsoleted by RFC 1629) -- Possible downref: Non-RFC (?) normative reference: ref. 'CLNP' -- Possible downref: Non-RFC (?) normative reference: ref. 'ES-IS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MULT-AMDS' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dave Marlow 2 March 9, 1994 NSWC-DD 4 Host Group Extensions for CLNP Multicasting 6 draft-ietf-tuba-host-clnp-multicas-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months. Internet-Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet- 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, venera.isi.edu, or 24 munnari.oz.au. 26 Abstract 28 This draft provides a specification for multicast extensions to the 29 CLNP protocol similar to those provided to IP by RFC1112. These 30 extensions are intended to provide the mechanisms needed by a host 31 for multicasting in a CLNP based Internet. This draft covers 32 addressing extensions to the CLNP addressing structure, extensions to 33 the CLNP protocol and extensions to the ES-IS protocol. An appendix 34 discusses the differences between IP multicast and the CLNP multicast 35 approach provided in this draft. 37 The multicast extensions to the CLNP addressing structure defines 38 group Network addresses which identify host groups. The multicast 39 extensions to CLNP provides a means for identifying a CLNP packet and 40 provides scope control mechanisms for CLNP multicast packets. The 41 multicast extensions to the ES-IS protocol provide the mechanisms 42 needed for a host to exchange control information with multicast 43 capable routers. These extensions to the ES-IS protocol provide for 44 a host to "announce" which multicast packets are of interest and for 45 a multicast capable router to dynamically "map" group Network 46 addresses to subnetwork addresses. 48 Contents 50 Status of this Memo 52 Abstract 54 1. Introduction 56 2. Levels of Conformance 58 3. Group Network Addresses 60 4. Model of a CLNP End System Multicast Implementation 62 5. Extensions to the CLNP Protocol 64 6. Extensions to the ES-IS Routeing Protocol 66 Appendix A. Considerations for ESGH and MAM PDU destination 67 SNPA address parameters 69 Appendix B. Differences with RFC 1112 71 Appendix C. Issues Under Study 73 References 75 Author's Address 77 1. Introduction 79 This draft provides a specification for multicast extensions for CLNP 80 in order to provide a CLNP based Internet the capabilities provided 81 for IP by RFC 1112 (Host Extensions for IP Multicasting) [RFC1112]. 82 This draft uses an outline similar to that of RFC 1112. 84 Paraphrasing RFC 1112, "CLNP multicasting is the transmission of a 85 CLNP datagram to a "host group", a set of zero or more End Systems 86 identified by a single group Network address (GNA). A multicast 87 datagram is delivered to all members of its destination host group 88 with the same "best-efforts" reliability as regular unicast CLNP 89 datagrams, i.e., the datagram is not guaranteed to arrive intact at 90 all members of the destination group or in the same order relative to 91 other datagrams. 93 "The membership of a host group is dynamic; that is End Systems may 94 join and leave groups at any time. There is no restrictions on the 95 location or number of members in a host group. An End System may be a 96 member of more than one group at a time. An End System need not be a 97 member of a group to send datagrams to it. 99 "A host group may be permanent or transient. A permanent group has an 100 administratively assigned GNA. It is the address, not the membership 101 of the group, that is permanent; at any time a permanent group may 102 have any number of members, even zero. 104 "Internetwork forwarding of CLNP multicast datagrams is handled by 105 "multicast capable" Intermediate Systems which may be co-resident 106 with, or separate from, unicast capable Intermediate Systems. 108 This draft specifies the extensions required by an End System to make 109 use of CLNP multicast. In addition the requirements placed upon 110 multicast capable Intermediate Systems to exchange information with 111 multicast capable End Systems is specified. No specifications are 112 provided related to the information exchanges between Intermediate 113 Systems to support multicast route selection or multicast Protocol 114 Data Unit (PDU) forwarding. A discussion of multicast route selection 115 and PDU forwarding has been written by Steve Deering [Deering91]. 116 Note that for these multicast extensions to work there must exist an 117 uninterrupted path of multicast capable routers between the End 118 Systems comprising a host group (such paths may utilize tunneling 119 (i.e. unicast CLNP encapsulated paths between multicast capable CLNP 120 routers). In order to support multicast route selection and 121 forwarding for a CLNP based internet additional specifications are 122 needed. Specifications of this type could come in the form of new 123 protocols, extensions to the current CLNP based routing protocols or 124 use of a technique out of the IETF`s Inter-Domain Multicast Routing 125 (IDMR) group. The IDMR group is currently investigating multicast 126 protocols for routers which utilize a router's unicast routing 127 protocols, this approach may extend directly to CLNP routers. 129 While many of the techniques and assumptions of IP multicasting (as 130 discussed in RFC 1112) are used in CLNP multicasting, there are 131 number of differences. Appendix B describes the differences between 132 CLNP multicasting and IP multicasting. This draft describes 133 techniques brought in directly from projects within ISO to 134 incorporate multicast transmission capabilities into CLNP [MULT- 135 AMDS]. This draft is consistent with the current draft specifications 136 of these ISO projects. Key contributions to the techniques described 137 in this draft have been made by a number of individuals within the 138 ANSI X3S3.3 and ISO SC6 Working Group 2 committees. 140 2. Levels of Conformance 142 There are three levels of conformance for End Systems to this 143 specification: 145 Level 0: no support for CLNP multicasting. 147 There is no requirement for a CLNP End System (or Intermediate 148 System) to support CLNP multicasting. Level 0 hosts should be 149 unaffected by the presence of multicast activity. The destination 150 addresses used in support of multicast transfers, the GNA, should not 151 be enabled by a non-multicast capable End System and the PDUs 152 themselves are marked differently than unicast PDUs and thus should 153 be quietly discarded. 155 Level 1: support for sending but not receiving CLNP multicast PDUs. 157 At this point this level is not defined for CLNP multicast. An End 158 System sourcing multicast PDUs with the current specification at 159 least needs to know whether a multicast Intermediate System is 160 attached to the subnetwork that the multicast PDU is sourced on (i.e. 161 to determine the destination SNPA (subnet) address). Further work on 162 this level of conformance may be undertaken if utility is identified. 164 Level 2: full support for CLNP multicasting. 166 Level 2 allows a host to join and leave host groups as well as send 167 CLNP PDUs to host groups. It requires implementation by the End 168 System of all parts of this specification. 170 3. Group Network Addresses 172 Individual Network addresses used by CLNP for End System addressing 173 are called Network Service Access Points (NSAPs). RFC 1237 defines 174 the NSAP address for use in the Internet. In order to provide an 175 address for a group of End Systems, this specification does not 176 change the definition of the NSAP address, but adds a new type of 177 identifier - the group Network address - that supports a multicast 178 Network service (i.e., between a single source NSAP, identified by an 179 individual Network address, and a group of destination NSAPs, 180 identified by a group Network address). Host groups are identified by 181 group Network addresses. 183 In the development of multicast address extensions to CLNP, 184 requirements were identified for: (1)"easily distinguishing" group 185 addresses at the Network layer from NSAP addresses; (2)leaving the 186 currently allocated address families unaffected and (3)ensuring that 187 the approach taken would not require the establishment of new 188 addressing authorities. In addition, it was agreed that providing 189 multicast options for all OSI Network layer users was desirable and 190 thus the group Network addressing solution should support options for 191 all address formats covered by ISO/IEC 8348 | Recommendation X.213. 192 The only viable means identified for meeting all requirements was via 193 creating a new set of AFI values with a fixed one-to-one mapping 194 between each of the existing AFI values and a corresponding group AFI 195 value. 197 Group Network addresses are defined by creating a new set of AFI 198 values, one for each existing AFI value, and a fixed one-to-one 199 mapping between each of the existing AFI values and a corresponding 200 group AFI value. The syntax of a group Network address is identical 201 to the syntax of an individual Network address, except that the value 202 of the AFI in an individual Network address may be only one of the 203 values already allocated for individual Network addresses, whereas 204 the value of the AFI in a group Network address may be only one of 205 the values allocated here for group Network addresses. The AFI values 206 allocated for group Network addresses have been chosen in such a way 207 that they do not overlap, in the preferred encoding defined by 208 ISO/IEC 8348 | CCITT Recommendation X.213, with any of the AFI values 209 that have already been allocated for individual Network addresses. 211 3.1 Definitions 213 group Network address: an address that identifies a set of zero or 214 more Network service access points; these may belong to multiple 215 Network entities, in different End Systems. 217 individual Network address: an address that identifies a single NSAP. 219 3.2 CLNP Addresses 221 A discussion of the CLNP address format is contained in RFC 1237. The 222 structure of all CLNP addresses is divided into two parts the Initial 223 Domain Part (IDP) and the Domain Specific Part (DSP). The first two 224 octets of the IDP are the Authority and Format Identifier (AFI) 225 field. The AFI has an abstract syntax of two hexadecimal digits with 226 a value in the range of 00 to FF. In addition to identifying the 227 address authority responsible for allocating a particular address and 228 the format of the address, the AFI also identifies whether an address 229 is an individual Network address or a group Network address. There 230 are 90 possible AFI values to support individual Network address 231 allocations. In addition, when the AFI value starts with the value 232 "0" this identifies that the field contains an incomplete individual 233 Network address (i.e. identifies an escape code). 235 Table 1 allocates 90 possible AFI values to support group Network 236 address allocations. In addition if the first two digits of the IDP 237 are hexadecimal FF, this indicates the presence of an incomplete 238 group Network address. The allocation of group addresses is 239 restricted to be only from the AFI values allocated for the 240 assignment of group addresses in Table 1. An addressing authority in 241 allocating either Network addresses or authorizing one or more 242 authorities to allocate addresses, allocates both individual and the 243 corresponding group addresses. Thus each block of addresses allocated 244 by an addressing authority (or its sub-authority) contains a block of 245 individual Network addresses and group Network addresses. The 246 individual and group address block allocated are differentiated by 247 the AFI values used which are related as shown in Table 1. 249 Group Network addresses are only used as the destination address 250 parameter of a CLNP PDU. Source Address parameters are never 251 permitted to be group Network addresses. 253 Table 2 lists the AFI values which have not been assigned, at this 254 time, for the support of neither individual nor group address 255 allocation. Future assignment of these AFI values is possible. 256 Additional information concerning individual Network addresses (i.e. 257 NSAP and NET (Network Entity Titles)) is contained in RFC 1237. 259 TABLE 1 - Relationship of AFI Individual and Group Values 260 ----------------------------------------------------------- 261 |Individual Group | Individual Group | Individual Group | 262 ----------------------------------------------------------- 263 | 0x FF | | | 264 | 10 A0 | 40 BE | 70 DC | 265 | 11 A1 | 41 BF | 71 DD | 266 | 12 A2 | 42 C0 | 72 DE | 267 | 13 A3 | 43 C1 | 73 DF | 268 | 14 A4 | 44 C2 | 74 E0 | 269 | 15 A5 | 45 C3 | 75 E1 | 270 | 16 A6 | 46 C4 | 76 E2 | 271 | 17 A7 | 47 C5 | 77 E3 | 272 | 18 A8 | 48 C6 | 78 E4 | 273 | 19 A9 | 49 C7 | 79 E5 | 274 | 20 AA | 50 C8 | 80 E6 | 275 | 21 AB | 51 C9 | 81 E7 | 276 | 22 AC | 52 CA | 82 E8 | 277 | 23 AD | 53 CB | 83 E9 | 278 | 24 AE | 54 CC | 84 EA | 279 | 25 AF | 55 CD | 85 EB | 280 | 26 B0 | 56 CE | 86 EC | 281 | 27 B1 | 57 CF | 87 ED | 282 | 28 B2 | 58 D0 | 88 EE | 283 | 29 B3 | 59 D1 | 89 EF | 284 | 30 B4 | 60 D2 | 90 F0 | 285 | 31 B5 | 61 D3 | 91 F1 | 286 | 32 B6 | 62 D4 | 92 F2 | 287 | 33 B7 | 63 D5 | 93 F3 | 288 | 34 B8 | 64 D6 | 94 F4 | 289 | 35 B9 | 65 D7 | 95 F5 | 290 | 36 BA | 66 D8 | 96 F6 | 291 | 37 BB | 67 D9 | 97 F7 | 292 | 38 BC | 68 DA | 98 F8 | 293 | 39 BD | 69 DB | 99 F9 | 294 ----------------------------------------------------------- 296 TABLE 2 - AFI values reserved for future allocation 297 -------------- 298 | 1A-1F | 299 | 2A-2F | 300 | 3A-3F | 301 | 4A-4F | 302 | 5A-5F | 303 | 6A-6F | 304 | 7A-7F | 305 | 8A-8F | 306 | 9A-9F | 307 | FA-FE | 308 -------------- 310 4. Model of a CLNP End System Multicast Implementation 312 The use of multicast transmission by a CLNP End System involves 313 extensions to two protocols: CLNP and the ES-IS Routeing Protocol. To 314 provide level 0 service (no support for CLNP multicast), no 315 extensions to the two present protocols are required. In order to 316 support level 2 service (full support for CLNP multicasting), the 317 extensions contained in the following sections are required. 318 Extensions identified for Intermediate Systems are not required (or 319 appropriate) for End Systems. Multicast transmission also requires 320 the use of a group Network address (as previously described) as the 321 destination address parameter. 323 5. Extensions to the CLNP protocol 325 This section provides extensions to the CLNP Protocol [CLNP] ISO 326 8473-1, to support multicast transmission. These additions provide 327 procedures for the connectionless transmission of data and control 328 information from one network-entity to one or more peer network- 329 entities. 331 In developing the multicast extensions for CLNP a decision was needed 332 on how to "mark" a packet as multicast (versus the current unicast 333 packets). Such marking is necessary since the forwarding behavior 334 for multicast packets is different (e.g. multiple copies of a packet 335 may need to be forwarded). The two alternatives considered were to 336 mark the packet (via a particular field) or to mark the destination 337 address, in the end both were done. The destination address for a 338 multicast PDU identifies a host group which is of a very different 339 nature than the unicast NSAP address. Rather than changing the 340 nature of NSAP addresses, a new set of addresses were created named 341 group Network addresses which are marked within the first octet (i.e. 342 the AFI field) with values reserved for group Network addresses. 344 Consideration was given to no further marking of the PDU; however, a 345 problem was identified with only using the group Network address to 346 identify multicast packets. Currently routers implementing the IS-IS 347 Intra-Domain protocol as Level 1 routers when receiving a packet with 348 an unknown destination address are permitted to either discard the 349 packet or send it to a Level 2 router. Such actions by non-multicast 350 capable routers to multicast packets can lead to non-deterministic 351 behavior. Level 1 routers upon receiving a packet containing a group 352 Network address might pass the packet up to a Level 2 router (which 353 may or may not be multicast capable) or it might discard it. 354 Depending upon the circumstances this might lead to whole regions 355 missing packets or packet duplication (possibly even explosion). The 356 result was to seek deterministic behavior by non-multicast capable 357 routers by creating a new PDU type (Multicast Data PDU) and inserting 358 into the CLNP reasons for discard: receiving a PDU of unknown type. 359 Note this reason for discard is mandatory on multicast capable and 360 non-multicast capable CLNP implementations. 362 5.1 Definitions 364 multicast: Data transmission to one or more destinations in a 365 selected group in a single service invocation. 367 multicast capable Intermediate System: An Intermediate System which 368 incorporates the multicast features of the Network layer. 370 5.2 Addresses 372 The destination address parameter of a multicast PDU shall contain a 373 group Network address. The source address parameter shall be an 374 individual Network address. 376 5.3 Extensions to the current protocol functions 378 In order to support multicast transmissions the following optional 379 CLNP protocol functions will be implemented: 381 5.3.1 Header Format Analysis function 383 The header format analysis function optionally provides capabilities 384 to Network entities which support multicast transfer to supply 385 applicable PDUs directly to End Systems served by such a Network 386 entity as well as to forward such PDUs on to other Network entities. 387 This optional functionality is realized through a Network entity with 388 multicast capability identifying a PDU as using multicast transfer 389 via the PDU type and the PDU's destination address field. 391 If a Network entity supports multicast transmission, then the header 392 format analysis function shall provide checking to ensure that a PDU 393 does not contain a group Network address in the source address field. 394 Any PDU header analyzed to have a group address in the source address 395 field shall be discarded. 397 5.3.2 Route PDU functions 399 The route PDU function optionally provides capabilities to Network 400 entities which support multicast transfer for determining multiple 401 Network entities to which a single PDU shall be forwarded to. This 402 may result in multiple invocations of the forward PDU function and 403 hence the need to make multiple copies of the PDU. For PDUs that are 404 received from a different Network entity, the optional functionality 405 for the route PDU function is realized as a result of the header 406 format analysis function's recognition of the PDU as being a 407 multicast PDU. A Network entity originating a multicast PDU should 408 invoke the forward PDU function on one and only one subnetwork to 409 which it is attached and on which it has learned of the existence of 410 at least one multicast capable IS. A Network entity attached to 411 multiple subnetworks should select a subnetwork for which a multicast 412 capable Intermediate System is attached if one exists for the initial 413 sourcing of a PDU. A Network entity attached to multiple subnetworks 414 but has not learned of the existence of any multicast capable IS is 415 permitted to originate a multicast PDU on multiple subnetworks. 417 Editor's Note: The purpose in having an originating Network entity 418 source a multicast PDU on only one subnetwork to which a multicast 419 capable IS is attached is to support the development of multicast 420 routing protocols which will need to determine on which subnetworks a 421 multicast PDU has visited. This behavior is predicated on the 422 assumption that the Intermediate Systems performing multicast 423 forwarding form a connected set. 425 5.3.3 Forward PDU function 427 This function issues an SN-UNITDATA request primitive, supplying the 428 subnetwork or Subnetwork Dependent Convergence Function (SNDCF) 429 identified by the route PDU function with the protocol data unit as 430 user data to be transmitted, the address information required by that 431 subnetwork or SNDCF to identify the "next" system or systems within 432 the subnetwork-specific addressing domain (this may be one or more 433 Intermediate Systems and/or one or more destination End Systems), and 434 quality of service constraints (if any) to be considered in the 435 processing of the user data. 437 5.3.4 Discard PDU function 439 Add an additional reason for discard - a PDU is received with an 440 unknown type code. 442 Editor's Note: Comments are requested as to whether this additional 443 reason for discard presents any problem with currently deployed CLNP 444 implementations. 446 5.3.5 Error reporting function 448 It is important to carefully control the use of the error reporting 449 capability in the case of multicast transfers. The primary concern 450 is to avoid the occurrence of broadcast storms and thus a multicast 451 PDU may not cause the origination of another multicast PDU. This is 452 the primary reason that the source address is not permitted to be a 453 group address. In addition, a multicast PDU with error reporting 454 permitted can result in flooding the source network-entity (as well 455 as the networks used) with Error Report PDUs. 457 While error reports are permitted on multicast PDUs, a PDU with a 458 group Network address in the source address field shall not be 459 responded to with an Error Report. This is to ensure that a multicast 460 PDU does not generate another multicast PDU. If the source address is 461 identified as a group address then an error report PDU shall not be 462 generated and the original PDU shall be discarded. 464 5.3.6 Source routing functions 466 No source routing capability is provided for multicast PDU transfer. 467 The NS provider shall not accept a multicast PDU with source route 468 parameters. 470 5.4 Scope control function 472 5.4.1 Overview 474 The scope control function is an option for multicast PDU forwarding 475 only. The scope control function allows the originator to limit the 476 forwarding of the multicast PDU. The scope control function provides 477 the capability to limit the relaying of a particular PDU based on the 478 individual Network addressing hierarchy and/or limit the amount of 479 multicast expansion which can take place. In cases where both forms 480 of scope control are applied to the same PDU, forwarding will cease 481 once either has reached its scope control limit. 483 5.4.2 Prefix Based Scope Control 485 The prefix based scope control function allows the originator to 486 specify a specific set of address prefixes where the multicast 487 forwarding of a PDU by an Intermediate System occurs only if one of 488 the prefixes matches the Network Entity Title (NET) of the 489 Intermediate System. Prefix based scope control may be selected only 490 by the originator of a PDU. Prefix based scope control is 491 accomplished using one or more address prefixes held in a parameter 492 within the options part of the PDU header. The length of this 493 parameter is determined by the originating network entity, and does 494 not change during the lifetime of a PDU. 496 When an Intermediate System receives a multicast PDU containing a 497 prefix based scope control parameter, forwarding is only performed if 498 every octet of one of the prefixes contained in the prefix based 499 scope control parameter matches that Intermediate System's NET, 500 starting from the beginning of its NET. If no such prefix match 501 exists, the Intermediate System discards the PDU. The error reporting 502 function shall not be invoked upon PDU discard. 504 5.4.3 Radius Scope Control 506 The radius scope control function allows the originator to specify a 507 maximum logical distance where multicast expansion can occur. It is 508 closely associated with the header format analysis function. Each IS 509 receiving a multicast PDU which is capable of expanding and which 510 contains a Radius Scope Control parameter, decrements the Radius 511 Scope Control field in the PDU by an administratively set amount 512 between 0 and the maximum value of the field. This function 513 determines whether the PDU received may be forwarded or whether its 514 Radius has been reached, in which case it shall be discarded. An 515 Intermediate System shall not forward a multicast PDU containing a 516 Radius Scope Control parameter with a value of 0. The error reporting 517 function shall not be invoked upon PDU discard. 519 5.4.3.1 Radius Scope Control Example 521 The Radius Scope Control parameter is useful where policies have been 522 established across the potential forwarding path. One possible 523 policy for Internet use is for multicast capable routers to treat 524 this field as a hop count within a domain (decrement by one unit) and 525 for inter-domain routers to either decrement this field to an even 526 multiple of 256 when crossing domains where prior agreements have 527 been made or decrement this field to 0 (i.e. discard the packet) for 528 other domains. 530 5.5 Structure and Encoding of PDUs 532 Multicast transmission is accomplished via the transfer of Multicast 533 Data (MD) PDUs. The PDU type code for a MD PDU is "1 1 1 0 1". The 534 format of the MD PDU is identical to that of the Data (DT) PDU. The 535 MD and DT PDU may contain the same optional parameters with the 536 following exceptions: (1)The source routing parameter is permitted 537 within DT PDUs but not MD PDUs; and (2)The scope control parameter is 538 permitted within MD PDUs but not DT PDUs. 540 5.6 Optional parameters for multicast support 542 5.6.1 Prefix Based Scope Control (this section is extended beyond the 543 ISO draft) 545 The prefix based scope control parameter specifies one or more 546 address prefixes for which Intermediate System forwarding requires a 547 match of one of the contained prefixes with the beginning of the 548 Intermediate System's NET. 550 Parameter Code: 1100 0100 552 Parameter Length: variable 554 Parameter Value: a concatenation of address prefix entries 556 The parameter value contains an address prefix list. The list 557 consists of variable length address prefix entries. The first octet 558 of each entry gives the length of the address prefix denominated in 559 bits that comprises the remainder of the entry. If the length field 560 does not specify an integral number of octets then the prefix entry 561 is followed by enough trailing zeroes to make the end of the entry 562 fall on an octet boundary. The list must contain at least one entry. 564 The prefix shall end on a boundary that is legal in the abstract 565 syntax of the address family from which it is derived. For example, 566 the encoding of a prefix whose DSP is expressed in decimal syntax 567 must end on a semi-octet boundary, while the encoding of a prefix 568 whose DSP is expressed in binary syntax can end on an arbitrary bit 569 boundary. If the end of the prefix falls within the IDP, then the 570 prefix must end on a semi-octet boundary and must not contain any 571 padding characters. 573 NOTE - The length of the prefix based scope control 574 parameter is determined by the originator of the PDU and is not 575 changed during the lifetime of the PDU. 577 5.6.1.1 Prefix matching 579 A prefix that extends into the DSP shall be compared directly against 580 the encoded NET address, including any padding characters that may be 581 present. A prefix which does not extend into the DSP shall be 582 compared against the derived quantity NET', which is obtained from 583 the NET address by removing all padding characters (as defined by the 584 binary encoding process of ISO 8348). 586 The existence of a match shall be determined as follows: 588 a) If the encoded NET (or NET') contains fewer bits than the pre- 589 fix, then there is no match. 591 b) If the encoded NET (or NET') contains at least as many bits as 592 the prefix, and all bits of the prefix are identical to the 593 corresponding leading bits of the encoded NET (or NET'), there 594 is a match. Otherwise, there is no match. 596 5.6.2 Radius Scope Control 598 The radius scope control parameter specifies the logical distance 599 that a multicast PDU can be forwarded. 601 Parameter Code: 1100 0110 (THIS CODE MAY CHANGE) 603 Parameter Length: two octets 605 Parameter Value: two octets which represents the remaining 606 distance, that the PDU can be forwarded, in administratively set 607 units. 609 5.7 Provision of the Underlying Service 611 For a subnetwork that provides an inherent multicast capability, it 612 is the functionality of the SNDCF to provide the mapping between 613 group Network addresses and the corresponding addressing capability 614 of the subnetwork. 616 5.8 Conformance 618 All of the extensions provided to the functions to support multicast 619 capability are optional. For an End System or Intermediate System 620 which is not multicast capable these extensions are not applicable. 621 An implementation claiming conformance as a multicast capable End 622 System shall meet all of the requirements for an End System which is 623 not multicast capable and also provide all of the multicast exten- 624 sions provided here. An implementation claiming conformance as a mul- 625 ticast capable Intermediate System shall meet all of the requirements 626 for an Intermediate System which is not multicast capable and also 627 provide all of the multicast extensions provided here. 629 6. Extensions to the ES-IS Routeing Protocol 631 This section provides optional extensions to the ES-IS Routeing Pro- 632 tocol [ES-IS], ISO 9542 to support the transfer of multicast PDUs. It 633 is an explicit goal of this specification that ESs and ISs, some of 634 which will have multicast capabilities and some without, will be able 635 to fully function on the same subnetworks. This specification does 636 not change any aspect of a currently defined (i.e. non-multicast) ISO 637 9542 implementation, it adds new optional functionality not modifying 638 current functionality. Two basic functions are provided: multicast 639 announcement and multicast address mapping. 641 6.1 Overview of the protocol 643 6.1.1 Operation of ESs receiving multicast PDUs 645 ESs, upon initialization and periodically thereafter, will construct 646 End System Group Hello (ESGH) PDUs identifying, by particular group 647 Network addresses, the multicast PDUs it wishes to receive. The ES 648 will periodically source (announce) these ESGH PDUs on the subnetwork 649 it wishes to receive these on. Reporting the same group Network 650 address on multiple subnetworks may result in the reception of dupli- 651 cate PDUs. ES-IS operations related to requesting the same group Net- 652 work address on multiple subnetworks are handled totally indepen- 653 dently (e.g. using different logical timers,...). It is permitted for 654 an ES to report a number of group Network addresses in the same ESGH 655 PDU. The only restrictions placed on providing multiple group Net- 656 work addresses within the same ESGH PDU are that all packets 657 requested are to be received on the same subnet, with the same hold- 658 ing time and that the ESGH PDU be of length equal to or less that its 659 maximum packet size constraint. Note each group Network address in 660 the ESGH PDU is paired with its own SNPA (subnetwork point of attach- 661 ment) address. 663 An ES will always have an SNPA address associated with each of its 664 active group Network addresses. An SNPA address is a subnetwork 665 address, in the case of a subnetwork which uses IEEE 802 addresses 666 the SNPA address is a 48 bit IEEE 802 MAC (media access control) 667 address. Of particular interest is the address used to mark the des- 668 tination group. For a subnetwork using IEEE 802 addressing a group 669 SNPA address uses a particular bit position to "mark" group SNPA 670 addresses. 672 Upon initialization the ES may have static SNPA address associations 673 (Pre-configured SNPA addresses). For any group Network address 674 without a Pre-configured SNPA address that the ES wishes to receive, 675 the ES will associate the "All Multicast End System Network Entities" 676 SNPA address. Upon receiving a Multicast Address Mapping (MAM) PDU 677 containing a group Network address that the ES is announcing, the ES 678 will use the SNPA address pairing contained in the MAM PDU for that 679 group Network address. Upon the expiration of the Mapping Holding 680 Timer, the ES shall revert back to associating either the Pre- 681 configured SNPA address if one exists or the "All Multicast End Sys- 682 tem Network Entities" SNPA address for the specific group Network 683 address. While an ES is permitted to listen in on other ESs announce- 684 ments (needed for the damping option), an ES is not permitted to 685 change its group Network address to SNPA address mapping based on the 686 announcement of other ESs. 688 Optionally, the ES may perform damping (resetting a Multicast 689 Announcement Timer corresponding to a particular group Network 690 address) if the conditions necessary to withhold a particular 691 announcement are met. In order to perform damping the following con- 692 ditions must be met: (1)The ES must be processing other ES's 693 announcements; (2)An ESGH PDU is received that identifies the exact 694 same group Network address and SNPA address pairing on a particular 695 subnetwork that this ES is announcing on; (3) The Multicast Holding 696 Timer parameter value in the ESGH PDU received is equal to or greater 697 than the Multicast Holding Timer value, for this subnetwork, that is 698 being used by the ES processing this ESGH PDU. 700 ESs will utilize a local default value for their Multicast Announce- 701 ment Timer to control the period for sending out their ESGH PDUs. The 702 Active Multicast IS, if one exists on a particular subnetwork, will 703 optionally suggest a value for ESs on the subnetwork to use for their 704 Multicast Announcement Timer for a specific group Network address. In 705 order to support the optional damping function, ESs are required to 706 incorporate a 25% jittering to the timer values that they are using. 708 6.1.2 Operation of ESs sourcing multicast PDUs 710 An ES which is attached to multiple subnetworks when sourcing multi- 711 cast PDUs is required to source only one such PDUs on to a subnetwork 712 to which a multicast IS is attached. No restrictions are placed on a 713 multiply attached ES for which none of the subnetworks to which it is 714 attached to has a multicast capable IS. The ES sourcing multicast 715 PDUs on a subnetwork that has a multicast IS attached always uses the 716 "All Multicast Intermediate System Network entities" as the SNPA des- 717 tination address for all PDUs sourced. For an ES which is not 718 attached to a subnetwork with a multicast capable IS, the ES uses 719 pre-configured multicast address mapping information if available and 720 if there is no pre-configured information maps the "All Multicast End 721 System Network Entities" multi-destination address to the group Net- 722 work address. The ES sourcing multicast PDUs identified by a specific 723 group Network address is not required to be a receiver of such PDUs 724 (and thus is not announcing that particular group Network address). 726 The reason for sourcing packets on a subnetwork with a multicast 727 capable IS attached by multicasting to all multicast capable ISs 728 versus unicasting to one of the multicast capable ISs is to limit the 729 maximum number of transmissions required on any subnetwork to two. 730 In the case of sourcing a packet, one transmission would be used for 731 sourcing the packet to all ISs that might need it and the second, if 732 needed, to multicast the packet to ESs on the subnetwork which belong 733 to the group. If this packet were sourced via a unicast to an IS, 734 then the packet may need to passed on to other ISs on the subnet 735 (depending upon the particular multicast tree) and the same packet 736 may need to be transmitted again to the ESs on the subnetwork which 737 belong to the group. 739 6.1.3 Operation of the Active Multicast IS 741 The Active Multicast IS listens in on all ESGH PDUs sourced on the 742 subnetwork for which it is serving as the Active Multicast IS. All 743 subnetworks are handled independently (even if multiple subnetworks 744 have the same ESs attached and the IS is serving as the Active Multi- 745 cast IS for these multiple subnetworks). 747 The Active Multicast IS sources MAM PDUs, for all group Network 748 addresses for which it has received ESGH PDUs, on the subnetwork due 749 to the following operational conditions: (1)The IS initializes either 750 as the Active Multicast IS after an election with other multicast 751 capable ISs or initializes believing it is the only multicast capable 752 IS (the determination of such conditions are outside of the scope of 753 this specification); (2)The IS receives an ESGH PDU with a group Net- 754 work address paired to an incorrect SNPA address; (3)The expiration 755 of the IS's Multicast Address Mapping Timer for that group Network 756 address (this is to prevent the expiration of Mapping Holding Timers 757 in ESs and to ensure that ESs which source specific multicast PDUs 758 but are not receivers of such PDUs are using the correct SNPA desti- 759 nation address in such PDUs that they source) or (4)The IS receives a 760 multicast PDU sourced on the subnetwork which used an incorrect des- 761 tination SNPA address (note: this specification does not place any 762 requirement on an IS to listen in on any multicast PDU, with the 763 exception of multicast PDUs addressed to "the All Multicast Inter- 764 mediate System Network Entities" group SNPA address but an IS may 765 receive a PDU with an incorrect destination SNPA address due to other 766 operational actions). 768 Actual relaying of any multicast PDUs sourced on a subnetwork will be 769 the responsibility of the multicast routing protocol used and is out- 770 side the scope of this specification. 772 6.2 Definitions 774 Active Multicast IS: The one multicast capable IS selected (via means 775 outside of this specification) to source Multicast Address Mapping 776 information on a particular subnetwork. 778 Paired SNPA Address: The SNPA address associated with a particular 779 group Network address on a specific subnetwork. 781 6.3 Routing information supporting multicast transmission 783 6.3.1 Multicast Announcement Information 785 An IS should forward a multicast PDU containing a particular destina- 786 tion group Network address onto a subnetwork to which it is attached 787 if and only if one or more of the ESs attached to that subnetwork 788 have declared an interest in receiving multicast PDUs destined for 789 that group Network address. Multicast announcement information 790 enables an IS that supports CLNP multicast to dynamically discover, 791 for each subnetwork to which it is attached, the group Network 792 addresses for which ESs attached to that subnetwork have declared an 793 interest. 795 On a point-to-point subnetwork the multicast announcement information 796 informs the Network entity, in the case where it is attached to an 797 End System, of the group Network addresses for which that End System 798 expects to receive multicast PDUs. 800 On a broadcast subnetwork the multicast announcement information 801 informs the multicast capable Intermediate Systems, of the group Net- 802 work addresses for which ESs attached to that subnetwork expect to 803 receive multicast PDUs. 805 Editor's Note: Intermediate Systems with the optional OSI multicast 806 capabilities do receive information identifying the SNPA address of 807 ESs on the broadcast network that want PDUs with particular group 808 Network addresses as their destination address; however, the critical 809 information is which multicast PDUs are needed, not which ESs need 810 them. 812 6.3.2 Multicast Address Mapping Information 814 In order to receive multicast PDUs destined for a particular group 815 Network address, an ES may be able to take advantage of an associa- 816 tion of the group Network address with a specific SNPA address. Mul- 817 ticast address mapping information enables an IS to inform ESs that 818 they can receive multicast PDUs destined for a particular group Net- 819 work address on a corresponding specific SNPA address. 821 Multicast address mapping information is not employed on point-to- 822 point subnetworks. 824 Multicast address mapping information is employed on broadcast sub- 825 networks to enable multicast capable Intermediate Systems to inform 826 the multicast capable End Systems that they can receive, on a 827 specific broadcast subnetwork, multicast PDUs destined for a particu- 828 lar group network address on a corresponding specific SNPA address. 830 6.4 Addresses 832 All exchanges using this protocol are accomplished over a single sub- 833 network. While the control PDU's contain Network addresses (i.e. 834 group Network addresses) actual control PDU transfer is accomplished 835 via Subnetwork based group addresses (i.e. group SNPA addresses). The 836 following group SNPA addresses are used: (1)All Multicast End System 837 Network entities; (2)All Multicast Intermediate System Network enti- 838 ties and (3)a group SNPA address corresponding to a group Network 839 address 841 6.5 Timers 843 Two additional timers are employed: (1)the Multicast Announcement 844 Timer (MAT) and (2)Multicast Address Mapping Timer (MAMT). Old 845 multicast announcement or multicast address mapping information shall 846 be discarded after the Holding Timer expires to ensure the correct 847 operation of the protocol. 849 6.5.1 Multicast Announcement Timer 851 The Multicast Announcement Timer is a local timer (i.e. maintained 852 independently by each End System, one timer per group Network 853 address) which assists in performing the Report Multicast Announce- 854 ment function. The timer determines how often an End System reports 855 its desire to receive multicast PDUs with that group Network address 856 as its destination address parameter. Considerations in setting this 857 timer are similar to those described for the Configuration timer in 858 the ES-IS specification. 860 6.5.2 Multicast Address Mapping Timer 862 The Multicast Address Mapping Timer is a local timer (i.e. maintained 863 independently by an Intermediate System which is actively participat- 864 ing with End Systems to transfer multicast PDUs) which assists in 865 performing the Report Multicast Address Mapping function. The timer 866 determines how often an Intermediate System, actively participating 867 with End Systems for the transfer of multicast PDUs, reports the Mul- 868 ticast Address Mapping for a particular group Network address. The 869 shorter the Multicast Address Mapping Timer, the more quickly End 870 Systems on the subnetwork will become aware of the correct address 871 mapping which may change due to the Intermediate System becoming 872 available or unavailable. There is a trade off between increased 873 responsiveness and increased use of resources in the subnetwork and 874 in the End Systems. 876 6.6 Extensions to the current protocol functions 878 In order to support multicast transmissions the following optional 879 ES-IS protocol functions will be implemented: 881 6.6.1 Report Configuration by Intermediate Systems 883 All multicast capable Intermediate Systems on a subnetwork will use 884 the Multicast Capable option in all ISH PDUs that they source. This 885 will provide multicast capable End Systems with a way to determine 886 that a multicast capable Intermediate System is operating on a par- 887 ticular subnetwork. 889 6.6.2 Query Configuration 891 Note: The Query Configuration function cannot be performed to find 892 the corresponding SNPA address of a group Network address since the 893 addressing information needed is the corresponding group SNPA address 894 and not the SNPA address of a particular End System responding. On a 895 large broadcast subnetwork, many different Configuration Responses 896 could result each incorporating a different End System Address. While 897 it is possible to design a Query Configuration for use with multi- 898 cast, this function does not appear to be required given the use of 899 the "All Multicast End System Network Entities" address for supplying 900 a SNPA address when the group SNPA address is not known. 902 6.7 Multicast Announcement 904 6.7.1 Report Multicast Announcement Function by End Systems 906 An End System which needs to receive or continue to receive any mul- 907 ticast PDUs (i.e. PDUs with group Network addresses as their destina- 908 tion address), constructs and transmits ESGH PDUs to inform multicast 909 capable Intermediate Systems of the set of group Network address des- 910 tinations for which it wishes to receive PDUs. This may be done by 911 constructing ESGH PDUs for each group Network address. Alternatively, 912 ESGH PDUs may be constructed which convey information about more than 913 one group Network address at a time, up to the limits imposed by the 914 permitted SNSDU size and the maximum header size of the ESGH PDU. 915 Each ESGH PDU is transmitted by issuing an SN-UNITDATA.Request with 916 the following parameters: 918 SN_Userdata (SNSDU) <- ESGH PDU 920 SN_Destination _Address <- multi-destination address that indicates 921 "All Multicast Intermediate System Network Entities" 923 If an End System supports more than one SNPA, the information about 924 each group Network address desired for receiving on a particular SNPA 925 serving the End System shall be transmitted via that SNPA. It is per- 926 missible for an End System to report group Network addresses on mul- 927 tiple SNPAs; however, duplicate multicast PDUs should be anticipated. 929 The Group Address Pair parameter carries a list of Group Network 930 Addresses, each paired with its associated SNPA address. This infor- 931 mation is used by the Active Multicast IS to determine whether a Mul- 932 ticast Address Mapping PDU should be emitted to update the associa- 933 tion between Group Network Addresses and SNPA addresses. 935 The Holding Time (HT) field is set to approximately twice the ES's 936 Multicast Announcement Timer (MAT) parameter. The value shall be 937 large enough so that even if every other ESGH PDU is discarded (due 938 to lack of resources), or otherwise lost in the subnetwork, the mul- 939 ticast announcement information will still be maintained. The value 940 should be set small enough so that Intermediate Systems resources are 941 not needlessly consumed when the ES no longer wishes to receive PDUs 942 destined to a group Network address. 944 Note: -- When combining multiple group Network addresses in a single 945 ESGH PDU, it should be realized that there is a single Holding Time 946 parameter associated with all of these addresses. 948 6.7.1.1 Generating Jitter on Multicast Announcement Timers 950 The ES shall apply a 25% jitter to its Multicast Announcement Timer 951 (MAT) parameter. When ESGH PDUs are transmitted as a result of timer 952 expiration, there is a danger that the timers of individual systems 953 may become synchronised. The result of this is that the traffic dis- 954 tribution will contain peaks. Where there are a large number of syn- 955 chronised systems, this can cause overloading of both the transmis- 956 sion medium and the systems receiving the PDUs. In order to prevent 957 this from occurring, all periodic timers, the expiration of which can 958 cause the transmission of PDUs, shall have "jitter" introduced as 959 defined in the following algorithm. 961 CONSTANT 963 Jitter = 25; 964 Resolution = 100; 966 (* The timer resolution in ms *) 967 PROCEDURE Random(max: Integer): Integer; 969 (* This procedure delivers a Uniformly distributed random 970 integer R such that 0 < R