idnits 2.17.00 (12 Aug 2021) /tmp/idnits10439/draft-ietf-mboned-pmbr-spec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) 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) 2022 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. ** 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 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2 Overview and example' ) ** 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 an Authors' Addresses Section. ** There are 91 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... Drafts are ...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '...ups may also ...' == Line 20 has weird spacing: '... Drafts may ...' == Line 21 has weird spacing: '...iate to use ...' == (86 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 3, 1997) is 9231 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Estrin96' on line 312 looks like a reference -- Missing reference section? 'Pusateri96' on line 320 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft Deborah Estrin (USC) 4 Ahmed Helmy (USC) 5 David Thaler (UMICH) 7 draft-ietf-mboned-pmbr-spec-00.txt Feb 3, 1997 9 PIM Multicast Border Router (PMBR) specification for connecting PIM- 10 SM domains to a DVMRP Backbone 12 Status of This Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. (Note that other groups may also distribute 17 working documents as Internet Drafts). 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a 23 ``working'' draft'' or ``work in progress.'' 25 Please check the I-D abstract listing contained in each Internet 26 Draft directory to learn the current status of this or any other 27 Internet Draft. 29 1 Assumptions 31 This document specifies the behavior of PIM-SM Multicast Border 32 Routers (PMBRs) that connect PIM-SM to DVMRP networks. We assume that 33 the reader is familiar with the PIM-SM protocol 34 specification.[Estrin96] 36 The following assumptions are made regarding the PMBR architecture 37 and connectivity: 39 1 The PMBR is located at the boundary of a PIM-SM multicast 40 domain, and connects the domain to a multicast domain that 41 does not run PIM-SM. In this document we focus on 42 connectivity to DVMRP speaking domains. 44 2 The PMBR implements the multicast protocols of the 45 multicast domains to which its interfaces are connected; in 46 this document this implies PIM-SM and DVMRP. Any PMBR 47 implementation can be logically viewed as having two 48 components; one implementing PIM-SM and another 49 implementing DVMRP. 51 3 Only one multicast protocol is implemented per interface; 52 mixed multicast protocol LANs on the border are not 53 permitted. Interfaces are classified as either PIM-SM or 54 DVMRP interfaces. Each component owns the interfaces 55 corresponding to its type. The PIM-SM component is 56 responsible for adding or deleting PIM-SM interfaces from 57 iif and oif entries of the multicast routing table, and 58 similarly the DVMRP component is responsible for adding and 59 deleting DVMRP interfaces. 61 4 The multicast backbone is running DVMRP. 63 5 A PMBR is used at all interconnection points between PIM-SM 64 and DVMRP regions. 66 2 Overview and example 68 The PMBR has two primary roles. First it must pull down packets 69 generated within the PIM-SM domain and inject them into the 70 DVMRP backbone. Second, it must import packets generated 71 outside the PIM-SM domain so that they can be delivered to group 72 members inside the PIM-SM domain, using PIM-SM mechanisms. 73 Furthermore, in case of transit networks, the PMBR acts to pass 74 the multicast traffic through the PIM domain. 76 3 Detailed Message Processing 78 This section discusses, in more detail, the message processing 79 in each of the PMBR components. Only deviations from the 80 standard behaviors, or additions thereto, are discussed. The 81 assumed standard behavior for PIM-SM and DVMRP is described in 82 PIM-SMv2 spec [Estrin96] and DVMRP spec [Pusateri96], 83 respectively. We assume that the forwarding entries are only 84 (S,G) forwarding entries. The internal communication protocol 85 between the components is assumed to support the internal signal 86 types: `Join', `Prune', `Creation', and `Deletion Request' 87 signals. All these internal signals are (S,G) specific. (The 88 internal communication protocol between the components of the 89 PMBR is not specified in this document, and is an implementation 90 issue.) 92 3.1 The PIM-SM Component 94 3.1.1 Receiving Bootstrap messages 96 Upon receiving a Bootstrap message, the PIM-SM Component does 97 the following: 99 1 The received Bootstrap message is processed as in standard 100 PIM (see section `Receiving and Forwarding Bootstrap' in 101 PIM-SMv2 spec). 103 2 If the Bootstrap message is accepted, a (*,*,RP) state is 104 set up for every new RP in the RP-Set whose mask indicates 105 that the RP supports non-local groups (for example, 106 239.X.X.X is considered locally scoped and PMBRs do not set 107 (*,*,RP) state for RPs supporting only that portion of the 108 address space). The (*,*,RP) states trigger (*,*,RP) Joins 109 towards the corresponding RPs. 111 (*,*,RP) Joins are periodically sent off of the (*,*,RP) 112 entries, as in 113 standard PIM. (*,*,RP) entries at the PMBRs are not deleted if 114 the 115 (*,*,RP) entry timer expires; they are deleted only when the 116 corresponding RP is removed from the RP-Set. 118 3.1.2 Receiving data packets from a PIM-SM interface 120 When a data packet is received on a PIM-SM interface: 122 1 The PIM-SM component processes the data packet as in 123 standard PIM, 125 2 If the packet for (S,G) is accepted, there was no previous 126 (S,G) entry, and `G' is a non-local group, then a new (S,G) 127 forwarding entry is created. In this case an internal 128 `Creation' signal is sent to the DVMRP component. 130 3 The packet is forwarded to the outgoing interface list 131 (oiflist) of the new entry (including the oifs added by the 132 DVMRP component, if any). 134 3.1.3 Receiving Register-Stop 136 Register-Stop messages are processed as in standard PIM (see 137 section 138 `Sending Registers and Receiving Register-Stops' in PIM-SMv2 139 spec). 140 Further, if the (S,G) forwarding entry oiflist becomes null 141 (an 142 entry set up for sending Registers is not considered a null 143 oiflist entry, 144 since this indicates a virtual encapsulation interface), and 145 the iif 146 is a DVMRP interface, an internal `Prune' is sent to the DVMRP 147 component. 149 3.1.4 Receiving PIM Join/Prune messages 151 When a PIM Join/Prune message is received on a PIM-SM interface: 153 1 The PIM-SM component processes the Join/Prune as in 154 standard PIM 156 2 If any affected (S,G) forwarding entry's oiflist changed 157 from null to non-null and a DVMRP interface as iif, an 158 internal `Join' is sent to the DVMRP component. 160 3 If the last oif is deleted from any (S,G) forwarding entry, 161 whose iif is a DVMRP interface, an internal `Prune' is sent 162 to the DVMRP component, for the corresponding entry(ies). 164 3.1.5 Receiving PIM Asserts 166 When a PIM Assert is received on a PIM-SM interface: 168 1 The PIM-SM component processes the Assert as in standard 169 PIM 171 2 If due to the Assert processing, the last oif is deleted 172 from any (S,G) forwarding entry(ies); where S is reached 173 via DVMRP interface, an internal `Prune' signal is sent to 174 the DVMRP component, for the corresponding entry(ies). 176 3.1.6 Register-bit timer expiry 178 When the Register-bit timer expires for an (S,G) entry, for 179 which iif is a DVMRP interface: 181 1 The PIM-SM component modifies the (S,G) forwarding entry to 182 support unicasting Registers with the Border-bit set, to 183 the corresponding RP. 185 2 If the forwarding entry had null oiflist, an internal 186 `Join' is sent to the DVMRP component. 188 3.1.7 (S,G) forwarding entry timeout 190 When a (S,G) entry timer expires in the PIM-SM component, an 191 internal `Deletion Request' signal is sent to the DVMRP 192 component. 194 3.1.8 Switching to the Shortest Path Tree (SPT) 196 Switching to the SPT is done according to standard PIM. In this 197 context the PMBR acts as a DR for external receivers. In 198 addition, if there is a (S,G) entry for which S is reached via 199 a PIM-SM interface, and the oiflist includes DVMRP interfaces, 200 the PMBR may switch to the SPT. 202 3.1.9 Receiving Internal Join 204 When the PIM-SM component receives an internal Join, the Join is 205 processed as a standard PIM (S,G) Join. However, instead of 206 restarting the oif timer, the entry timer for the corresponding 207 entry is restarted. 209 3.1.10 Receiving Internal Prune 211 The internal Prune is handled by the PIM-SM component as a 212 standard PIM (S,G) Prune. 214 3.1.11 Receiving Internal Creation Signal 216 When the PIM-SM component receives a `Creation' signal for 217 (S,G), if S is reached via a DVMRP interface, the PIM-SM 218 component modifies the (S,G) forwarding entry to support sending 219 PIM Registers with the Border bit set, to the corresponding RP. 221 3.1.12 Receiving Internal Deletion Request Signal 223 If the entry timer for the (S,G) forwarding entry has expired in 224 the PIM-SM component the entry is deleted. 226 3.1.13 Routing Updates For PIM-SM transit domains we require that 227 the PIM-SM component (as well as all PIM internal routers), 228 implement the DVMRP routing information exchange protocol to 229 support consistant RPF computation on both sides of the PIM-SM 230 domain. The PIM-SM component exchanges routing updates with the 231 DVMRP component of the PMBR, according to standard DVMRP. 233 3.2 The DVMRP Component 235 3.2.1 Receiving data packets from a DVMRP interface 237 Upon receiving data packets from a DVMRP interface, 238 the following actions are taken: 240 1 The DVMRP component processes the packet according to DVMRP 241 rules. 243 2 If a packet for (S,G) is accepted, for which there was no 244 previous (S,G) state, a (S,G) state is created, and an 245 internal `Creation' signal is sent to the PIM-SM component. 247 3 The packet is forwarded to the oiflist of the new entry 248 (including oifs added by the PIM-SM component, if any). 250 3.2.2 Receiving DVMRP (S,G) Prunes 252 When a DVMRP Prune message for (S,G) is received on a DVMRP 253 interface, the DVMRP component performs the following: 255 1 The DVMRP component processes the Prune message according 256 to DVMRP rules. 258 2 If the oiflist for the corresponding entry becomes null, 259 and the iif for the entry is a PIM-SM interface, an 260 internal `Prune' signal is sent to the PIM-SM component. 262 3.2.3 Receiving DVMRP (S,G) Graft 264 When a DVMRP Graft message is received on a DVMRP interface, for 265 a source reached via a PIM-SM interface, the DVMRP component 266 performs the following: 268 1 The DVMRP component processes the Graft message according 269 to DVMRP rules. 271 2 If the matching entry previously had null oiflist, an 272 internal `Join' is sent to the PIM-SM component. 274 3.2.4 (S,G) Prune timeout 276 When an interface Prune timer expires, for a (S,G) entry; where 277 S is reached via a PIM-SM interface, the DVMRP component 278 performs the following: 280 1 The timeout is processed as in standard DVMRP 282 2 If the forwarding entry previously had a null oiflist, an 283 internal `Join' is sent to the PIM-SM component. 285 3.2.5 Receiving Internal Join 287 The internal Join is treated as a DVMRP Graft. 289 3.2.6 Receiving Internal Prune 291 The internal Prune is treated as a DVMRP Prune. 293 3.2.7 Receiving Internal Creation signal 295 When the DVMRP component receives an internal `Creation' signal 296 for a (S,G) forwarding entry, the following is performed: 298 1 All dependent downstream DVMRP interfaces, for the given 299 source, are added to the oiflist of the corresponding 300 forwarding entry, as specified by DVMRP. 302 2 If S is reached via a DVMRP interface, a DVMRP Graft is 303 sent upstream. 305 3.2.8 Receiving Internal Deletion Request signal 307 If the entry timer has expired in the DVMRP component, the entry 308 is deleted. 310 4 References 312 [Estrin96] Protocol Independent Multicast Sparse-Mode (PIM-SM): 313 Protocol 314 Specification. 315 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, 316 S. Deering, M. Handley, V. Jacobson, G. Liu, P. 317 Sharma, L. Wei, 318 December 1997 320 [Pusateri96] Distance Vector Multicast Routing (DVMRP): Protocol 321 Specification. Tomas Pusateri, 322 September 1996 323 Expire in six months