RFC 1768
Host Group Extensions for CLNP Multicasting
RFC 1768: Host Group Extensions for CLNP Multicasting 🎀
Okay bestie, let's get into it 💖 RFC 1768 is titled Host Group Extensions for CLNP Multicasting. It was written by D. Marlow from NSWC-DD and dated March 1995. It's in the Experimental category, so it's an experiment, not a standard 🧪 Its header doesn't list any RFCs it obsoletes or updates ✨
Status of This Memo 📜
So this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈 The authors want discussion and suggestions for improvement, and distribution of the memo is unlimited 💜
Abstract ✨
This memo comes from the TUBA (TCP/UDP over Bigger Addresses) working group of the IPng area, which did its work before the July 1994 decision to use SIPP-16 as the basis for IPng 🌸 The TUBA group was busy extending the Internet Protocol suite using ISO 8473 (CLNP) and its related routing protocols 🦋
So the memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use. Publishing it does not mean any IETF Working Group has accepted the ideas in it 🫶
It gives a spec for multicast extensions to CLNP that are similar to what RFC1112 gave IP. The goal is to give a host the mechanisms it needs to do multicasting in a CLNP based Internet 🌈 It covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol, and extensions to the ES-IS protocol. There's also an appendix comparing IP multicast with the CLNP multicast approach in this memo 🧚
Acknowledgments 🫶
This spec was built by a bunch of people in the IETF TUBA working group, plus the ANSI X3S3.3 and ISO SC6 WG2 committees 👑 Key contributions came from Steve Deering, Joel Halpern, Dave Katz and Dave Oran. Iconic team 💅
Table of Contents 🗂️
1. Introduction .......................................... 2
2. Levels of Conformance.................................. 3
3. Group Network Addresses................................ 4
4. Model of a CLNP End System Multicast Implementation.... 8
5. Extensions to the CLNP Protocol........................ 8
6. Extensions to the ES-IS Routeing Protocol ............. 15
7. Security Considerations ............................... 39
Appendix A. Differences with RFC 1112 .................... 40
Appendix B. Issues Under Study ........................... 43
References ................................................ 44
Author's Address .......................................... 451. Introduction 🌸
Okay so this memo gives a spec for multicast extensions for CLNP, so a CLNP based Internet can have the same kind of stuff RFC 1112 (Host Extensions for IP Multicasting) [RFC1112] gave IP 💖 It uses an outline that's similar to RFC 1112's, which is very on-brand for it 🎀
Paraphrasing RFC 1112 (no cap, it's a great definition 😭): CLNP multicasting means sending a CLNP datagram to a "host group." That's a set of zero or more End Systems that share a single group Network address (GNA) ✨ A multicast datagram gets delivered to all members of its destination host group with the same "best-efforts" reliability you get from regular unicast CLNP datagrams. So it is not guaranteed to arrive intact at every member, and it's not guaranteed to arrive in the same order relative to other datagrams 💀
Membership is super dynamic. End Systems can join and leave groups at any time 🦋 There's no restriction on where members are or how many there are. An End System can be in more than one group at once, and it doesn't have to be a member of a group to send datagrams to it 💅
A host group can be permanent or transient. A permanent group has an administratively assigned GNA. The address is what stays permanent, not the membership. At any moment a permanent group can have any number of members, even zero 🌈
Internetwork forwarding of CLNP multicast datagrams is handled by "multicast capable" Intermediate Systems, which can sit alongside unicast capable Intermediate Systems 🧚
Now the extensions themselves. The multicast extensions to the CLNP addressing structure define group Network addresses, which identify host groups ✨ The multicast extensions to CLNP give a way to identify a CLNP packet, and they provide scope control mechanisms for CLNP multicast packets 🔥 The multicast extensions to the ES-IS protocol give hosts the mechanisms they need to swap control info with multicast capable routers. A host can "announce" which multicast packets it's interested in, and a multicast capable router can dynamically "map" group Network addresses to subnetwork addresses 🫶
This memo specifies the extensions an End System needs to use CLNP multicast. It also specifies what multicast capable Intermediate Systems have to do to exchange info with multicast capable End Systems 👑 It does not specify anything about the info exchanges between Intermediate Systems that support multicast route selection or multicast Protocol Data Unit (PDU) forwarding. Steve Deering wrote up a discussion of multicast route selection and PDU forwarding [Deering91] 💜
Heads up bestie ⚠️ For these multicast extensions to work, there must exist an uninterrupted path of multicast capable routers between the End Systems that make up a host group. Those paths may use tunneling, meaning unicast CLNP encapsulated paths between multicast capable CLNP routers 🌸
To support multicast route selection and forwarding in a CLNP based internet, more specs are needed. Those could be new protocols, extensions to the current CLNP based routing protocols, or a technique from the IETF's Inter-Domain Multicast Routing (IDMR) group 🦋 The IDMR group is looking at multicast protocols for routers that use a router's unicast routing protocols, and that approach might extend straight to CLNP routers 🧚
Lots of the techniques and assumptions from IP multicasting (as discussed in RFC 1112) carry over to CLNP multicasting, but there are some differences. Appendix A covers them 💅 This memo also brings in techniques straight from ISO projects that added multicast transmission capabilities to CLNP [MULT-AMDS] 🌈
2. Levels of Conformance 🎀
There are three levels of conformance for End Systems to this spec 💖
Level 0: no support for CLNP multicasting.
So there is no requirement for a CLNP End System (or Intermediate System) to support CLNP multicasting 🙈 Level 0 hosts should be unaffected by the presence of multicast activity. The destination addresses used for multicast transfers, the GNA, should not be enabled by a non-multicast capable End System. Also, the multicast PDUs are marked differently from unicast PDUs, so they should be quietly discarded 🫶
Level 1: support for sending but not receiving CLNP multicast PDUs.
An End System that originates multicast PDUs is required to know whether a multicast capable Intermediate System is attached to the subnetwork(s) it originates multicast PDUs on. That's so it can work out the destination SNPA (subnet) address 🔥 A Level 1 End System is required to implement all parts of this specification except for those that support only Multicast Announcement. And it is not required to know the current Multicast Address Mapping to start originating multicast PDUs ✨
Note: A End System that doesn't implement Multicast Address Mapping can still successfully originate multicast PDUs, but only if it knows a multicast capable Intermediate System exists. That can lead to inefficient subnetwork use 💀 So when an End System continues (or may continue) to originate multicast PDUs for the same group, implementations are to provide Multicast Address Mapping support 🧚
Level 2: full support for CLNP multicasting.
Level 2 lets a host join and leave host groups, and also send CLNP PDUs to host groups 👑 It requires the End System to implement all parts of this specification 🌈
3. Group Network Addresses 💜
Individual Network addresses used by CLNP for End System addressing are called Network Service Access Points (NSAPs). RFC 1237 defines the NSAP address for use in the Internet 🌸 To give an address to a group of End Systems, this spec doesn't change the NSAP address definition. Instead it adds a new kind of identifier, the group Network address, which supports a multicast Network service 🦋 That's a service between one source NSAP (identified by an individual Network address) and a group of destination NSAPs (identified by a group Network address). Host groups are identified by group Network addresses ✨
Here's where it gets good. While they were building the multicast address extensions to CLNP, they had three requirements 🔥 One: "easily distinguishing" group addresses at the Network layer from NSAP addresses. Two: leaving the currently allocated address families unaffected. Three: making sure the approach wouldn't need new addressing authorities to be set up 🫶 They also agreed that offering multicast options to all OSI Network layer users was desirable, so the group Network addressing solution should support options for every address format covered by ISO/IEC 8348 | CCITT Recommendation X.213 💅 The only viable way they found to meet all of that was to create a new set of AFI values, with a fixed one-to-one mapping between each existing AFI value and a matching group AFI value 👑
So group Network addresses are defined by creating a new set of AFI values. There's one for each existing AFI value, plus that fixed one-to-one mapping between the existing AFI values and their matching group AFI values 🌈 The syntax of a group Network address is identical to the syntax of an individual Network address. The only difference is which AFI values are allowed. An individual Network address can only use the AFI values already allocated for individual Network addresses, while a group Network address can only use the AFI values allocated for group Network addresses 🧚 The group AFI values were chosen so they don't overlap with any AFI values already allocated for individual Network addresses, in the preferred encoding defined by ISO/IEC 8348 | CCITT Recommendation X.213 🎀
3.1. Definitions 📖
Here are the key definitions, bestie 💖
- group Network address: an address that identifies a set of zero or more Network service access points; these may belong to multiple Network entities, in different End Systems. 💜
- individual Network address: an address that identifies a single NSAP. 🦋
3.2. CLNP Addresses 🌸
(Part 1 ends here, so keep an eye out for part 2 🧚✨)
Okay so the CLNP address format is explained in RFC 1237, bestie, go read it if you're curious 🧚. Every CLNP address is split into two halves: the Initial Domain Part (IDP) and the Domain Specific Part (DSP). The first two octets of the IDP are the Authority and Format Identifier (AFI) field 💅. The AFI is written as two hexadecimal digits, anywhere from 00 to FF. It tells you who's in charge of handing out the address, what format the address is in, and whether it's an individual Network address or a group Network address 🦋. There are 90 AFI values for individual Network address allocations. And if the AFI starts with the value "0", that's an escape code meaning the field holds an incomplete individual Network address 🙈.
Table 1 gives 90 AFI values to group Network address allocations. If the first two digits of the IDP are hexadecimal FF, that means you've got an incomplete group Network address. Group addresses can only come from the AFI values set aside for them in Table 1, no cap, that's strict 💀. When an addressing authority hands out Network addresses (or lets other authorities do it), it gives out individual and the matching group addresses together. So every block has a chunk of individual addresses AND a chunk of group addresses, and you tell them apart by which AFI values they use, as Table 1 shows 🌈.
Group Network addresses are only used as the destination address parameter of a CLNP PDU. Source Address parameters are never permitted to be group Network addresses, so don't even try it 🙅♀️.
Table 2 lists the AFI values that haven't been assigned yet, for either individual or group allocation. They might get assigned later, so keep an eye out 👀. More details on individual Network addresses (NSAP and NET, which means Network Entity Titles) live in RFC 1237, again 📖.
Note: While the format of the Initial Domain Part of a group Network address is assigned, the format for the Domain Specific Part of the group Network address is specified by an addressing authority and is out of the scope of this memo. While NSAP address assignments are typically made to support hierarchical unicast routing, a similar consideration for group Network address assignments may not exist.
TABLE 1 - Relationship of AFI Individual and Group Values
-----------------------------------------------------------
|Individual Group | Individual Group | Individual Group |
-----------------------------------------------------------
| 0x FF | | |
| 10 A0 | 40 BE | 70 DC |
| 11 A1 | 41 BF | 71 DD |
| 12 A2 | 42 C0 | 72 DE |
| 13 A3 | 43 C1 | 73 DF |
| 14 A4 | 44 C2 | 74 E0 |
| 15 A5 | 45 C3 | 75 E1 |
| 16 A6 | 46 C4 | 76 E2 |
| 17 A7 | 47 C5 | 77 E3 |
| 18 A8 | 48 C6 | 78 E4 |
| 19 A9 | 49 C7 | 79 E5 |
| 20 AA | 50 C8 | 80 E6 |
| 21 AB | 51 C9 | 81 E7 |
| 22 AC | 52 CA | 82 E8 |
| 23 AD | 53 CB | 83 E9 |
| 24 AE | 54 CC | 84 EA |
| 25 AF | 55 CD | 85 EB |
| 26 B0 | 56 CE | 86 EC |
| 27 B1 | 57 CF | 87 ED |
| 28 B2 | 58 D0 | 88 EE |
| 29 B3 | 59 D1 | 89 EF |
| 30 B4 | 60 D2 | 90 F0 |
| 31 B5 | 61 D3 | 91 F1 |
| 32 B6 | 62 D4 | 92 F2 |
| 33 B7 | 63 D5 | 93 F3 |
| 34 B8 | 64 D6 | 94 F4 |
| 35 B9 | 65 D7 | 95 F5 |
| 36 BA | 66 D8 | 96 F6 |
| 37 BB | 67 D9 | 97 F7 |
| 38 BC | 68 DA | 98 F8 |
| 39 BD | 69 DB | 99 F9 |
----------------------------------------------------------- TABLE 2 - AFI values reserved for future allocation
--------------
| 1A-1F |
| 2A-2F |
| 3A-3F |
| 4A-4F |
| 5A-5F |
| 6A-6F |
| 7A-7F |
| 8A-8F |
| 9A-9F |
| FA-FE |
--------------4. Model of a CLNP End System Multicast Implementation ✨
Multicast transmission by a CLNP End System involves extensions to two protocols: CLNP and the ES-IS Routeing Protocol. For level 0 service (no support for CLNP multicast), no extensions to these two protocols are REQUIRED. For level 1 service (support for sending but not receiving CLNP multicast PDUs), all extensions in the following sections are REQUIRED, except for those supporting only Multicast Announcement. To get level 2 service (full support for CLNP multicasting), the extensions in the following sections are REQUIRED. Extensions identified for Intermediate Systems are not REQUIRED (or appropriate) for End Systems 🖥️. Multicast transmission also needs a group Network address (as described earlier) as the destination address parameter 🎯.
5. Extensions to the CLNP protocol 🦄
This section adds extensions to the CLNP Protocol [CLNP] ISO 8473-1 to support multicast transmission. These additions define procedures for connectionless transmission of data and control information from one network-entity to one or more peer network-entities 📡.
Okay, so the big design question was how to "mark" a packet as multicast, since normal ones are unicast 🤔. Marking matters because multicast packets get forwarded differently (you might need to send multiple copies). The two options were to mark the packet with a particular field, or to mark the destination address. In the end they did BOTH 😭. A multicast PDU's destination identifies a host group, which is a totally different thing from a unicast NSAP address. Instead of messing with NSAP addresses, they made a new set called group Network addresses, marked by the first octet (the AFI field) using values reserved for group Network addresses 💜.
They also thought about not marking the PDU further, but there was a problem with relying only on the group Network address to spot multicast packets 😬. Right now, routers running the IS-IS Intra-Domain protocol as Level 1 routers are allowed to either discard a packet with an unknown destination address or send it to a Level 2 router when they get one. If non-multicast-capable routers do that with multicast packets, things get non-deterministic 🌀. Level 1 routers that receive a packet with a group Network address might pass it up to a Level 2 router (which may or may not be multicast capable), or they might discard it. Depending on the situation, whole regions could end up missing packets, or packets could get duplicated (maybe even exploding) 💥. So the fix was to get deterministic behaviour from non-multicast-capable routers by creating a new PDU type (the Multicast Data PDU) and adding "receiving a PDU of unknown type" to the CLNP reasons for discard. This discard reason is mandatory on both multicast-capable and non-multicast-capable CLNP implementations 🫶.
5.1 Definitions 📖
multicast: Data transmission to one or more destinations in a selected group in a single service invocation.
multicast capable Intermediate System: An Intermediate System which incorporates the multicast features of the Network layer.
5.2 Addresses 🏷️
The destination address parameter of a multicast PDU SHALL contain a group Network address. The source address parameter SHALL be an individual Network address 💖.
5.3 Extensions to the current protocol functions ⭐
To support multicast transmissions, the following OPTIONAL CLNP protocol functions will be implemented:
5.3.1 Header Format Analysis function 🔍
The header format analysis function optionally gives Network entities that support multicast transfer the power to hand applicable PDUs straight to End Systems they serve, as well as forward them on to other Network entities 🚀.
This optional functionality works through a Network entity with multicast capability, which identifies a PDU as using multicast transfer via the PDU type and the PDU's destination address field 🧐.
If a Network entity supports multicast transmission, the header format analysis function SHALL check that a PDU does not contain a group Network address in the source address field. Any PDU header analysed to have a group address in the source address field SHALL be discarded 🗑️. Not okay, no thanks 🙅♀️.
5.3.2 Route PDU function 🛣️
The route PDU function optionally gives Network entities that support multicast transfer the ability to figure out multiple Network entities to forward a single PDU to. This can mean multiple invocations of the forward PDU function, which means making multiple copies of the PDU 📋. For PDUs received from a different Network entity, this optional functionality comes from the header format analysis function recognising the PDU as multicast. A Network entity attached to more than one subnetwork is permitted to originate a multicast PDU on more than one subnetwork when it originates one 🌐.
Note: The ES-IS function "Extensions to the ISO CLNP Route Function by End Systems", discussed in section 6.10, identifies which subnetworks an End System attached to more than one subnetwork MUST originate multicast PDUs on.
Note: The reason for letting an originating Network entity send a multicast PDU on multiple subnetworks is to support multicast IS-IS protocols, which will need to work out which subnetworks a multicast PDU has already visited. This behaviour is based on the assumption that the Intermediate Systems in the OSI environment doing multicast forwarding form a connected set 🌸.
5.3.3. Forward PDU function ✨
okay so this one is the Forward PDU function, and it's basically the handoff 🦋 It sends an SN-UNITDATA request primitive down to the subnetwork or SNDCF that the route PDU function picked out. The payload is the protocol data unit as user data. It also brings the address info that the subnetwork or SNDCF needs to find the "next" system or systems in its own addressing domain (that could be one or more Intermediate Systems, one or more destination End Systems, or a mix), plus any quality of service constraints that should be considered while the user data is processed. main character energy 💅
5.3.4. Discard PDU function 🧚
bestie, this one just adds one more reason to discard a PDU: it was received with an unknown type code. 🙈
5.3.5. Error reporting function 🚨
this part is super important 😭 Error reporting has to be handled really carefully for multicast transfers, because the big worry is broadcast storms 🌪️ So a multicast PDU MUST NOT cause the origination of another multicast PDU. That's the main reason a source address is not allowed to be a group address. Also, if error reporting is allowed on a multicast PDU, it can flood the source network-entity (and the networks it goes through) with Error Report PDUs. yikes 💀
Error reports are allowed on multicast PDUs, but a PDU with a group Network address in its source address field SHALL NOT be responded to with an Error Report. This makes sure a multicast PDU never generates another multicast PDU. If the source address is a group address, then an error report PDU SHALL NOT be generated and the original PDU SHALL be discarded. no exceptions, periodt ✨
5.3.6. Source routing functions 🌸
no source routing for multicast PDU transfer, sorry not sorry. The NS provider SHALL NOT accept a multicast PDU that has source route parameters 🙅♀️
5.4. Scope control function 🎀
5.4.1. Overview 💜
the scope control function is an option that only applies to multicast PDU forwarding. It lets the originator limit how far the multicast PDU gets forwarded 🦋 It can limit relaying based on the individual Network addressing hierarchy, and/or limit how much multicast expansion is allowed to happen. If both kinds of scope control are applied to the same PDU, forwarding stops as soon as either one hits its limit. ✋
5.4.2. Prefix Based Scope Control 🌈
with prefix based scope control, the originator can pick a specific set of address prefixes. An Intermediate System only forwards the multicast PDU if one of those prefixes matches its NET 🗺️ Only the originator of a PDU MAY select prefix based scope control. It's done with one or more address prefixes stored in a parameter inside the options part of the PDU header. The length of that parameter is decided by the originating network entity, and it doesn't change for the whole lifetime of the PDU.
When an Intermediate System gets a multicast PDU with a prefix based scope control parameter, it only forwards if every octet of one of the prefixes in that parameter matches its NET, counting from the start of the NET. If there's no match, the Intermediate System discards the PDU. The error reporting function SHALL NOT be invoked when a PDU gets discarded like this. 🙃
5.4.3. Radius Scope Control 🦄
radius scope control lets the originator set a maximum logical distance where multicast expansion can happen. It's closely tied to the header format analysis function 🔗 Every IS that receives a multicast PDU, can expand it, and has a Radius Scope Control parameter, decrements the Radius Scope Control field by an administratively set amount, somewhere between 0 and the field's maximum value. When an IS decrements that field and the current value is less than the amount it's supposed to subtract, the IS SHALL place a value of 0 into the field. This function decides whether the PDU received MAY be forwarded, or whether its Radius has already been reached, in which case it SHALL be discarded. An Intermediate System SHALL NOT forward a multicast PDU with a Radius Scope Control parameter whose value is 0. Again, the error reporting function SHALL NOT be invoked upon PDU discard. 🫶
5.4.3.1. Radius Scope Control Example 🍓
the Radius Scope Control parameter is handy where policies have been set up across the path a PDU could take 🛣️ One possible policy for Internet use: multicast capable routers treat this field as a hop count within a domain (they decrement by one unit). For inter-domain routers, they either decrement the field down to an even multiple of 256 when crossing into domains where prior agreements exist, or they decrement it to 0 (meaning discard the packet) for any other domains. big brain energy 🧠✨
5.5. Structure and Encoding of PDUs 🌷
multicast transmission happens through Multicast Data (MD) PDUs 📦 The PDU type code for an MD PDU is "1 1 1 0 1". The MD PDU has the same format as the Data (DT) PDU. The MD and DT PDUs MAY contain the same OPTIONAL parameters, with these exceptions: (1) the source routing parameter is allowed in DT PDUs but not MD PDUs, and (2) the scope control parameter is allowed in MD PDUs but not DT PDUs. literally such a clean split 😌
5.6. Optional parameters for multicast support 💖
5.6.1. Prefix Based Scope Control 🌺
the prefix based scope control parameter lists one or more address prefixes. For these prefixes, Intermediate System forwarding requires that one of them matches the beginning of the Intermediate System's NET 🎯
Parameter Code: 1100 0100
Parameter Length: variable
Parameter Value: a concatenation of address prefix entriesthe parameter value holds an address prefix list. The list is made of variable length address prefix entries. The first octet of each entry gives the length of the address prefix in bits, and that prefix makes up the rest of the entry. If the length field doesn't add up to a whole number of octets, the prefix entry gets enough trailing zeroes to make its end land on an octet boundary. The list MUST contain at least one entry. 📝
The prefix SHALL end on a boundary that is legal in the abstract syntax of the address family it comes from. For example, a prefix whose DSP is written in decimal syntax MUST end on a semi-octet boundary, while a prefix whose DSP is written in binary syntax can end on any bit boundary. If the end of the prefix falls within the IDP, then the prefix MUST end on a semi-octet boundary and MUST NOT contain any padding characters. these rules are strict but they make sense, iykyk 🤓
Note: The length of the prefix based scope control parameter is determined by the originator of the PDU and does not change during the lifetime of the PDU. 🔒
5.6.1.1. Prefix matching 🔍
a prefix that extends into the DSP SHALL be compared directly against the encoded NET address, padding characters and all 🧩 A prefix that does NOT extend into the DSP SHALL be compared against the derived quantity NET', which you get by removing all padding characters (as defined by the binary encoding process of ISO 8348). Wait, careful: that second one is a plain statement, so I'm keeping it lowercase. The prefix that does not extend into the DSP SHALL be compared against NET', which is the NET address with all padding characters removed (as defined by the binary encoding process of ISO 8348). 🫧
The existence of a match is determined like this:
a) If the encoded NET (or NET') contains fewer bits than the prefix, then there is no match. 🙅♀️
b) If the encoded NET (or NET') contains at least as many bits as the prefix, and all bits of the prefix are identical to the corresponding leading bits of the encoded NET (or NET'), then there is a match. Otherwise, there is no match. ✅
5.6.2. Radius Scope Control 🎈
the radius scope control parameter says how far a multicast PDU can be forwarded, logical distance wise 📏
Parameter Code: 1100 0110
Parameter Length: two octets
Parameter Value: two octets which represents the remaining
distance, that the PDU can be forwarded,
in administratively set units.5.7. Provision of the Underlying Service 🌙
for a subnetwork that has multicast built in, the SNDCF handles mapping group Network addresses to the matching addressing capability of that subnetwork 🗝️
5.8. Conformance 🏅
all the extensions that add multicast support to the functions are OPTIONAL. For an End System or Intermediate System that isn't multicast capable, these extensions don't apply 🙌 An implementation that claims conformance as a multicast capable End System SHALL meet all of the requirements for an End System that isn't multicast capable, and ALSO provide all of the multicast extensions in here. An implementation that claims conformance as a multicast capable Intermediate System SHALL meet all of the requirements for an Intermediate System that isn't multicast capable, and ALSO provide all of the multicast extensions in here. ✨
6. Extensions to the ES-IS Routeing Protocol 🛰️
this section has OPTIONAL extensions to the ES-IS Routeing Protocol [ES-IS], ISO 9542, so it can transfer multicast PDUs 📡 A big goal of this spec is that ESs and ISs (some with multicast, some without) can all work fully on the same subnetworks 🫂 This spec doesn't change anything in a currently defined (aka non-multicast) ISO 9542 implementation. It only adds new OPTIONAL functionality without modifying the current stuff. There are two basic functions: multicast announcement and multicast address mapping. 💫
6.1. Overview of the protocol 🧭
6.1.1. Operation of ESs receiving multicast PDUs 📣
ESs, when they start up and then periodically after that, build End System Group Hello (ESGH) PDUs. These list, by particular group Network addresses, the multicast PDUs the ES wants to receive 🎧 The ES periodically originates (announces) these ESGH PDUs on the subnetwork where it wants to receive them. Reporting the same group Network address on multiple subnetworks MAY result in receiving duplicate PDUs 👯 ES-IS operations for requesting the same group Network address on multiple subnetworks are handled totally independently (for example, using different logical timers and so on). It's permitted for an ES to report several group Network addresses in the same ESGH PDU. The only restrictions on putting multiple group Network addresses in the same ESGH PDU are that all the packets requested must be received on the same subnet, with the same holding time, and the ESGH PDU must be of a length equal to or less than its maximum packet size constraint. 📏 Also, note that each group Network address in the ESGH PDU is paired with its own SNPA (subnetwork point of attachment) address. 🌟
An ES always has an SNPA address associated with each of its active group Network addresses 💖 An SNPA address is a subnetwork address. On a subnetwork that uses IEEE 802 addresses, the SNPA address is a 48 bit IEEE 802 MAC (media access control) address. The one we care about most is the address used to mark the destination group. For a subnetwork using IEEE 802 addressing, a group SNPA address uses a particular bit position to "mark" group SNPA addresses 🦋
When the ES first initializes, it may already have static SNPA address associations, called Pre-configured SNPA addresses ✨ For any group Network address that doesn't have a Pre-configured SNPA address but that the ES wants to receive, the ES associates the "All Multicast Capable End Systems" SNPA address 🌸 When the ES receives a Multicast Address Mapping (MAM) PDU that contains a group Network address the ES is announcing, the ES uses the SNPA address pairing contained in that MAM PDU for that group Network address 💅 When the Mapping Holding Timer expires, the ES shall go back to associating, for that specific group Network address, either its Pre-configured SNPA address (if one exists) or the "All Multicast Capable End Systems" SNPA address 🫶 An ES is allowed to listen in on other ESs' announcements (which is needed for the damping option), but it is not allowed to change its group Network address to SNPA address mapping based on what other ESs announce 🙈
Damping is optional 🎀 The ES may perform damping, which means resetting a Multicast Announcement Timer for a particular group Network address, if the conditions needed to hold back a particular announcement are met. To perform damping, all of these conditions must be met:
- The ES must be processing other ES's announcements.
- An ESGH PDU is received that identifies the exact same group Network address and SNPA address pairing on a particular subnetwork that this ES is announcing on.
- The Multicast Holding Timer parameter value in the ESGH PDU received is equal to or greater than the Multicast Holding Timer value, for this subnetwork, that is being used by the ES processing this ESGH PDU.
ESs use a local default value for their Multicast Announcement Timer to control how often they send out their ESGH PDUs ⏰ If an Active Multicast IS exists on a particular subnetwork, it may suggest a value for ESs on that subnetwork to use for their Multicast Announcement Timer for a specific group Network address 🧚 To support the optional damping function, ESs are required to add 25% jitter to the timer values they use 🌈
6.1.2. Operation of ESs originating multicast PDUs 💜
An ES that originates multicast packets for a specific group Network address is not required to be a receiver of those packets, so it is not announcing that group Network address 🦋 Originating multicast PDUs differs from originating unicast PDUs in two ways: (1) the mechanism for selecting a destination SNPA address, and (2) for End Systems attached to more than one subnet, the decision on which subnet(s) to originate the PDUs on 👑
Which destination SNPA address gets used depends on whether a multicast capable IS is attached to the subnetwork 🔥 When a multicast capable IS is attached, the choice depends on whether multicast address mapping information is available for that subnetwork for the group Network address used as the destination address parameter of the multicast packet. If a multicast capable IS is attached to a subnetwork and multicast address mapping information is available for the group Network address, then the SNPA address obtained from that mapping information is used 💖 Using the destination SNPA address that is used for receiving such multicast packets means the multicast packets won't need extra forwarding on the originating subnetwork(s) ✨ If a multicast capable IS is attached to a subnetwork but there is no multicast address mapping information for the group Network address, then the SNPA address used is the "All Multicast Capable Intermediate Systems" address 🌸
When no multicast capable IS is attached to a subnetwork, the ES originating a multicast PDU uses pre-configured information if it is available, or the "All Multicast Capable End Systems" SNPA address if no pre-configured information is available 💅
ESs attached to more than one subnetwork forward each multicast packet they originate onto every attached subnetwork for which the NSAP address being used as the source address of the multicast packet is actively being reported through the unicast ES-IS Report Configuration function 🫶
6.1.3. Operation of the Active Multicast IS 🎀
The Active Multicast IS listens in on all ESGH PDUs originated on the subnetwork it is serving as the Active Multicast IS for 👂 Every subnetwork is handled independently, even if multiple subnetworks have the same ESs attached and the IS is serving as the Active Multicast IS for those subnetworks 🌈
The Active Multicast IS originates MAM PDUs, for all group Network addresses for which it has received ESGH PDUs, on the subnetwork, because of the following operational conditions:
- The IS initializes either as the Active Multicast IS after an election with other multicast capable ISs, or it initializes believing it is the only multicast capable IS.
Note: Working out these conditions is outside the scope of this specification 🙃
- The IS receives an ESGH PDU with a group Network address paired to an incorrect SNPA address.
- The IS's Multicast Address Mapping Timer for that group Network address expires; or
Note: This is there to prevent the expiration of Mapping Holding Timers in ESs 🧸
- The IS receives a multicast PDU originated on the subnetwork which used an incorrect destination SNPA address.
Note: The big worry is multicast packets using the "All Multicast Capable Intermediate Systems" SNPA address when another SNPA address should have been used 😭 On top of that, multicast capable ISs are responsible for listening in on all multicast packets that use destination SNPA addresses contained within the current multicast address mapping information 👀
When the event-driven conditions happen (that is, conditions 2 or 4 above), the Active Multicast IS sends a MAM PDU with direct information, which means it doesn't need to analyze the Mask parameters 🍓 The Active Multicast IS also limits how many MAM PDUs it sends per unit of time. MAM PDUs with direct information won't be sent more than once per second ⭐ For continuing event-driven conditions, a MAM PDU is sent again whenever an event occurs more than 10 seconds after the last such MAM PDU was issued 💜
The Active Multicast IS is responsible for forwarding a multicast packet back onto the subnetwork it was originated on when that packet used the "All Multicast Capable Intermediate System" SNPA address and another SNPA address should have been used 🔁 A packet forwarded back onto the subnetwork it was originated on is given a CLNP Lifetime of "1", which stops the multicast ISs from relaying duplicate packets over and over 🛑
Any further relaying of a multicast packet originated on a subnetwork is the job of the multicast routing protocol being used, and it is outside the scope of this specification 🦋
6.2. Definitions 📖
Active Multicast IS: The one multicast capable IS selected (through means outside of this specification) to originate Multicast Address Mapping information on a particular subnetwork 👑
Paired SNPA Address: The SNPA address associated with a particular group Network address on a specific subnetwork 🫶
6.3. Routing information supporting multicast transmission 📡
6.3.1. Multicast Announcement Information 📣
An IS should forward a multicast PDU containing a particular destination group Network address onto a subnetwork it is attached to if and only if one or more of the ESs attached to that subnetwork have declared an interest in receiving multicast PDUs destined for that group Network address 💖 Multicast announcement information lets an IS that supports CLNP multicast dynamically discover, for each subnetwork it is attached to, the group Network addresses that ESs on that subnetwork have declared an interest in ✨
On a point-to-point subnetwork, multicast announcement information tells the Network entity, when it is attached to an End System, which group Network addresses that End System expects to receive multicast PDUs for 🌸
On a broadcast subnetwork, multicast announcement information tells the multicast capable Intermediate Systems which group Network addresses the ESs attached to that subnetwork expect to receive multicast PDUs for 💅
Note: ISs with the optional OSI multicast capabilities do receive information identifying the SNPA address of ESs on the broadcast network that want PDUs with particular group Network addresses as their destination address. However, the critical information is which multicast PDUs are needed, not which ESs need them 🙈
6.3.2. Multicast Address Mapping Information 🗺️
To receive multicast packets destined for a particular group Network address, an ES may need to associate a specific SNPA address with that group Network address 🦋 Multicast address mapping information lets an IS tell ESs that they can receive multicast packets destined for a particular group Network address on a corresponding specific SNPA address 🎀 On top of that, multicast address mapping information may provide the specific destination SNPA addresses an ES needs for originating multicast packets 🌈
Multicast address mapping information is not used on point-to-point subnetworks 🚫
Multicast address mapping information is used on broadcast subnetworks so that multicast capable Intermediate Systems can tell the multicast capable End Systems that they can receive, on a specific broadcast subnetwork, multicast packets destined for a particular group Network address on a corresponding specific SNPA address 🫶 It also provides, for each multicast packet an IS originates on a specific broadcast subnetwork, the specific destination SNPA address that corresponds to that packet's group Network address 🧚
6.4. Addresses 🏠
All exchanges using this protocol happen over a single subnetwork 🌸 Control PDUs contain Network addresses (that is, group Network addresses), but the actual transfer of control PDUs is done using Subnetwork based group addresses (that is, group SNPA addresses) 💜 The following group SNPA addresses are used:
- All Multicast Capable End Systems;
- All Multicast Announcements;
- All Multicast Capable Intermediate Systems; and
- a group SNPA address corresponding to a group Network address.
6.5. Timers ⏰
Okay so, two more timers are in the mix 🦋: (1) the Multicast Announcement Timer (MAT) and (2) the Multicast Address Mapping Timer (MAMT). Old multicast announcement or multicast address mapping info SHALL be discarded once the Holding Timer expires, and that's what keeps the protocol behaving correctly 💅✨
6.5.1 Multicast Announcement Timer 🎀
This one is a local timer, which means every End System keeps its own copy, with one timer per group Network address 🫶 It's the timer behind the Report Multicast Announcement function. It decides how often an End System says "hey, I still want multicast PDUs sent to this group Network address" by putting that group Network address in its destination address parameter 📣 Considerations for setting it are similar to the ones for the Configuration timer in the ES-IS spec, so go peek there for the vibes 🌸
6.5.2 Multicast Address Mapping Timer 🧚
This timer is local too, but it's kept by an Intermediate System that's actively helping End Systems move multicast PDUs around 🛰️ It runs the Report Multicast Address Mapping function, meaning it sets how often that IS reports the Multicast Address Mapping for a particular group Network address. The shorter this timer is, the faster End Systems on the subnetwork catch on to the right address mapping, which can change when an IS becomes available or unavailable 😭 But it's a trade-off, bestie. Faster responsiveness means more resources used on the subnetwork and in the End Systems 💀
6.6 Extensions to the current protocol functions 🌈
To support multicast transmissions, the following OPTIONAL ES-IS protocol functions will be implemented:
6.6.1 Report Configuration by Intermediate Systems
Every multicast capable Intermediate System on a subnetwork SHALL use the Multicast Capable option in all ISH PDUs it originates 🍓 That gives multicast capable End Systems a way to figure out that a multicast capable IS is running on that subnetwork 👀
6.6.2 Query Configuration
Note: The Query Configuration function cannot be performed to find the corresponding SNPA address of a group Network address, because the addressing info it needs is the corresponding group SNPA address, not the SNPA address of a particular End System responding. On a large broadcast subnetwork, lots of different Configuration Responses could come back, each one carrying a different End System Address 😵 Sure, it's possible to design a Query Configuration for multicast, but this function does not appear to be required, since the "All Multicast Capable End Systems" address can supply a SNPA address whenever the group SNPA address isn't known 🙈
6.7 Multicast Announcement ✨
6.7.1 Report Multicast Announcement Function by End Systems 📢
An End System that needs to receive, or keep receiving, any multicast PDUs (so PDUs with group Network addresses as their destination address) builds and sends ESGH PDUs to tell multicast capable Intermediate Systems which group Network address destinations it wants 🔥 It can make one ESGH PDU for each group Network address, or pack info about several group Network addresses into one ESGH PDU, as long as it stays within the permitted SNSDU size and the maximum header size of the ESGH PDU 📦 Each ESGH PDU goes out by issuing an SN-UNITDATA.Request with these parameters:
SN_Userdata (SNSDU) <- ESGH PDU
SN_Destination _Address <- multi-destination address that indicates
"All Multicast Announcements"If an End System is attached to more than one subnetwork, the info about each group Network address it wants to receive on a particular subnetwork SHALL be sent through that subnetwork 🛤️ Reporting group Network addresses on multiple subnetworks is permissible, but duplicate multicast PDUs SHOULD be expected 👯
The Group Address Pair parameter carries a list of Group Network Addresses, each paired with its associated SNPA address. The Active Multicast IS uses this to figure out whether a Multicast Address Mapping PDU should be emitted to update the association between Group Network Addresses and SNPA addresses 🧠
The Holding Time (HT) field is set to approximately twice the ES's Multicast Announcement Timer (MAT) parameter. The value SHALL be large enough that even if every other ESGH PDU gets discarded (due to lack of resources), or is otherwise lost in the subnetwork, the multicast announcement info will still be maintained 🛡️ The value SHOULD be set small enough that Intermediate Systems resources aren't needlessly eaten up when the ES no longer wants PDUs destined to a group Network address 🗑️
Note: When combining multiple group Network addresses in a single ESGH PDU, it SHOULD be realized that there is a single Holding Time parameter associated with all of these addresses.
6.7.1.1 Generating Jitter on Multicast Announcement Timers 🎲
The ES SHALL apply a 25% jitter to its Multicast Announcement Timer (MAT) parameter. When ESGH PDUs go out because a timer expired, the timers of individual systems can end up synchronised, and the traffic then bunches into peaks 📈 With a large number of synchronised systems, that can overload both the transmission medium and the systems receiving the PDUs 😱 To stop that from happening, all periodic timers whose expiration can cause PDU transmission SHALL have "jitter" introduced, as defined in the following algorithm 💅
CONSTANT
Jitter = 25;
Resolution = 100;
(* The timer resolution in ms *)
PROCEDURE Random(max: Integer): Integer;
(* This procedure delivers a Uniformly distributed random
integer R such that 0 < R <max *)
PROCEDURE WaitUntil(time: Integer)
(* This procedure waits the specified number of
ms and then returns *)
PROCEDURE CurrentTime(): Integer
(* This procedure returns the current time in ms *)
PROCEDURE
DefineJitteredTimer(baseTimeValueInSeconds : Integer;
expirationAction : Procedure);
VAR
baseTimeValue, maximumTimeModifier, waitTime : Integer;
nextexpiration : Time;
BEGIN
baseTimeValue := baseTimeValueInSeconds * 1000 / Resolution;
maximumTimeModifier := baseTimeValue * Jitter / 100;
(* Compute maximum possible jitter *)
WHILE running DO
BEGIN
(*First compute next expiration time *)
randomTimeModifier := Random(maximumTimeModifier);
waitTime:= baseTimeValue - randomTimeModifier;
nextexpiration := CurrentTime() + waitTime;
(* Then perform expiration Action *)
expirationAction;
WaitUntil(nextexpiration);
END (* of Loop *)
END (* of DefineJitteredTimer *)So the call DefineJitteredTimer(HelloTime, SendHelloPDU); where HelloTime is 10 seconds will make the action SendHelloPDU run at random intervals between 7.5 and 10 seconds 🎉 The whole trick is that randomTimeModifier gets randomised inside the inner loop. Also, the new expiration time is set right when the last interval expires, not once the expiration action has finished ⏰
The time resolution SHALL be less than or equal to 100 ms. It is RECOMMENDED to be less than or equal to 10ms. The time resolution is the maximum interval than can elapse without any change in the timer's value. The periodic transmission period SHALL be random or pseudo-random in the specified range, with uniform distribution across similar implementations 🌈
Note: Applying jitter to the MAT parameter is REQUIRED in order to support the OPTIONAL Damping function. If no jitter is applied on a subnetwork where many ESs are requesting a particular multicast PDU, it's likely they'll all have the same value for their MAT, and these timers may all become synchronised. That synchronisation results in peaks in the distribution of traffic, as described above. The resulting overload of the transmission medium and the systems receiving the PDUs will negate any benefit from the Damping function (since systems may be trying to transmit their own ESGH PDUs at the moment they receive ESGH PDUs originated by other ESs with the same group Network address 💀
6.7.2 Record Multicast Announcement Function 📚
This function receives ESGH PDUs, extracts the multicast announcement info, and updates the info in its routing information base 🗂️
The receiving system is NOT REQUIRED to process any option fields in a received ESGH PDU 🙅
Note: When a system chooses to process these OPTIONAL fields, the precise actions are not specified by this International Standard. 🤷
6.7.2.1 Record Multicast Announcement Function by Intermediate Systems 🛰️
When an ESGH PDU arrives, an IS with the OPTIONAL multicast capabilities extracts the configuration info and stores the {group Network address, subnetwork} in its routing information base, replacing any other info for the same entry 🔁
The Active Multicast IS, on receiving an ESGH PDU, also extracts the Paired SNPA Address parameter for each group Network address in that PDU. If the Active Multicast IS has a mapping for a group Network address carried in the ESGH for which the paired SNPA address doesn't match, it performs the Report Multicast Address Mapping function 🧩
6.7.2.2 Optional Damping Function 🦋
An ES with the OPTIONAL capabilities to support multicast transfer MAY decide to process ESGH PDUs multicast by other End Systems. There's potentially some reduction in network traffic by doing this. An ES requesting to receive multicast PDUs is permitted to reset its Multicast Announcement Timer corresponding to one group Network address on one subnetwork, upon receiving an ESGH PDU from another ES, under the following circumstances:
- a) The {group Network address, paired SNPA address} received on a particular subnetwork matches that of the ES processing the ESGH PDU for that subnetwork.
- b) The Holding Timer parameter value in the ESGH PDU received is equal to or greater than the Holding Timer value for the, group Network address, being used by the ES processing this PDU.
6.7.3 Flush Old Multicast Announcement Function 🧹
This function runs to remove multicast announcement entries from its routing information base whose Holding Timer has expired. When the Holding Timer for a group Network address expires, it removes the matching entry from the local IS's routing information base for the corresponding subnetwork 🫧
6.8 Multicast Address Mapping 💜
6.8.1 Report Multicast Address Mapping Function by Intermediate Systems ✨
okay bestie, so the Active Multicast IS is the one building MAM PDUs 🎀 for a group Network address it learned about through the Record Multicast Announcement function. It sends them out when any of these things happen:
a) the IS starts up, either as the Active Multicast IS after an election with other multicast capable ISs, or after figuring out it's the only multicast capable IS (how those conditions get figured out is outside the scope of this standard) 🌸
b) the IS gets an ESGH PDU where a group Network address is paired with an SNPA address that's different from the one in the Active Multicast IS's multicast address mapping info for that group Network address, or
Note: The Active Multicast IS decides which mappings are correct. Pre-configured mappings used before the Active Multicast IS initializes might get marked as incorrect by it 🙈
c) the IS's Multicast Address Mapping Timer for that group Network address expires 💅
Note: This is so the Holding Timers in ESs don't expire 🫶
d) the IS gets a multicast PDU from its subnetwork that used the wrong destination SNPA address 😭
Note: The big worry here is multicast packets using the "All Multicast Capable Intermediate Systems" SNPA address when a different SNPA address should have been used 💀 When that happens, the Originating Subnetwork Forwarding function runs (see section 6.11) ✨
Note: Multicast capable ISs need to receive multicast packets on every SNPA address in the current multicast address mapping info for the subnetwork 🦋 They are not required to receive multicast packets on any other SNPA addresses, except the "All Multicast Capable Intermediate Systems" SNPA address 💜
Events b) and d) are the event driven conditions that make the Active Multicast IS build and send a MAM PDU. The Active Multicast IS shall limit how many MAM PDUs it sends per unit of time. MAM PDUs with identical info shall not be sent more than once per second. Event conditions that show up 10 seconds after the last MAM PDU was sent shall lead to another MAM PDU being sent 🍓
The IS acting as the Active Multicast Intermediate System may build one MAM PDU per group Network address. Or it can build MAM PDUs that carry info about more than one group Network address at once, as long as it stays within the SNSDU size limit and the maximum header size of the MAM PDU 🧚 The IS does all of its multicast address mapping work separately for each subnetwork, even if it's the Active Multicast IS on several subnetworks 🌈 Every MAM PDU gets sent by issuing an SN-UNITDATA.Request with these parameters:
SN_Userdata (SNSDU) <- MAM PDU
SN_Destination _Address <- multi-destination address that indicates
"All Multicast Capable End Systems"The Holding Time (HT) field is set to about twice the Intermediate System's Multicast Address Mapping Timer (MAMT) parameter. This value shall be big enough that even if every other MAM PDU for a particular group Network address gets thrown away (because of a lack of resources) or otherwise lost in the subnetwork, the multicast address mapping info still sticks around 💖 It should be small enough that End Systems quickly stop using mappings from ISs that have failed 👑
Note: -- The Holding Timer parameter value applies to every group Network address called out in the MAM PDU.
The Group Address Pair parameter is how the association between Group Network Addresses and SNPA addresses gets communicated 🎀
The Active Multicast IS can optionally add info to the MAM PDU saying that the same multicast address mapping info applies to a bigger population of group Network addresses. There are two optional fields for this: the Group Network Address Mask option and the Paired SNPA Address Mask option 🔥
There are three permitted ways to include or leave out the masks. In the first, both masks are absent. Then the MAM PDU only talks about one set of enumerated group Network addresses ✨
Note: -- Multiple group address pairs can be in a single MAM PDU.
In the second, the MAM PDU has a Group Network Address Mask but no Paired SNPA Address Mask. Then the MAM PDU describes an equivalence class of group Network addresses, and it shows that several group Network addresses map to the same SNPA address 🦋
In the third, the MAM PDU has both masks. Like the second case, it describes an equivalence class of group Network addresses, but here it reveals that the SNPA addresses for that class are embedded inside the group Network addresses themselves 🧚 The Paired SNPA Address Mask shows where the SNPA address sits inside the group Network Address(es) 💜
When an event driven condition happens, the Active Multicast IS shall build a MAM PDU that has direct info, so nobody needs to analyse the Mask parameters. The Active Multicast IS may add more info to that MAM PDU through Mask parameters 💅
An IS can suggest a value for End Systems on its local subnetwork to use as their Multicast Announcement Timers for a specific group Network address by including the Suggested ES Multicast Announcement Timer (ESMAT) parameter in the MAM PDU it sends 🌸 Setting this lets the Active Multicast IS influence how often ESs send ESGH PDUs, which is so iconic 🙌
Note: If the ESMAT parameter is used, the single value allowed in the MAM PDU is suggested for every group Network address called out in that MAM PDU.
6.8.2 Record Multicast Address Mapping Function by End Systems 🦋
The Record Multicast Address Mapping function takes in MAM PDUs, pulls out the multicast address mapping info, and updates the info in its routing information base. The receiving system is not required to process any option fields in a received MAM PDU, except for the Suggested ES Multicast Announcement Timer (ESMAT) parameter 💖
Note: When a system chooses to process these optional fields, this International Standard doesn't specify the exact actions 🤷♀️
When a MAM PDU arrives, an ES with the optional multicast capabilities pulls out the multicast address mapping info and stores the {group Network address, paired SNPA address} for a particular subnetwork in its routing information base. It replaces any other info for the same group Network address and subnetwork 🎀
On top of that, an ES shall set its Multicast Announcement Timer, for the group Network address it's running the Record Multicast Address Mapping function for, based on getting a MAM PDU for that group Network address that contains an ESMAT parameter ✨
Note: An ES can process ESGH PDUs multicast by other ESs to support the optional Damping function, but it is not permitted to change its own mapping because of the mapping it finds in other ES's ESGH PDUs 🙅♀️
6.8.3 Flush Old Multicast Address Mapping Function by End Systems 🧹
The Flush Old Multicast Address Mapping function runs to remove multicast address mapping entries from its routing information base whose Holding Timer has expired 🥀 When a Holding Timer for a multicast address mapping expires, this function removes the matching entry from its routing information base for the corresponding SNPA 💅
6.9 Paired SNPA Address Selection Function by End Systems 💜
An End System shall pair each group Network address with an associated SNPA address so it can support receiving (for example, performing the Report Multicast Announcement function) and originating multicast PDUs 🌈
6.9.1 Paired SNPA Address Selection for Receiving Multicast PDUs 🫶
An End System always has a paired SNPA address for every active group Network address on a particular subnetwork. It gets that mapping by:
a) recording a multicast address mapping that's still maintaining an active holding timer, or, if no dynamic info has been received, by
b) having pre-configured multicast address mapping info, or, if neither dynamic nor pre-configured info is available, by
c) mapping the "All Multicast Capable End Systems" multi-destination address to the group Network address 👑
6.9.2 Paired SNPA Address Selection for Originating Multicast PDUs ✨
okay so this one is about an End System (ES) that's about to send a multicast PDU 📤 It has to pair up an SNPA address with the group Network address, and it figures that out in a few steps 💅
a) If there is a multicast capable IS reachable on the subnetwork, then the SNPA address an End System uses when originating a multicast PDU is either the paired SNPA address from the multicast address mapping information tied to the group Network address in the multicast PDU's Destination address parameter, or, if there's no valid entry for that group Network address, the one from the "All Multicast Capable Intermediate Systems" multi-destination address. If there's no multicast capable Intermediate System on the subnetwork at all, it goes by
Note: Multicast address mapping information is valid if the Holding Timer associated with it has not expired.
Quick bestie reminder 🫶 the info is only valid if the Holding Timer hasn't run out. Expired info is a no-go, so it MUST NOT be used.
Note: An ES can determine if a multicast capable IS is reachable on the subnetwork by having for that subnetwork either (1) multicast address mapping information or (2) routing information received via an ISH PDU containing a Multicast Capable optional parameter. In either case the information MUST be valid (i.e., the Holding Timer for the information MUST NOT have expired).
So an ES can tell a multicast capable IS is around if it has either the mapping info OR routing info from an ISH PDU with the Multicast Capable parameter. Either way that info MUST be valid, meaning the Holding Timer hasn't expired. Not optional, babe 💀
b) having pre-configured multicast address mapping information, or if neither a multicast capable Intermediate System is present on the subnetwork nor pre-configured information is available, by
c) mapping the "All Multicast Capable End Systems" multi-destination address to the group Network address.
Ngl this is giving "choose your fallback" energy 🌈 Try the IS route first, then pre-configured info, then the "All Multicast Capable End Systems" address as the last resort 🧚
6.10 Extensions to the ISO CLNP Route Function by End Systems 🛣️
okay this section is about an End System that's plugged into more than one subnetwork 🌸 When it originates a multicast PDU, it has to decide whether to forward that PDU to more than one subnetwork or not. The ES SHALL originate each multicast PDU on all subnetworks where the ISO ES-IS Configuration function is actively reporting the NSAP address in the multicast PDU's Source Address parameter. Because of this, a single ES originating a multicast PDU can end up invoking the ISO CLNP Forwarding function multiple times 🔥
6.11 Originating Subnetwork Forwarding Function by Intermediate Systems 🔁
this is the rescue mission 🦸♀️ The Active Multicast IS gets a multicast PDU that was originated on a subnetwork using the "All Multicast Capable Intermediate Systems" SNPA address, when a different SNPA address should have been used. Then it runs the Originating Subnetwork Forwarding function. The multicast address mapping information is what defines the correct SNPA address pairings for a given subnetwork 💖
That function forwards the multicast PDU back out on the subnetwork it was originated on. If the ES was attached to more than one subnetwork and originated the PDU on several of them, then each subnetwork's Active Multicast IS runs the Originating Subnetwork Forwarding function for the subnetwork it's responsible for 👑
The Active Multicast IS builds the contents for this function from the multicast PDU that came in with the incorrect destination SNPA address. It replaces the original PDU Lifetime field with the value one (0000 0001). Then it performs the ISO 8473 PDU Composition function and forwards the PDU to the subnetwork it was originated on, using the ISO 8473 Forwarding function with the correct destination SNPA address ✨
Note: The PDU Lifetime field is set to "one" to ensure that ISs attached to the originating subnetwork do not forward this PDU on. Such ISs should have received the PDU when it was originated since this function is only performed in the event of receiving a multicast PDU incorrectly addressed to the "All Multicast Capable Intermediate Systems" SNPA address.
6.12 Structure and Encoding of PDUs 🧩
the ES-IS multicast control functions run on the exchange of ESGH and MAM PDUs 📦 The one exception is a brand new optional parameter, the Multicast Capable parameter, which goes inside the ISH PDU. Yay for a little plot twist 🎀
6.12.1 PDU Type Codes 🔢
Multicast Announcement happens through the transfer of End System Group Hello (ESGH) PDUs, and their PDU type code is "0 0 1 0 1". Multicast Address Mapping (MAM) happens through the transfer of Multicast Address Mapping PDUs, and their PDU type code is "0 0 1 1 1" 💜
6.12.2 Hold Time field ⏳
The Holding Time field says the maximum amount of time the receiving Network entity can keep the multicast announcement or multicast address mapping information contained in the PDU. Time's ticking, bestie ⏰
6.12.3 Structure of Addressing Parameters 🏷️
ESGH and MAM PDUs carry one or more group Network addresses (GNAs), and each one comes with its own Paired SNPA Address (PSA) 🦋
6.12.4 Group Address Pair Parameter for ESGH and MAM PDUs 💕
The Group Address Pair parameter is a list of one or more group Network addresses, each with its own associated Paired SNPA address. The group Network address picks out specific multicast PDUs, and the Paired SNPA address is the SNPA address the ES expects to receive those multicast PDUs on for that subnetwork. Here's how it's encoded in the ESGH and MAM PDUs, as shown in Figure 1 🎨
Octet
,----------------------------------------------------,
| Number of Group Address Pairs | 10
|----------------------------------------------------|
| Group Network Address Length Indicator (GNAL) | 11
|----------------------------------------------------|
| | 12
: Group Network Address (GNA) :
| |
|----------------------------------------------------|
| Paired SNPA Address Length Indicator (PSAL) |
|----------------------------------------------------|
| |
: Paired SNPA Address (PSA) :
| |
|----------------------------------------------------|
| GNAL |
|----------------------------------------------------|
| |
: GNA :
| |
|----------------------------------------------------|
| PSAL |
|----------------------------------------------------|
| |
: PSA :
| | m-1
'----------------------------------------------------'
Figure 1 - ESGH and MAM PDUs - - Group Address Pair Parameter6.12.5 Extensions to the current Option Parameters 🎁
The Security and Priority optional parameters MAY be carried in an ESGH PDU. There is no Security or Priority option for the MAM PDU 🙈
6.12.6 Suggested ES Multicast Announcement Timer ⏲️
The ESMAT parameter MAY appear only in the MAM PDU 💅
The ESMAT parameter carries the value an IS would like the receiving ESs to use as their local Multicast Announcement Timer 🌷
Parameter Code: 1100 0111
Parameter Length: two octets
Parameter Value: ESMAT in units of seconds.6.12.7 Multicast Capable 📡
The Multicast Capable option MAY appear only in the ISH PDU 🦄
The Multicast Capable option is just a one octet code and a one octet parameter length field. There's no parameter field, so it's super minimal and iconic ✨
Parameter Code: 1100 1000
Parameter Length: zero octets
Parameter Value: none (parameter does not exist).6.12.8 Group Network Address Mask 🎭
The Group Network Address Mask option MAY only appear in the MAM PDU 🧁
The Group Network Address Mask parameter says the multicast address mapping information applies to a bigger group of group Network Addresses than the ones listed in the MAM PDU. When this option shows up in a MAM PDU, the masking relationship MUST be valid for all group Network addresses in that PDU. An End System MAY ignore this parameter 🙃
The Group Network Address Mask makes an equivalence class of group Network addresses that all share the same multicast address mapping information. To check whether a trial group Network address falls inside that class, the ES lines up the trial group Network address with the Group Network Address Mask, padding the mask with trailing zero octets if needed. If, in every bit position where the mask is "1", the trial address matches the Group Network Address field of the Group Address Pair parameter in the MAM PDU, then the trial address belongs to the equivalence class described by that MAM PDU 🔍
The Group Network Address Mask parameter has extra semantics when it's looked at together with the Paired SNPA Address Mask parameter 💫
Parameter Code: 1110 0011
Parameter Length: variable, up to 20 octets
Parameter Value: a comparison mask of octets to be
aligned with the Group Network Address
field of the Group Address Pair
parameter of the MAM PDU.6.12.9 Paired SNPA Address Mask 🪞
The Paired SNPA Address Mask option MAY only appear in the MAM PDU 🌈
When the Paired SNPA Address Mask is there, the equivalence class defined by the Group Network Address Mask also has a common structure below the Group Network Address Mask. That means the part of the group Network address where the Group Network Address Mask is logically "0". The Paired SNPA Address Mask adds extra info about that structure by marking certain bit positions in the space "below" the Group Network Address Mask. Specifically, it shows where the Paired SNPA address sits inside the Group Network Address 🧠
This parameter MAY appear in a MAM PDU only if the Group Network Address Mask is also present. When this option is included in a MAM PDU, the masking relationship MUST be valid for all group Network addresses in that PDU. An ES receiving such a MAM PDU MAY safely ignore both masks. However (since having both masks means different behaviour than having only the Group Network Address Mask) an ES SHALL NOT ignore one of the masks while heeding the other. Don't mix and match, bestie 🙅♀️
Parameter Code: 1110 0100
Parameter Length: variable
Parameter Value: a comparison mask of octets to be
aligned with the Group Network Address
field(s) of the Group Address Pair
parameter of the MAM PDU.6.12.9.1 Mask Parameters Example ✨
okay so this bit is all about showing how the Group Network Address Mask and the Paired SNPA Address Mask actually get used 💅 the examples are for CLNP multicasting over subnetworks with IEEE 802 addressing (the Internet usage, obviously 🌐). the group Network address format we're working with looks like this:
+-----+----------------------------------------+
| IDP | Upper DSP | Embedded SNPA address | SEL|
+-----+-----------+-----------------------+----+
octets: | 3 | 10 | 6 | 1 |
+-----+-----------+-----------------------+----+so the group Network address is 20 octets total 🎀 for these examples, the ONLY field we care about is the Embedded SNPA address field and where it sits inside the group Network address 👀
in the first example, "this part of the Internet" has a policy of mapping the Embedded SNPA address into the IEEE 802 address space that's reserved for group addressing using LOCAL assignment. that corresponds to all 48-bit values where the two low order bits of the first octet are set to "11" 🦋
the Active Multicast Intermediate System on this subnetwork may build a MAM PDU to map a group Network address of {13 octets, 03-00-DA-DA-DA-DA, 1 octet} to a paired SNPA address of 03-00-DA-DA-DA-DA. it can also put a Group Network Address Mask of FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-03-00-00-00-00-00-00 into that same MAM PDU 🧚
with that parameter, every group Network address that shares the identical first 13 octets AND has "11" in the two low order bits of the 14th octet gets put into one equivalence class and shares the same mapping info 🌸 if that were the only option present, all of those group Network addresses would end up with a paired SNPA address of 03-00-DA-DA-DA-DA. iconic, honestly 🫶
now, to map the group Network addresses onto the IEEE address range from this example, the MAM PDU must also contain a Paired SNPA Address Mask. the Paired SNPA Address Mask tells you where the SNPA Address lives inside the group Network addresses (the ones defined by the equivalence class formed by the Group Network Address Mask in that same PDU) 🔍 for this example, the Paired SNPA Address Mask is 00-00-00-00-00-00-00-00-00-00-00-00-00-FF-FF-FF-FF-FF-FF-00 💖
for a second example, say we want every group Network address with a specific OUI (organizationally unique identifier) in the twenty octet format above to map to its embedded SNPA address 🌈 quick refresher: an OUI is assigned by IEEE 802, it's three octets long, and it's the first three address octets of a GLOBALLY assigned IEEE 802 address ✨ for this one, the MAM PDU needs to contain:
- A group Network address contained within the MAM PDU with the OUI of interest.
- A group Network address Mask of
FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-FF-00-00-00-00. - A Paired SNPA Address of
00-00-00-00-00-00-00-00-00-00-00-00-00-FF-FF-FF-FF-FF-FF-00.
6.12.10 End System Group Hello (ESGH) PDU 🎀
okay the ESGH PDU is shaped like figure 2 below, so let's look at it together 🦋
Octet
,----------------------------------------------------,
| Network Layer Protocol Identifier | 1
|----------------------------------------------------|
| Length Indicator | 2
|----------------------------------------------------|
| Version/Protocol ID Extension | 3
|----------------------------------------------------|
| reserved (must be zero) | 4
|----------------------------------------------------|
| 0 | 0 | 0 | Type (00101 = ESGH) | 2
|----------------------------------------------------|
| Holding Time | 6,7
|----------------------------------------------------|
| Checksum | 8,9
|----------------------------------------------------|
| Number of Group Address Pairs | 10
|----------------------------------------------------|
| Group Network Address Length Indicator (GNAL) | 11
|----------------------------------------------------|
| | 12
: Group Network Address (GNA) :
| |
|----------------------------------------------------|
| Paired SNPA Address Length Indicator (PSAL) |
|----------------------------------------------------|
| |
: Paired SNPA Address (PSA) :
| |
|----------------------------------------------------|
| GNAL |
|----------------------------------------------------|
| |
: GNA |
| |
|----------------------------------------------------|
| PSAL |
|----------------------------------------------------|
| |
: PSA :
| | m-1
|----------------------------------------------------|
| | m
: Options :
| | p-1
'----------------------------------------------------'
Figure 2 - ESGH PDU Format6.12.11 Multicast Address Mapping (MAM) PDU ✨
okay so the MAM PDU has the format shown in figure 3 🎀
Octet
,----------------------------------------------------,
| Network Layer Protocol Identifier | 1
|----------------------------------------------------|
| Length Indicator | 2
|----------------------------------------------------|
| Version/Protocol ID Extension | 3
|----------------------------------------------------|
| reserved (must be zero) | 4
|----------------------------------------------------|
| 0 | 0 | 0 | Type (00111 = MAM) | 2
|----------------------------------------------------|
| Holding Time | 6,7
|----------------------------------------------------|
| Checksum | 8,9
|----------------------------------------------------|
| Number of Group Address Pairs | 10
|----------------------------------------------------|
| Group Network Address Length Indicator (GNAL) | 11
|----------------------------------------------------|
| | 12
: Group Network Address (GNA) :
| |
|----------------------------------------------------|
| Paired SNPA Address Length Indicator (PSAL) |
|----------------------------------------------------|
| |
: Paired SNPA Address (PSA) :
| |
|----------------------------------------------------|
| GNAL |
|----------------------------------------------------|
| |
: GNA :
| |
|----------------------------------------------------|
| PSAL |
|----------------------------------------------------|
| |
: PSA :
| | m-1
|----------------------------------------------------|
| | m
: Options :
| | p-1
'----------------------------------------------------'
Figure 3 - MAM PDU Format6.13 Conformance 💅
all of the extensions provided to the functions to support multicast capability are optional 🫶 for an End System or Intermediate System that is not multicast capable, these extensions are not applicable. a Network entity may choose to be multicast capable, and a multicast capable Network entity is required to support both multicast announcement information and multicast address mapping information 🌸
an implementation claiming conformance as a multicast capable End System shall meet all of the requirements for an End System which is not multicast capable, and shall support multicast announcement information and shall implement the functions marked as Mandatory (M) in column 4 of table 3. a multicast capable End System implementation shall also support multicast address mapping information and shall implement the functions marked as Mandatory (M) in column 5 of table 3 🔥
an implementation claiming conformance as a multicast capable Intermediate System shall meet all of the requirements for an Intermediate System which is not multicast capable, and shall support multicast announcement information and shall implement the functions marked as Mandatory (M) in column 6 of table 3. a multicast capable Intermediate System implementation shall also support multicast address mapping information and shall implement the functions marked as Mandatory (M) in column 7 of table 3 🦋
Table 3 - Static Conformance Requirements for Multicast Capable Network Entities 🧚
ES IS
Clause --------------
Label Function Reference AI MI AI MI
------------------------------------------------------------------
RpMAn Report Multicast Announcement 6.7.1 M - - -
RcMAn Record Multicast Announcement 6.7.2.1 - - M -
RcDamp Record Damping 6.7.2.2 O - - -
FlMAn Flush Old Multicast Announcement 6.7.3 O - M -
RpMAdMa Report Multicast Address Mapping 6.8.1 - - - M
MATGn ESMAT Generation 6.8.1 - - - M
RcMAdMa Record Multicast Address Mapping 6.8.2 - M - -
MATPr ESMAT Processing 6.8.2 - M - -
FlMAdMa Flush Old Multicast Address Map 6.8.3 - M - -
PSAdSel Paired SNPA Address Selection 6.9.1 - M - -
ExtForw Extensions to CLNP Route Function 6.10 - M - -
OSuForw Originating Subnetwork Forwarding 6.11 - - - M
Key:
AI = Multicast Announcement information supported
MI = Multicast Address Mapping information supported
M = Mandatory; O = Optional; - = not applicable7. Security Considerations 💀
Security issues are not discussed in this memo. 😭 so this one's a little quiet on the security front, bestie, so keep your guard up when you build on it! 🙈
Appendix A. Differences with RFC 1112 📚✨
Okay bestie, this appendix is the "how is CLNP multicast different from IP multicast??" explainer 🦋 It covers the differences between the CLNP Multicast mechanisms in this spec and the IP multicast ones in RFC 1112. CLNP multicast was built after IP multicast, and it was explicitly trying to bring the RFC 1112 capabilities into a CLNP context 💅 Just know this is background info only. It is not meant to justify why the mechanisms were picked 🙈
Static/Dynamic Address Binding of Multicast Datagrams
IP multicast uses a static binding of Class D IP addresses to a specific range of IEEE 802 48 bit group addresses 🔒 That range sits inside the block IEEE 802 allocates for "Global" administration. IANA controls that block, and it has allocated the block for IP multicast use. It's super simple and efficient ✨ With a 32 bit IP address, the lower 23 bits of the Class D address get mapped into the lower 23 bits of a 48 bit IEEE 802 address, and the upper 25 bits are fixed. Static binding like this is global in scope, so all members of a group use the same IEEE 802 address on all subnets (at least all the ones that use IEEE 802 addressing) 🌍
CLNP multicast uses a dynamic binding of a group Network address (up to 20 bytes) to any subnetwork address 🎀 If no multicast capable Intermediate Systems are attached to a subnetwork, the binding uses preconfigured information or the "All Multicast Capable End Systems" subnetwork addresses. The large GNA leaves room for a full 48 bit IEEE 802 address if you want one 💜 Mask capabilities are optionally provided, so a multicast capable Intermediate System can specify a "static" binding for a particular subnetwork. The whole point of dynamic binding is to tailor a host's subnetwork address usage to the capabilities of the systems attached to it 🧚 Hardware capabilities vary a lot. The number of addresses that hardware can recognise depends on the interface a system uses. For example, an Ethernet interface and an FDDI interface within the same system may have quite different capabilities 🙈 Dynamic binding like this is local in scope, so members of a group may use different subnetwork addresses (e.g., IEEE 802 addresses) on different subnets.
Originating of Multicast Datagrams
IP multicast originates multicast datagrams directly. The host that originates a datagram sends it with the group Subnetwork address as its destination, and hosts attached to the network where the datagram was originated receive it directly 📮
CLNP multicast also originates multicast datagrams directly, using the group's subnetwork address as the destination, but only when multicast address mapping information is available 🗺️ That happens when a multicast capable Intermediate System is attached to the subnetwork and a host on that subnetwork is announcing interest in multicast packets identified by a particular group Network address. The Active Multicast IS may use MAM PDU mask parameters to provide multicast address mapping information for a large number of group Network addresses 🌸 When there is no multicast address mapping information for a particular group Network address on a subnetwork that has a multicast capable IS attached, hosts originate packets using such addresses and send them to the "All Multicast Capable Intermediate Systems" SNPA address. This happens when there are no receivers of such multicast packets on the originating subnetwork. When a multicast capable Intermediate System is not attached to a subnetwork, the End System may use either preconfigured information (which might be a direct mapping from a portion of the group Network address) or the "All Multicast Capable End Systems" address 💖
Address Binding of Control Packets
IP multicast sends the control packets for the IGMP protocol on the same subnetwork address that the multicast data traffic uses 📦
CLNP multicast sends the control packets for the ES-IS protocol extensions on specific group subnetwork addresses, namely the "All Multicast Capable End Systems" and "All Multicast Announcements" addresses 📣
Router Requirements for relaying Multicast Datagrams
IP multicast requires that a multicast router run in "promiscuous" mode. It has to receive all multicast datagrams originated on a subnetwork, no matter the destination 👀 This is a result of the choices made in "Originating of Multicast Datagrams" and "Address Binding of Control Packets" above.
CLNP multicast lets a multicast router limit multicast packet reception to only the datagrams sent to SNPA addresses where there is current multicast address mapping information, or to the "All Multicast Capable Intermediate Systems" address 🛡️ The goal is to let multicast routers be in control of the SNPA addresses for the multicast packets they need to receive. This is also a result of the choices made in "Originating of Multicast Datagrams" and "Address Binding of Control Packets" above.
Aggregation of Control Information
In IP multicast, a host is required to withhold an announcement report when it hears another host reporting a similar interest in a particular Class D address on a particular subnetwork 🤐 For CLNP multicast this is an option instead, applying when interest in a particular group Network address on a particular subnetwork is heard. IP multicast reports are not combined. CLNP multicast supports providing multiple announcements (and address mappings) within a single packet 📦✨ A mask feature for address mappings lets you identify mappings for a range of group Network addresses within a single control packet 🎀
Datagram Scope Control
IP multicast supports using the IP Hop Count as a means of scope control. While it is not documented in RFC 1112, a technique is also being used that employs bits within the Class D address to identify whether a datagram has single subnetwork, "campus" or global scope 🌍
CLNP has considerable scope control functionality 🔭 The PDU Lifetime field can be used in a similar way to the IP Hop Count, but two additional options are available. Radius scope control provides a mechanism for "administratively" setting distance values, and it decouples multicast scope control from the PDU lifetime function. Even better, Prefix based scope control appears to provide considerable and flexible functionality that can adjust to situations where a known, hierarchical unicast addressing structure exists 💅
Marking of Multicast Datagrams
IP multicast marks a multicast PDU by using an IP Class D address as its destination address parameter 🏷️ CLNP multicast marks both the PDU (which is a different PDU type) and the destination address parameter (i.e., the group Network address) 💜
Unicast Addressing Differences
An IP address identifies a specific host interface, while a CLNP individual Network address (i.e., NSAP address) identifies a particular Network entity 🧠 This difference has led to a difference with RFC 1112. IP multicast requires a host that is attached to more than one subnetwork to originate a multicast packet on only one subnetwork. CLNP multicast requires a host that is attached to more than one subnetwork to originate a multicast packet on every subnetwork where the ISO ES-IS Configuration function is reporting the NSAP address contained in the source address parameter of the multicast PDU 🌈
Error Reports
Error reports sent in response to receiving a multicast PDU are not permitted in IP multicast, but they are permitted in CLNP multicast 📝
Source Routing
Source routing of multicast PDUs is permitted in IP multicast (though at the present time this is discouraged) 🙃 It is not permitted in CLNP multicast 🚫
Appendix B. Issues Under Study 🔍
This appendix records the current issues, as discussed at the March 1994 TUBA meeting 🗓️
1. Local versus Global address bindings
The extensions to the ES-IS protocol provide a multicast address mapping function that supports dynamically binding a group Network address to a subnetwork address 🔗 Some people are concerned that this is an unnecessary feature that complicates the job of network administrators without suitable benefit 😬 One suggestion is a static, global binding of group Network addresses to IEEE 802 subnetwork addresses, like the one IP multicast uses.
The two main reasons the group Network address to subnetwork (IEEE 802) address mapping was made locally configurable are these. First, to support multicast on subnets with hosts that have a mixture of capabilities, specifically how many multicast subnetwork addresses a host can register to receive at a time. Second, to support multicast on subnets that do not use 48 bit IEEE 802 addresses. So it was felt this should be done per subnetwork rather than globally 🧩 Even multi-homed hosts on subnets that use 802 addresses may have varying capabilities, looking at typical Ethernet, FDDI and 802.5 implementations.
One possible solution is to recommend a direct mapping in any Internet use of CLNP multicast on subnets that use IEEE 802 addressing 💡 This could be a default for all Internet hosts. A policy would be needed to identify the Internet's group Network address format. Given such a mapping, the only operational overhead would be that, in the presence of a mapping server (the Active Multicast IS) that supports this mapping, a MAM PDU would periodically be sent with a Group Network Address Mask that identifies the direct mapping 📬
2. "Real Time" Scope Control Features
The scope control features are provided via optional parameters. Using multicast to transfer audio and video streams may require scope control mechanisms that operate very quickly ⚡
One possible solution is to embed scope control mechanisms into the group Network address itself 🎯 For example, a group Network address using the "Local" AFI is automatically limited so that it does not cross inter-domain borders. Further, more flexible address formats may be developed 🌟
References ✨
okay bestie, here's where all the receipts live 📚🎀
[Deering91] Deering, S., "Multicast Routing in a Datagram Internetwork", PhD thesis, Electrical Engineering Dept., Stanford University, December 1991. 🧠
[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989. 🌸
[RFC1237] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC, July 1991. 🦋
[CLNP] Protocol for providing the connectionless-mode network service, International Standard 8473-1, Second Edition, ISO/IEC JTC 1, Switzerland 1994. (Available via FTP from merit.edu:pub/iso/iso8473part1.ps). 💜
[ES-IS] End system to Intermediate system routing exchange protocol for use in conjunction with the Protocol for providing the connectionless-mode network service, International Standard 9542, ISO/IEC JTC 1, Switzerland 1987. (Available via FTP from merit.edu:pub/iso/iso9542.ps). 🍓
[MULT-AMDS]: Amendments to ISO standards to support CLNP multicast extensions:
- ISO 8348 AM5 Amendment to the Network Service to support Group Network Addressing. International Standard ISO 8348 Amendment 5, ISO/IEC JTC 1, Switzerland 1994. ✨
- ISO 8473-1 DAM1 - Draft Amendment to the Second Edition of the Protocol for providing the connectionless-mode network service [CLNP], Multicast Extension, 1993. 🔥
- ISO 9542 DAM2 - Draft Amendment to the ES-IS [ES-IS] protocol, Addition of connectionless- mode multicast capability, 1993. 👑
Author's Address 🫶
Here's who wrote it, so you know who to thank (or blame, iykyk) 💅
Dave Marlow
Code B35
NSWC-DD
Dahlgren, VA. 22448
Phone: (703) 663-1675
EMail: dmarlow@relay.nswc.navy.milThat's the whole RFC, bestie! 🌈💖 Every single bit is accounted for. Slay. 💅✨
📦 where this page comes from
- ietf: rfc1768 1995-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms