idnits 2.17.1 draft-leecy-pimsm-atm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([PIM-SM,PIM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 104 has weird spacing: '...elected on a ...' -- 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 (24 March 1998) is 9523 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: 'PIM-SM' is mentioned on line 28, but not defined == Missing Reference: 'PIM' is mentioned on line 28, but not defined == Missing Reference: 'ILMIDET' is mentioned on line 97, but not defined == Unused Reference: 'AF-ILMI' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'AF-PNNIV1' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'AF-PNNIV2' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'PIMSM' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'PAR' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'OPAQUE' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'AF-MIPAR' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'ILMI' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'OSPF94' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'DEMAND' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'OSPF98' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'MARS' is defined on line 294, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-PPAR' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPAR' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-ILMI' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-PNNIV1' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-UNI' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-PNNIV2' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIMSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'INTRALIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'PAR' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPAQUE' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF-MIPAR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ILMI' ** Obsolete normative reference: RFC 1577 (ref. 'IPOA') (Obsoleted by RFC 2225) ** Obsolete normative reference: RFC 1583 (ref. 'OSPF94') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 2178 (ref. 'OSPF98') (Obsoleted by RFC 2328) Summary: 13 errors (**), 0 flaws (~~), 19 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C.Y. Lee 3 INTERNET DRAFT Nortel 4 24 March 1998 6 PIM-SM over ATM and Proxy PAR 7 9 Status of This Memo 11 This document is an Internet Draft, Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material, or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 Abstract 28 This document describes how PIM-SM [PIM-SM, PIM] operates in ATM 29 networks in the presence of Proxy PAR. [PPAR, OSPF_PPAR]. The 30 mechanisms described allow for simpler, more efficient and 31 cost-effective network designs. 33 2. Scope 35 2.1 Scoping PIM-SM over Proxy PAR 37 PIM-SM over Proxy PAR [PPAR] is scoped to prevent information 38 from being flooded unnecessarily throughout the ATM network. 39 In this document, the PAR advertisement for PIM-SM would be 40 limited to PIM-SM scope only (level 60 only as shown in Figure 1). 41 These advertisements may be propagated to the BGMP scope (level 40 42 in Figure 1) but the purpose and mechanism is beyond the scope of 43 this document. 45 +-+ 46 | | PNNI peer group # PPAR capable @ PNNI capable * Router 47 +-+ switch switch 48 Level 40 - BGMP 49 +---------------------------+ 50 | | 51 | | 52 | @ ---- @ ---- @ | 53 | | | | 54 +----- | ----------- | -----+ 55 | | 56 Level 60 - PIM-SM | | Level 60 - PIM-SM 57 +------------- | ---+ +-- | --------------+ 58 | | | | | | 59 R1* ------#-P1------@ | | @---------P3-#------- * R3 60 | | | | | | 61 R2* ------#-P2------+ | | +---------P4-#------- * R4 62 | | | | 63 +-------------------+ +-------------------+ 65 Figure 1: Scoping PIM-SM and BGMP over Proxy PAR (ATM Topology) 66 (Modified for IP multicasting from [PPAR]) 68 2.2 Model 70 This document describes 2 different models for PIM-SM over ATM. 72 The first, Model A is the same model described in [INTRALIS]. The 73 document [INTRALIS] requires that "each router within a LIS knows IP 74 and ATM addresses of all other routers within the LIS" but the 75 mechanism to obtain this information is not specified. Section A of 76 this document describes how Proxy PAR can be used by PIM-SM routers 77 to auto discover their peers in a LIS (Logical IP Subnet) [IPOA]. 79 The second Model B (FFS now), described in Section B is based on 80 [INTRALIS], with the following differences: 81 - this section describes multicasting over ATM within a PIM-SM 82 routing domain 83 - the mechanisms proposed in this section do not require a priori fully 84 meshed distribution (point-to-multipoint) VC to exist among the routers 85 in a LIS. 86 - LIJ (Leaf Initiated Join) [AF-UNI] is used to setup point to 87 multipoint VCs. 89 3. Section A 91 3.1 Auto Configuring PIM-SM routers 93 Each PIM-SM router in a LIS is configured with its own IP address, 94 mask, and router priority. This configuration information is 95 bound to a local ATM end point address and registered by the router 96 (Proxy PAR client) to the Proxy Server. Proxy PAR server detection 97 is described in [ILMIDET]. The Proxy PAR server then flood the 98 registered router information. A router may query the server to get 99 information about other routers in the ATM cloud. Once the 100 configuration information about each PIM-SM router in the LIS is learned 101 via Proxy PAR, the shared distribution VCs described in 102 [INTRALIS] may be setup. 104 In PIM-SM a DR router is elected on a multi-access network using 105 the Hello mechanism, the router with the largest network address 106 assumes the role of DR. (With Hello extensions [HELLO_EXT], the Router 107 with the highest priority will be elected). 108 When PIM-SM is run over Proxy PAR the exchange of these Hellos to 109 elect a DR may be replaced by Proxy PAR advertisements. 111 3.2 Service Definition of PIM-SM routers 113 Each router register configuration information for each 114 NSAP (ATM address) in the UNI Service IG. Within each UNI Service IG, 115 a router register its routing protocol service, PIM-SM in this case, 116 in the UNI IPv4 Service Definition IG and the PIM-SM specific 117 configuration parameters in the UNI PIM-SM IPv4 Service Definition IG 118 as shown in the figures below. 120 This IG is then registered with the Proxy PAR server at the appropriate 121 scope. If any of the parameters in the IG is changed, the client must 122 reregister the new parameters with the Proxy PAR server. 124 A - UNI Service IG 125 B - UNI IPv4 Service Definition IG 126 C - UNI PIM-SM IPv4 Service Definition IG 128 <---------------------------- A --------------------------------> 129 <------- B ---------> .... <----- B -------> 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | | C | ..... | C | .... | C | .... | C | | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 Figure 2: PNNI IG (Information Groups) used by PIM-SM over Proxy PAR 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type=784 | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | IP instance | Padding | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | IP Address | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | IP Address Mask | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | | 148 | Service Mask | 149 | | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 4: UNI IPv4 Service Definition IG 153 (Note: The UNI IPv4 Service Definition IG is reproduced here from [AF-PPAR] 154 to illustrate its use) 156 Type IG Type 157 IP Instance The IP instance PIM-SM is registered for 158 IP Address The IP address or IP address prefix PIM-SM is 159 registered for 160 IP Address Mask Contiguous mask fo the IP address/prefix. 161 Service Mask Bitmask of registered services, Bit 11 = PIM-SM 163 0 1 2 3 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type=804 | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Priority | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 5: UNI PIM-SM Service Definition IG 173 Type 804 174 Length Length of IG 175 Priority Used for DR election 177 4. Section B 179 Editor's Note: 181 This section is FFS. 183 If the RP for the group in the multicast routing domain can 184 be determined by querying the DNS as proposed in [STATIC_MCAST], 185 Proxy PAR may be used to discover the DNS server in the ATM network. 186 The only requirement is that a least one DNS server must be located 187 within or attached to the ATM network. 188 Using DNS to locate the RP reduces the amount of routing control 189 information (BSR and C-RP advertisements) that must be flooded 190 in the WAN and reduces the number of VCs required among routers. 192 If a VC to the upstream router does not yet exist : 193 A PIM-SM Join to an upstream router is preceeded by a LIJ to 194 the upstream router : 195 1) if using a group shared point to multipoint VC, (224.0.0.1) is 196 specified as the connection idenfifier in the LEAF SETUP MESSAGE. 197 2) if requiring a dedicated group specific point to multipoint VC 198 [INTRALIS], Group specific Joins can be communicated to the upstream 199 router using ATM LIJ, Leaf Initiated Join (specifying the IP 200 multicast address as the LIJ connection identifier to the upstream 201 router which is the root of the pt-mpt VC. 202 In both cases, the ATM address of the upstream router may be obtained 203 from Proxy PAR and must be specified in the LEAF SETUP MESSAGE. 204 Note that LIJ to (224.0.0.1) is only setup if the LIJ VC does not 205 exist. 207 The upstream router will then establish a LIJ to the 208 (224.0.0.1) to the downstream router. This will allow the PIM-SM Join 209 to be sent to the upstream router. The need to establish a VC to the 210 downstream router is either implicit in the connection identifier 211 and/or additonal signalling information may be defined (eg B-LLI). 213 The above procedures do not require a priori fully meshed distribution 214 (point-to-multipoint) VC to exist among the routers in a LIS. 215 The rules concerning eg. "Switching to a Source-Rooted Tree, 216 Adding New Members to a Source-Rooted Tree, Handling the Packet 217 Relection Problem" specified in [INTRALIS] still apply here. 219 VC management relating to VC establishment and tear-down, VC sharing. 220 will be discussed in more detail in the next version of the draft. 222 5. Acknowledgments 224 Comments and contributions from Tony Przygienda and Patrick Droz 225 are included in this work. Tony Przygienda suggested the use of LIJ 226 to setup point to multipoint VC. The use of Join to setup VC was 227 first proposed in [INTRALIS]. Thanks to Ahmed Helmy and Dave Thaler 228 for clarifying the details of PIM-SM. 230 6. Security Consideration 232 Security issues are not discussed in this memo. 234 References 236 [AF-PPAR] T. Przygienda and P. Droz. Proxy PAR Specification. 237 ATM Forum 97-0495, 97-0705, 97-0882, July 1997. 239 [PPAR] T. Przygienda and P. Droz. 240 Proxy PAR, Internet Draft, November 1997 242 [OSPF_PPAR] T. Przygienda and P. Droz. 243 OSPF over ATM and Proxy PAR, Internet Draft, October 1997 245 [AF-ILMI] ATM-Forum. Interim Local Management Interface (ILMI) 246 Specification 4.0. ATM Forum 95-0417R8, June 1996. 248 [AF-PNNIV1] ATM-Forum. Private Network-Network Interface Specification 249 Version 1.0. ATM Forum af-pnni-0055.000, March 1996. 251 [AF-UNI] ATM-Forum. Private Network-Network Interface Specification 252 Version 4.0. ATM Forum af-sig-0061.000, July 1996. 254 [AF-PNNIV2] ATM-Forum. Private Network-Network Interface Specification 255 Version 2.0. ATM Forum LTD-PNNI-02.00 December 1997. 257 [PIMSM] Estrin, Farinacci, Helmy, Thaler, Deering, Handley, 258 Jacobson, Liu, Sharma, and Wei. 259 Protocol independent multicast-sparse mode (PIM- SM): 260 Specification. Internet Draft, September 1996. 262 [INTRALIS] D. Farinaccci, D. Meyer, Y. Rekhter 263 Intra-LIS IP multicast among routers over ATM using 264 Sparse Mode, Internet Draft, 1997 266 [STATIC_MCAST] M. Ohta, J. Crowcroft Static Multicast, 268 [PAR] R. Callon and al. An Overview of PNNI Augmented Routing. 269 ATM Forum 96-0354, April 1996. 271 [OPAQUE] R. Coltun and J. Heinanen. Opaque LSA in OSPF. 272 Internet Draft, 1997. 274 [AF-MIPAR] R. Coltun, T. Przygienda, and S. Shew. 275 MIPAR: Minimal PNNI Augmented Routing. 276 ATM Forum 96-0838, June 1996. 278 [ILMI] M. Davison. Simple ILMI-Based Server Discovery. 279 Internet Draft, 1997. 281 [IPOA] M. Laubach. Classical IP and ARP over ATM, 282 RFC 1577. January 1994. 284 [SIG_IPOA] ATM Signalling Support for IP over ATM, 285 RFC 1755, February 1995. 287 [OSPF94] J. Moy. OSPFv2, RFC 1583. March 1994. 289 [DEMAND] J. Moy. Extending OSPF to Support Demand Circuits, 290 RFC 1793. April 1995. 292 [OSPF98] J. Moy. OSPFv2, RFC 2178. July 1997. 294 [MARS] G. Armitage. Support for Multicast over UNI 3.0/3.1 295 based ATM Networks, RFC 2022. November 1996. 297 Authors' Addresses 299 Cheng-Yin Lee 300 Nortel 301 PO Box 3511, Station C 302 Ottawa, ON K1Y 4H7 303 Canada 304 leecy@nortel.ca