idnits 2.17.1 draft-ietf-tuba-host-clnp-multicas-01.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-03-19) 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 41 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. ** 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 616: '... 1100 0110 (THIS CODE MAY CHANGE)...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 360 has weird spacing: '... nature than ...' == Line 684 has weird spacing: '...address uses ...' == Line 798 has weird spacing: '...ion the multi...' -- 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 2011, 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: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dave Marlow 2 May 13, 1994 NSWC-DD 4 Host Group Extensions for CLNP Multicasting 6 draft-ietf-tuba-host-clnp-multicas-01.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 The primary change in this updated Internet Draft is the 49 incorporation of "direct origination of multicast packets" as 50 discussed at the March TUBA meeting and over the email. This change 51 to the behavior of hosts originating multicast packets enables hosts 52 announcing an interest in particular group Network addresses to 53 directly receive such multicast packets originated on a subnetwork to 54 which they are connected. This replaces the previous method which in 55 some cases required a multicast capable router to resend such 56 packets. 58 Contents 60 Status of this Memo 62 Abstract 64 1. Introduction 66 2. Levels of Conformance 68 3. Group Network Addresses 70 4. Model of a CLNP End System Multicast Implementation 72 5. Extensions to the CLNP Protocol 74 6. Extensions to the ES-IS Routeing Protocol 76 Appendix A. Differences with RFC 1112 78 Appendix B. Issues Under Study 80 References 82 Author's Address 84 1. Introduction 86 This draft provides a specification for multicast extensions for CLNP 87 in order to provide a CLNP based Internet the capabilities provided 88 for IP by RFC 1112 (Host Extensions for IP Multicasting) [RFC1112]. 89 This draft uses an outline similar to that of RFC 1112. 91 Paraphrasing RFC 1112, "CLNP multicasting is the transmission of a 92 CLNP datagram to a "host group", a set of zero or more End Systems 93 identified by a single group Network address (GNA). A multicast 94 datagram is delivered to all members of its destination host group 95 with the same "best-efforts" reliability as regular unicast CLNP 96 datagrams, i.e., the datagram is not guaranteed to arrive intact at 97 all members of the destination group or in the same order relative to 98 other datagrams. 100 "The membership of a host group is dynamic; that is End Systems may 101 join and leave groups at any time. There is no restrictions on the 102 location or number of members in a host group. An End System may be a 103 member of more than one group at a time. An End System need not be a 104 member of a group to send datagrams to it. 106 "A host group may be permanent or transient. A permanent group has an 107 administratively assigned GNA. It is the address, not the membership 108 of the group, that is permanent; at any time a permanent group may 109 have any number of members, even zero. 111 "Internetwork forwarding of CLNP multicast datagrams is handled by 112 "multicast capable" Intermediate Systems which may be co-resident 113 with unicast capable Intermediate Systems. 115 This draft specifies the extensions required by an End System to make 116 use of CLNP multicast. In addition the requirements placed upon 117 multicast capable Intermediate Systems to exchange information with 118 multicast capable End Systems is specified. No specifications are 119 provided related to the information exchanges between Intermediate 120 Systems to support multicast route selection or multicast Protocol 121 Data Unit (PDU) forwarding. A discussion of multicast route selection 122 and PDU forwarding has been written by Steve Deering [Deering91]. 123 Note that for these multicast extensions to work there must exist an 124 uninterrupted path of multicast capable routers between the End 125 Systems comprising a host group (such paths may utilize tunneling 126 (i.e. unicast CLNP encapsulated paths between multicast capable CLNP 127 routers)). In order to support multicast route selection and 128 forwarding for a CLNP based internet additional specifications are 129 needed. Specifications of this type could come in the form of new 130 protocols, extensions to the current CLNP based routing protocols or 131 use of a technique out of the IETF`s Inter-Domain Multicast Routing 132 (IDMR) group. The IDMR group is currently investigating multicast 133 protocols for routers which utilize a router's unicast routing 134 protocols, this approach may extend directly to CLNP routers. 136 While many of the techniques and assumptions of IP multicasting (as 137 discussed in RFC 1112) are used in CLNP multicasting, there are 138 number of differences. Appendix A describes the differences between 139 CLNP multicasting and IP multicasting. This draft describes 140 techniques brought in directly from projects within ISO to 141 incorporate multicast transmission capabilities into CLNP [MULT- 142 AMDS]. Coordination is being made to keep this draft consistent with 143 the specifications of these ISO projects. Key contributions to the 144 techniques described in this draft have been made by a number of 145 individuals within the TUBA, ANSI X3S3.3 and ISO SC6 Working Group 2 146 committees. 148 2. Levels of Conformance 150 There are three levels of conformance for End Systems to this 151 specification: 153 Level 0: no support for CLNP multicasting. 155 There is no requirement for a CLNP End System (or Intermediate 156 System) to support CLNP multicasting. Level 0 hosts should be 157 unaffected by the presence of multicast activity. The destination 158 addresses used in support of multicast transfers, the GNA, should not 159 be enabled by a non-multicast capable End System and the PDUs 160 themselves are marked differently than unicast PDUs and thus should 161 be quietly discarded. 163 Level 1: support for sending but not receiving CLNP multicast PDUs. 165 An End System originating multicast PDUs is required to know whether 166 a multicast capable Intermediate System is attached to the 167 subnetwork(s) that it originates multicast PDUs (i.e. to determine 168 the destination SNPA (subnet) address). An End System with Level 1 169 conformance is required to implement all parts of this specification 170 except for those supporting only Multicast Announcement. An End 171 System is not required to know the current Multicast Address Mapping 172 to start originating multicast PDUs. 174 Note: It is possible for End System not implementing Multicast 175 Address Mapping to successfully originate multicast PDUs (but with 176 the End System knowing of the existence of a multicast capable 177 Intermediate System). Such operation may lead to inefficient 178 subnetworks use. Thus when an End System continues (or may continue) 179 to originate multicast PDUs destined for the same group, 180 implementations are to provide Multicast Address Mapping support. 182 Level 2: full support for CLNP multicasting. 184 Level 2 allows a host to join and leave host groups as well as send 185 CLNP PDUs to host groups. It requires implementation by the End 186 System of all parts of this specification. 188 3. Group Network Addresses 190 Individual Network addresses used by CLNP for End System addressing 191 are called Network Service Access Points (NSAPs). RFC 1237 defines 192 the NSAP address for use in the Internet. In order to provide an 193 address for a group of End Systems, this specification does not 194 change the definition of the NSAP address, but adds a new type of 195 identifier - the group Network address - that supports a multicast 196 Network service (i.e., between a single source NSAP, identified by an 197 individual Network address, and a group of destination NSAPs, 198 identified by a group Network address). Host groups are identified by 199 group Network addresses. 201 In the development of multicast address extensions to CLNP, 202 requirements were identified for: (1)"easily distinguishing" group 203 addresses at the Network layer from NSAP addresses; (2)leaving the 204 currently allocated address families unaffected and (3)ensuring that 205 the approach taken would not require the establishment of new 206 addressing authorities. In addition, it was agreed that providing 207 multicast options for all OSI Network layer users was desirable and 208 thus the group Network addressing solution should support options for 209 all address formats covered by ISO/IEC 8348 | Recommendation X.213. 210 The only viable means identified for meeting all requirements was via 211 creating a new set of AFI values with a fixed one-to-one mapping 212 between each of the existing AFI values and a corresponding group AFI 213 value. 215 Group Network addresses are defined by creating a new set of AFI 216 values, one for each existing AFI value, and a fixed one-to-one 217 mapping between each of the existing AFI values and a corresponding 218 group AFI value. The syntax of a group Network address is identical 219 to the syntax of an individual Network address, except that the value 220 of the AFI in an individual Network address may be only one of the 221 values already allocated for individual Network addresses, whereas 222 the value of the AFI in a group Network address may be only one of 223 the values allocated here for group Network addresses. The AFI values 224 allocated for group Network addresses have been chosen in such a way 225 that they do not overlap, in the preferred encoding defined by 226 ISO/IEC 8348 | CCITT Recommendation X.213, with any of the AFI values 227 that have already been allocated for individual Network addresses. 229 3.1 Definitions 231 group Network address: an address that identifies a set of zero or 232 more Network service access points; these may belong to multiple 233 Network entities, in different End Systems. 235 individual Network address: an address that identifies a single NSAP. 237 3.2 CLNP Addresses 239 A discussion of the CLNP address format is contained in RFC 1237. The 240 structure of all CLNP addresses is divided into two parts the Initial 241 Domain Part (IDP) and the Domain Specific Part (DSP). The first two 242 octets of the IDP are the Authority and Format Identifier (AFI) 243 field. The AFI has an abstract syntax of two hexadecimal digits with 244 a value in the range of 00 to FF. In addition to identifying the 245 address authority responsible for allocating a particular address and 246 the format of the address, the AFI also identifies whether an address 247 is an individual Network address or a group Network address. There 248 are 90 possible AFI values to support individual Network address 249 allocations. In addition, when the AFI value starts with the value 250 "0" this identifies that the field contains an incomplete individual 251 Network address (i.e. identifies an escape code). 253 Table 1 allocates 90 possible AFI values to support group Network 254 address allocations. In addition if the first two digits of the IDP 255 are hexadecimal FF, this indicates the presence of an incomplete 256 group Network address. The allocation of group addresses is 257 restricted to be only from the AFI values allocated for the 258 assignment of group addresses in Table 1. An addressing authority in 259 allocating either Network addresses or authorizing one or more 260 authorities to allocate addresses, allocates both individual and the 261 corresponding group addresses. Thus each block of addresses allocated 262 by an addressing authority (or its sub-authority) contains a block of 263 individual Network addresses and group Network addresses. The 264 individual and group address block allocated are differentiated by 265 the AFI values used which are related as shown in Table 1. 267 Group Network addresses are only used as the destination address 268 parameter of a CLNP PDU. Source Address parameters are never 269 permitted to be group Network addresses. 271 Table 2 lists the AFI values which have not been assigned, at this 272 time, for the support of neither individual nor group address 273 allocation. Future assignment of these AFI values is possible. 274 Additional information concerning individual Network addresses (i.e. 275 NSAP and NET (Network Entity Titles)) is contained in RFC 1237. 277 TABLE 1 - Relationship of AFI Individual and Group Values 278 ----------------------------------------------------------- 279 |Individual Group | Individual Group | Individual Group | 280 ----------------------------------------------------------- 281 | 0x FF | | | 282 | 10 A0 | 40 BE | 70 DC | 283 | 11 A1 | 41 BF | 71 DD | 284 | 12 A2 | 42 C0 | 72 DE | 285 | 13 A3 | 43 C1 | 73 DF | 286 | 14 A4 | 44 C2 | 74 E0 | 287 | 15 A5 | 45 C3 | 75 E1 | 288 | 16 A6 | 46 C4 | 76 E2 | 289 | 17 A7 | 47 C5 | 77 E3 | 290 | 18 A8 | 48 C6 | 78 E4 | 291 | 19 A9 | 49 C7 | 79 E5 | 292 | 20 AA | 50 C8 | 80 E6 | 293 | 21 AB | 51 C9 | 81 E7 | 294 | 22 AC | 52 CA | 82 E8 | 295 | 23 AD | 53 CB | 83 E9 | 296 | 24 AE | 54 CC | 84 EA | 297 | 25 AF | 55 CD | 85 EB | 298 | 26 B0 | 56 CE | 86 EC | 299 | 27 B1 | 57 CF | 87 ED | 300 | 28 B2 | 58 D0 | 88 EE | 301 | 29 B3 | 59 D1 | 89 EF | 302 | 30 B4 | 60 D2 | 90 F0 | 303 | 31 B5 | 61 D3 | 91 F1 | 304 | 32 B6 | 62 D4 | 92 F2 | 305 | 33 B7 | 63 D5 | 93 F3 | 306 | 34 B8 | 64 D6 | 94 F4 | 307 | 35 B9 | 65 D7 | 95 F5 | 308 | 36 BA | 66 D8 | 96 F6 | 309 | 37 BB | 67 D9 | 97 F7 | 310 | 38 BC | 68 DA | 98 F8 | 311 | 39 BD | 69 DB | 99 F9 | 312 ----------------------------------------------------------- 314 TABLE 2 - AFI values reserved for future allocation 315 -------------- 316 | 1A-1F | 317 | 2A-2F | 318 | 3A-3F | 319 | 4A-4F | 320 | 5A-5F | 321 | 6A-6F | 322 | 7A-7F | 323 | 8A-8F | 324 | 9A-9F | 325 | FA-FE | 326 -------------- 328 4. Model of a CLNP End System Multicast Implementation 330 The use of multicast transmission by a CLNP End System involves 331 extensions to two protocols: CLNP and the ES-IS Routeing Protocol. To 332 provide level 0 service (no support for CLNP multicast), no 333 extensions to the two present protocols are required. To provide 334 level 1 service (support for sending but not receiving CLNP multicast 335 PDUs) all extensions contained in the following sections are required 336 except for those supporting only Multicast Announcement. In order to 337 support level 2 service (full support for CLNP multicasting), the 338 extensions contained in the following sections are required. 339 Extensions identified for Intermediate Systems are not required (or 340 appropriate) for End Systems. Multicast transmission also requires 341 the use of a group Network address (as previously described) as the 342 destination address parameter. 344 5. Extensions to the CLNP protocol 346 This section provides extensions to the CLNP Protocol [CLNP] ISO 347 8473-1, to support multicast transmission. These additions provide 348 procedures for the connectionless transmission of data and control 349 information from one network-entity to one or more peer network- 350 entities. 352 In developing the multicast extensions for CLNP a decision was needed 353 on how to "mark" a packet as multicast (versus the current unicast 354 packets). Such marking is necessary since the forwarding behavior 355 for multicast packets is different (e.g. multiple copies of a packet 356 may need to be forwarded). The two alternatives considered were to 357 mark the packet (via a particular field) or to mark the destination 358 address, in the end both were done. The destination address for a 359 multicast PDU identifies a host group which is of a very different 360 nature than the unicast NSAP address. Rather than changing the 361 nature of NSAP addresses, a new set of addresses were created named 362 group Network addresses which are marked within the first octet (i.e. 363 the AFI field) with values reserved for group Network addresses. 365 Consideration was given to no further marking of the PDU; however, a 366 problem was identified with only using the group Network address to 367 identify multicast packets. Currently routers implementing the IS-IS 368 Intra-Domain protocol as Level 1 routers when receiving a packet with 369 an unknown destination address are permitted to either discard the 370 packet or send it to a Level 2 router. Such actions by non-multicast 371 capable routers to multicast packets can lead to non-deterministic 372 behavior. Level 1 routers upon receiving a packet containing a group 373 Network address might pass the packet up to a Level 2 router (which 374 may or may not be multicast capable) or it might discard it. 375 Depending upon the circumstances this might lead to whole regions 376 missing packets or packet duplication (possibly even explosion). The 377 result was to seek deterministic behavior by non-multicast capable 378 routers by creating a new PDU type (Multicast Data PDU) and inserting 379 into the CLNP reasons for discard: receiving a PDU of unknown type. 380 Note this reason for discard is mandatory on multicast capable and 381 non-multicast capable CLNP implementations. 383 5.1 Definitions 385 multicast: Data transmission to one or more destinations in a 386 selected group in a single service invocation. 388 multicast capable Intermediate System: An Intermediate System which 389 incorporates the multicast features of the Network layer. 391 5.2 Addresses 393 The destination address parameter of a multicast PDU shall contain a 394 group Network address. The source address parameter shall be an 395 individual Network address. 397 5.3 Extensions to the current protocol functions 399 In order to support multicast transmissions the following optional 400 CLNP protocol functions will be implemented: 402 5.3.1 Header Format Analysis function 404 The header format analysis function optionally provides capabilities 405 to Network entities which support multicast transfer to supply 406 applicable PDUs directly to End Systems served by such a Network 407 entity as well as to forward such PDUs on to other Network entities. 408 This optional functionality is realized through a Network entity with 409 multicast capability identifying a PDU as using multicast transfer 410 via the PDU type and the PDU's destination address field. 412 If a Network entity supports multicast transmission, then the header 413 format analysis function shall provide checking to ensure that a PDU 414 does not contain a group Network address in the source address field. 415 Any PDU header analyzed to have a group address in the source address 416 field shall be discarded. 418 5.3.2 Route PDU function 420 The route PDU function optionally provides capabilities to Network 421 entities which support multicast transfer for determining multiple 422 Network entities to which a single PDU shall be forwarded to. This 423 may result in multiple invocations of the forward PDU function and 424 hence the need to make multiple copies of the PDU. For PDUs that are 425 received from a different Network entity, the optional functionality 426 for the route PDU function is realized as a result of the header 427 format analysis function's recognition of the PDU as being a 428 multicast PDU. A Network entity attached to more than one subnetwork 429 when originating a multicast PDU is permitted to originate the PDU on 430 more than one subnetwork. 432 Note: The ES-IS function "Extensions to the ISO CLNP Route Function 433 by End Systems" discussed in section 6.10 identifies on which 434 subnetworks an End System attached to more than one subnetwork must 435 originate multicast PDUs on. 437 Note: The purpose in allowing an originating Network entity to 438 originate a multicast PDU on multiple subnetworks is to support the 439 development of multicast IS-IS protocols which will need to determine 440 on which subnetworks a multicast PDU has visited. This behavior is 441 predicated on the assumption that the Intermediate Systems in the OSI 442 environment performing multicast forwarding form a connected set. 444 5.3.3 Forward PDU function 446 This function issues an SN-UNITDATA request primitive, supplying the 447 subnetwork or Subnetwork Dependent Convergence Function (SNDCF) 448 identified by the route PDU function with the protocol data unit as 449 user data to be transmitted, the address information required by that 450 subnetwork or SNDCF to identify the "next" system or systems within 451 the subnetwork-specific addressing domain (this may be one or more 452 Intermediate Systems and/or one or more destination End Systems), and 453 quality of service constraints (if any) to be considered in the 454 processing of the user data. 456 5.3.4 Discard PDU function 458 Add an additional reason for discard - a PDU is received with an 459 unknown type code. 461 5.3.5 Error reporting function 463 It is important to carefully control the use of the error reporting 464 capability in the case of multicast transfers. The primary concern 465 is to avoid the occurrence of broadcast storms and thus a multicast 466 PDU may not cause the origination of another multicast PDU. This is 467 the primary reason that the source address is not permitted to be a 468 group address. In addition, a multicast PDU with error reporting 469 permitted can result in flooding the source network-entity (as well 470 as the networks used) with Error Report PDUs. 472 While error reports are permitted on multicast PDUs, a PDU with a 473 group Network address in the source address field shall not be 474 responded to with an Error Report. This is to ensure that a multicast 475 PDU does not generate another multicast PDU. If the source address is 476 identified as a group address then an error report PDU shall not be 477 generated and the original PDU shall be discarded. 479 5.3.6 Source routing functions 481 No source routing capability is provided for multicast PDU transfer. 482 The NS provider shall not accept a multicast PDU with source route 483 parameters. 485 5.4 Scope control function 487 5.4.1 Overview 489 The scope control function is an option for multicast PDU forwarding 490 only. The scope control function allows the originator to limit the 491 forwarding of the multicast PDU. The scope control function provides 492 the capability to limit the relaying of a particular PDU based on the 493 individual Network addressing hierarchy and/or limit the amount of 494 multicast expansion which can take place. In cases where both forms 495 of scope control are applied to the same PDU, forwarding will cease 496 once either has reached its scope control limit. 498 5.4.2 Prefix Based Scope Control 500 The prefix based scope control function allows the originator to 501 specify a specific set of address prefixes where the multicast 502 forwarding of a PDU by an Intermediate System occurs only if one of 503 the prefixes matches the Network Entity Title (NET) of the 504 Intermediate System. Prefix based scope control may be selected only 505 by the originator of a PDU. Prefix based scope control is 506 accomplished using one or more address prefixes held in a parameter 507 within the options part of the PDU header. The length of this 508 parameter is determined by the originating network entity, and does 509 not change during the lifetime of a PDU. 511 When an Intermediate System receives a multicast PDU containing a 512 prefix based scope control parameter, forwarding is only performed if 513 every octet of one of the prefixes contained in the prefix based 514 scope control parameter matches that Intermediate System's NET, 515 starting from the beginning of its NET. If no such prefix match 516 exists, the Intermediate System discards the PDU. The error reporting 517 function shall not be invoked upon PDU discard. 519 5.4.3 Radius Scope Control 521 The radius scope control function allows the originator to specify a 522 maximum logical distance where multicast expansion can occur. It is 523 closely associated with the header format analysis function. Each IS 524 receiving a multicast PDU which is capable of expanding and which 525 contains a Radius Scope Control parameter, decrements the Radius 526 Scope Control field in the PDU by an administratively set amount 527 between 0 and the maximum value of the field. This function 528 determines whether the PDU received may be forwarded or whether its 529 Radius has been reached, in which case it shall be discarded. An 530 Intermediate System shall not forward a multicast PDU containing a 531 Radius Scope Control parameter with a value of 0. The error reporting 532 function shall not be invoked upon PDU discard. 534 5.4.3.1 Radius Scope Control Example 536 The Radius Scope Control parameter is useful where policies have been 537 established across the potential forwarding path. One possible 538 policy for Internet use is for multicast capable routers to treat 539 this field as a hop count within a domain (decrement by one unit) and 540 for inter-domain routers to either decrement this field to an even 541 multiple of 256 when crossing domains where prior agreements have 542 been made or decrement this field to 0 (i.e. discard the packet) for 543 other domains. 545 5.5 Structure and Encoding of PDUs 547 Multicast transmission is accomplished via the transfer of Multicast 548 Data (MD) PDUs. The PDU type code for a MD PDU is "1 1 1 0 1". The 549 format of the MD PDU is identical to that of the Data (DT) PDU. The 550 MD and DT PDU may contain the same optional parameters with the 551 following exceptions: (1)The source routing parameter is permitted 552 within DT PDUs but not MD PDUs; and (2)The scope control parameter is 553 permitted within MD PDUs but not DT PDUs. 555 5.6 Optional parameters for multicast support 557 5.6.1 Prefix Based Scope Control (this section is extended beyond the 558 ISO draft) 560 The prefix based scope control parameter specifies one or more 561 address prefixes for which Intermediate System forwarding requires a 562 match of one of the contained prefixes with the beginning of the 563 Intermediate System's NET. 565 Parameter Code: 1100 0100 567 Parameter Length: variable 569 Parameter Value: a concatenation of address prefix entries 571 The parameter value contains an address prefix list. The list 572 consists of variable length address prefix entries. The first octet 573 of each entry gives the length of the address prefix denominated in 574 bits that comprises the remainder of the entry. If the length field 575 does not specify an integral number of octets then the prefix entry 576 is followed by enough trailing zeroes to make the end of the entry 577 fall on an octet boundary. The list must contain at least one entry. 579 The prefix shall end on a boundary that is legal in the abstract 580 syntax of the address family from which it is derived. For example, 581 the encoding of a prefix whose DSP is expressed in decimal syntax 582 must end on a semi-octet boundary, while the encoding of a prefix 583 whose DSP is expressed in binary syntax can end on an arbitrary bit 584 boundary. If the end of the prefix falls within the IDP, then the 585 prefix must end on a semi-octet boundary and must not contain any 586 padding characters. 588 NOTE - The length of the prefix based scope control 589 parameter is determined by the originator of the PDU and is not 590 changed during the lifetime of the PDU. 592 5.6.1.1 Prefix matching 594 A prefix that extends into the DSP shall be compared directly against 595 the encoded NET address, including any padding characters that may be 596 present. A prefix which does not extend into the DSP shall be 597 compared against the derived quantity NET', which is obtained from 598 the NET address by removing all padding characters (as defined by the 599 binary encoding process of ISO 8348). 601 The existence of a match shall be determined as follows: 603 a) If the encoded NET (or NET') contains fewer bits than the pre- 604 fix, then there is no match. 606 b) If the encoded NET (or NET') contains at least as many bits as 607 the prefix, and all bits of the prefix are identical to the 608 corresponding leading bits of the encoded NET (or NET'), there 609 is a match. Otherwise, there is no match. 611 5.6.2 Radius Scope Control 613 The radius scope control parameter specifies the logical distance 614 that a multicast PDU can be forwarded. 616 Parameter Code: 1100 0110 (THIS CODE MAY CHANGE) 618 Parameter Length: two octets 620 Parameter Value: two octets which represents the remaining 621 distance, that the PDU can be forwarded, in administratively set 622 units. 624 5.7 Provision of the Underlying Service 626 For a subnetwork that provides an inherent multicast capability, it 627 is the functionality of the SNDCF to provide the mapping between 628 group Network addresses and the corresponding addressing capability 629 of the subnetwork. 631 5.8 Conformance 633 All of the extensions provided to the functions to support multicast 634 capability are optional. For an End System or Intermediate System 635 which is not multicast capable these extensions are not applicable. 636 An implementation claiming conformance as a multicast capable End 637 System shall meet all of the requirements for an End System which is 638 not multicast capable and also provide all of the multicast exten- 639 sions provided here. An implementation claiming conformance as a mul- 640 ticast capable Intermediate System shall meet all of the requirements 641 for an Intermediate System which is not multicast capable and also 642 provide all of the multicast extensions provided here. 644 6. Extensions to the ES-IS Routeing Protocol 646 This section provides optional extensions to the ES-IS Routeing Pro- 647 tocol [ES-IS], ISO 9542 to support the transfer of multicast PDUs. It 648 is an explicit goal of this specification that ESs and ISs, some of 649 which will have multicast capabilities and some without, will be able 650 to fully function on the same subnetworks. This specification does 651 not change any aspect of a currently defined (i.e. non-multicast) ISO 652 9542 implementation, it adds new optional functionality not modifying 653 current functionality. Two basic functions are provided: multicast 654 announcement and multicast address mapping. 656 6.1 Overview of the protocol 658 6.1.1 Operation of ESs receiving multicast PDUs 660 ESs, upon initialization and periodically thereafter, will construct 661 End System Group Hello (ESGH) PDUs identifying, by particular group 662 Network addresses, the multicast PDUs it wishes to receive. The ES 663 will periodically originate (announce) these ESGH PDUs on the subnet- 664 work it wishes to receive these on. Reporting the same group Network 665 address on multiple subnetworks may result in the reception of dupli- 666 cate PDUs. ES-IS operations related to requesting the same group Net- 667 work address on multiple subnetworks are handled totally indepen- 668 dently (e.g. using different logical timers,...). It is permitted for 669 an ES to report a number of group Network addresses in the same ESGH 670 PDU. The only restrictions placed on providing multiple group Net- 671 work addresses within the same ESGH PDU are that all packets 672 requested are to be received on the same subnet, with the same hold- 673 ing time and that the ESGH PDU be of length equal to or less that its 674 maximum packet size constraint. Note each group Network address in 675 the ESGH PDU is paired with its own SNPA (subnetwork point of attach- 676 ment) address. 678 An ES will always have an SNPA address associated with each of its 679 active group Network addresses. An SNPA address is a subnetwork 680 address, in the case of a subnetwork which uses IEEE 802 addresses 681 the SNPA address is a 48 bit IEEE 802 MAC (media access control) 682 address. Of particular interest is the address used to mark the des- 683 tination group. For a subnetwork using IEEE 802 addressing a group 684 SNPA address uses a particular bit position to "mark" group SNPA 685 addresses. 687 Upon initialization the ES may have static SNPA address associations 688 (Pre-configured SNPA addresses). For any group Network address 689 without a Pre-configured SNPA address that the ES wishes to receive, 690 the ES will associate the "All Multicast Capable End Systems" SNPA 691 address. Upon receiving a Multicast Address Mapping (MAM) PDU con- 692 taining a group Network address that the ES is announcing, the ES 693 will use the SNPA address pairing contained in the MAM PDU for that 694 group Network address. Upon the expiration of the Mapping Holding 695 Timer, the ES shall revert back to associating either the Pre- 696 configured SNPA address if one exists or the "All Multicast Capable 697 End Systems" SNPA address for the specific group Network address. 699 While an ES is permitted to listen in on other ESs announcements 700 (needed for the damping option), an ES is not permitted to change its 701 group Network address to SNPA address mapping based on the announce- 702 ment of other ESs. 704 Optionally, the ES may perform damping (resetting a Multicast 705 Announcement Timer corresponding to a particular group Network 706 address) if the conditions necessary to withhold a particular 707 announcement are met. In order to perform damping the following con- 708 ditions must be met: (1)The ES must be processing other ES's 709 announcements; (2)An ESGH PDU is received that identifies the exact 710 same group Network address and SNPA address pairing on a particular 711 subnetwork that this ES is announcing on; (3) The Multicast Holding 712 Timer parameter value in the ESGH PDU received is equal to or greater 713 than the Multicast Holding Timer value, for this subnetwork, that is 714 being used by the ES processing this ESGH PDU. 716 ESs will utilize a local default value for their Multicast Announce- 717 ment Timer to control the period for sending out their ESGH PDUs. The 718 Active Multicast IS, if one exists on a particular subnetwork, may 719 suggest a value for ESs on the subnetwork to use for their Multicast 720 Announcement Timer for a specific group Network address. In order to 721 support the optional damping function, ESs are required to incor- 722 porate a 25% jittering to the timer values that they are using. 724 6.1.2 Operation of ESs originating multicast PDUs 726 The ES originating multicast packets identified by a specific group 727 Network address is not required to be a receiver of such packets (and 728 thus is not announcing that particular group Network address). The 729 origination of multicast PDUs involves two differences to the origi- 730 nation of unicast PDUs. The two differences are: (1)The mechanism 731 for selecting a destination SNPA address and (2)For End Systems 732 attached to more than one subnet, the decision on which subnet(s) to 733 originate the PDUs. 735 The destination SNPA address used for originating each multicast 736 packet depends on whether there is a multicast capable IS attached to 737 the subnetworks. When a multicast capabale IS is attached, the deci- 738 sion depends on whether there is multicast address mapping informa- 739 tion corresponding to the group Network address used as the destina- 740 tion address parameter of the multicast packet available for that 741 subnetwork. When there is a multicast capable IS attached to a sub- 742 network and there is multicast address mapping information available 743 corresponding to the group Network address, then the SNPA address 744 obtained from the multicast address mapping information is used. Ori- 745 ginating multicast packets using the destination SNPA address used 746 for receiving such multicast packets ensures that the multicast pack- 747 ets will not require additional forwarding on the originating 748 subnetwork(s). When there is a multicast capable IS attached to a 749 subnetwork but for which there is no multicast address mapping infor- 750 mation available corresponding to the the group Network address, then 751 the SNPA address used is the "All Multicast Capable Intermediate Sys- 752 tems" address. 754 When there is no multicast capable IS attached to a subnetwork then 755 the ES originating a multicast PDU uses pre-configured information if 756 it is available or the "All Multicast Capable End Systems" SNPA 757 address when no pre-configured information is available. 759 ES's attached to more than one subnetwork forward each multicast 760 packet that they originate onto every attached subnetwork for which 761 the NSAP address being used as the source address of the multicast 762 packet is actively being reported through the unicast ES-IS Report 763 Configuration function. 765 6.1.3 Operation of the Active Multicast IS 767 The Active Multicast IS listens in on all ESGH PDUs originated on the 768 subnetwork for which it is serving as the Active Multicast IS. All 769 subnetworks are handled independently (even if multiple subnetworks 770 have the same ESs attached and the IS is serving as the Active Multi- 771 cast IS for these subnetworks). 773 The Active Multicast IS originates MAM PDUs, for all group Network 774 addresses for which it has received ESGH PDUs, on the subnetwork due 775 to the following operational conditions: 777 1) The IS initializes either as the Active Multicast IS after an 778 election with other multicast capable ISs or initializes believ- 779 ing it is the only multicast capable IS; 781 Note: The determination of such conditions is outside of the scope of 782 this specification; 784 2) The IS receives an ESGH PDU with a group Network address paired 785 to an incorrect SNPA address; 787 3) The expiration of the IS's Multicast Address Mapping Timer for 788 that group Network address; or 790 Note: This is to prevent the expiration of Mapping Holding Timers in 791 ESs. 793 4) The IS receives a multicast PDU originated on the subnetwork 794 which used an incorrect destination SNPA address. 796 Note: Of particular concern are those multicast packets using the 797 "All Multicast Capable Intermediate Systems" SNPA address when 798 another SNPA address should have been used. In addition the multi- 799 cast capable ISs are responsible for listening in on all multicast 800 packets using destination SNPA addresses that are contained within 801 the current multicast address mapping information. 803 As a result of the event driven conditions (i.e. conditions 2 or 4 804 above), the Active Multicast IS sends a MAM PDU with direct informa- 805 tion (i.e. not needing analysis of the Mask parameters). The Active 806 Multicast IS limits the number of MAM PDUs that are sent out per unit 807 of time. Particular MAM PDUs with direct information will not be 808 sent more than once per second. MAM PDU will be sent in response to 809 continuing event driven conditions such that events occurring greater 810 than 10 seconds after the issuance of such a MAM PDU will result in 811 the issuance of another MAM PDU. . 813 The Active Multicast IS is responsible for forwarding a multicast 814 packet back on the subnetwork it was originated when a multicast 815 packet used the "All Multicast Capable Intermediate System" SNPA 816 address when another SNPA address should have been used. A packet 817 forwarded back onto the subnetwork the multicast packet was ori- 818 ginated on will be given a CLNP Lifetime of "1" to prevent the con- 819 tinued relaying of duplicate packets by the multicast ISs. 821 The further relaying of any multicast packet originated on a subnet- 822 work is the responsibility of the multicast routing protocol used and 823 is outside the scope of this specification. 825 6.2 Definitions 827 Active Multicast IS: The one multicast capable IS selected (via means 828 outside of this specification) to originate Multicast Address Mapping 829 information on a particular subnetwork. 831 Paired SNPA Address: The SNPA address associated with a particular 832 group Network address on a specific subnetwork. 834 6.3 Routing information supporting multicast transmission 836 6.3.1 Multicast Announcement Information 838 An IS should forward a multicast PDU containing a particular destina- 839 tion group Network address onto a subnetwork to which it is attached 840 if and only if one or more of the ESs attached to that subnetwork 841 have declared an interest in receiving multicast PDUs destined for 842 that group Network address. Multicast announcement information 843 enables an IS that supports CLNP multicast to dynamically discover, 844 for each subnetwork to which it is attached, the group Network 845 addresses for which ESs attached to that subnetwork have declared an 846 interest. 848 On a point-to-point subnetwork the multicast announcement information 849 informs the Network entity, in the case where it is attached to an 850 End System, of the group Network addresses for which that End System 851 expects to receive multicast PDUs. 853 On a broadcast subnetwork the multicast announcement information 854 informs the multicast capable Intermediate Systems, of the group Net- 855 work addresses for which ESs attached to that subnetwork expect to 856 receive multicast PDUs. 858 Note: Intermediate Systems with the optional OSI multicast capabili- 859 ties do receive information identifying the SNPA address of ESs on 860 the broadcast network that want PDUs with particular group Network 861 addresses as their destination address; however, the critical 862 information is which multicast PDUs are needed, not which ESs need 863 them. 865 6.3.2 Multicast Address Mapping Information 867 In order to receive multicast packets destined for a particular group 868 Network address, an ES may need to associate with the group Network 869 address a specific SNPA address. Multicast address mapping informa- 870 tion enables an IS to inform ESs that they can receive multicast 871 packets destined for a particular group Network address on a 872 corresponding specific SNPA address. In addition, multicast address 873 mapping information may provide the specific destination SNPA 874 addresses needed by an ES for originating multicast packets. 876 Multicast address mapping information is not employed on point-to- 877 point subnetworks. 879 Multicast address mapping information is employed on broadcast sub- 880 networks to enable multicast capable Intermediate Systems to inform 881 the multicast capable End Systems that they can receive, on a 882 specific broadcast subnetwork, multicast packets destined for a par- 883 ticular group Network address on a corresponding specific SNPA 884 address. In addition multicast address mapping information provides 885 the specific destination SNPA address, that corresponds to a particu- 886 lar group Network address, for each multicast packet that it ori- 887 ginates on a specific broadcast subnetwork. 889 6.4 Addresses 891 All exchanges using this protocol are accomplished over a single sub- 892 network. While the control PDU's contain Network addresses (i.e. 893 group Network addresses) actual control PDU transfer is accomplished 894 via Subnetwork based group addresses (i.e. group SNPA addresses). The 895 following group SNPA addresses are used: (1)All Multicast Capable End 896 Systems; (2)All Multicast Announcements; (3)All Multicast Capable 897 Intermediate Systems and (4)a group SNPA address corresponding to a 898 group Network address 900 6.5 Timers 902 Two additional timers are employed: (1)the Multicast Announcement 903 Timer (MAT) and (2)Multicast Address Mapping Timer (MAMT). Old multi- 904 cast announcement or multicast address mapping information shall be 905 discarded after the Holding Timer expires to ensure the correct 906 operation of the protocol. 908 6.5.1 Multicast Announcement Timer 910 The Multicast Announcement Timer is a local timer (i.e. maintained 911 independently by each End System, one timer per group Network 912 address) which assists in performing the Report Multicast Announce- 913 ment function. The timer determines how often an End System reports 914 its desire to receive multicast PDUs with that group Network address 915 as its destination address parameter. Considerations in setting this 916 timer are similar to those described for the Configuration timer in 917 the ES-IS specification. 919 6.5.2 Multicast Address Mapping Timer 921 The Multicast Address Mapping Timer is a local timer (i.e. maintained 922 independently by an Intermediate System which is actively participat- 923 ing with End Systems to transfer multicast PDUs) which assists in 924 performing the Report Multicast Address Mapping function. The timer 925 determines how often an Intermediate System, actively participating 926 with End Systems for the transfer of multicast PDUs, reports the Mul- 927 ticast Address Mapping for a particular group Network address. The 928 shorter the Multicast Address Mapping Timer, the more quickly End 929 Systems on the subnetwork will become aware of the correct address 930 mapping which may change due to the Intermediate System becoming 931 available or unavailable. There is a trade off between increased 932 responsiveness and increased use of resources in the subnetwork and 933 in the End Systems. 935 6.6 Extensions to the current protocol functions 937 In order to support multicast transmissions the following optional 938 ES-IS protocol functions will be implemented: 940 6.6.1 Report Configuration by Intermediate Systems 942 All multicast capable Intermediate Systems on a subnetwork will use 943 the Multicast Capable option in all ISH PDUs that they originate. 944 This will provide multicast capable End Systems with a way to deter- 945 mine that a multicast capable Intermediate System is operating on a 946 particular subnetwork. 948 6.6.2 Query Configuration 950 Note: The Query Configuration function cannot be performed to find 951 the corresponding SNPA address of a group Network address since the 952 addressing information needed is the corresponding group SNPA address 953 and not the SNPA address of a particular End System responding. On a 954 large broadcast subnetwork, many different Configuration Responses 955 could result each incorporating a different End System Address. While 956 it is possible to design a Query Configuration for use with multi- 957 cast, this function does not appear to be required given the use of 958 the "All Multicast Capable End Systems" address for supplying a SNPA 959 address when the group SNPA address is not known. 961 6.7 Multicast Announcement 963 6.7.1 Report Multicast Announcement Function by End Systems 965 An End System which needs to receive or continue to receive any mul- 966 ticast PDUs (i.e. PDUs with group Network addresses as their destina- 967 tion address), constructs and transmits ESGH PDUs to inform multicast 968 capable Intermediate Systems of the set of group Network address des- 969 tinations for which it wishes to receive PDUs. This may be done by 970 constructing ESGH PDUs for each group Network address. Alternatively, 971 ESGH PDUs may be constructed which convey information about more than 972 one group Network address at a time, up to the limits imposed by the 973 permitted SNSDU size and the maximum header size of the ESGH PDU. 974 Each ESGH PDU is transmitted by issuing an SN-UNITDATA.Request with 975 the following parameters: 977 SN_Userdata (SNSDU) <- ESGH PDU 979 SN_Destination _Address <- multi-destination address that indicates 980 "All Multicast Announcements" 982 If an End System is attached to more than one subnetwork, the infor- 983 mation about each group Network address desired for receiving on a 984 particular subnetwork serving the End System shall be transmitted via 985 that subnetwork. It is permissible for an End System to report group 986 Network addresses on multiple subnetworks; however, duplicate multi- 987 cast PDUs should be anticipated. 989 The Group Address Pair parameter carries a list of Group Network 990 Addresses, each paired with its associated SNPA address. This infor- 991 mation is used by the Active Multicast IS to determine whether a Mul- 992 ticast Address Mapping PDU should be emitted to update the associa- 993 tion between Group Network Addresses and SNPA addresses. 995 The Holding Time (HT) field is set to approximately twice the ES's 996 Multicast Announcement Timer (MAT) parameter. The value shall be 997 large enough so that even if every other ESGH PDU is discarded (due 998 to lack of resources), or otherwise lost in the subnetwork, the mul- 999 ticast announcement information will still be maintained. The value 1000 should be set small enough so that Intermediate Systems resources are 1001 not needlessly consumed when the ES no longer wishes to receive PDUs 1002 destined to a group Network address. 1004 Note: -- When combining multiple group Network addresses in a single 1005 ESGH PDU, it should be realized that there is a single Holding Time 1006 parameter associated with all of these addresses. 1008 6.7.1.1 Generating Jitter on Multicast Announcement Timers 1010 The ES shall apply a 25% jitter to its Multicast Announcement Timer 1011 (MAT) parameter. When ESGH PDUs are transmitted as a result of timer 1012 expiration, there is a danger that the timers of individual systems 1013 may become synchronised. The result of this is that the traffic dis- 1014 tribution will contain peaks. Where there are a large number of syn- 1015 chronised systems, this can cause overloading of both the transmis- 1016 sion medium and the systems receiving the PDUs. In order to prevent 1017 this from occurring, all periodic timers, the expiration of which can 1018 cause the transmission of PDUs, shall have "jitter" introduced as 1019 defined in the following algorithm. 1021 CONSTANT 1023 Jitter = 25; 1024 Resolution = 100; 1026 (* The timer resolution in ms *) 1027 PROCEDURE Random(max: Integer): Integer; 1029 (* This procedure delivers a Uniformly distributed random 1030 integer R such that 0 < R