idnits 2.17.1 draft-sami-pim-ng-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 29) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 124 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 23 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2124 has weird spacing: '... client askin...' == Line 2334 has weird spacing: '... 5- If a PIM...' == Line 3241 has weird spacing: '...R's in other...' == Line 3354 has weird spacing: '... that are ...' == Line 3560 has weird spacing: '...receive a C-...' == (8 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 29, 2018) is 2152 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) -- Looks like a reference, but probably isn't: 'TYPE' on line 5349 -- Looks like a reference, but probably isn't: 'X' on line 5268 -- Looks like a reference, but probably isn't: 'VALUE' on line 2078 -- Looks like a reference, but probably isn't: 'D1' on line 3027 -- Looks like a reference, but probably isn't: 'R2-D1' on line 3032 -- Looks like a reference, but probably isn't: '0-255' on line 3779 -- Looks like a reference, but probably isn't: '1-9900' on line 3925 -- Looks like a reference, but probably isn't: '9901-9999' on line 3927 -- Looks like a reference, but probably isn't: '10000-4294000000' on line 3930 -- Looks like a reference, but probably isn't: '4294000001-4294967293' on line 3932 -- Looks like a reference, but probably isn't: '1-64511' on line 3944 -- Looks like a reference, but probably isn't: '64536-4200000000' on line 3944 -- Looks like a reference, but probably isn't: '64512-65512' on line 3948 -- Looks like a reference, but probably isn't: '65513-65535' on line 3952 -- Looks like a reference, but probably isn't: '4200000001-4294967293' on line 3955 -- Looks like a reference, but probably isn't: 'Y' on line 5349 -- Looks like a reference, but probably isn't: 'NUMBER' on line 5349 == Unused Reference: '3' is defined on line 7912, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 7919, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 7931, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 7938, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 7944, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 7948, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (ref. '5') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. '7') (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet working group S. Sami 2 Internet Draft 3 Intended status: Proposed standard May 29, 2018 4 Expires: November 2018 6 Protocol independent multicast- Next Generation (PIM-NG): 7 Protocol Specifications 9 draft-sami-pim-ng-13.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on November 29, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Abstract 58 This document specifies a new generation of PIM family of multicast 59 routing protocols called Protocol Independent Multicast-Next 60 Generation (PIM-NG) which is faster in source discover and provides 61 many features suitable for Different type of networks. PIM-NG uses 62 the underlying unicast routing information, but unlike PIM-SM it 63 doesn't necessarily need to build unidirectional shared trees rooted 64 at a Rendezvous Point (RP) per group. It achieves this due to the 65 fact that the processes through which a source registers with the 66 Rendezvous Point and a host finds the source of the multicast 67 destination groups it needs are done in a whole new way and hence, 68 the source of multicast group (G) is discovered faster at the cost of 69 additional memory. So at some points PIM-NG works faster than its 70 predecessor. Also the new Domain concept, unique to PIM-NG, along the 71 RPF check method used in PIM-NG specifications provides many features 72 along a robust and flexible control and administration over multicast 73 networks. 75 Table of Contents 77 1. Introduction...................................................9 78 2. Terminology....................................................9 79 2.1. Definitions..............................................10 80 3. IP Address considerations.....................................14 81 4. PIM-NG processes..............................................15 82 4.1. New packet Header........................................15 83 4.2. Source Discovery.........................................16 84 4.2.1. Source register process with RP.....................17 85 4.2.2. Communication between client and the source.........21 86 4.2.3. Source specific multicast...........................31 87 4.2.4. Source Discovery Delay Prevention...................33 88 4.2.4.1. Delay prevention in Default-Mode...............34 89 4.2.4.2. Delay prevention in Admin-Mode.................36 90 4.3. Communication between PIM-NG routers.....................39 91 4.4. RP discovery.............................................44 92 4.4.1. Static RP discovery.................................45 93 4.4.2. Dynamic RP discovery................................46 94 4.4.2.1. Multicast IP addresses used....................47 95 4.4.2.2. Dynamic RP discovery TYPE-1....................47 96 4.4.2.2.1. RP introduction process...................49 97 4.4.2.2.2. Back up C-RP considerations...............51 98 4.4.2.2.3. PIM-NG clients processes in Dynamic-RP....58 99 4.4.2.2.3.1. New PIM-NG router/client.............60 100 4.4.2.3. Dynamic RP discovery type 2....................61 101 4.4.2.3.1. Client related concepts...................63 102 4.4.2.3.2. C-MAPPER concepts.........................64 103 4.4.2.3.2.1. Value of the A-BIT...................67 104 4.4.2.3.2.2. C-MAPPER preparation.................67 105 4.4.2.3.3. C-RP concepts.............................69 106 4.4.2.3.3.1. C-RP redundancy......................70 107 4.4.2.3.3.2. C-RP processes.......................72 108 4.4.2.3.3.3. Redundant C-RPs......................73 109 4.4.2.3.3.4. PIM-NG Anycast RP....................79 110 4.4.2.3.3.5. PIM-NG C-RP Mesh-Group...............80 111 4.4.2.3.3.6. Backup C-RP considerations...........82 112 4.5. C-MAPPER Redundancy in PIM-NG............................82 113 4.5.1. SC-MAPPER considerations............................91 114 4.5.2. C-MAPPER Mesh-Group.................................92 115 4.5.2.1. Active C-MAPPER Election.......................94 116 4.5.3. ANYCAST RP rules....................................95 117 4.5.4. Configuration process of Redundant C-MAPPERs........95 118 4.5.5. C-RP and Redundant C-MAPPERs........................97 119 4.6. Multiple multicast domains...............................98 120 4.6.1. Definitions and concepts...........................100 121 4.6.1.1. Domain........................................100 122 4.6.1.2. PIM-EDGE-ROUTER (PER/PPER)....................107 123 4.6.1.3. Tree Root (TR)................................114 124 4.6.1.4. Domain-set and RPF check......................117 125 4.6.2. Inter-domain connectivity concepts.................121 126 4.6.2.1. Public Domains................................121 127 4.6.2.1.1. Intra-domain concepts....................122 128 4.6.2.1.2. Inter-domain concepts....................124 129 4.6.2.2. Private domains...............................128 130 4.6.2.2.1. Intra-Domain processes...................129 131 4.6.2.2.2. Inter-domain concepts....................135 132 4.6.3. Core-Domain implementation.........................138 133 4.6.4. Multiple multicast domains scenario................143 134 4.6.5. PIM-NG Sub-Domain..................................149 135 4.6.6. PIM-NG Stub-Domain.................................161 136 4.7. PIM-NG Bidirectional logic..............................164 137 4.7.1. Requirements.......................................164 138 4.7.2. Bidirectional Multicast Group Discovery............165 139 4.7.2.1. Manual Mode...................................165 140 4.7.2.2. Autosense mechanism...........................167 141 4.7.3. Redundant TRs......................................170 142 4.7.3.1. ANYCAST Approach..............................170 143 4.7.3.2. TR Grouping...................................171 144 4.7.4. Bidirectional Tree formation.......................173 145 4.7.4.1. Tree formation between TRs....................174 146 4.7.4.2. Completing the Tree formation.................175 147 4.7.5. Inter-Domain Bidirectional connectivity rules......177 148 4.8. PIM-SM compatibility....................................181 149 4.8.1. PIM-SM compatibility and SA messages...............181 150 4.8.2. PIM-SM compatibility and join/prune messages.......184 151 4.9. Loop prevention.........................................186 152 4.10. DR election and PIM Assert Message.....................187 153 5. Security Considerations......................................187 154 5.1. Attacks based on forged messages........................188 155 5.1.1. Unicast forged messages............................188 156 5.1.2. Forged link local messages.........................188 157 5.1.3. Forged multicast messages..........................189 158 5.2. Non-cryptographic authentication mechanisms.............190 159 5.3. Authentication..........................................191 160 5.3.1. Protecting Multicast Introduction Message..........192 161 5.4. Denial-Of-Service attacks...............................192 162 6. IANA Considerations..........................................193 163 6.1. PIM-NG multicast destination group addresses............193 164 6.2. PIM-NG packets and values of type field.................193 165 6.3. PIM-NG Domain numbers...................................193 166 7. Conclusions..................................................194 167 8. References...................................................194 168 8.1. Normative References....................................194 169 8.2. Informative References..................................195 170 9. Acknowledgments..............................................196 171 Table of figures 173 Figure 1 the new packet Header.......................................15 175 Figure 2 source register request packet..............................18 177 Figure 3 multicast mapping table.....................................18 179 Figure 4 C-RP acknowledge message....................................19 181 Figure 5 source communication with the RP............................20 183 Figure 6 Request for source packet................................23 185 Figure 7 Request for Source packet format..........................24 187 Figure 8 C-RP Acknowledge packet format..............................25 189 Figure 9 C-RP answer to the host in case that source doesn't exist...26 191 Figure 10 Join/prune message format..................................29 193 Figure 11 Encoded Source Address Format..............................30 195 Figure 12 Communication between Host and Source......................32 197 Figure 13 Client Request Table (CRT).................................38 199 Figure 14 New-Activated-Source-Notification message format...........38 201 Figure 15 original PIM-SM hello packet compared with the new hello 202 packet format........................................................40 204 Figure 16 PIM domain topology table (PDTT)...........................42 206 Figure 17 C-MAPPER-INTRODUCTION massage sent to 239.0.1.190..........50 208 Figure 18 SC-MAPPER/RP answers to a host REQUEST-FOR-C-MAPPER message53 210 Figure 19 SC-MAPPER/RP multicast introductions to all PIM-NG-CLIENTS.54 212 Figure 20 PIM-NG network with backup RP (SC-RP)......................55 214 Figure 21 RP introduction message format.............................56 216 Figure 22 C-MAPPER/RP unicast HELLO/KEEP-ALIVE message to back up RPs58 217 Figure 23 request- for-C-MAPPER packet sent to the SC-MAPPER.........59 219 Figure 24 New client added...........................................61 221 Figure 25 network design with one multicast domain...................63 223 Figure 26 C-MAPPER introduction message formats......................66 225 Figure 27 multicast domain with one C-MAPPER.........................69 227 Figure 28 network designs with one multicast domain..................70 229 Figure 29 C-RP introduction message format...........................71 231 Figure 30 PEER-MAPPING table and PEER-LIST table.....................75 233 Figure 31 AMMT compared with MMT.....................................76 235 Figure 32 AMMT Format................................................77 237 Figure 33 network with single multicast domain and redundant C-MAPPERs83 239 Figure 34 PEER-MAPPING Table.........................................84 241 Figure 35 introduction message format sent to ALL PIM-NG MAPPERS 242 239.0.1.188..........................................................86 244 Figure 36 A- Multicast MAPPING TABLE.................................87 246 Figure 37 sample illustration of the above process...................90 248 Figure 38 network with 2 PIM-NG multicast domains....................99 250 Figure 39 PER introduction message..................................113 252 Figure 40 Internal Multicast Source Table...........................113 254 Figure 41 TR introduction message...................................116 256 Figure 42 Joined-Groups table used by both TR'(s) and Clients.......117 258 Figure 43 Inter-domain connectivity and RPF check...................119 260 Figure 44 Intra-Domain connectivity and RPF check...................120 262 Figure 45 network with 2 multicast domains..........................125 263 Figure 46 Multicast network with private PIM-NG domains.............129 265 Figure 47 core domain implementation................................141 267 Figure 48 join/prune message being sent towards the source..........143 269 Figure 49 network with multiple multicast domains...................144 271 Figure 50 multicast network and multicast advertisements............146 273 Figure 51 Mesh-Groups and C-MAPPER peering..........................157 275 Figure 52 PPER and PER communication with C-MAPPER..................159 277 Figure 53 Sample PIM-NG domain Divided to Sub-Domains...............160 279 Figure 54 Stub-Domain as the transitory multicast domain............163 281 Figure 55 Bidirectional Groups Table (BGT)..........................165 283 Figure 56 Bidirectional Tree formation with ANYCAST TR Address......176 285 Figure 57 Bidirectional Tree formation with TR grouping.............177 286 1. Introduction 288 This document specifies a protocol for efficiently routing multicast 289 groups that may span wide-area (and inter-domain) internets. This 290 protocol is called protocol independent multicast-Next Generation or 291 simply put PIM-NG. The name is chosen duo to the fact that this new 292 protocol has some behaviors similar to PIM-SM, in parts related to 293 using the underlying unicast routing information base to find the 294 best path to reach a source and not being limited to any specific 295 routing protocol. 297 But as the overall process of Multicast source discovery is a whole 298 new story it is called PIM-NG or the next generation of PIM-SM[7]. 300 PIM-NG provides many new features and concepts related to multicast 301 routing which together open new doors and possibilities. These 302 features are but not limited to removing the need for Shared path 303 trees to form using a well thought method, being able to easily 304 consider transit multicast domains, use as much as 254*255 RPs within 305 a single multicast domain. In addition to the previous it provides 306 the ability to use redundant Tree Roots per bidirectional tree and 307 eventually redundant Bidirectional Trees per Bidirectional Group. 309 Apart from the above this protocol is a lot more secure than current 310 implementations because of its unique multicast domain concept 311 introduced for the first time. Throughout this document different 312 features of PIM-NG will be investigated and author tries to explain 313 in an easy to understand and follow way. 315 2. Terminology 317 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 318 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 319 "MAY","ONLY" and "OPTIONAL" are to be interpreted as described in RFC 320 2119 [1] and indicate requirement levels for compliant PIM-NG 321 implementations. 323 Commands used in this document, MUST NOT be interpreted as the solid 324 commands, and are only used as an example to simplify the explanation 325 of the processes used by PIM-NG. 327 2.1. Definitions 329 The following terms have special significance for PIM-NG: 331 Candidate Rendezvous Point (C-RP): 333 C-RP is a router that has been configured to take the role of a 334 multicast information station in a PIM-NG domain. Unlike PIM-SM 335 specifications in RFC4601 [7], it is not used as the root of the non- 336 source-specific distribution tree for a multicast group. Any 337 multicast source will inform the RP about its existence by sending a 338 register message (S,G) to the RP , and RP will save the unicast 339 address of the source for further use in an special table. And any 340 host looking for the source of any desired multicast group will send 341 a request of (*,G) or (S,G) to the RP to receive the unicast address 342 of the desired multicast source. 344 Candidate MAPPER (C-MAPPER): 346 C-MAPPER is a router in charge of introducing the existing components 347 of a PIM-NG multicast domain to all PIM-NG population within a 348 multicast domain and also is responsible for the exchange of A- 349 Multicast Mapping Table between different PIM-NG multicast domains. 350 It acts like a BSR [9] in parts related to introducing the C-RPs to 351 all PIM-NG routers. The difference between a C-MAPPER and a BSR is 352 that the C-MAPPER doesn't do the group to RP mapping. It will only 353 introduce the existing components such as C-RP'(s), 355 Client: 357 Client is a router that either wants to register a source, or is 358 looking for a source. To be more specific any none C-RP or C-MAPPER 359 router can be called a client. And each C-RP and C-MAPPER can act as 360 a client too, which is not recommended. 362 Tree Root (TR): 364 A PIM-NG-AWARE router that after being configured, MUST be introduced 365 to the multicast domain to become the root of each (S,G) tree. Any 366 client in need of receiving multicast traffic from a source will send 367 its join/prune messages towards the existing TR in the domain, or if 368 no TR is considered in the domain, directly to the existing TRs in 369 the core-domain. 371 EDGE-Client: 373 It is a PIM-NG client within a PIM-NG multicast domain that can act 374 as a boundary between downstream clients and upstream clients, to 375 limit the propagation of multicast introduction messages sent by C- 376 MAPPER'(s) or C-RP'(s). an EDGE-CLIENT can be placed at the edge of 377 multi-access network'(s), which are part of one unified PIM-NG 378 multicast domain. 380 PIM-EDGE-ROUTER (PER): 382 It is a PIM-NG aware router that connects 2 or more separate PIM-NG 383 multicast domains and Sub-Domains by using the underlying IGP 384 protocol used inside the network or a routing protocol capable of 385 transferring multicast traffic like MBGP. 387 PRIVATE-PIM-EDGE-ROUTER (PPER): 389 It is PIM-NG PER that is placed at the edge of a private PIM-NG 390 multicast domain. A PPER is also in charge of NAT operations in the 391 domain. As soon as the PPER is configured it MUST introduce itself to 392 the closest C-MAPPER in the domain. 394 BORDER-PIM-ROUTER (BPR): 396 It is a PER or PPER which is placed between a PIM-NG multicast Domain 397 and a PIM-SM multicast domain, and has one or more internal 398 interfaces connected to the PIM-NG multicast domain and one or more 399 interfaces connected to the PIM-SM multicast domain. In case of using 400 PER as the BPR, the PER MUST introduce itself to the closest C- 401 MAPPER. 403 Second candidate Rendezvous Point (SC-RP): 405 SC-RP is a router configured or elected to act as the backup C-RP if 406 needed. And if C-RP goes offline will immediately take its place. 408 Second Candidate MAPPER (SC-MAPPER): 410 SC-MAPPER is a router configured or chosen to act as the backup C- 411 MAPPER if needed. And if C-MAPPER goes offline will immediately take 412 its place 414 Internal interface (II): 416 All interfaces of a PIM-NG router are internal interfaces by default, 417 and are assumed to be connected to either internal domain from a PIM- 418 NG-PER/PPER or PIM-NG-BPR point of view or a multi-access-network 419 from a PIM-NG-CLIENT point of view. 421 External interface (EI): 423 It is an interface configured as an external interface. External 424 interface is assumed to be connected to an external domain from a 425 PIM-NG-PER point of view or connected to the domain a PIM-NG-CLIENT 426 is a member of and thus, multicast introductions received on an 427 external interface won't be forwarded to internal interfaces. Also a 428 PIM-NG-BPR can have an external interface which is by default the 429 interface connected to a PIM-SM domain. 431 PIM-NG DOMAIN: 433 A domain is actually a public or private PIM-NG multicast network 434 including its own set of C-MAPPERs, C-RPs and clients isolated from 435 other domains. Clients and C-RPs inside one domain do not react to C- 436 MAPPER introduction messages that might be received from other 437 Domains. The only points of connection between 2 different domains 438 are the C-MAPPERs and if used PIM-EDGE-ROUTERs. Each DOMAIN can be 439 connected to either one or more PIM-NG-DOMAIN and if needed PIM-SM 440 domains or a single PIM-NG-CORE-DOMAIN. 442 PIM-NG CORE-DOMAIN: 444 A special domain implementation of PIM-NG, which if applied gives a 445 hierarchical design approach, alongside a good and sound multicast 446 traffic flow control to the administrators of different CORE-DOMAINs. 447 A CORE-DOMAIN can be connected to one or more CORE-DOMAINs and one or 448 more PIM-NG-DOMAINs. PIM-NG-DOMAINs MUST BE connected to the outside 449 world or World Wide Web through a CORE-DOMAIN if they need to 450 advertise their multicast sources globally. 452 Multicast mapping table (MMT): 454 After a router is configured as a C-RP, a table called multicast- 455 mapping table is created on it. This table will then hold the 456 information needed to be used by clients to find a source. After a C- 457 RP receives a register message from a source it will put an entry for 458 that source in this table which indicates the unicast address of the 459 source plus the multicast destination group it is representing in the 460 format (S,G) alongside the unicast address of the client which is 461 sending the register message. It is done to bring compatibility with 462 the needs of SSM. 464 Abbreviated multicast mapping table (A-multicast mapping table) 465 (AMMT): 467 Is an abbreviated form of Multicast mapping table which only holds 468 the information regarding each source which exists in the domain and 469 the unicast address of that source. This table is created on C- 470 MAPPERs and C-RPs and is used in related processes. 472 PIM domain topology table (PDTT): 474 This table is used to store the information needed to find C-RP/RPs, 475 C-MAPPER, TRs and other components that may exist in a PIM-NG 476 multicast Domain. It holds the unicast address of such components 477 alongside other information needed. 479 Core topology table (CTT): 481 It is created on C-MAPPERS inside the core-domain. It only holds the 482 address of any existing TR'(s) inside the core domain. And is the 483 only PIM-NG topology table that CAN be exchanged between the PIM-NG- 484 CORE-DOMAIN and any existing PIM-NG-DOMAIN connected to the core 485 domain. Also this table is the ONLY PIM-NG topology table that CAN be 486 exchanged between peer C-MAPPERs in different PIM-NG-DOMAINs so that 487 all PIM-NG-DOMAINs will know about the TR'(s) inside the core domain. 488 This table MUST NOT be exchanged between PIM-NG-CORE-DOMAINs. 490 Peer mapping table: 492 It is created on C-RPs and C-MAPPERs as soon as a C-RP or C-MAPPER 493 becomes peer with new C-RP or C-MAPPER. 495 Internal multicast source table (IMST): 497 This table is created on PPER'(s) and in case of private network'(s) 498 within a unified PIM-NG multicast domain connected to other parts of 499 the Network using NAT, on EDGE-CLIENTS, and helps the PPER or EDGE- 500 CLIENT to act on behalf of a host in search of a source by putting an 501 entry inside the table to keep track of the behavior of the domain. 502 It holds the address of the requesting client and the multicast group 503 requested. 505 Client request table (CRT): 507 This table is created on C-RP'(s) and holds the unicast address of 508 clients to which the C-RP sends a NULL-ACK in response to the clients 509 request to find the source for multicast group(G)along the multicast 510 group (G)which the client needs to find the generating source. 512 Bidirectional Groups Table (BGT): 514 This table is created on C-MAPPERs and C-RPs and hold the information 515 of active or to be active Bidirectional multicast groups. 517 Bidirectional Translator TR (TTR): 519 A TR part of all available TR groups which is used to communicate 520 with TRs in other multicast domains with regards to exchanging the 521 information of active Bidirectional multicast groups. 523 3. IP Address considerations 525 PIM-NG processes need to use 3 new multicast destination addresses 526 from Internetwork Control Block [2]. These addresses are going to be 527 used in PIM-NG processes and are needed to be assigned. For the 528 simplicity of explanations in this document, multicast address 529 239.0.1.188, 239.0.1.189 and 239.0.1.190 from the Scoped Multicast 530 Ranges are used as advised by IANA. But PIM-NG needs the use of 531 addresses from the "internetwork control block" and the use of the 3 532 addresses from the scoped multicast range is only for the sake of 533 simplicity in the process of explanation. 535 Also it MUST BE noted that any IP addresses, whether multicast or 536 unicast, used in this document from this point forward ARE ONLY used 537 as an example to simplify the explanation process. For example 538 addresses 228.8.8.8 and 229.9.9.9 are used only to simplify the 539 explanation process. 541 4. PIM-NG processes 543 PIM-NG processes are related tightly to the new packet formats 544 defined for it. So in each section related packet formats are going 545 to be explained or shown. 547 4.1. New packet Header 549 The new packet'(s) format is designed and defined in the way, so it 550 can support the needs of PIM-NG. 552 The new packet header format specification for PIM-NG is as follows: 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 |PIM Ver| Type | Reserved | Checksum | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 1 the new packet Header 561 PIM-ver : is 3 563 As the new packet format will be used in different situations, the 564 new type field definitions must be explained. The new definitions are 565 as follows: 567 5 bit TYPE field to support up to 32 different functions: 569 Message type destination 571 --------------------------------------------------------------------- 573 0- Hello Multicast to All-PIM routers 574 1- Register Unicast to RP and EDGE-CLIENT 575 2- Keep alive to RP Unicast from source to RP 576 3- Join/prune Multicast to ALL-PIM-ROUTERs 577 4- Request For Source Unicast to RP 578 5- Ack to Client/source Unicast from RP or EDGE-Client 579 To source 580 6- Assert Multicast to ALL-PIM routers 581 7- Host request to C-MAPPER Unicast to C-MAPPER 582 8- RP introduction Multicast to ALL-RPs 583 9- RP introduction Unicast to C-MAPPER 584 10- C-MAPPER introduction1 Multicast to ALL-PIM-NG routers 585 11- C-MAPPER introduction2 Multicast to ALL-MAPPERs 586 12- Request-for-C-MAPPER Unicast to SC-MAPPER 587 13- C-MAPPER ack Unicast to Client 588 14- Edge Unicast to C-MAPPER 589 15- BPR Unicast to C-MAPPER 590 16- TR Unicast to C-MAPPER and 591 Peer-TR 592 17- NASN Unicast from C-RP to C-MAPPER 593 And Multicast from C-MAPPER to 594 ALL-PIM-NG routers 596 The above definitions will be explained, as we proceed through out 597 different sections of PIM-NG specifications. 599 4.2. Source Discovery 601 In the original PIM-SM specifications of the communication between a 602 SOURCE and RP we see that the source sends Register messages to the 603 RP and the RP will only accept the Register message, if any host or 604 hosts asked for that particular multicast group. Otherwise the RP 605 will send a register-stop message back to the source and the source 606 starts a register-suppression timer of 60 seconds. And 5 seconds 607 before the suppression timer expires the source sends a register- 608 message with its null-register bit set. Now if the RP doesn't know 609 any hosts asking for that specific group it will send another 610 register-stop. The process goes on until a host asks the RP about 611 that group. 613 Now what happens if right after the suppression timer starts by the 614 source a host comes up and asks for that specific source? As it is 615 explained in the original PIM-SM specifications, the host will have 616 to send its join messages to the RP until the RP hears again from the 617 source and this time, due to the fact that there is a host asking for 618 the group the RP won't send a register stop and will forward the 619 packet down the RPT .This process didn't seem so efficient, so some 620 changes has been made to the way a SOURCE communicates with the RP 621 alongside the new packet definitions 623 4.2.1. Source register process with RP 625 In PIM-NG the process to initially deliver the multicast traffic to a 626 host asking for it, is somehow different from that of PIM-SM. It 627 initially starts by: 629 1- Source introducing itself to a router called RP(rendezvous 630 point) 632 2- RP keeps and enters the information related to the source in to 633 a table for further use. 635 3- Host asks the RP about the source of an specific group 637 4- Host sends a join request to the source directly 639 For the sake of simplicity let's consider that all the routers know 640 the address of C-RP. The source of the multicast traffic starts its 641 process by introducing itself to the C-RP, by sending Unicast- 642 Encapsulated register messages to it. The source does the 643 introduction process completely different from the original PIM-SM 644 specifications. In PIM-SM source introduces itself by sending a 645 packet containing the multicast data to be sent. But the introduction 646 process in PIM-NG is done through sending a register-request packet 647 containing only the address of the source along the multicast group 648 address the source represents (Figure 2). The C-RP receives the 649 message and by looking in its type field, it knows that it is a 650 Source register request message sent from a source. From here the C- 651 RP will act differently from what is defined in the PIM-SM 652 specifications. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 |PIM Ver| Type | Reserved | Checksum | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |B| RESERVED | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | D O M A I N | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Source unicast address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Multicast destination group 1(G) | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Source Host (server) address | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | . | 670 | . | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Multicast destination group n (G) | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Source Host (server) address | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 2 source register request packet 678 o Type: register 680 o Source Unicast Address: Holds the unicast address of the PIM- 681 NG-CLIENT sending the register message to the C-RP. 683 o Source HOST Address: holds the unicast address of the, server 684 or host in the connected LAN which is the actual generator of 685 the multicast data. 687 The C-RP looks in to the source unicast address and the Multicast 688 group destination address fields and puts an entry into its multicast 689 mapping table. The multicast mapping table consists of the multicast 690 group represented by a source and that source's unicast address, 691 along 2 timers. Figure 3 shows the multicast mapping table(MMT) 692 created by C-RP'(S): 694 +-------------------------------------------------------------------+ 695 |Source addr(S)|Dest group (G)|Source HOST| keep alive |expiry time | 696 +-------------------------------------------------------------------+ 697 | | | | | | 698 +-------------------------------------------------------------------+ 699 | | | | | | 700 +-------------------------------------------------------------------+ 701 Figure 3 multicast mapping table 703 o Source keep alive timer : the time in which RP should receive 704 keep alive from the source 706 o Source expiry time : time in which , if no keep-alive received 707 the entry will be deleted 709 Each C-RP will create another table besides the multicast-mapping 710 table called A-MULTICAST MAPPING TABLE (AMMT) which will be explained 711 later. Each new multicast destination address it enters in its MMT 712 will be put in the AMMT too. 714 Inside the register-message, each source sends a keep-alive timer 715 value defaulting to 30sec to the C-RP, which later will be used by 716 the C-RP in the process. 718 Then the C-RP sends a unicast acknowledge-message(Figure 5) back to 719 the source, using the unicast address of the source .after receiving 720 the acknowledge the source proceeds with sending periodic keep-alive 721 messages to C-RP , to tell the C-RP that it is alive and so the C-RP 722 wont delete the entry related to the source from its multicast- 723 mapping table. For each keep-alive C-RP receives it will send an 724 acknowledgement. If the C-RP doesn't hear the first keep alive, it 725 will start to count down the expiry timer for the source which is by 726 default 3*keep-alive timer .if the C-RP doesn't hear from the source 727 in the expiry time duration it will delete the entry for that source. 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |PIM Ver| Type | Reserved | Checksum | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | D O M A I N | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | RP's unicast address | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Multicast Destination Group 1 | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | . | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Multicast Destination Group n | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Figure 4 C-RP acknowledge message 746 o Type : RP acknowledge to source 748 [Figure is presented in PDF version] 750 Figure 5 source communication with the RP 752 Now let's start by explaining the process related to the 753 communication of the source and RP as shown in Figure 5: 755 1- The server behind R1 (called S1), starts sending multicast to 756 228.8.8.8 and R1 receives those multicasts on its connected LAN 757 interface. 759 2- R1 will try to contact the C-RP and introduce itself and the 760 multicast group it represents, by sending the Unicast-Encapsulated 761 register-request message to the address of the C-RP. C-RP receives 762 a PIM packet and looks at the TYPE-FIELD. 764 3- After looking at the TYPE_FIELD C-RP finds out that it is a 765 register-request which is sent from a source. So the C-RP looks in 766 to the source unicast address and the Multicast group destination 767 address fields and writes the unicast address of the source 768 alongside the multicast group address it represents alongside the 769 keep-alive timer and the expiry timer as a new entry in its MMT. 771 4- RP sends acknowledge back to the SOURCE. 773 5- After receiving the acknowledge the source starts its keep-alive 774 timer ,and will send periodic keep-alive messages as long as it 775 wants to send traffic for the multicast group address it 776 represents. These keep-alive messages can be simply a register 777 message. 779 So this was the process related to the communication between a source 780 and the C-RP. In the next section the process related to the 781 communication between a host and a source, or how a host sends join 782 request for a multicast group address to the source will be 783 explained. 785 4.2.2. Communication between client and the source 787 The process through which, a host finds the source and communicates 788 with it in order to receive the multicast traffic, is in parts 789 different from that of the original PIM-SM specifications. So let's 790 have a flash back at the process of the original PIM-SM: 792 1. Host sends a join message of (*, G) to the RP, and joins the RPT 793 for the (*, G). 795 2. RP sends the join request to the source with (S,G), indicating 796 that a host is asking for the traffic or the RP simply forwards the 797 multicast packets received from the source down RPT towards the 798 host. 800 3. Source sends the multicast packet to the RP ,and RP forwards it to 801 the host 803 4. After receiving the first couple of packets , the host sends a 804 join request directly to the source 806 5. So the host leaves the RPT and switches to SPT for (S,G) 808 6. Host sends a prune to the upstream router, so the RP will stop 809 forwarding that traffic. 811 This process works fine, but not as efficient and as fast as 812 possible. Waiting for the first couple of packets or even first 813 packet to be received and then switch to SPT for the (S,G) and after 814 that sending a prune to the upstream router ,doesn't seem so 815 efficient. What happens when a host sends a join for a particular 816 group (*, G) or (S, G) right after the RP sent a register-stop to the 817 source? The process seems to waste some valuable time. 819 So PIM-NG uses a new process to reach the source, alongside new 820 messages. We are going to consider that the host/hosts know about the 821 C-RP for now. 823 Let's start by assuming that a HOST behind R4(Figure 5), asks for 824 228.8.8.8 traffic using IGMPV2-3 .the request arrives at R4, and now 825 it is up to R4 to find the source and send Join message to the 826 source. But in order to find the source R4 knows that it will have to 827 ask C-RP as the information station of the Multicast domain about the 828 address of the source. 830 So R4 sends a unicast-encapsulated PIM-NG request message to the C- 831 RP. R4 sets the TYPE-FIELD to " Request For Source" and puts its own 832 unicast IP address in the "SOURCE UNICAST ADDRESS" field and puts the 833 multicast group address 228.8.8.8 in the format of (* , 228.8.8.8) in 834 the " Multicast group destination address " field, And sends the 835 packet to the destination address of C-RP. 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 |PIM Ver| Type | Reserved | Checksum | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 |B| reserved | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | D O M A I N | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Client's unicast address(R4) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Multicast destination group 1(G) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | source of multicast group 1(*) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | . | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Multicast destination group N (G) | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | source of multicast group N(*) | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Figure 6 Request for source packet 860 o Type: Request For Source 862 There might be a case that there are two source HOSTs sending traffic 863 for the 228.8.8.8 group and the host behind R4 , asks through IGMP to 864 receive the traffic generated by a specific source (i.e.10.1.1.10) 865 .then the format of the request packet it sends will be as shown in 866 Figure 7.this is different from SSM multicast. As it is considered 867 that the CLIENT/HOST knows the address of the server or host 868 originating the traffic destined for group (G), but not the address 869 of CLIENT who is responsible for forwarding the traffic on behalf of 870 the server and acting as the DR. 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |PIM Ver| Type | Reserved | Checksum | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 |B| reserved | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | D O M A I N | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Client's unicast address(R4) | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Multicast destination group1(G) | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Source Host of Group 1(G)(S) | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | . | 888 | . | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Multicast destination group n(G) | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Source Host of Group n(G)(S) | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Figure 7 Request for Source packet format 896 o Type: Request For Source 898 C-RP receives the packet, and checks the type-field.the type-field 899 indicates that it is a host request to find the unicast address of a 900 source. So C-RP checks the Multicast group destination address field 901 and finds out that the host is either: 903 1- Looking for the unicast address of a source representing 904 228.8.8.8 multicast traffic (*, G). 906 2- Looking for the unicast address of a specific source representing 907 228.8.8.8 multicast traffic (*, S, G). Different from PIM-SSM. 909 Then the C-RP looks in to its MMT or AMMT if the network is consisted 910 of separate PIM-NG domains, and acts in two different ways: 912 1- C-RP finds an entry in its MMT which indicates that the source 913 exists: 915 In this case, instead of forwarding the traffic towards the source 916 and join the SPT for (S,G), C-RP sends back the address of the source 917 directly toward R4 using R4's unicast address found in the "source 918 unicast address " field with a packet shown in Figure 8 : 920 0 1 2 3 921 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 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 |PIM Ver| Type | Reserved | Checksum | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | D O M A I N | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | RP's unicast address(R4) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | GDPT | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Requested Multicast Group 1 (G) | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Source of group 1(G),(S) | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | DOMAIN-set for Group 1 | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | . | 938 | . | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Requested Multicast Group n (G) | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Source of group n(G),(S) | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | DOMAIN-set for Group n | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 8 C-RP Acknowledge packet format 948 o Type: RP acknowledge to host 950 o DOMAIN-SET: is part of the AMMT and its use will be explained 951 later. It shows the domain in which a source is registered. And 952 also the path towards the source, so that a client can decide on 953 generating the join/prune message better. 955 o GDPT Filed: Holds the global Delay prevention timer set on C-RP 956 and is used to automatically synchronize this timer on all the 957 clients receiving a Null-ACK from C-RP. 959 C-RP sets the type field to "RP acknowledge to host" and puts its own 960 unicast IP address in the source unicast address field and fills out 961 the "Multicast group destination address" field in the format of (S, 962 G). 964 One other thing that the C-RP sends back to the client is the Domain 965 set, which shows the domain in which the source is resided and also 966 the path through which the join/prune message can reach the source. 967 In case that the source resides in a separate domain and to be more 968 specific the PIM-NG network is consisted of different and separate 969 domains, clients will use the domain set to decide whether a 970 join/prune message MUST path a core domain first or MUST NOT which 971 the related concepts will be explained later. A Domain-Set with the 972 Null value in it indicates that a source is resided within a Multi- 973 Access Network which the related processes will be discussed in the 974 appropriate sections. 976 2- C-RP doesn't find an entry in its multicast-mapping table: 978 In this case C-RP answers to the host, with a packet which indicates 979 that the source doesn't exist now and the host must try again later. 980 Figure 9 shows the packet sent by RP to the host: 982 0 1 2 3 983 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 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 |PIM Ver| Type | Reserved | Checksum | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | D O M A I N | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | RP's unicast address(R4) | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | GDPT | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Requested Multicast group 1 (G) | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Source of group 1(*) | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | . | 998 | . | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Requested Multicast group n (G) | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Source of group n (*) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 Figure 9 C-RP answer to the host in case that source doesn't exist 1005 o Type: RP acknowledge 1007 R4 receives a unicast-encapsulated PIM_NG packet, and looks into the 1008 TYPE-FIELD. The type field indicates that it is the C-RP answer to 1009 the host request for finding the unicast address of a source. So R4 1010 will check the source unicast address field and makes sure it was 1011 sent from the C-RP and then looks into the Multicast group 1012 destination address field. 1014 R4 will act in 2 different ways, depending which one of the 2 above 1015 conditions is meat: 1017 1- If the entry inside the " Source of group field" is in the format 1018 of (*, G), then R4 understands that the source doesn't exists for 1019 now and it has to try again later .the time of resending the 1020 request will be equal to the HELLO time or 30 seconds. 1022 2- If the entry inside the "Source of group field" is in the format 1023 of (S, G) then R4 will take S, and looks into its unicast routing 1024 table to find the best way for reaching to S which is in our 1025 example the unicast address of R1. After finding the best path to 1026 R1, R4 sends a join/prune message to the upstream neighbor in the 1027 best path towards the source so the join/prune messages goes hop- 1028 by-hop until it reaches the desired destination. And depending on 1029 whether a TR exists in the domain or not and whether any core- 1030 domain is considered in the PIM-NG overall network, client will : 1032 o Join the (S,G)tree in case there are no residing TRs inside the 1033 domain 1035 o Join the (S, G, RPT) which is assumed by PIM-NG specifications 1036 the shortest path tree rooted at TR in case a TR exists in the 1037 domain. Joining the (S,G,RPT) tree inside each single domain is 1038 strongly advised due to the fact that it will reduce the 1039 unnecessary join/prune messages being sent towards a source in 1040 case that new clients come up later which need to receive the 1041 same traffic. 1043 o Join the (S, G, RPT) which is considered by PIM-NG 1044 specifications the shortest path tree towards a source rooted 1045 at core-domain-TR. for this tree to be formed 2 conditions 1046 MUST exist : 1048 1. Core-domain MUST do exist, and any existing TR inside 1049 the core-domain MUST be known to the PIM-NG population. 1051 2. A source MUST be reachable by passing through the core- 1052 domain. Which the decision is up to the client 1053 generating the join/prune message, by checking the 1054 DOMAIN-SET associated with a source. 1056 This process MUST be done if the above conditions are meat, 1057 duo to the fact that, if a PIM-NG-Core-domain exists there 1058 will be one or more PIM-NG-DOMAINs connected to it and if one 1059 or more new clients in other domains come up later which are 1060 in need of receiving the same traffic, it will be waste of 1061 time and network resources to send the new join/prune messages 1062 towards the source. Related concepts will be explained later. 1064 R4 MUST save the state for the join message being sent. By saving the 1065 incoming interface for (*, G) or (S, G, TR) if it is a SSM join, and 1066 the outgoing interface for the (S, G) or (S, G, TR).and use this for 1067 RPF check later when receiving packets destined for (G). The related 1068 processes are done the way described in RFC4601 [7]. 1070 The packet that is being sent by R4 to R1 as a join/prune message is 1071 shown in Figure 10 along the new encoded source address format 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 |PIM Ver| Type | Reserved | Checksum | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | Upstream Neighbor Address (Encoded-Unicast format) | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Reserved | Num groups | Holdtime | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Multicast Group Address 1 (Encoded-Group format) | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Number of Joined Sources | Number of Pruned Sources | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Joined Source Address 1 (Encoded-Source format) | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Tree Root address | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Core Domain Tree Root Address | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | . | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Joined Source Address n (Encoded-Source format) | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Tree Root address | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Core Domain Tree Root Address | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Pruned Source Address 1 (Encoded-Source format) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | . | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Pruned Source Address n (Encoded-Source format) | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | . | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Multicast Group Address m (Encoded-Group format) | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Number of Joined Sources | Number of Pruned Sources | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Joined Source Address 1 (Encoded-Source format) | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | . | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Joined Source Address n (Encoded-Source format) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Pruned Source Address 1 (Encoded-Source format) | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | . | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Pruned Source Address n (Encoded-Source format) | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 Figure 10 Join/prune message format 1125 o Type : join/prune 1126 o Tree-Root address: if any TR exists in the Domain, this field 1127 holds the address of the TR to towards which the message MUST be 1128 forwarded first, before being forwarded towards the source. The 1129 concepts will be discussed later. 1130 o Core Domain Tree-Root Address: holds the unicast address of the 1131 TR resided in the core domain, and is used only in topologies that 1132 contain Core-domain implementations, and incase the source is not 1133 an internal source and MUST be reached by passing a core domain. 1134 The related concepts will be discussed later. 1136 0 1 2 3 1137 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 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Addr Family | Encoding Type | Rsrvd |S|C|R| Mask Len | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Source Address 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 1143 Figure 11 Encoded Source Address Format 1145 o S-BIT: only for compatibility with PIM-V1. 1147 o R-BIT: Tree Root bit is set by the client who is sending the 1148 join/prune message for the first time for a source in a topology 1149 with one or more TR'(s) to join the (S, G, TR) tree. a value of 1 1150 is set by the creator of the join/prune message to tell upstream 1151 routers that the packet MUST be forwarded first towards the 1152 existing TR in the domain which the address of it can be found in 1153 the appropriate field .and a value of 0 can be set by the TR after 1154 receiving the join/prune message and before forwarding it towards 1155 the source. A value of 0 dictates to upstream routers that the 1156 join/prune had reached an existing TR In the domain and from now on 1157 MUST be forwarded towards either the source, if the source is an 1158 internal source or there are no core domain implementations, or the 1159 TR inside the core domain if the source is an external source that 1160 can be reached by core domain. This bit can also be set by a PER or 1161 by a PER/BPR in case a join/prune message is received from another 1162 PIM-NG domain or a PIM-SM domain and must be forwarded towards any 1163 existing TR in the domain to either reach a source inside the 1164 domain or towards a source in other domains. 1166 o C-BIT: Core-Domain-BIT can be set by either the client originating 1167 a join/prune message or the TR inside the core domain. If a client 1168 is originating a join/prune message for a source which is not an 1169 internal source and can be reached by passing through an existing 1170 core domain, it will set this bit to 1. A value of 1 means that the 1171 packet MUST be forwarded towards the TR inside the core domain 1172 first with the unicast address that can be found in the appropriate 1173 field. And a value of 0 can be set by the TR inside the core 1174 domain, which dictates to upstream routers that the join/prune 1175 message MUST be forwarded hop-by-hop towards the source from now 1176 on. This bit can also be set by a BPR in case it receives a 1177 join/prune message from a PIM-SM neighbor router. The related 1178 processes and concepts will be discussed later. 1180 Source (R1) receives the join/prune message. And joins the shortest 1181 path tree for (G) and starts sending the multicast data destined for 1182 (G) down the shortest path tree towards the receiver. 1184 In order to receive packets from R1, R4 will have to send periodic 1185 keep-alive or join messages every 30 seconds to R1. R1 receives the 1186 join-request and will know that R4 still needs the traffic. If R1 1187 (source) doesn't receive 2 keep-alive messages from the host (R4) it 1188 will assume that the host doesn't exist anymore and will 1189 automatically stop forwarding multicast traffic to the host (R4). 1191 If R4 no longer needs to receive the traffic from R1, it will inform 1192 R1 by sending a prune message to the upstream PIM-NG router 1193 forwarding the traffic .this is done due to the fact that there might 1194 be other hosts connected to the upstream routers in need of receiving 1195 the traffic. 1197 4.2.3. Source specific multicast 1199 Source specific multicast (SSM) [6] can be implemented under the 1200 following rules: 1202 o PIM-NG routers MUST NOT send the unicast-encapsulated Request 1203 for Source message for SSM addresses. 1205 o PIM-NG routers MUST NOT send a register message for any packet 1206 that is destined to an SSM address. 1208 o If any TR exists in a PIM-NG domain, a PIM-NG router MUST join 1209 the (S, G, RPT) rooted at the TR which is considered the 1210 shortest path tree towards a source by PIM-NG specifications. 1212 o ONLY incase that in a PIM-NG multicast Domain TR is implemented 1213 and the TR and C-RP are the same components, a Client is allowed 1214 to create the join/prune message for the SSM address and send it 1215 towards the existing C-RP, which is also the TR. 1217 [Figure is presented in PDF version] 1219 Figure 12 Communication between Host and Source 1221 4.2.4. Source Discovery Delay Prevention 1223 One of the important factors in a multicast domain is the time 1224 through which a client discovers or finds the source of a multicast 1225 group (G). 1227 Up to this point the processes through which a source registers with 1228 C-RP and finally a client discovers the (S) for (G) by sending a 1229 request for source message to the C-RP have been explained. 1230 Throughout the explanations we saw that if a source is registered 1231 ,since the information regarding the source is saved in an special 1232 table called MMT as soon as a client sends a request for source to C- 1233 RP the C-RP will be able to send back the unicast address of (S) for 1234 (G) in an acknowledge message to the client. 1236 Now what happens if a client sends its request for source message to 1237 find the (S) for (G) to the C-RP and the source (S) for (G) is not 1238 registered yet? 1240 As it has been explained by PIM-NG specifications, in such a case the 1241 C-RP will send a NULL-ACK for the requested (G) back to the client 1242 which is in the form of (*, G) and the client will have to start a 30 1243 second timer after receiving the NULL-ACK from C-RP and send 1244 periodical request for source messages until the source becomes 1245 active and the C-RP responds with an acknowledge containing (S) for 1246 (G). 1248 Now what will happen if the (S) for (G) becomes active right after 1249 the C-RP sends the NULL-ACK to the client? 1251 As explained the client will have to try again in 30 seconds and send 1252 its periodical request again to the C-RP. In this case and 1253 considering that the (S) for (G) becomes active 1 second after the C- 1254 RP responds to client with a NULL-ACK, the worst case scenario will 1255 be that an unwanted 30 second delay will occur until the client sends 1256 its request again and finds the (S) for (G). 1258 To eliminate this delay in source discovery, PIM-NG introduces a 1259 mechanism or process through which the C-RP will: 1261 o Save the state of the clients to which it sends a NULL-ACK for 1262 the requested (G). 1264 o As soon as the (S) for (G) becomes active and registers the C- 1265 RP will inform the clients who had been responded with a NULL- 1266 ACK for that specific source (S). 1268 Through the above the C-RP will be able to inform the client as soon 1269 as the source becomes active and the client will be able to find (S) 1270 for (G) as fast as possible. 1272 To do so PIM-NG specifications introduces its Source Discovery Delay 1273 Prevention method which is divided in to 2 modes: 1275 o Default-Mode. 1277 o Admin-Mode. 1279 4.2.4.1. Delay prevention in Default-Mode 1281 This mode is activated by default as soon as a PIM-NG-Aware Router is 1282 configured to become a C-RP and is suitable for all types of 1283 multicast network topologies form small sized networks to large sized 1284 networks. But it is strongly advised by PIM-NG specifications to use 1285 this mode in small sized networks in which the number of clients are 1286 low. 1288 Bellow rules and specifications apply to Default-Mode: 1290 o It is done automatically by existing C-RPs. 1292 o It is suitable for small sized network topologies but 1293 applicable to medium and large sized networks too. 1295 o In this mode C-RP will save the state of clients to which a 1296 NULL-ACK is sent in a special table called Client Request Table 1297 (CRT). And by state PIM-NG means the unicast address of the 1298 client alongside the multicast group (G) which the client needs 1299 to find the associated source(S) for it and finally a timer 1300 which defaults to 33sec (30+3). 1302 o C-RP MUST only put an entry in CRT for the clients to which it 1303 sends a NULL-ACK. 1305 o For each (G) that the C-RP sends a NULL-ACK an entry MUST be 1306 put in CRT. 1308 o The timer which defaults to 33sec(30sec for the default 1309 periodical client request + 3sec) is a countdown timer and 1310 resets to 33sec ONLY when both of the bellow conditions are 1311 true: 1313 1- The source is not active and registered within 33seconds. 1315 2- C-RP receives clients periodical Request For source within 1316 33sec which shows that the client is still interested in 1317 finding (S) for (G). 1319 o An entry is deleted from CRT when any of the bellow conditions 1320 is true: 1322 1- The source for (G) becomes active within the time period of 1323 25 seconds or since the timer in CRT is a countdown timer 33 1324 to 8 seconds which results in C-RP sending an Acknowledge 1325 containing (S) for (G) to the client. 1327 2- The source becomes active in the time period between 8 to 0 1328 seconds and C-RP receives the periodical Request for Source 1329 form the client and responds to client's request by an 1330 Acknowledge of (S, G). 1332 3- The source is not activated within the 33sec time interval 1333 and C-RP doesn't receive the periodical Request of client for 1334 that specific (G) in 33sec which indicates that the client is 1335 not interested anymore in finding (S) for (G). 1337 4- The source is activated and registered in the time interval 1338 between 8 to 0 seconds but the C-RP doesn't receive the 1339 periodical Request for Source from the Client which shows 1340 that there client is not interested anymore in finding (S) 1341 for (G). 1343 o As long as there is an entry in CRT, for each new source (S) 1344 that becomes active C-RP MUST check the contents of CRT and 1345 check the (G) represented by newly activated source(S) against 1346 the entries inside CRT and if there is a match then depending on 1347 the time that is shown by the timer C-RP MUST act in one of the 1348 bellow ways: 1350 1- If the timer shows a time between 33 to 8 seconds, the C-RP 1351 MUST immediately send its unicast-encapsulated Acknowledge 1352 containing (S) for (G) to the client and after the timer goes 1353 off and becomes equal to 0 delete that entry from the CRT. 1355 2- If the timer shows a time between 8 to 0 seconds, the C-RP 1356 MUST NOT send an Acknowledge back to the client and MUST wait 1357 to receive the client's periodical Request for Source and 1358 then send an Acknowledge in response to the Client's Request 1359 and delete the entry from CRT. Note that each 30 seconds the 1360 client who has received a NULL-ACK will send periodical 1361 Request to C-RP and since when the timer shows 8sec we will 1362 have 3 seconds to the next periodical Request it will help to 1363 reduce C-RP's work to wait for the next periodical Request, 1364 also in case that the client is not interested anymore in 1365 finding the (S) for (G) then at this point it will be a waste 1366 of C-RP resources to send an Acknowledge after the timer 1367 passes the 8sec. 1369 o For Default-Mode to work without problem the timers on all 1370 routers MUST be the same. Thus the C-RP sends the value of the 1371 Timer set on it in the Null-ACK packet in the GDPT field so that 1372 the synchronization is done automatically. 1374 o If the default timer is changed by an administrator, the time 1375 range in which the C-RP is to send a notification MUST be 1376 between the higher limit and the 8 seconds. so if for instance 1377 the time is set to 60 then C-RP MUST only send notifications 1378 between 60 to 8 seconds. 1380 The above being explained and since the involved processes will keep 1381 the C-RP a little busier it is suggested to use this mode in 1382 topologies with a low number of clients although this mode works 1383 perfectly under any topology. Also it must be noted and considered 1384 that due to the unique Domain concept(4.6.1.1. ) introduced by PIM-NG 1385 which allows implementing the Sub-Domain concept(section 4.6.5) it is 1386 possible to divide any large multicast domain to a number of smaller 1387 domains which then makes it possible to easily use the Default-Mode 1388 under any network topology. 1390 4.2.4.2. Delay prevention in Admin-Mode 1392 This mode is a suitable choice for large network topologies with many 1393 clients which will reduce the work overhead of C-RP'(s). and is 1394 suggested to be used in scenarios in which C-MAPPER'(s) are 1395 considered and also the Sub-Domain concept is not considered. 1397 Bellow rules and specifications apply to Admin-Mode: 1399 o The Admin-Mode as the name implies needs to be activated on all 1400 existing C-RPs by an administrator. 1402 o For each Client's Request for Source to find the (S) for (G) 1403 that the C-RP sends a NULL-ACK of (*, G) an entry MUST be put in 1404 CRT. 1406 o The entry in CRT is as explained in Default-Mode. 1408 o As long as there is an entry in CRT, for each new source (S) 1409 that becomes active C-RP MUST check the contents of CRT and 1410 check the (G) represented by newly activated source(S) against 1411 the entries inside CRT and if there is a match then depending on 1412 the time that is shown by the timer C-RP MUST act in one of the 1413 bellow ways: 1415 1- If the timer shows a time between 33 to 8 seconds and 1416 Dynamic RP discovery type 1(4.4.2.2. ) is in use, the C-RP 1417 which is also acting as the C-MAPPER MUST send a Multicast 1418 Notification called New-Activated-Source-Notification(NASN) 1419 to the entire population of PIM-NG-AWARE routers using the 1420 destination address 239.0.1.190 which is used by this draft 1421 for the simplicity in explaining the processes as the address 1422 used by C-MAPPER'(s) when sending multicast introductions or 1423 notification within the multicast domain. This notification 1424 contains either only all the (G) for which there is an entry 1425 in CRT or both the (G) and the unicast address of the source 1426 (S) representing (G). both methods can be used although the 1427 later is faster approach but less secure because it is not a 1428 good approach to let all the clients know about the unicast 1429 address of all the sources that are active in the domain. 1431 2- If the timer shows a time between 33 to 8 seconds and 1432 Dynamic RP discovery type 2(4.4.2.3. ) is in use, then the C- 1433 RP MUST send a unicast-encapsulated New-Activated-Source- 1434 Notification to the closest Active C-MAPPER the way it sends 1435 its introductions. This notification contains either only all 1436 the (G) for which there is an entry in CRT or both the (G) 1437 and the unicast address of the source (S) representing (G). 1438 both methods can be used although the later is faster 1439 approach but less secure because it is not a good approach to 1440 let all the clients know about the unicast address of all the 1441 sources that are active in the domain. After C-MAPPER 1442 receives the C-RP notification it will send out a multicast 1443 notification to the entire population of PIM-NG-AWARE routers 1444 within the domain using the destination address 239.0.1.190. 1446 3- If the timer shows a time between 8 to 0 seconds, the C-RP 1447 MUST NOT send the notification to the C-MAPPER and MUST wait 1448 to receive the client's periodical Request for Source and 1449 then send an Acknowledge in response to the Client's Request 1450 and delete the entry from CRT. Note that each 30 seconds the 1451 client who has received a NULL-ACK will send periodical 1452 Request to C-RP and since when the timer shows 8sec we will 1453 have 3 seconds to the next periodical Request it will help to 1454 reduce C-RP's work to wait for the next periodical Request, 1455 also in case that the client is not interested anymore in 1456 finding the (S) for (G) then at this point it will be a waste 1457 of C-RP resources to send an Acknowledge after the timer 1458 passes the 8sec. 1460 4- In all the above conditions, after the C-RP receives the 1461 client's request for source representing (G) for each (G) 1462 there is an entry in CRT, the C-RP MUST delete the entry for 1463 that (G) from the CRT after the timer goes off and is equal 1464 to 0. 1466 o All the clients receive the notification and those that have 1467 received a NULL-ACK for (G) will send their queries to C-RP 1468 again only if there is an entry for (G) they had received a 1469 NULL-ACK for. Since considering that if the clients send their 1470 queries immediately RP might get too busy, then each client MUST 1471 activate a 3 second timer and after the timer goes off will send 1472 its query. Or if the notification contains the unicast address 1473 of the source too then clients will be able to join the SPT for 1474 (S, G) immediately. it is possible to make modifications so that 1475 this special notification is only readable by clients that have 1476 received a NULL-ACK 1478 +-----------------------------------------------------+ 1479 |Client unicast addr| Requested Group (G) |Timer | 1480 +-----------------------------------------------------+ 1481 | | | | 1482 +-----------------------------------------------------+ 1483 Figure 13 Client Request Table (CRT) 1485 0 1 2 3 1486 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 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 |PIM Ver| Type | Reserved | Checksum | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | D O M A I N | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | C-MAPPER's unicast address | 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 | Activated Group 1 (G-1) | 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 | . . . | 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | Activated Group N (G-N) | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 Figure 14 New-Activated-Source-Notification message format 1502 o Type: NASN (New-Activated-Source-Notification) 1504 4.3. Communication between PIM-NG routers 1506 It is important, that connected PIM-NG neighbor routers maintain a 1507 steady state of connection. In order to do this PIM-NG routers will 1508 send periodic HELLO messages or simply called Keep-Alive messages to 1509 their neighbors. 1511 This HELLO messages will be sent to the address 224.0.0.13, all PIM 1512 routers. 1514 What is changed is not the process of sending, rather the contents of 1515 the hello message. A new hello packet is defined and compared to the 1516 original PIM-SM specifications, Figure 15. 1518 Original PIM-SM HELLO packet 1520 0 1 2 3 1521 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 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 |PIM Ver| Type | Reserved | Checksum | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | OptionType | OptionLength | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | OptionValue | 1528 | ... | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | . | 1531 | . | 1532 | . | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | OptionType | OptionLength | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | OptionValue | 1537 | ... | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 PIM-NG hello packet 1542 0 1 2 3 1543 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 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 |PIM Ver| Type | Reserved | Checksum | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 |R|E|Z| | 1548 |M|D|T| Reserved | 1549 |G|C| | | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | D O M A I N | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | PIM Domain topology table | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | JOINED GROUPS TABLE | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | OptionValue | 1558 | ... | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | . | 1561 | . | 1562 | . | 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | OptionType | OptionLength | 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | OptionValue | 1567 | ... | 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 Figure 15 original PIM-SM hello packet compared with the new hello 1570 packet format 1572 Type: HELLO 1574 New fields are added to the new packet which in later sections their 1575 usage will be covered: 1577 1- RM-BIT: can be set to 1 by the sending neighbor to inform the 1578 other neighbors about the existence of the C-MAPPER incase dynamic 1579 methods are being used. A value of 0 indicates that the neighbor 1580 doesn't know about any RP or C-MAPPER. 1582 2- EDG-BIT: if set indicates to all downstream CLIENTS that a PIM 1583 EDGE-Client exists in the network to limit the propagation of 1584 multicast introductions sent by C-MAPPERs and C-RPs. And to 1585 register a multicast source the clients MUST send the register 1586 message directly to the EDGE-CLIENT which is responsible of NAT 1587 operations. The EDGE-CLIENT can be considered as the DR of a Multi- 1588 Access Network which is part of one PIM-NG Multicast Domain. 1589 Downstream routers need to look into PIM DOMAIN TOPOLOGY TABLE to 1590 find the address of EDGE-CLIENT, if the EDGE-BIT is set. 1592 3- ZTC-BIT: if set indicates that there has been a change in the 1593 multicast groups the CLIENT has joined the SPT for. a PIM-NG-CLIENT 1594 will set this bit in case there has been a change in its JOINED 1595 GROUP TBALE and will send the table in the hello message. 1597 4- Domain field: a 32 bit field used to announce the Domain a PIM-NG- 1598 ROUTER is resided in to the neighbors. Only PIM-NG-ROUTERs with 1599 matching Domains can become neighbor. 1601 5- PIM Domain topology table: this table as described before in the 1602 definition section, holds the information related to the C-RP'(s), 1603 C-MAPPER'(s) and other components. What is included in this table 1604 is actually the unicast addresses of each of the components 1605 mentioned. 1607 6- JOINED GROUPS TABLE: holds the list of all the multicast groups a 1608 PIM-NG-CLIENT has joined the SPT for and is receiving the related 1609 traffic, in the format of (S, G) or (S, S, G) which the first S 1610 indicates the unicast address of the PIM-NG-CLIENT which is sending 1611 the traffic to the domain and the second S indicates the address of 1612 the host or server inside the LAN behind the client. this table 1613 will help clients in the process of sending join messages to the 1614 source of a multicast group in case their neighbors are already 1615 receiving that traffic : 1617 o the client in need of receiving multicast traffic for 1618 (*,G)or(S,G) first looks inside this table to see if the 1619 neighbor PIM-NG-CLIENTS has already joined the group and 1620 receiving the traffic ,before asking the C-RP for the unicast 1621 address of the source. 1623 o If there is an entry in this table for the multicast group it 1624 needs it will send a join/prune message to the neighbor for 1625 that group. 1627 o If there is no entry for the multicast group it needs in this 1628 table, it will then ask the C-RP. 1630 o A CLINET will send the table only incase that there has been a 1631 change in its internal JOINED GROUP TABLE , like joining the 1632 SPT for a new group or leaving/pruning from a group .in such 1633 cases client must inform the neighbors by setting the ZTC-BIT 1634 in its hello message. 1636 +-----------------------------------------------------+ 1637 |Source unicast addr| Role | priority |Domain|TR Group| 1638 +-----------------------------------------------------+ 1639 | | | | | | 1640 +-----------------------------------------------------+ 1641 | | | | | | 1642 +-----------------------------------------------------+ 1643 Figure 16 PIM domain topology table (PDTT) 1645 o Source unicast address field: holds the unicast address, related 1646 with either one of C-MAPPER, C-RP, SC-MAPPER, BPR or EDGE-CLIENT. 1648 o Role: indicates that the address entry inside the source unicast 1649 address field belongs to what component of the PIM-NG domain: 1651 1. C-MAPPER(C-M) and SC-MAPPER(SC-M)with binary codes 1 and 2 1653 2. C-RP and SC-RP with binary codes 3 and 4 1655 3. A ROLE of EDGE with binary code 9, can be seen in designs, that 1656 to reduce the propagation of multicast introduction messages, a 1657 Client is chosen to act as the EDGE-CLIENT and will not pass any 1658 multicast introductions received on external interfaces to 1659 internal interfaces. In such a design the EDGE-CLIENT IS 1660 responsible of introducing only the existing TR'(S) to its 1661 downstream clients by sending the PIM-DOMAIN TOPOLOGY TABLE to 1662 downstream neighbors. An EDGE-CLIENT MUST BE ONLY used in parts 1663 of a PIM-NG multicast network where no C-MAPPER, C-RP or TR 1664 exists. And the downstream routers MUST BE only clients. Also in 1665 such networks a multicast source can use private IP addresses, 1666 and such a source MUST send register messages to the existing 1667 EDGE-CLIENT'(s). Related concepts will be explained in the 1668 appropriate section'(S). 1670 4. A role of PPER (PRIVATE-PIM-EDGE-ROUTER) with binary code 8 can 1671 be seen when a private PIM-NG domain is connected to another 1672 domain through the use of PIM-EDGE-ROUTERs which are responsible 1673 for the process of NETWORK ADDRESS TRANSLATION (NAT). 1675 5. A role of BPR with binary code 10 can be seen in designs where 1676 a PIM-NG multicast domain is connected to a PIM-SM multicast 1677 domain. The information related to BPR is locally significant to 1678 C-MAPPER and won't be sent to all PIM-NG routers. 1680 6. A role of STC-MAPPER (STANDBY-C-MAPPER) with binary code 5 can 1681 be seen in network designs with PEER-C-MAPPERs inside the same 1682 Domain. In the case of existing Peer C-MAPPERs, C-RPs will use 1683 the closest C-MAPPER to propagate the information associated 1684 with existing sources inside the domain. 1686 7. A role of TR with binary code 6 can be seen in case any TR 1687 implementations are considered inside the domain. Please do note 1688 that a C-MAPPER or C-RP can take the role of TR too or the TR 1689 can be a separate and unique PIM-NG-AWARE-ROUTER inside the 1690 domain. 1692 8. A role of C-TR (core-TR) with binary code 7 can be seen in PIM- 1693 NG-DOMAINs. It indicates the existence of a core-domain and the 1694 unicast address of any existing TR inside the core domain for 1695 further use by clients inside each domain. 1697 o Priority: this field holds the priority related to an EDGE-CLIENT 1698 and is used only in hello packets sent to private networks by an 1699 edge-client. Related concepts will be discussed later. 1701 o DOMAIN: in case separate PIM-NG multicast domains are going to be 1702 connected to each other through the use of an EDGE router, the 1703 Domain to which a PIM-EDGE-ROUTER is connected will be informed 1704 inside this field. This field is usable by C-MAPPERs inside each 1705 domain and thus won't be sent to ALL-PIM-NG-CLIENTS by C-MAPPER 1706 when sending introductions to 239.0.1.190. 1708 o TR Group: this field indicates the TR group each TR belongs too 1709 and is set to 0 by default. It is ONLY set by C-MAPPER or the 1710 Active C-MAPPER and is used in Bidirectional PIM-NG processes. 1712 When a PIM-NG-CLIENT receives a join message from its neighbor for a 1713 multicast group, that it is joined to and is receiving the traffic 1714 for, it will then forward the traffic on the interface that the 1715 neighbor is connected to and towards that neighbor. 1717 The definitions given by the original PIM-SM [7] are applicable to the 1718 other fields. 1720 4.4. RP discovery 1722 RP discovery in general, points to the processes involved in, how a 1723 Client finds the C-RP in the first place to send a request to and 1724 reach the destination it wants. 1726 In PIM-NG RP discovery is done in 3 different conditions or better to 1727 say network topologies. Choosing the best solution depends on the 1728 specifications of the network and will be decided by network 1729 administrators. 1731 Bellow the 3 different RP discovery solutions are briefly defined, 1732 and will be explained later: 1734 1- Static RP discovery : 1736 The unicast address of C-RP is statically given to each PIM-NG 1737 router through special commands. 1739 2- Dynamic RP discovery type 1 : 1741 Type 1 is used in networks not so big to need redundant RPs. and 1742 also used in order to make the process of RP discovery easier and 1743 more scalable. This type uses its own set of commands for the sake 1744 of simplicity in explaining the processes .in this type of RP- 1745 DISCOVERY a router is given the role of both C-MAPPER and C-RP 1747 3- Dynamic RP discovery type 2 : 1749 Type 2 is used in large networks with many routers, which will need 1750 to have C-RP redundancy. Also this type is suitable for the future 1751 needs of World Wide Web (internet). This type uses its own set of 1752 commands for the sake of simplicity in explaining the processes. In 1753 this type C-MAPPER and C-RP'(s) are different routers. 1755 In the following sections the above three RP discovery methods will 1756 be discussed. 1758 Also please note that any command line written in this document from 1759 this point forward is just to provide a good sense of understanding, 1760 and to provide simplicity in explaining the processes involved and 1761 shall not be taken as the solid command line to be used. Also to make 1762 the explanation process and the understanding easier some of the 1763 processes and specifications are explained through scenarios and 1764 examples. 1766 4.4.1. Static RP discovery 1768 As the name indicates, the unicast address of the C-RP which is the 1769 IP address of a loop back interface created on RP, is set on each PIM 1770 router so the PIM routers will be able to communicate with RP. 1772 The process is as follows: 1774 1- A loopback interface, typically loopback0 is created on RP and an 1775 IP address is assigned to it. 1777 2- The candidate RP router will know that it is the RP and will have 1778 to use its loopback 0 by initiating the command : 1780 <# IP PIM-NG SET-RP SOURC-LO "x" INTERFACE X, INTERFACE Y, INTERFACE 1781 Z.> 1783 by initiating this command on the router, the router understands that 1784 it is the RP and it will have to use its loopback 0 unicast address 1785 to communicate, or better to say it will use its loopback 0 in the " 1786 source unicast address field " and also if it sees its loopback 0 1787 unicast IP address as the destination of a PIM-NG packet it will have 1788 to answer to that packet. And also it will have to bring its 1789 interface "X, Y, Z" in to the PIM game. 1791 3- On all the other PIM routers the bellow command is initiated : 1793 <# IP PIM-NG CLIENT RP-ADDRESS "X.Y.Z.W" INTERFACE "X", INTERFACE 1794 "Y"> 1796 This command tells the router that it is a client of the RP with 1797 address of "X.Y.Z.W" .and to find any source or to be able to send 1798 multicast traffic to any host looking for that traffic, it will have 1799 to contact the RP through the processes explained before. And also it 1800 will have to bring its interface "X, Y" in to the PIM game. 1802 Since the C-MAPPER plays a significant role when it comes to 1803 connecting different PIM-NG multicast domains and for exchanging the 1804 information related to existing multicast sources in each domain the 1805 C-RP takes the role of a C-MAPPER too in the static mode. But no C- 1806 MAPPER introduction messages will be generated by the C-RP within the 1807 multicast domain and the additional role of C-MAPPER is only used 1808 when exchanging information related to existing multicast sources 1809 with other domains. 1811 A PIM-NG specification advises that a mechanism be implemented 1812 through which any existing components such as PPER'(s) and BPR'(s) 1813 MUST learn about the C-MAPPER or better to say the existing C-RP 1814 through static configuration of the C-RP unicast address. 1816 In case any TR exists within the multicast domain or the domain is 1817 connected to a PIM-NG core domain, PIM-NG strongly advises that the 1818 unicast address of existing TR'(S) be introduced to each Client 1819 through static configuration since there will be no C-MAPPER 1820 introduction in the static RP discovery mode. 1822 At the end PIM-NG specifications strongly advises to implement the 1823 static RP discovery method in design plans where the multicast domain 1824 is of small size and the domain is not connected to other domains. 1825 And if the multicast domain whether big or small is supposed to be 1826 connected to another domain it is strongly advised by PIM-NG 1827 specifications to use one of the Dynamic RP discovery methods 1828 described in the following sections. 1830 Although in the final sections of PIM-NG specifications a new concept 1831 will be explained which is related to connection of a Multi-Access 1832 network which can also be considered a small sized multicast domain 1833 to another domain or a service provider multicast domain without the 1834 need for existing of any C-MAPPER, C-RP or TR in that Multi-Access 1835 network which is unique to PIM-NG. 1837 4.4.2. Dynamic RP discovery 1839 As stated before PIM-NG uses 2 types of dynamic RP discovery methods 1840 depending on the needs and the size of the network: 1842 1- Dynamic discovery type 1 1844 2- Dynamic discovery type 2 1846 4.4.2.1. Multicast IP addresses used 1848 Before explaining the processes involved in PIM-NG DYNAMIC-RP- 1849 DISCOVERY-TYPE1, there are some multicast destination group addresses 1850 that must be defined which are used in both DYNAMIC-RP-DISCOVERY 1851 methods: 1853 1- Multicast group address 239.0.1.190 : 1855 This address is reserved to be used by C-MAPPER at the time of 1856 introducing itself to other PIM-NG routers. PIM-GN routers/clients 1857 will listen to this multicast group address to find the C-MAPPER 1858 and the existing C-RPS. So a new PIM-NG C-MAPPER will send its 1859 introduction to this destination address. 1861 2- Multicast group address 239.0.1.189: this address is required to 1862 be used as the reserved range for the communication of RPs in order 1863 to hold an election between RPs incase backup RPs are needed. Also 1864 this address is used to find peers automatically in case redundant 1865 C-RP is needed in the network. 1867 3- Multicast group address 239.0.1.188 : this address is required to 1868 be used as the reserved range for the communication of MAPPERs in 1869 order to hold an election between MAPPERs incase backup MAPPERs are 1870 needed. The usage of this range will be covered later. 1872 Now that the addresses are defined, it is time to explain the process 1873 through which the PIM-NG dynamic RP discovery is done and 1874 implemented. 1876 4.4.2.2. Dynamic RP discovery TYPE-1 1878 There might be some network designs in which, the presence of only 1879 one dedicated router as the RP is adequate but for administration 1880 purposes, administrators prefer to use an automatic mechanism, so 1881 that every PIM router will know the RP. An example of such networks 1882 can be an enterprise or a company which uses multicast applications 1883 such as voice and video conference often and not always. In other 1884 words the network doesn't need to have multiple redundant RPs and 1885 also they don't use multicast applications all the time, but for the 1886 sake of easy administration and maintenance administrators prefer to 1887 use the automatic mechanism. 1889 In such a network a router will be used as the designated RP or 1890 candidate RP (C-RP), and will introduce itself to other PIM 1891 routers/clients as both C-MAPPER and C-RP .and as soon as all the 1892 clients understand about the presence of the C-MAPPER and C-RP the 1893 rest of the process is as before. 1895 The process is as follows: 1897 1- A router is chosen as the C-RP. Then like the specifications of 1898 the static RP a loopback interface is configured on it. The 1899 loopback is better to be the loopback 0 interface. 1901 2- The commands : 1903 <#IP PIM-NG DYNAMIC-RP1 SOURCE-LO "X" INTERFACE [TYPE] "X" , 1904 INTERFACE [TYPE] "Y"> and 1906 <#IP PIM-NG DOMAIN [X]> are initiated on the RP. 1908 Above commands tells the router that it is both C-MAPPER and C-RP 1909 in the network and the Dynamic discovery method used is type1 and 1910 it should use its interface loopback "X" as the C-MAPPER and C-RP 1911 unicast address in introductions. And it should bring its interface 1912 "x, y,.." into the PIM-Ng game. 1914 So router sees that it is the C-RP and the discovery protocol used 1915 is Dynamic and the discovery method is type1, and knows that: 1917 o It is the only RP in the network and also it must introduce 1918 itself as the C-MAPPER. 1920 o It is resided in domain X 1922 o It should Send multicast introduction messages to multicast 1923 address 239.0.1.190, out its interface "x, y" and any other 1924 interfaces configured to be in the PIM-NG game. 1926 o It should put the interfaces defined in the command in to 1927 forwarding for the multicast address destinations 239.0.1.188 1928 and 239.0.1.189. 1930 o It should Send periodic C-MAPPER-introduction messages every 60 1931 seconds. 1933 o If by any means it is reloaded as soon as it comes back up, it 1934 should send a multicast introduction to 239.0.1.190 ASAP. 1936 3- All the other none-RP PIM-NG routers are configured as the clients 1937 of C-MAPPER/RP. 1939 4- on PIM-NG none-RP routers(clients) commands : 1941 <#IP PIM-NG DYNAMIC-RP CLIENT INTERFACE [TYPE] "X", INTERFACE 1942 [TYPE] "Y"> 1944 <#IP PIM-NG DOMAIN [X]> are initiated. 1946 above commands tells the router that it is in a PIM-NG network and 1947 the protocol by which it can find the RP is Dynamic RP discovery 1948 .also it understands that it should bring its interface "x ,y" and 1949 any other interfaces dictated, in PIM-NG game. 1951 After entering the above commands in a none-RP or a client 1952 router'(s) the router knows that: 1954 o it is in PIM-NG domain X 1956 o It should use dynamic methods to find the RP .so it will wait 1957 to receive a C-MAPPER introduction message. 1959 o it should listen to multicast address 239.0.1.190 to hear the 1960 C-MAPPER-introduction message to learn about the C-RP/RPs 1962 o it should bring the interfaces mentioned in the command in PIM- 1963 NG game 1965 o It should put the interfaces mentioned in the command in 1966 forward for the address 239.0.1.190 so others will hear the C- 1967 MAPPER introduction message. Also it should put those interfaces 1968 in to forwarding state for group addresses 239.0.1.189 and 1969 239.0.1.188. 1971 o If it doesn't receive the address of the C-MAPPER in the first 1972 hello-acknowledge received from the neighbor, it should wait to 1973 hear from the C-MAPPER. 1975 Now that the overall process is covered, in the next section the way 1976 RP and clients communicate will be explained and the new packet 1977 formats will be shown. 1979 4.4.2.2.1. RP introduction process 1981 As soon as the router designated as the C-RP and C-MAPPER, is 1982 configured and knows that it is the only RP in the network, it will 1983 start the process of introducing itself as the C-MAPPER to the 1984 network by sending the C-MAPPER-INTRODUCTION massage to the multicast 1985 destination address 239.0.1.190 (Figure 17). 1987 0 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 |PIM Ver| Type | Reserved | Checksum | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | D O M A I N | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 |R| | | |Z| | | 1995 |M|A| G R O U P |P R I O R I T Y|T|B| R E S E R V E D | 1996 | | | | | |C| | | 1997 | | | | |N| | | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | HOLD TIME | R E S E R V E D | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | C-MAPPER's unicast address | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | SC-MAPPER'S unicast Address | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | PIM domain topology table | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 Figure 17 C-MAPPER-INTRODUCTION massage sent to 239.0.1.190 2009 o Type: C-MAPPER-INTRODUCTION 2011 o RM-BIT field : if set to 1 in a C-MAPPER introduction message sent 2012 to 239.0.1.190 , tells to all PIM-NG CLIENTS that only 1 RP exists 2013 in the domain .so the address of the C-MAPPER is the unicast 2014 address of C-RP . If this bit is not set to 1 then indicates to all 2015 PIM-NG CLIENTS that in order to find existing C-RPs they should 2016 read the contents of PDTT. 2018 o A-BIT field: is set to 0 in this type. Its usage will be discussed 2019 later. 2021 o GROUP and PRIORITY fields: 8 bit fields, and are set to all zeros 2022 when sending introduction to 239.0.1.190 .and clients won't read 2023 the contents of these fields. 2025 o ZTCN-BIT field : if a C-MAPPER needs to inform ALL-PIM-NG-CLIENTS 2026 about a change it will set this bit, also if a C-MAPPER needs to 2027 inform a change in the domain to SC-MAPPER or PEER C-MAPPERs ,it 2028 will set this bit .use will be discussed later. 2030 o B-BIT: Bidirectional Bit. If set to 1 in such introduction message 2031 indicates that the domain uses the manual mode(4.7.2.1. ) and for 2032 any multicast group found in Bidirectional Groups Table sources and 2033 receivers MUST immediately join the SPT rooted at closest TR. 2035 o DOMAIN: indicates the domain in which a C-MAPPER resides. It can 2036 be used as either a security factor or as an scoping mechanism so 2037 that clients and C-RPs inside one domain wont react to the 2038 introductions sent from a C-MAPPER in another domain. 2040 o PIM Domain topology table (PDTT): when the RM-BIT is set the C- 2041 MAPPER won't send this table in its introductions sent to 2042 239.0.1.190, unless a TR is considered in the domain. 2044 The Type field is set to C-MAPPER-INTRODUCTION1 so the clients 2045 receiving the packet will know that it is an introduction message 2046 sent from the C-MAPPER and will look directly into the "SOURCE 2047 UNICAST ADDRESS" field. The address field contains the unicast 2048 address of the interface loopback "X" of the C-MAPPER.and the next 2049 field contains the address of the SC-MAPPER if any exists. 2051 After sending the first introduction message , C-MAPPER/RP sets a 2052 timer of 60 seconds and starts counting down to 0 ,and resends the 2053 introduction message so all the PIM-NG routers will know that the C- 2054 MAPPER still exists. 2056 4.4.2.2.2. Back up C-RP considerations 2058 If any backup C-RP is needed to be considered in such networks 2059 explained above for the sake of high availability a mechanism for the 2060 negotiation between the RPs and election of the candidate RP(C-RP) is 2061 needed. 2063 The process is as follows: 2065 1- The addition of to the command tells the router 2066 its group number and the PEER RP GROUP[X] tells the router that 2067 there is another RP which it must become peer with but since the 2068 group number of the peer is the same as its own value an 2069 election is needed to elect the C-RP and SC-RP. The values in 2070 front of the GROUP means that all the RPs belong to one unified 2071 group. The usage of the GROUP will later be more clarified. and 2072 the at the end of the command 2073 will define each C-RP's priority in the election process : 2075 <#IP PIM-NG DYNAMIC-RP1 SOURCE-LO "X" INTERFACE [TYPE] "X" , 2076 INTERFACE [TYPE] "Y"> 2078 <#IP PIM-NG GROUP [X] PRIORITY[VALUE]> 2079 <#IP PIM-NG PEER RP GROUP[X] ADDRESS> 2081 2- If the address of the peer is not used, RPs will send multicast 2082 introduction messages to the reserved address 239.0.1.189, so 2083 the other RP/RPS will find each other. 2085 3- An election based on the highest priority configured on each C- 2086 RP , or highest C-RP unicast address will be held between the C- 2087 RPs 2089 4- The candidate RP will take the responsibility of both C-MAPPER 2090 and C-RP as explained above 2092 5- RPs will send unicast keep-alive messages to each other every 2093 30 second. 2095 6- The candidate RP, C-RP, will send a copy of its multicast- 2096 mapping table only incase that any changes occur in the domain. 2097 And C-RP periodical introduction messages to SC-RP wont contain 2098 any MULTICAST MAPPING table. 2100 7- In case any changes occur C-RP will set the Z-BIT inside its 2101 introduction message to SC-RP which indicates that a change has 2102 occurred. 2104 8- If more than 2 RPs are considered in a network design, an 2105 election between none candidate RPS will be held to choose the 2106 second best choice (SC-RP) to be the RP if the candidate RP is 2107 dead. 2109 9- The candidate C-RP which has the role of C-MAPPER too, will 2110 send the unicast address of the second best candidate as SC- 2111 MAPPER in its introduction message sent to all PIM-NG routers 2112 every 60 second for further use by PIM-NG clients. 2114 10- PIM-NG clients will write the address of the C-MAPPER, SC- 2115 MAPPER and C-RP in a special table called PIM Domain Topology 2116 Table (PDTT) for further use. 2118 11- If SC-MAPPER/RP doesn't receive any INTRODUCTION/KEEPALIVE- 2119 MESSAGE from the C-MAPPER/RP in 2*INTRODUCTION/KEEPALIVE-MESSAGE 2120 plus 5 seconds timer (2*30+5) it will immediately take the place 2121 of the C-RP and send a multicast introduction to 239.0.1.190. 2123 12- If the SC-MAPPER/RP receives a REQUEST-FOR-C-MAPPER message 2124 from a client asking about the existence of the C-MAPPER in 70 2125 seconds it will react in 2 ways : 2127 o It will immediately query the C-MAPPER/RP by sending an 2128 introduction message and if it receives a KEEP-ALIVE message 2129 from the C-MAPPER/RP which means the C-MAPPER/RP is still 2130 alive then it assumes that the client which is looking for 2131 C-MAPPER/RP is having problems .so it will return the 2132 address of the current C-MAPPER/RP back to the host in a 2133 unicast C-MAPPER-INTRODUCTION (Figure 17) 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 |PIM Ver| Type | Reserved | Checksum | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | D O M A I N | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 |R| | | |Z| | 2143 |M|A| G R O U P |P R I O R I T Y|T| R E S E R V E D | 2144 | | | | | |C| | 2145 | | | | |N| | 2146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 | C-MAPPER's unicast address | 2148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2149 | SC-MAPPER'S unicast Address | 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | PIM domain topology table | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2153 Figure 18 SC-MAPPER/RP answers to a host REQUEST-FOR-C-MAPPER message 2155 o Type: C-MAPPER acknowledge 2157 o If SC-MAPPER/RP hasn't received KEEP_ALIVE messages for the 2158 past 2*30 seconds , then it should not receive such a 2159 message, as by now SC-MAPPER/RP must had taken the place of 2160 C-MAPPER/RP and sent out a C-MAPPER introduction to 2161 introduce itself. (Figure 18). 2163 0 1 2 3 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 |PIM Ver| Type | Reserved | Checksum | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | D O M A I N | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 |R| | | |Z| | | 2171 |M|A| G R O U P |P R I O R I T Y|T|B| R E S E R V E D | 2172 | | | | |C| | | 2173 | | | | |N| | | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | HOLD TIME | RESERVED | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | C-MAPPER's unicast address | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 | SC-MAPPER'S unicast Address | 2180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 | PIM domain topology table | 2182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2183 Figure 19 SC-MAPPER/RP multicast introductions to all PIM-NG-CLIENTS 2185 Type: C-MAPPER INTRODUCTION1 2187 If clients see the address of the SC-MAPPER in the C-MAPPER unciast 2188 address field they will assume that the current C-MAPPER is dead and 2189 will update their tables with the new one. 2191 13- If the previous C-MAPPER/RP gets back again then another 2192 election will be held between RPS and the C-RP will introduce 2193 itself. 2195 14- All PIM-NG routers will put their interfaces inside the game 2196 of PIM-NG into forwarding for the group address 239.0.1.189 and 2197 239.0.1.188 and won't listen to these packets. Only will forward 2198 them. 2200 [Figure is presented in PDF version] 2202 Figure 20 PIM-NG network with backup RP (SC-RP) 2204 RP introduction packet formats are shown below: 2206 0 1 2 3 2207 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 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 |PIM Ver| Type | Addr length | Checksum | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | D O M A I N | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 |P|Z| PRIORITY | GROUP | MESH-PRIORITY |R|reserved | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 | HOLD TIME | RESERVED | 2216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2217 | RP'S unicast address | 2218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2219 | Sc-RP unicast address | 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | PEER list | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | Multicast MAPPING table | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | A-Multicast mapping table | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 Figure 21 RP introduction message format 2229 o Type: RP introduction 2230 o P-BIT field (PEER): is used when a C-RP wants to become peer with 2231 another C-RP. C-RP sets this bit to 1 and sends an introduction to 2232 239.0.1.189. By seeing this bit set only C-RPs configured to become 2233 peer with another C-RP from a different Group will react to the 2234 message contents. Others will only forward. 2236 o Z-BIT field (ZONE TOPOLOGY CHANGE NOTIFICATION): this bit is set 2237 to 1 in case a C-RP needs to inform the SC-MAPPER C-MAPPER or 2238 peering C-RP about any changes occurred. when this bit is set ,the 2239 C-RP will then sends out one of the tables shown in Figure-34 2240 depending on the fact that to whom this introduction is being sent 2241 and in what type of domain it is resided. 2243 o Group field: 8 bit field containing the group that the C-RP is a 2244 member of. Helps the C-RPs to see if the packet is sent from a C-RP 2245 they are configured to become peer with or in cases that backup C- 2246 RP is needed. This field is set to all ZEROs when sending to a C- 2247 MAPPER. 2249 o Priority field: is only used when finding and communicating with 2250 SC-RP. Otherwise set to all ZEROs. 2252 o Mesh-priority: will be used in the process of electing the active 2253 C-RP in a MESH-Group. 2255 o R-BIT: if set to 1 by a C-RP, indicates to the C-MAPPER that the 2256 RP has the role of TR too. 2258 o SC-RP unicast address: will be sent only when introducing to PEER- 2259 C-RPs or C-MAPPER.and not to a back up RP. 2261 o DOMAIN: indicates the domain the C-RP is a member of. helps the C- 2262 RP to differ between the packets received from C-RPs inside other 2263 domain in an special design of multiple PIM-NG multicast domains. 2265 o Multicast MAPPING table (MMT): it is sent only when introducing to 2266 SC-RP.and is sent in case any changes occur. 2268 o A-Multicast MAPPING table (AMMT): this table is sent by a C-RP to 2269 C-MAPPER in case it realizes that the domain it is resided in is 2270 connected to another domain, or there are multiple C-MAPPERs 2271 resided in the domain. When the C-RP receives a C-MAPPER 2272 introduction with the A-BIT set, it starts to send this table to 2273 the C-MAPPER. Also this table is sent by C-RP to PEER-C-RPs if any 2274 PEER-C-RP exists. 2276 o Hold time: is used only when introducing to C-MAPPER and indicates 2277 the amount of time C-MAPPER will expect to hear C-RP keep-alive 2278 message. 2280 0 1 2 3 2281 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 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2283 |PIM Ver| Type | Addr length | Checksum | 2284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2285 | D O M A I N | 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 |P|Z| PRIORITY | GROUP | MESH-PRIORITY |R|reserved | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | HOLD TIME | RESERVED | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | RP'S unicast address | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | PEER list | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | Multicast MAPPING table | 2296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2297 | A-Multicast mapping table | 2298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 Figure 22 C-MAPPER/RP unicast HELLO/KEEP-ALIVE message to back up RPs 2301 o Type: RP introduction 2303 4.4.2.2.3. PIM-NG clients processes in Dynamic-RP 2305 PIM-NG router/client processes are related to the process of 2306 forwarding special multicast traffics by default out of the 2307 interfaces which are in the game of PIM-NG, and the processes of 2308 finding RP and maintain connectivity with RP and PIM-NG neighbors. 2310 The processes are as follows: 2312 1- Each PIM-NG router using DYNAMIC-RP-DISCOVERY will put its 2313 interfaces inside the game of PIM-NG, in to forward for the 2314 multicast address groups 239.0.1.189, 239.0.1.190 and 239.0.1.188. 2316 2- PIM-NG clients need to read the content of RM bit inside C-MAPPER 2317 introduction messages to interpret the topology of the network. If 2318 this bit is set to 1, it means that only one C-RP exists in the 2319 network and the unicast address of the C-MAPPER inside the 2320 introduction message is the real address of the C-RP. If this bit 2321 is not set then clients will assume that there are possibly more 2322 than 1 C-RP in the network and in order to find the unicast address 2323 of C-RP or C-RPs they will have to read the contents of PIM domain 2324 topology table, and update their local PDTT with the information 2325 provided in this table by C-MAPPER. 2327 3- Each PIM-NG router maintains connectivity with its neighbor PIM-NG 2328 router through the process of sending periodic HELLO/KEEP-ALIVE 2329 messages to its neighbor every 30 seconds. 2331 4- If no HELLO message is received from the neighbor router in 2332 2*HELLO time, the entry for that neighbor is erased. 2334 5- If a PIM-NG router doesn't hear from the C-MAPPER in 70 2335 seconds(periodic C-MAPPER introduction+10sec) it will act as 2336 follows : 2338 o It will send a unicast REQUEST-FOR-C-MAPPER message to the address 2339 of the SC-MAPPER if any SC-MAPPER does exist in the network and 2340 waits for the response from the SC-MAPPER/RP as described in the 2341 previous section (4.4.2.2.2. ) .Figure 22 shows the format of the 2342 packet. 2344 0 1 2 3 2345 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 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 |PIM Ver| Type | Reserved | Checksum | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | D O M A I N | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | Clients unicast address | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 | C-MAPPER's unicast address | 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 Figure 23 request- for-C-MAPPER packet sent to the SC-MAPPER 2357 o Type: REQUEST-FOR-C-MAPPER 2359 o The Client (i.e. R4) puts its own address in the client unicast 2360 address field and the unicast address of the SC-MAPPER/RP in the 2361 C-MAPPER unicast address field. 2363 o If no SC-MAPPER/RP exists then it will query the neighboring PIM- 2364 NG routers by sending a HELLO packet with the RM-BIT set to 0, 2365 indicating that it doesn't know any C-MAPPER. 2367 o If it doesn't receive the C-MAPPER's unicast address from the 2368 neighbor in the first hello inside the Pim-domain-topology-table 2369 or if the C-MAPPER address received from the neighbor PIM-NG 2370 router is the same as its own current entry for the C-MAPPER then 2371 it should wait to hear from the C-MAPPER. 2373 4.4.2.2.3.1. New PIM-NG router/client 2375 In this section, actions taken by a new PIM-NG router added to the 2376 network using DYNAMIC-DISCOVERY without any knowledge about the C-RP 2377 is explained: 2379 1- Puts its interfaces defined by the related commands in to 2380 forwarding for the multicast address groups 239.0.1.189/40/188 2382 2- Sends HELLO message to all PIM routers address of 224.0.0.13 out 2383 of the interfaces in the game of PIM-NG, to introduce itself to the 2384 neighbor PIM-NG routers. 2386 3- If in the first received HELLO message from the neighbor it sees 2387 the unicast address of the C-MAPPER it will use it and updates its 2388 PMTT. 2390 4- If no C-MAPPER address is seen in the HELLO packet received from 2391 the upstream neighbor, it will wait to hear an introduction from 2392 the C-MAPPER or receive it inside the next hello messages sent from 2393 the neighbor. 2395 5- If in the Hello message received the EDGE-BIT is set, it assumes 2396 that it is inside a private network, and it may have to act 2397 differently in order to register a source with the C-RP. The 2398 related concepts will be discussed later in a separate section. 2400 [Figure is presented in PDF version] 2402 Figure 24 New client added 2404 4.4.2.3. Dynamic RP discovery type 2 2406 In previous sections the processes related to the dynamic RP 2407 discovery type 1 in which there are no needs for redundant RPs and 2408 networks seems to be of small to medium size has been described. Now 2409 let us consider larger networks. In larger networks (i.e. internet or 2410 enterprises) with many multicast actions and sessions in process, the 2411 high availability of the RPs and also load balance between RPs 2412 through using redundant RPs becomes an important factor. 2414 In fact hosts in different parts of a large network must be able to 2415 find the desired source as fast as possible, if the source exists. So 2416 as described by the original PIM-SM specifications, the network will 2417 need redundant RPs alongside a new feature called MAPPING-AGENT or 2418 simply PIM-NG-C-MAPPER. 2420 C-MAPPER is in charge of introducing C-RPs to all PIM-NG routers. And 2421 the process is in parts like the original PIM-SM RFC 4601[7], and in 2422 parts different. Bellow the steps involved in the process of PIM-NG 2423 is briefly described and later will be explained in details: 2425 1- C-MAPPER introduces itself to all PIM-NG routers, so that everyone 2426 knows about its address. 2428 2- C-RP'(s) introduce themselves to the C-MAPPER, by sending unicast 2429 RP introductions to the C-MAPPER's address. So they wait to receive 2430 a C-MAPPER introduction. 2432 3- If any TR exists in the multicast domain, it MUST introduce itself 2433 to the closest C-MAPPER. 2435 4- C-MAPPER will send discovery messages or introduction messages to 2436 PIM-NG routers to inform them about the existence of the RPs so 2437 sources can use the RP address to introduce themselves to the 2438 nearest RP. 2440 5- Clients or simply put all none PIM-NG C-MAPPER, RP and TR routers 2441 will use the C-MAPPER to find RP'(s) or TR'(s). 2443 6- Clients or simply put ALL none PIM-NG C-MAPPER, RP and TR routers 2444 will either only-forward specific multicast address groups or 2445 listen to them . 2447 Figure 25 will be used as the basic topology to explain the process 2448 related to an enterprise network with one multicast domain. 2450 [Figure is presented in PDF version] 2452 Figure 25 network design with one multicast domain 2454 In the following sections processes related to different components 2455 of a PIM-NG domain will be explained. 2457 4.4.2.3.1. Client related concepts 2459 The processes related to a client are as described in section 2460 4.4.2.2.3. . 2462 Clients will choose the closest C-RP or C-MAPPER according to their 2463 unicast routing information. And if there is a tie, they will choose 2464 based on the highest C-RP or C-MAPPER IP address that can be found 2465 inside the PMTT information received with the C-MAPPER introduction 2466 message. 2468 4.4.2.3.2. C-MAPPER concepts 2470 C-MAPPER is in charge of discovering C-RP'(s) and introducing them to 2471 the population of PIM-NG routers through sending INRODUCTION-MESSAGES 2472 to the destination address 239.0.1.190. Sending these periodic 2473 introductions causes any existing C-RP'(s) or TR'(s) and PIM-NG 2474 clients to learn the unicast address of the C-MAPPER and SC-MAPPER in 2475 case any BACKUP MAPPER is considered in the network. 2477 In the introduction message C-MAPPER will send its own unicast 2478 address alongside the unicast address of the C-RP/RPs inside the 2479 PMTT. 2481 The introduction messages are sent under these circumstances: 2483 1. Periodically as keep-alive messages so all the population knows 2484 about the existence of the C-MAPPPER, and new routers can learn 2485 about the C-MAPPER and the C-RP/RPs. sent to 239.0.1.190 2487 2. Whenever it receives an introduction from a new C-RP. Sent to 2488 239.0.1.190 2490 3. Whenever it receives an introduction from a C-RP indicating a 2491 change in the group addresses the C-RP represents. Sent to 2492 239.0.1.190 2494 4. Whenever it receives a request from a client, The C-MAPPER will 2495 send a unicast introduction or acknowledgment in this case to 2496 the address of the client. 2498 5. If other MAPPERs exist in the network as backup C-MAPPERs the 2499 MAPPERs will send introduction messages to the address group 2500 239.0.1.188 to find each other and hold elections to elect the 2501 C-MAPPER and SC-MAPPER (backup MAPPER) or to become PEERs. 2503 Message format sent to 239.0.1.190(ALL-PIM-NG-CLIENTS) 2505 0 1 2 3 2506 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 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 |PIM Ver| Type | Reserved | Checksum | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | D O M A I N | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 |R| | | |Z| | | 2513 |M|A| G R O U P |P R I O R I T Y|T|B| R E S E R V E D | 2514 | | | | |C| | | 2515 | | | | |N| | | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | HOLD TIME | RESERVED | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | C-MAPPER's unicast address | 2520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2521 | SC-MAPPER'S unicast Address | 2522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 | PIM domain topology table | 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 o Type: MAPPER introduction1 2526 o Group: is not used and will be set to all 0's. 2527 o Priority: is not used and will be set to all 0's. 2529 Message format sent to 239.0.1.188(ALL-PIM-NG-MAPPERs) and PEER-MAPPERS 2531 0 1 2 3 2532 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 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 |PIM Ver| Type | Reserved | Checksum | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2536 | D O M A I N | 2537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 |R| |P| | |Z| | | 2539 |M|A|E| G R O U P |P R I O R I T Y|T| MESH-PRIORITY |RSRVD | 2540 | | |E| | |C| | | 2541 | | |R| | |N| | | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | HOLD TIME | RESERVED | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | C-MAPPER's unicast address | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | SC-MAPPER'S unicast Address | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 | PIM domain topology table | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | A-MULTICAST MAPPING TABLE | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Core topology table | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 Figure 26 C-MAPPER introduction message formats 2557 o PEER-BIT field: if set indicates that the introduction message 2558 is meant for a PEER C-MAPPER and not for SC-MAPPERS and will be 2559 discussed later. 2560 o A-BIT: won't be set in this message type. 2561 o Hold time: will be set to all 0's, when sending the 2562 introduction to 239.0.1.188. when sending to found peers this 2563 field holds the hold time timer that must be used for the peer. 2565 C-MAPPER will set the type field to MAPPER introduction 1 or 2 2566 depending on the destination group it is sending the message to. And 2567 will put its own unicast address in the C-MAPPER unicast address 2568 field. And also will use the SC-MAPPER unicast address field to 2569 introduce the SC-MAPPER if any exists. 2571 After introducing itself it will introduce any existing C-RP'(s) or 2572 TR'(s) in the domain, by sending PMTT. 2574 As this periodical introductions sent by C-MAPPER are used by all 2575 PIM-NG routers to confirm the existence of the C-MAPPER and also will 2576 be considered by all PIM-NG none-RP routers (clients) as C-RP'(s) or 2577 any existing TR KEEP-ALIVE message , the C-MAPPER sends periodical 2578 unicast introductions every 30 seconds to the C-RP/RPs and will 2579 expect to hear from C-RP/RPs every 30 seconds by receiving a unicat 2580 RP-introduction. 2582 C-MAPPER will set the A-BIT (4.4.2.3.2.1. ) as soon as it becomes 2583 PEER with another C-MAPPER with either different domain value or the 2584 same domain value and different group. 2586 4.4.2.3.2.1. Value of the A-BIT 2588 This bit is set by the C-MAPPER as soon as it becomes PEER with 2589 another C-MAPPER. It indicates to the C-RPs that: 2591 o They are in a network with more than 1 C-MAPPER which became 2592 peers or in a network with different and separate Multicast 2593 domains, with each domain connected to the other one through 2594 peer C-MAPPERs. 2596 o C-RP/RPs will have to send A-MULTICAST-MAPPING TABLE to the C- 2597 MAPPER. 2599 4.4.2.3.2.2. C-MAPPER preparation 2601 The process begins by choosing a router to act as the C-MAPPER in 2602 the PIM-NG network. For the sake of simplicity of understanding and 2603 explaining the processes , first the processes related to a single C- 2604 MAPPER is explained and later processes related to redundant C- 2605 MAPPERs will be explained(4.5. ). 2607 In a single multicast domain (Figure 25) with one C-MAPPER, the 2608 process starts by choosing one router to act as C-MAPPER .when it is 2609 chosen the rest is as follows: 2611 o commands : 2613 <#IP PIM-NG DYNAMIC-RP2> 2615 <#IP PIM-NG DOMAIN [X]> 2617 <#IP PIM-NG MAPPER> 2619 <#IP PIM-NG SOURCE-LO"X"> 2621 <#IP PIM-NG INTERFACE "X", INTERFACE"Y"> 2623 Are initiated on the router. This command tells the router that: 2625 1- It is in PIM-NG DOMAIN X that uses DYNAMIC-RP-DISCOVERY 2626 TYPE2 2628 2- It is the C-MAPPER in the network 2629 3- It should bring its interfaces "x, y" and any other 2630 interfaces configured as a PIM-NG interface in to the PIM-NG 2631 game. 2633 4- As no other commands are entered, it is the only MAPPER and 2634 it is in a single multicast domain. So it MUST NOT set the A- 2635 BIT when sending introduction messages out of its interfaces 2636 in the game of PIM-NG. 2638 5- It should send its introduction to multicast destination 2639 address of 239.0.1.190 as the C-MAPPER, so all PIM-NG routers 2640 and especially C-RP/RPs will learn its address. 2642 6- As a PIM-NG router it should maintain connectivity with its 2643 neighboring PIM-NG routers through sending HELLO messages out 2644 of the interfaces defined by the command. 2646 7- As a PIM-NG C-MAPPER it should send introduction/keep-alive 2647 messages every 60 seconds to 239.0.1.190, so every router in 2648 the PIM-NG network knows about its existence and the new ones 2649 will learn its address and the C-RP/RPs address. This 2650 periodic introduction/keep-alive messages will also act as 2651 the introduction/keep-alive on behalf of the C-RP/RPs. 2653 8- As soon as it receives a C-RP introduction, the C-MAPPER 2654 will check the DOMAIN value to see if it matches its own 2655 value and if it does the C-MAPPER will put an entry in its 2656 PMTT alongside the multicast groups and the associated 2657 unicast addresses it may receives from each C-RP inside the 2658 AMMT. 2660 9- The C-MAPPER will maintain connectivity with each C-RP by 2661 sending periodic unicast introduction messages to the address 2662 of each C-RP. And will expect to receive an introduction from 2663 each C-RP in return. 2665 10- If it doesn't receive an introduction from each C-RP for 2666 60+10sec it will delete the entry for the RP and announces 2667 the loss in its next introduction. 2669 11- In case any SC-RP exists , if C-MAPPER doesn't receive a 2670 keep alive from the C-RP for (60sec+10=70sec) , it will 2671 automatically send an intro to the address of Sc-MAPPER.and 2672 after receiving the first intro from Sc-MAPPER it will inform 2673 all PIM-NG clients in an introduction message. 2675 [Figure is presented in PDF version] 2677 Figure 27 multicast domain with one C-MAPPER 2679 4.4.2.3.3. C-RP concepts 2681 As explained before, the role of a C-RP in general is like an 2682 information registry station. Any client that needs to register a 2683 source will communicate with the C-RP and any client in need to find 2684 a source for a multicast group (G) will have to ask the C-RP. These 2685 parts had been covered in the first sections and we are not going to 2686 talk about the related processes again. 2688 What had been explained earlier about the C-RP, was mainly related to 2689 its processes in a domain with a small or medium size that the 2690 presence of only one C-RP and if needed, a backup C-RP (SC-RP) could 2691 support the needs of the network. But in larger networks beside the 2692 high availability factor, redundancy becomes vital. 2694 In this case there may be the need for presence of more than 1 C-RP 2695 all working together to bring both high availability and redundancy 2696 to the network. 2698 4.4.2.3.3.1. C-RP redundancy 2700 In a single domain (Figure 28) with redundant C-RPs, the main task is 2701 for the C-RPS to find each other and also introduce themselves to all 2702 PIM-NG clients. 2704 [Figure is presented in PDF version] 2706 Figure 28 network designs with one multicast domain 2708 After a PIM-NG router is configured to become a C-RP and is told that 2709 Dynamic-Discovery type 2 is in use. It needs to introduce itself to 2710 all PIM-NG clients. To do so a PIM-NG C-RP needs to wait to learn 2711 about the existence of a C-MAPPER in the domain. As explained in the 2712 previous sections this is done when a C-RP receives a C-MAPPER 2713 introduction sent to 239.0.1.190, containing the unicast address of 2714 the C-MAPPER. Then it will introduce itself as the C-RP to the C- 2715 MAPPER by sending a unicast C-RP introduction message to the address 2716 of C-MAPPER. Format of this introduction and related definitions can 2717 be seen bellow. 2719 0 1 2 3 2720 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 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 |PIM Ver| Type | Addr length | Checksum | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | D O M A I N | 2725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2726 |P|Z| PRIORITY | GROUP | MESH-PRIORITY |R|reserved | 2727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 | HOLD TIME | RESERVED | 2729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2730 | RP'S unicast address | 2731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 | Sc-RP unicast address | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | PEER list | 2735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2736 | Multicast MAPPING table | 2737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2738 | A-Multicast mapping table | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2740 Figure 29 C-RP introduction message format 2742 o Type : RP introduction dynamic 2743 o Priority : set to 0 2744 o Group : set to 0 2745 o Hold time: Hold time is the amount of time a receiver must keep 2746 the neighbor reachable, in seconds. If the Hold time is set to 2747 '0xffff', the receiver of this message never times out the 2748 neighbor. This may be used with dial-on-demand links, to avoid 2749 keeping the link up with periodic Hello messages. 2750 o P-BIT : set to 0 2751 o PEER-LIST : won't be sent 2752 o Multicast Mapping Table : won't be sent to C-MAPPER and only to 2753 Sc-RP 2754 o A- Multicast Mapping Table : will be sent to C-MAPPER ,SC-RP and 2755 peer C-RPs 2757 4.4.2.3.3.2. C-RP processes 2759 The processes involved are as follows: 2761 1- A router is chosen to become C-RP and also told that it is in a 2762 network that a C-MAPPER exists as a separate component by 2763 initiating a set of commands : 2765 <#IP PIM-NG DYNAMIC-RP2> 2767 <#IP PIM-NG DOMAIN [X]> 2769 <#IP PIM-NG RP> 2771 <#IP PIM-NG SOURCE-LO"X"> 2773 <#IP PIM-NG INTERFACE "X", INTERFACE"Y"> 2775 2- The above set of commands tells the router that it is a RP in 2776 PIM-NG-domain(X). And it should use its LOOP-BACK "X" interface 2777 as the RP source address when introducing itself. Also it has 2778 to bring the interfaces "X, Y" inside the PIM-NG game and put 2779 them into forward for 239.0.1.190, 239.0.1.189 and 239.0.1.188. 2781 3- Because the RP discovery method used is of type2, a PIM-NG RP 2782 waits until it hears the C-MAPPER introduction. 2784 4- After receiving C-MAPPER introduction message first it checks 2785 the Domain field inside the introduction message to see if the 2786 domain value matches its own domain value it puts the source 2787 address of the C-MAPPER into its local PIM domain topology 2788 table. 2790 5- The C-RP'(s) MUST check the A-BIT, to understand how should it 2791 contact with the C-MAPPER. 2793 6- RP sends a unicast introduction to the unicast address of C- 2794 MAPPER and waits to receive a unicast introduction from C- 2795 MAPPER which is interpreted as an acknowledgment from the C- 2796 MAPPER. 2798 7- After the acknowledgment from the C-MAPPER is received, RP 2799 starts to sending periodical unicast introductions as keep 2800 alive every 60 seconds to C-MAPPER in response to C-MAPPER 2801 periodical unicast introductions. 2803 8- If any SC-RP exists, the C-RP will also send the address of SC- 2804 RP for further use by C-MAPPER. 2806 9- If any changes occur in the domain, like the registration or 2807 deletion of a multicast group source (G) the RP will only 2808 update its own tables since the A-BIT is set to 0. 2810 4.4.2.3.3.3. Redundant C-RPs 2812 Now that the processes and concepts related to each C-RP are 2813 explained it is time to bring redundancy to the network and make C- 2814 RPs redundant. 2816 Considering the design shown in Figure 28, we have 2 C-RPs in our 2817 network ,one belongs to GROUP-A and the other GROUP-B.and each one of 2818 the C-RPs are configured up to this point to act as a C-RP and 2819 introduce itself to the C-MAPPER. Also it should be noted that both 2820 C-RPs MUST be inside the same DOMAIN. 2822 In order to bring redundancy in to the network, each C-RP must be 2823 told to become peer with a C-RP in another group, so they will be 2824 able to exchange their entire AMMT. This way we will cover both needs 2825 of the network which are high availability (backup C-RP) and 2826 redundancy at the same time. But it MUST be noted that a C-RP cannot 2827 and MUST NOT become peer with a C-RP in another domain. 2829 The processes involved are as follows: 2831 1- Each C-RP must be told that it belongs to a GROUP, and also 2832 that it is peer with a C-RP from another Group. This is done by 2833 initiating a set of commands on each RP .consider the following 2834 set of commands are initiated on both C-RPs (Figure 28) : 2836 <#IP PIM-NG GROUP [A]> 2838 <#IP PIM-NG PEER RP GROUP [B]|PEER ADDRESS> 2840 2- After the above commands are initiated on C-RP-GROUP-A (C-RP-A 2841 for simplicity) it starts a series of processes. 2843 3- First of all it puts an entry for the new peer in a table 2844 called PEER-LIST. 2846 4- Sends out a multicast C-RP introduction message to all PIM-NG 2847 C-RPs with the destination address of 239.0.1.189. 2849 5- In the introduction message, C-RP-A sets the P-BIT to 1 which 2850 tells to existing C-RPS that the introduction message is meant 2851 for a C-RP that is looking for its peer. This is done duo to the 2852 fact that there might be SC-RPs in the network, and this bit 2853 will make them to ignore the packet. 2855 6- Sets the value of GROUP field to its own GROUP value. 2857 7- Alongside its unicast address and any existing SC-RP, C-RP will 2858 send keep-alive timer value to C-RP-B. it shows the keep-alive 2859 timer value that C-RP-B has to set for C-RP-A. 2861 8- One other table that is sent in this initial introduction 2862 message is the entire AMMT of C-RP-A. 2864 9- After receiving an introduction message from the other C-RP 2865 which in our case is C-RP-B, C-RP-A will update its PEER MAPPING 2866 table with information needed. And starts sending periodic 2867 unicast introduction messages as keep-alive messages to the 2868 unicast address of C-RP-B every 60 seconds. These periodic 2869 introductions do not contain the MMT. 2871 10- After the initial phase of finding C-RP-B is done, C-RP-A will 2872 send the entire AMMT table just in case there is a change in the 2873 domain. This change can be the registration of a new source with 2874 C-RP-A or deletion of a source from the MMT. In such a case C- 2875 RP-A will set the Z-BIT in its unicast introduction message. 2877 11- In a case, that C-RP-A receives an introduction from its peer 2878 with the Z-BIT set and containing the AMMT, it will only update 2879 its own AMMT and won't inform the C-MAPPER about the change if 2880 the A-BIT inside the received C-MAPPER introduction messages is 2881 set to 1. This is duo to this fact that the change had been 2882 informed to the C-MAPPER before by C-RP-B, and if C-RP-A is 2883 going to inform again it will be a double introduction process 2884 and will waste bandwidth and C-MAPPERs resources and is not a 2885 necessary task nor recommended. 2887 12- If C-RP-A doesn't receive an intro from the C-RP-B for 60 sec 2888 it will send a final unicast intro to the unicast address of C- 2889 RP-B to see if it is alive or not. If after this last unicast 2890 introduction C-RP-A doesn't receive any introductions from C-RP- 2891 B and there is any SC-RP-B, C-RP-A will immediately send a 2892 unicast introduction to the address of SC-RP-B. 2894 13- If no SC-RP-B is considered in the domain, then C-RP-A will 2895 start sending periodic multicast introduction messages to the 2896 address 239.0.1.189 to find its peer every 60 seconds. Until it 2897 hears again from the C-RP-B or other C-RPs it might have became 2898 peer with. 2900 The same set of actions will be done by the other C-RP (C-RP-B). 2902 Now that the related processes are explained let's take a look at the 2903 format of PEER-MAPPING table and PEER-LIST table which is created on 2904 both C-MAPPER'(s) and C-RP'(s) in Figure 30. 2906 PEER-MAPPING table 2908 +--------------------------------------------------------------------+ 2909 |PEER ADDR|Domain|GROUP|Mesh-Group|Priority|status|keep-alive|expiry | 2910 +--------------------------------------------------------------------+ 2911 | | | | | | | | | 2912 +--------------------------------------------------------------------+ 2913 | | | | | | | | | 2914 +--------------------------------------------------------------------+ 2915 Figure 30 PEER-MAPPING table and PEER-LIST table 2917 o Peer unicast address: unicast address of the peer which will be 2918 found later. 2919 o Status: gets a value of either A (active) or S (standby) and is 2920 used by C-MAPPERs in case more than one C-MAPPER exists. 2922 Multicast mapping table 2924 +-------------------------------------------------------------------+ 2925 |Source addr(S)|Dest group (G)|Source HOST| keep alive |expiry time | 2926 +-------------------------------------------------------------------+ 2927 | | | | | | 2928 +-------------------------------------------------------------------+ 2929 | | | | | | 2930 +-------------------------------------------------------------------+ 2931 A-Multicast mapping table 2933 +------------------------------------------------------------------+ 2934 |Source addr|Dest group (G)|Sorce Host|Originator|DOMAIN-set|status| 2935 +------------------------------------------------------------------+ 2936 | | | | | | | 2937 +------------------------------------------------------------------+ 2938 | | | | | | | 2939 +------------------------------------------------------------------+ 2940 o Status field: takes the values equal to suspend or active. If an 2941 entry inside the AMMT has the status of suspend, it means that it 2942 cannot be used until either it is removed or activated again but 2943 its usage is not meant for this process and will be discussed 2944 later. So if any entry inside this table has the status of suspend 2945 C-RPs won't give the source address to any clients that may be 2946 looking for the source address of a group (G) which matches that 2947 entry. 2949 o Domain-set: shows the domain in which a source is generated and 2950 registered. It is called domain-set due to the fact that when 2951 separate and different PIM-NG multicast domains are connected to 2952 each other, a C-MAPPER inside one domain will add its domain number 2953 to the domain value before sending the AMMT to a peer C-MAPPER in 2954 another domain. So at the end there will be a string of domain 2955 numbers like, 2-1-core2-core1-3-2, which will be used later. But a 2956 C-RP only adds its domain value for any sources that is registered 2957 with it or in a singly multicast domain design with one C-MAPPER 2958 and multiple PEER C-RP'(s), for any source that is received from a 2959 PEER-C-RP before sending it to another PEER-C-RP. This way the 2960 domain-set itself can be used to RPF check. 2962 Figure 31 AMMT compared with MMT 2964 +---------------------------------------+ 2965 | ORIGINATED MULTICAST GROUP 1 | 2966 +---------------------------------------+ 2967 | ORIGINATOR UNICAST ADDRESS | 2968 +---------------------------------------+ 2969 | MULTICAST GROUP(G) | 2970 +---------------------------------------+ 2971 | SOURCE UNICAST ADDRESS | 2972 +---------------------------------------+ 2973 | DOMAIN-SET | 2974 +---------------------------------------+ 2975 | . | 2976 +---------------------------------------+ 2977 | ORIGINATED MULTICAST GROUP N | 2978 +---------------------------------------+ 2979 | . | 2980 +---------------------------------------+ 2981 | DELETED MULTICAST GROUP 1 | 2982 +---------------------------------------+ 2983 | MULTICAST GROUP(G) | 2984 +---------------------------------------+ 2985 | SOURCE UNICAST ADDRESS | 2986 +---------------------------------------+ 2987 | . | 2988 +---------------------------------------+ 2989 | DELETED MULTICAST GROUP M | 2990 +---------------------------------------+ 2991 | . | 2992 +---------------------------------------+ 2993 | SUSPENDED MULTICAST GROUP 1 | 2994 +---------------------------------------+ 2995 | ORIGINATOR UNICAST ADDRESS | 2996 +---------------------------------------+ 2997 | MULTICAST GROUP(G) | 2998 +---------------------------------------+ 2999 | SOURCE UNICAST ADDRESS | 3000 +---------------------------------------+ 3001 | DOMAIN-SET | 3002 +---------------------------------------+ 3003 | . | 3004 +---------------------------------------+ 3005 | SUSPENDED MULTICAST GROUP N | 3006 +---------------------------------------+ 3007 | . | 3008 +---------------------------------------+ 3009 Figure 32 AMMT Format 3011 The above(Figure 32) is the real format of the A-MULTICAST MAPPING 3012 TABLE (AMMT) being exchanged between either peering C-RP'(s) or a C- 3013 RP and a C-MAPPER in case there are multiple PIM-NG domains or peer 3014 C-MAPPERs in the domain ,with the bellow definitions and 3015 specifications : 3017 o In a single multicast domain network design which only one C- 3018 MAPPER exists ,and multiple PEER-C-RPs are considered for 3019 redundancy , each C-RP MUST add its domain value to the domain- 3020 set of the received sources from a peer C-RP before sending them 3021 to another peer C-RP. The domain-set will be used by peer C-RPs 3022 to RPF check the received sources inside the domain. Consider 3023 the bellow network design including 3 C-RPs all part of 3024 multicast domain(1),in which a source registers with R1 and R1 3025 starts to advertise the new originated source to its peers R2 3026 and R3.R3 receives an update for (S,G) with the domain-set of D1 3027 from R1 and another update for (S,G) with domain-set [D1,D1] 3028 from R2.so at this point the received update from R2 fails the 3029 RPF check because of the longer domain-set string and R3 will 3030 only accept the received update from R1. 3032 [R2-D1] 3033 / \ 3034 / \ 3035 / \ 3036 {(S,G),D1} / \{(S,G),D1,D1} 3037 / \ 3038 / \ 3039 / \ 3040 [R1-D1]-------------[R3-D1] 3041 (S,G) {(S,G),D1} 3043 o Suspended multicast group: a C-RP MUST NOT put an entry for a 3044 suspended multicast group. This field MUST only be filled out by 3045 a C-MAPPER or PPER which loses connectivity with its PEER-C- 3046 MAPPER (PPER) from another domain. 3048 Now that the processes related to bringing redundancy to the domain 3049 by using redundant C-RPs in a single multicast domain network and 3050 also the C-RP related processes in such a network has been covered we 3051 are going to explain the reactions of a C-RP in a multiple domain 3052 network and the related concepts. 3054 4.4.2.3.3.4. PIM-NG Anycast RP 3056 Up to this point we have discussed the concepts related to redundant 3057 RPs of up to 2 C-RPs in a domain. In such a multicast domain it won't 3058 be a problem for the C-MAPPER to introduce all existing C-RPs one by 3059 one inside the PDTT. But if the network size becomes bigger with the 3060 need for many C-RPs to bring redundancy and high availability to the 3061 network ,the process of introducing all existing C-RPs in the domain 3062 by C-MAPPER to ALL-PIM-NG-ROUTERs including CLIENTS and any other C- 3063 MAPPERs will be a waste of network resources. 3065 So PIM-NG specifications suggest the use of ANYCAST-RP concept [11] 3066 with bellow specifications and rules: 3068 o Each C-RP MUST use 2 different unicast addresses. One will be 3069 used in the processes related to introducing to existing C- 3070 MAPPER'(s) and PEER-C-RPs. And one unicast address will be used 3071 as the ANYCAST address. So it is better to put it this way, each 3072 C-RP MUST use 2 interface loopbacks for its processes .one 3073 interface with the ANYCAST address and one with the address used 3074 for introductions. 3076 o Clients MUST communicate with the closest C-RP. 3078 o Existing C-MAPPERs MUST become aware of ANYCAST concept usage 3079 in the domain alongside the ANYCAST ADDRESS in use ,by 3080 initiating a command such as : 3082 <#IP PIM-NG ANYCAST ADDRESS [A.B.C.D]> 3084 On any existing C-MAPPER'(s). So that C-MAPPERs will use the 3085 configured ANYCAST address when introducing C-RPs to the domain 3086 which will only be one entry inside the PIM DOMAIN TOPOLOGY 3087 TABLE compared to up to 256 different C-RPs. 3089 o If only one C-MAPPER exists in the domain or the domain is not 3090 connected to other domains, C-RP'(s) won't need to introduce 3091 themselves to the C-MAPPER. But C-RP'(s) MUST become peer with 3092 each other in order to exchange the contents of AMMT with each 3093 other to bring redundancy. 3095 o If the A-BIT in the received C-MAPPER introduction message is 3096 set then each C-RP will have to introduce itself to the closest 3097 C-MAPPER and start exchanging AMMT individually with the closest 3098 C-MAPPER.and in such case it is advised not to peer C-RPs with 3099 each other. This is due to the fact that C-MAPPERs will inform 3100 C-RPs about any new sources that are registered with a C-RP. 3102 4.4.2.3.3.5. PIM-NG C-RP Mesh-Group 3104 Up to this point of explaining PIM-NG specifications we, have 3105 explained the process of bringing redundancy to a PIM-NG domain by 3106 peering C-RPs and in case the network is a large sized network ,the 3107 usage of ANYCAST RP concept with its specifications have been 3108 explained. 3110 In some multicast domain designs, the needs of the network may 3111 dictate the use of many C-RP'(s) in the domain to both bring 3112 redundancy and high availability. ANYCAST RP concept solves a problem 3113 regarding the introduction of C-RPs to the domain in a way that C- 3114 MAPPER'(s) will only need to introduce one unicast address as the 3115 address of the C-RP. But one problem remains unsolved which is 3116 related to the fact that with ANYCAST RP, each C-RP still has to 3117 introduce itself directly to the C-MAPPER and exchange the contents 3118 of A-MULTICAST MAPPPING TABLE. Now if the number of existing C-RPs 3119 goes high, the amount of data that is going to be transferred between 3120 large number of C-RPs and C-MAPPER will waste both network and C- 3121 MAPPER resources. 3123 To solve the above issue PIM-NG specifications introduces the concept 3124 of C-RP MESH-GROUP with bellow specifications: 3126 o A PIM-NG domain can contain up to 25 C-RP Mesh-Groups. With 3127 each group containing up to 10 C-RPs. 3129 o A Mesh-Group priority value between [0-255] MUST be defined 3130 on each C-RP that is going to be a member of a Mesh-Group. 3131 This priority is different from the priority that had been 3132 used at the time of choosing backup or SC-RP and defaults to 3133 100. The higher the better. 3135 o The C-RP with the highest priority in the Mesh-Group will 3136 become the active C-RP and better to say the speaker on 3137 behalf of the Mesh-Group.to do so an election MUST be held 3138 between members of the Mesh-Group : 3140 1. Each C-RP introduces itself to its peers by sending a 3141 multicast introduction to the destination address 3142 239.0.1.189, which contains its GROUP number, and the 3143 priority that will be used in the election process. 3145 2. Each C-RP receiving such introduction message will 3146 compare the priority in the received message with its 3147 own priority and puts an entry in its PEER-MAPPING- 3148 TABLE for that peer with the status of either active or 3149 standby. 3151 3. If the priority associated with a peer in a received 3152 introduction is lower than the priority set on the C- 3153 RP, then that peer will get the status of standby, and 3154 if the associated priority of a peer is higher, that 3155 peer gets an active status. 3157 4. At the end of this election process, each C-RP knows 3158 the active C-RP. 3160 o It is advised by PIM-NG specifications that a mechanism be 3161 implemented and used through configuration, that each member 3162 of a Mesh-Group becomes aware about the number of members 3163 within a Mesh-Group. 3165 o The active C-RP in a Mesh-Group is responsible for 3166 interacting with the closest C-MAPPER and exchanging the 3167 AMMT which contains any sources that registers with any 3168 members of the C-RP Mesh-Group. 3170 o If the current active C-RP dies and doesn't have any SC-RP, 3171 the next C-RP with the highest priority takes its place 3172 immediately. 3174 o Each member of the Mesh-Group MUST inform all the other 3175 members about any changes that occurs. So for instance, if 3176 we have 10 members in a Mesh-Group and C-RP1 receives 3177 information regarding a new source from C-RP2, it MUST NOT 3178 forward it to other members due to the fact that it has been 3179 informed to other members by C-RP2. 3181 o A C-RP can be a member of different Mesh-Groups, but such an 3182 implementation is not advised. 3184 o The above can be done by initiating command lines such as 3185 the bellow command lines on each C-RP : 3187 <#IP PIM-NG RP-MESH GROUP [1-25]> 3189 <#IP PIM-NG RP-MESH GROUP MEM-COUNT [1-10]> 3191 <#IP PIM-NG MESH-PEER GROUP [1-255]> 3193 <#IP PIM-NG MESH-PRIORITY [0-255]> 3194 PIM-NG specifications dictates that, such a command MUST 3195 indicate the use of C-RP Mesh-Group, total number of members 3196 in the Mesh-Group, Mesh-Group that a C-RP is a member of, 3197 Group number of all the members of Mesh-Group that the C-RP 3198 is supposed to become peer with and finally the priority of 3199 the Current C-RP in the Mesh-Group. 3201 4.4.2.3.3.6. Backup C-RP considerations 3203 In a single PIM-NG multicast network design with redundant C-RPs 3204 there seems that no SC-RP is needed to be considered .as each C-RP 3205 can be used as the backup for the other one. 3207 But in larger networks, the existence of backup RP seems necessary 3208 and of high importance due to the fact that the high availability of 3209 each C-RP becomes an important factor. 3211 If any SC-RP should be considered, the processes are as explained 3212 before with one additional table being exchanged between C-RP and SC- 3213 RP, which is the A-MULTICAST-MAPPIN-TABLE. 3215 4.5. C-MAPPER Redundancy in PIM-NG 3217 Peering C-MAPPERs will bring redundancy to existing C-MAPPERs .in 3218 large networks and special designs the redundancy between C-MAPPERs 3219 inside the same domain might become handy. 3221 The main use of peer C-MAPPERs is going to be felt when connecting 2 3222 or more separate PIM-NG domains, which will be discussed later. 3224 So for the sake of simplicity in explaining the processes involved we 3225 are going to explain the processes in a PIM-NG network with one 3226 multicast domain. See Figure 33. 3228 [Figure is presented in PDF version] 3230 Figure 33 network with single multicast domain and redundant C-MAPPERs 3232 As you see in Figure 33 we have a single domain and redundant 3233 MAPPERS. If you look at the picture each C-MAPPER is assigned to a 3234 unique GROUP. 3236 PIM-NG specifications dictate that each C-MAPPER can only communicate 3237 with MAPPERS inside the same GROUP and domain. In other words each 3238 MAPPER can hear the introduction of MAPPERs in other groups sent to 3239 239.0.1.188 but won't show any reaction to it and will only forward 3240 it, unless it is told that it can listen to the introduction of C- 3241 MAPPER's in other groups and use the information inside the 3242 introduction message. 3244 The process begins by telling each C-MAPPER that it is peer with a C- 3245 MAPPER from other groups. Consider the sample network illustrated in 3246 Figure 33. C-MAPPER-WEST(called west for simplicity) which is in 3247 domain 1 and is assigned to GROUP-A is told that it is peer with a C- 3248 MAPPER in domain 1 and GROUP-B which is in this case C-MAPPER- 3249 EAST(called east for simplicity).this must be done on both sides. As 3250 soon as west is told that it is peer with east a series of actions 3251 occurs: 3253 1- West puts an entry for east or simply GROUP-B in a special table 3254 called PEER-MAPPING.and also an entry in the Hold Time field of the 3255 introduction message which shows the keep-alive timer each peer 3256 should set for the C-MAPPER-west . 3258 +--------------------------------------------------------------------+ 3259 |PEER ADDR|Domain|GROUP|Mesh-Group|Priority|status|keep-alive|expiry | 3260 +--------------------------------------------------------------------+ 3261 | | | | | | | | | 3262 +--------------------------------------------------------------------+ 3263 | | | | | | | | | 3264 +--------------------------------------------------------------------+ 3265 Figure 34 PEER-MAPPING Table 3267 o Peer unicast address: unicast address of the peer which will be 3268 later found. 3269 o Status : gets a value of either A(active) or S(standby) 3271 2- West sends a multicast introduction to the destination address of 3272 239.0.1.188 which will be heard by all the MAPPERs .in this 3273 introduction message the west introduces its unicast address plus 3274 the Domain number assigned to it and the GROUP it represents and 3275 sends its AMMT along with the PEER-LIST table. This introduction 3276 messages will be read only by those C-MAPPERs that are supposed to 3277 become peers with the sender, and in this case east. 3279 3- When West becomes peer with a C-MAPPER it sets the A-BIT in its 3280 introduction messages sent to ALL-PIM-NG-CLIENTS and All-C-RPs, so 3281 that C-RPs start sending AMMT to C-MAPPERs. 3283 4- If the C-MAPPERs inside the domain are forming C-MAPPER MESH- 3284 GROUPS (4.5.2. ) then, in its introduction message sent to 3285 239.0.1.188 to find peers from the same domain, west will send its 3286 MESH-PRIORITY value. This priority value is going to be used in an 3287 election process between peer C-MAPPERs forming a MESH-GROUP inside 3288 the same domain which will be discussed later. 3290 5- If the C-MAPPERs are not forming a MESH-GROUP then no priority 3291 needs to be sent. 3293 6- West will keep sending the introduction every 30 seconds until it 3294 receives an acknowledge or simply put introduction from east ,which 3295 can be either a unciast introduction to west sent from east or a 3296 multicast introduction sent from east in order to find its peers. 3298 7- After the introduction from east is heard, and the Domain number 3299 and group numbers are checked and verified, west keeps sending 3300 periodical introduction messages every 60 seconds by default or 3301 every X second equal to the time set in the KEEP-ALIVE-TIMER inside 3302 PEER-LIST. 3304 8- If the Mesh-Priority value of EAST is lower than its own Mesh- 3305 Priority it means that , it is the ACTIVE-C-MAPPER and responsible 3306 of introducing east or any other STANDBY-C-MAPPER(STC-MAPPER) 3307 existing inside the domain to ALL-PIM-NG ROUTERs so that C-RPs will 3308 learn the address of STANBY-C-MAPPERs to use the closest C-MAPPER. 3310 9- Introduction messages will be sent by west under these conditions 3311 : 3313 o Triggered multicast introductions whenever west is told to become 3314 peer with a new C-MAPPER. 3316 o Periodical unicast introductions, which will act as keep-alive 3317 messages after finding the peer. In this type of introduction no 3318 AMMT will be exchanged. 3320 o Triggered unicast introduction to the address of east to inform a 3321 change in the network, like a new entry in the AMMT by setting a 3322 flag called ZONE-TOPOLOGY-CHANGE-NOTIFICATION (ZTCN) and sending 3323 the entire new AMMT. 3325 0 1 2 3 3326 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 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 |PIM Ver| Type | Reserved | Checksum | 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | D O M A I N | 3331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 |R| |P| | |Z| | | 3333 |M|A|E| G R O U P |P R I O R I T Y|T| MESH-PRIORITY |RSRVD | 3334 | | |E| | |C| | | 3335 | | |R| | |N| | | 3336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 | HOLD TIME | RESERVED | 3338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3339 | C-MAPPER's unicast address | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | SC-MAPPER'S unicast Address | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | PIM DOMAIN TOPOLOGY TABLE | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | A-MULTICAST MAPPING TABLE | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Core TOPOLOGY TABLE | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 Figure 35 introduction message format sent to ALL PIM-NG MAPPERS 3350 239.0.1.188 3352 o Type: MAPPER introduction 3353 o Peer field: is set. This field will be check by other C-MAPPERs 3354 that are looking for a peer to differentiate between 3355 packets sent from normal MAPPERs and peer C-MAPPERs. 3356 o Group : C-MAPPER puts its own GROUP in this field 3357 o Domain: holds the domain number associated with the C-MAPPER 3358 o ZTCN: ZONE-TOPOLOGY-CHANGE-NOTIFICATION. Set if any changes 3359 occur. 3361 A-Multicast mapping table 3363 +------------------------------------------------------------------+ 3364 |Source addr|Dest group (G)|Sorce Host|Originator|DOMAIN-set|status| 3365 +------------------------------------------------------------------+ 3366 | | | | | | | 3367 +------------------------------------------------------------------+ 3368 | | | | | | | 3369 +------------------------------------------------------------------+ 3370 +---------------------------------------+ 3371 | ORIGINATED MULTICAST GROUP 1 | 3372 +---------------------------------------+ 3373 | ORIGINATOR UNICAST ADDRESS | 3374 +---------------------------------------+ 3375 | MULTICAST GROUP(G) | 3376 +---------------------------------------+ 3377 | SOURCE UNICAST ADDRESS | 3378 +---------------------------------------+ 3379 | DOMAIN-SET | 3380 +---------------------------------------+ 3381 | . | 3382 +---------------------------------------+ 3383 | ORIGINATED MULTICAST GROUP N | 3384 +---------------------------------------+ 3385 | . | 3386 +---------------------------------------+ 3387 | DELETED MULTICAST GROUP 1 | 3388 +---------------------------------------+ 3389 | MULTICAST GROUP(G) | 3390 +---------------------------------------+ 3391 | SOURCE UNICAST ADDRESS | 3392 +---------------------------------------+ 3393 | . | 3394 +---------------------------------------+ 3395 | DELETED MULTICAST GROUP M | 3396 +---------------------------------------+ 3397 | . | 3398 +---------------------------------------+ 3399 | SUSPENDED MULTICAST GROUP 1 | 3400 +---------------------------------------+ 3401 | ORIGINATOR UNICAST ADDRESS | 3402 +---------------------------------------+ 3403 | MULTICAST GROUP(G) | 3404 +---------------------------------------+ 3405 | SOURCE UNICAST ADDRESS | 3406 +---------------------------------------+ 3407 | DOMAIN-SET | 3408 +---------------------------------------+ 3409 | . | 3410 +---------------------------------------+ 3411 | SUSPENDED MULTICAST GROUP N | 3412 +---------------------------------------+ 3413 | . | 3414 +---------------------------------------+ 3415 Figure 36 A- Multicast MAPPING TABLE 3417 The above table (Figure 36) is the real format of A-MULTICAST MAPPING 3418 TABLE that is exchanged between peer C-MAPPERs with bellow 3419 definitions: 3421 o Originator unicast address: holds the address of the C-MAPPER 3422 that, a source is originated in its domain and it has received 3423 the information regarding the source from a connected C-RP. It 3424 is used by PEER-C-MAPPERs inside the same domain as a means for 3425 RPF check of a received update regarding a source that is inside 3426 their domain. Also the Originator address will be used when a 3427 PIM-NG domain is going to be connected to a PIM-SM domain to 3428 bring compatibility. 3429 o A C-MAPPER MUST change the contents of originator unicast 3430 address field with its own address, for sources that are 3431 originated inside its own domain and received from a downstream 3432 C-RP. 3433 o A C-MAPPER MUST NOT change the contents of originator unicast 3434 address field of sources that are received from a peer C-MAPPER 3435 or PPER. 3436 o Each C-MAPPER MUST add its domain number value to the domain- 3437 set of a received source when sending the AMMT to a peer C- 3438 MAPPER either inside the same domain or in another domain. This 3439 domain-set is used as a means of RPF check which will be 3440 discussed later. 3441 o If a C-MAPPER or PPER wants to send an update to a peer in 3442 another domain, it MUST first remove any additional domain 3443 values equal to its domain value from the string, and then add 3444 its domain value to the string and send it to other domains. The 3445 additional domain values are those added by C-MAPPERs inside the 3446 domain to be used for RPF check. 3447 o Suspended multicast group: holds the information regarding any 3448 multicast sources that MUST be treated as suspended .when a C-RP 3449 receives this information it will not answer to requests from 3450 clients for that source until the sources are again active or 3451 deleted. 3453 Now that west has done its part of the work, it is time to see what 3454 are the processes related to its peer C-MAPPER-EAST. 3456 As soon as east is told that it is peer with Group-A, it will do as 3457 described above .also it will wait to hear a multicast introduction 3458 destined for 239.0.1.188. When east receives such packets it will do 3459 the following: 3461 1- First of all it will check the PEER field to see if it is set. 3462 If this field is set, it means that it is sent from a C-MAPPER 3463 that is looking for a peer or wants to introduce itself to a 3464 peer. In our example east receives a packet destined for 3465 239.0.1.188 .checks the PEER field .and sees that it is set by 3466 sender. 3468 2- East checks the Domain field to see if it is sent from inside 3469 the domain or not. 3471 3- Then east will check the GROUP field to see if the packet 3472 belongs to a group it is looking for and wants to become peer 3473 with. In this case east will see A in the GROUP field. 3475 4- It checks its PEER-MAPPING table and sees an entry for GROUP-A 3476 .so it understands that the packet is sent from its peer. 3478 5- If the Mesh-Group concept is implemented, Then east checks the 3479 Mesh-Priority value to see if the sender has a higher value or 3480 not. And without the Mesh-Group concept EAST MUST start sending 3481 introductions to 239.0.1.190 introducing itself to PIM-NG 3482 population. And use the information regarding WEST to only 3483 exchange information regarding multicast sources. 3485 6- If the Mesh-Priority value is higher it means that it is going 3486 to be in standby mode and only connect with existing C-RPs 3487 through unicast introduction messages it will receive from C- 3488 RPs. And won't send multicast introductions to 239.0.1.190 as 3489 long as the ACTIVE C-MAPPER exists. 3491 7- East will then look in the SOURCE-UNICAST-ADDRESS field to find 3492 the address of the sender. And in our example east finds the 3493 address of west, and puts the west's unicast address in its 3494 PEER-MAPPING table alongside the associated status. 3496 8- Now it is time for east to check the PEER-LIST table inside the 3497 introduction message. It finds an entry for GROUP-A alongside 3498 the associated KEEP-ALIVE timer. East then puts the associated 3499 keep-alive timer in the right field in its PEER-MAPPING table. 3501 9- It will read the content of the AMMT sent from west and enters 3502 the new mappings in its own AMMT for further use. 3504 10- It will send a unicast introduction to the unicast address of 3505 west as an acknowledgement and also for west to learn east's 3506 address. 3508 11- If any C-RP introduces itself to east , then east will have to 3509 send the unicast address of C-RPs to west inside the PDTT so 3510 that west will be able to introduce the existing C-RPs to ALL- 3511 PIM-NG-CLIENTS by sending multicast introduction to 239.0.1.190. 3513 12- East will inform C-RPs connected to it, about any changes 3514 received inside the A-MULTICAST MAPPING table by sending unicast 3515 introductions containing the A-MULTICAST MAPPING table to C-RPs 3516 it knows. 3518 [Figure is presented in PDF version] 3520 Figure 37 sample illustration of the above process 3522 The above concepts are mostly related to a design in which C-MAPPER 3523 Mesh-Group concept is considered to reduce the amount of C-MAPPER 3524 introduction message sent to 239.0.1.190.so without the Mesh-Group 3525 concept: 3527 o each C-MAPPER starts sending introduction messages to 239.0.1.190 3528 individually and since the C-RP'(s), RC'(s) and clients residing 3529 in a PIM-NG multicast domain MUST communicate with the closest C- 3530 MAPPER, then peer C-MAPPERs(WEST,EAST) MUST ONLY exchange AMMT and 3531 do not need to exchange the information regarding C-RP'(s) or 3532 TR'(s). 3534 o In the case of peer C-MAPPERs without the Mesh-Group concept, if 3535 the needs of multicasting in a domain dictates that the 3536 information regarding existing C-RP'(s) or TR'(s) MUST be 3537 exchanged between the peer C-MAPPERs, PIM-NG specification 3538 strongly advices that this MUST be done through command initiation 3539 as an optional feature. 3541 o Duo to the fact that, in designs with more than one existing C- 3542 MAPPER, the amount of C-MAPPER introductions destined for 3543 239.0.1.190 will go high and will consume network resources; it is 3544 STRONGLY advised to use the Mesh-Group concept. 3546 4.5.1. SC-MAPPER considerations 3548 Actions taken by C-MAPPERs and SC-MAPPER are as follows: 3550 1- In the case of existing backup MAPPER'(s), C-MAPPER will send the 3551 learned unicast address of the peers in its PDTT along the new 3552 multicast groups it may learn in its introduction messages to the 3553 SC-MAPPER so in case that the C-MAPPER crashes and dies the SC- 3554 MAPPER will be able to immediately take its place and introduces 3555 itself on behalf of its GROUP to the peering C-MAPPER. C-MAPPER 3556 will inform the SC-MAPPER about any changes in the domain by 3557 sending AMMT. 3559 2- As explained in previous sections, if the SC-MAPPER doesn't 3560 receive a C-MAPPER introduction for 2*30 seconds it will 3561 immediately take its place and send a C-MAPPER introduction to the 3562 domain. And in this case as the SC-MAPPER is aware of the existence 3563 of PEER C-MAPPERs it will send unicast introductions to the unicast 3564 address of peers. 3566 3- If C-MAPPER-EAST (Figure 37) doesn't receive an introduction from 3567 its peer for 70 seconds (default timer+10sec) it will send an 3568 introduction to the address of SC-MAPPER-WEST .although if 3569 everything works accordingly by this time C-MAPPER-EAST must have 3570 received the introduction message of SC-MAPPER-WEST. 3572 4.5.2. C-MAPPER Mesh-Group 3574 In a single PIM-NG multicast domain with needs for redundant C- 3575 MAPPERs or PEER-C-MAPPERs ,a mechanism MUST be used to prevent each 3576 single one of existing C-MAPPERs from sending multicast introduction 3577 messages to the destination group 239.0.1.190 which will be heard by 3578 ALL-PIM-NG-CLIENTS and PIM-NG-C-RPs. this prevention mechanism MUST 3579 be implemented due to the fact that ,if each C-MAPPER is going to 3580 send the mentioned multicast introduction message , the multicast 3581 traffic created will consume lots of bandwidth and network resources. 3583 To do so PIM-NG specifications define the concept of C-MAPPER MESH- 3584 GROUP and ACTIVE-C-MAPPER and STANDBY-C-MAPPER (STC-MAPPER) in a way 3585 that: 3587 o Each Domain can have up to 25 C-MAPPER MESH-GROUPs, with each 3588 group ONLY including up to 10 C-MAPPERs. 3590 o Through an election between the existing C-MAPPERs, one C- 3591 MAPPER becomes the ACTIVE C-MAPPER and all the other C-MAPPERs 3592 become STANDBY C-MAPPERs. 3594 o The ACTIVE C-MAPPER is in charge of introducing other C-MAPPERs 3595 or STC-MAPPERs to ALL-PIM-NG-CLIENTS and C-RPs inside the domain 3596 it is resided in, in case ANYCAST RP is not considered, by means 3597 of sending multicast introduction messages to 239.0.1.190 and 3598 sending the unicast address and role of other C-MAPPERS inside 3599 the PIM domain topology table. So that C-RPs in different parts 3600 of the domain will find the closest C-MAPPER and introduce to 3601 that C-MAPPER, whether it is an ACTIVE or STANBY C-MAPPER. 3603 o STC-MAPPERs will maintain connectivity with the active C- 3604 MAPPER, which the related processes had been explained. 3606 o Each STC-MAPPER will send the information related to new C-RPs 3607 it finds to the ACTIVE-C-MAPPER by sending unicast introduction 3608 messages and sending the PIM domain topology table inside it 3609 which contains the information regarding the newly found C-RPs. 3611 o Active C-MAPPER then introduces the existing C-RPs and TR'(s) 3612 to ALL-PIM-NG-CLIENTS by sending multicast introduction messages 3613 to 239.0.1.190, which include PDTT. Through the above process 3614 each CLIENT will be able to contact the closest C-RP in case it 3615 has a source to register or it needs to find a source. 3617 o Each C-MAPPER in a MESH-GROUP (STC-MAPPER and ACTIVE-C-MAPPER) 3618 MUST inform other C-MAPPERs about any changes regarding the 3619 existing multicast sources in the domain by updating its AMMT 3620 with the information it receives from its connected C-RPs. This 3621 way if, for instance C-MAPPER1 receives an update from C- 3622 MAPPER2, it will not need to send it to C-MAPPER3 as it has been 3623 done by C-MAPPER2. 3625 o C-MAPPERs, both ACTIVE and PASSIVE, MUST then inform their 3626 connected or downstream C-RPs about any changes regarding the 3627 existing multicast sources by sending the AMMT. This way ALL- 3628 PIM-NG C-RPs in different parts of the network will have enough 3629 information about the domain to answer the requests of clients 3630 in need of finding a source. This process will eliminate the 3631 need for PEER C-RPs. 3633 o If the design of multicast domain, dictates to form more than 3634 one C-MAPPER Mesh-Group, PIM-NG specifications STRONGLY advises 3635 to place a boundary between different Mesh-Group areas by simply 3636 putting PER'(s) where ever needed. This will limit the 3637 propagation of C-MAPPER introduction messages sent by ACTIVE-C- 3638 MAPPER in each Mesh-Group area to other areas and will reduce 3639 the network resources consumption by unwanted multicast traffic. 3641 o If no boundary is considered between different areas, 3642 components of the PIM-NG domain such as C-RP, Client, and ETC, 3643 MUST react to the introduction message of the closest ACTIVE C- 3644 MAPPER according to the contents of the SOURCE UNICAST ADDRESS 3645 field of the introduction message and the information inside the 3646 unicast routing table. The only issue within the domain MUST BE 3647 ONLY the consumption of network resources by unnecessary 3648 multicast traffic related to multiple ACTIVE C-MAPPER 3649 introduction messages. 3651 o In the case of implementing more than one Mesh-Group, each area 3652 separated from other areas by PER'(s) will act normally, and 3653 existing components such as C-RP'(s), Clients and other 3654 components will respond to the introduction messages received 3655 from the active C-MAPPER in the area. 3657 o If a PIM-NG domain is consisted of more than one C-MAPPER Mesh- 3658 Group and separated in to different areas, PIM-NG specification 3659 STRONGLY advises to peer 2 C-MAPPERs from each Mesh-Group with 3660 each other using the static methods so that the information 3661 related to multicast sources in each area reaches other areas. 3662 Using the static method of connecting 2 different Mesh-Group 3663 will eliminate the need for the C-MAPPER introduction messages 3664 sent to 239.0.1.188 to find other C-MAPPERs, to be forwarded by 3665 PER'(s) between areas. 3667 o If a C-MAPPER in a Mesh-Group is becoming peer with a C-MAPPER 3668 in another Group, depending on the needs of multicasting in the 3669 domain, it may need to advertise the information regarding the 3670 existing C-RP'(s) and TR'(s) too, so in case anything happens to 3671 C-RP'(s) or TR'(s) in one area, the network stays stable and 3672 converges automatically. PIM-NG specifications advise to do this 3673 through command initiation on C-MAPPERs as an optional feature. 3675 4.5.2.1. Active C-MAPPER Election 3677 The election process starts as soon as a c-MAPPER inside a domain 3678 becomes aware that it is part of a MESH-GROUP and is peer with a C- 3679 MAPPER inside the same domain but with a different group. The related 3680 processes are explained bellow: 3682 1- As soon as each C-MAPPER becomes aware that it is peer with 3683 another C-MAPPER in a MESH-GROUP in the same domain but with a 3684 different group, it starts the process of sending multicast 3685 introduction messages to ALL-PIM-NG C-MAPPERs destination 3686 address of 239.0.1.188. 3688 2- Each C-MAPPER will set the PEER-BIT, so that incase there are 3689 any SC-MAPPERs inside the network, they won't read the contents 3690 of the message. 3692 3- Each C-MAPPER sends its domain number, group number, alongside 3693 the priority to be used in the process of election. 3695 4- As soon as each C-MAPPER receives an introduction from its peer 3696 C-MAPPER, it will compare the Mesh-Priority value inside the 3697 introduction message with its own Mesh-Priority value. 3699 5- If the received priority value is higher than its own priority 3700 value then, it will put an entry for the peering C-MAPPER inside 3701 its PEER-MAPPING table with the status of ACTIVE. And by this 3702 time the C-MAPPER understands that it is the STC-MAPPER and must 3703 act as one. 3705 6- If the received priority value is lower than its own priority 3706 value then an entry will be put in the PEER-MAPPING table with 3707 the status of STANDBY. And by this time the C-MAPPER knows that 3708 it is the active C-MAPPER and should act as an ACTIVE-C-MAPPER. 3710 7- In case there is more than 2 C-MAPPERs inside the domain, and 3711 thus each C-MAPPER is configured to become peer with more than 1 3712 C-MAPPER from its own domain, then each C-MAPPER must do the 3713 above processes until it finds all of its peers and comes to a 3714 conclusion that who is the ACTIVE-C-MAPPER inside MESH-GROUP in 3715 the domain. 3717 8- It is strongly advised by PIM-NG specification that a mechanism 3718 be implemented through configuration that informs each C-MAPPER 3719 about the total number of C-MAPPERs that are members of a Mesh- 3720 Group. 3722 9- By this time each C-MAPPER knows that which C-MAPPER is the 3723 active one .so without doing much more process, each C-MAPPER 3724 will silently accept its role and starts the related process. 3726 Through the above processes existing C-MAPPERs in a domain can decide 3727 who is the ACTIVE-C-MAPPER and the rest of them will be STC-MAPPERs. 3729 4.5.3. ANYCAST RP rules 3731 When ANYCAST RP is in use, and more than one C-MAPPER is implemented 3732 in the domain, a C-MAPPER MUST NOT send the information regarding any 3733 new C-RP it finds through the introduction processes, to its peers. 3734 This is due to the fact that from the CLIENTS point of view ALL-C-RPs 3735 has the same unicast address. 3737 Each C-MAPPER MUST maintains connectivity with each C-RP it finds. 3739 4.5.4. Configuration process of Redundant C-MAPPERs 3741 With explanations in previous sections the process is straight 3742 forward also refer to Figure 37 if needed: 3744 1- Each component residing inside a domain is supposed to have a 3745 domain number. So it is assumed that up to this point ALL-PIM-NG 3746 routers inside a domain has been configured with a command which 3747 indicates the domain a CLIENT , RP and MAPPER resides in : 3749 <#IP PIM-NG DOMAIN [X]> 3751 The concepts related to DOMAIN are explained in section 4.6.1.1. . 3753 2- Each C-MAPPER needs to be assigned a GROUP number : 3755 <#IP PIM-NG MAPPER GROUP [1-255]> 3757 The above commands tells the C-MAPPER that it belongs to a 3758 specific GROUP, which in our illustrated example will be 3759 GROUP-A(west) and GROUP-B(east).please keep in mind that the 3760 group value is a number between 1 to 255 3762 3- Each C-MAPPER needs to know its peer GROUP and if needed the 3763 address of the peer: 3765 <#IP PIM-NG PEER MAPPER DOMAIN[X] [GROUP [0-255]| [MAPPER address]]> 3767 Or in case of a mesh group 3769 <#IP PIM-NG MAPPER-MESH-GROUP [1-25]> 3771 <#IP PIM-NG MAPPER-MESH-GROUP MEM-COUNT [1-25]> 3773 <#IP PIM-NG MESH-PEER MAPPER DOMAIN[X] [GROUP [0-255]| [MAPPER 3774 address]]> 3776 <#IP PIM-NG MESH-PRIORITY [0-255(default 100]> 3778 THE above command lines dictates to the C-MAPPER that it must become 3779 peer with a C-MAPPER from DOMAIN X and GROUP[0-255] ,which in our 3780 example will be GROUP-B for west and GROUP-A from east. And also it 3781 should use the configured priority value to be used in ACTIVE-C- 3782 MAPPER election. 3784 Or in case of implementing the Mesh-Group concept dictates the Mesh- 3785 Group Number, total number of Mesh-Group members, group number of the 3786 peer or the unicast address of the peer C-MAPPER and finally the 3787 priority used in the Active C-MAPPER election. 3789 4- In case the unicast address of the peering C-MAPPER is used the 3790 router will send unicast introduction messages to its peer. 3791 Although not advised because of the dynamic nature of this process, 3792 and especially when there are backup peers in each group, but it is 3793 a way to do it. 3795 4.5.5. C-RP and Redundant C-MAPPERs 3797 In such network designs with redundant C-MAPPERs, Active C-MAPPER 3798 informs the C-RPs about the existing C-MAPPERs inside the domain by 3799 sending multicast introduction messages to ALL-PIM-NG-CLIENTS 3800 destination address 239.0.1.190. 3802 Also as described before as soon as a C-MAPPER becomes peer with 3803 another C-MAPPER it will set the A-BIT when sending introduction 3804 messages to either ALL-PIM-NG-CLIENTs (239.0.1.190) or unicast 3805 address of a C-RP. 3807 The above processes dictate to the existing C-RPs that they MUST: 3809 o Find the closest C-MAPPER based on the unicast address of the 3810 C-MAPPER and the information inside the unicast routing 3811 information base. 3813 o Introduce to the closest C-MAPPER. 3815 o If any changes occur inside the domain like, the registration 3816 of a new source or deletion of a new source, each C-RP must 3817 inform the C-MAPPER by sending the AMMT to the C-MAPPER. This 3818 way other C-RPs inside the domain will receive the information 3819 regarding a new source registration inside the network from 3820 their closest C-MAPPER which they had introduced themselves to 3821 it. 3823 o If a C-RP receives a request from a CLIENT for a source, C-RP 3824 MUST send the Domain-set associated with a source to the 3825 client, so that the client knows that where the source is 3826 generated and use the DOMAIN-SET later when sending a join 3827 request to the source. 3829 4.6. Multiple multicast domains 3831 Throughout the specifications of PIM-NG up to this point the concepts 3832 and processes that occur in a single PIM-NG multicast domain have 3833 been explained. 3835 But in large sized networks such as an enterprise network or the 3836 World Wide Web (WWW) itself, the need for using multiple multicast 3837 domains instead of a single multicast domain is needed to be 3838 considered. 3840 Examples of such cases can be: 3842 o Enterprise networks ,which the needs of the network dictates to 3843 divide the multicast domain in to 2 or more separate domains 3844 to have a better control over the propagation of the multicast 3845 traffic. 3847 o Enterprises or companies, with buildings and networks in 3848 different places. With each network or building connected by 3849 means of GRE-TUNNELs or MP-BGP to carry multicast traffic. 3851 o The internet as the biggest network of all, which is divided to 3852 different multicast domains, each connected to the other ones 3853 by different methods like MP-BGP as the carrier protocol of 3854 multicast traffic. 3856 connecting 2 or more PIM-NG multicast domains to exchange the 3857 information regarding the multicast sources originated in each 3858 domain, is done through making 2 or more C-MAPPERs from one domain 3859 peer with one or more C-MAPPER'(s) in the other domain. The C-MAPPERs 3860 then will start to exchange their AMMT'(s) with each other through 3861 sending unicast-encapsulated introduction messages to each other. And 3862 because of the bellow facts: 3864 o The propagation of multicast introduction messages of one 3865 domain in to other domains is not desired. 3867 o A PIM-NG domain may be 1 or more Autonomous Systems away. 3869 o There may be a transitory AS between 2 PIM-NG domains, which 3870 only provides the connectivity in terms of forwarding 3871 multicast traffic destined for group (G) or join/prune 3872 messages. Such a scenario can be seen in designs where 2 PIM- 3873 NG domains are either connected through an ISP or a PIM-SM 3874 network. 3876 o There might be one or more AS'(s) or networks between 2 PIM-NG 3877 domains, that must not receive the information regarding some 3878 of the sources that are being originated, or must not receive 3879 them at all. But their network infrastructure is needed to 3880 forward join/prune messages and multicast traffics. 3882 C-MAPPERs MUST NOT use the automated mechanisms described up to this 3883 point to become peers and MUST use the unicast address of their 3884 desired peers in other domains. 3886 Also PIM-NG uses a unique method to RPF check the received 3887 information regarding multicast sources which provides the existence 3888 of transitory Ass unlike the RPF check method used in PIM-SM and MSDP 3889 which has some limitations in this part. 3891 So PIM-NG specifications uses some rules, processes and definitions 3892 specific to PIM-NG to connect different PIM-NG domains or a network 3893 of PIM-NG domains with a network of PIM-SM domains, which are 3894 explained in the following sections. 3896 [Figure is presented in PDF version] 3898 Figure 38 network with 2 PIM-NG multicast domains 3900 4.6.1. Definitions and concepts 3902 In the following sections different features and rules that are used 3903 when connecting multiple PIM-NG multicast domains, and related 3904 definitions and concepts are explained. 3906 4.6.1.1. Domain 3908 PIM-NG introduces the concept of domain in a way that each domain is 3909 distinguished from the other domains by the domain number or value. 3910 Each domain has its separate set of CLIENTS, C-RPs, TRs and C- 3911 MAPPERs. 3913 PIM-NG uses a 32 bit domain field to support future needs of 3914 multicasting and classifies the range in to 4 groups which are 3915 explained bellow. But PIM-NG specifications suggest to different 3916 methods of domain number assignment which both of them classifies the 3917 range in to 4 groups: 3919 1- This method is unique to PIM-NG specifications and we STRONGLY 3920 advise the use of this method which will need the domain numbers 3921 to be either globally unique and assigned by IANA or locally 3922 unique and assigned by either the RIRs or an entity or enterprise 3923 with a unique PIM-NG-CORE-DOMAIN number: 3925 o Domain range [1-9900] as PIM-NG-DOMAIN. 3927 o Domain range [9901-9999] as PIM-NG-DOMAIN for private, 3928 experimental and documentation use. 3930 o DOMAIN range [10000-4294000000] as PIM-NG-Core-DOMAIN. 3932 o Domain range [4294000001-4294967293] as PIM-NG-Core-DOMAIN for 3933 private, experimental and documentation use. 3935 o Domain numbers 0 and 4294967294 are reserved. 3937 2- This method won't need any assignment by IANA or any RIR, since a 3938 domain number will be the same as the globally unique autonomous 3939 system number (AS number) assigned by IANA to be used as PIM-NG- 3940 CORE-DOMAIN numbers, and PIM-NG-DOMAIN numbers will be chosen from 3941 the private ranges. But this method is only introduced to make the 3942 domain number assignment easier and is not the advised method: 3944 o Domain range [1-64511] and [64536-4200000000] as PIM-NG-CORE- 3945 DOMAIN numbers which due to the fact the numbers are assigned 3946 by IANA as AS numbers, they are globally unique. 3948 o Domain range [64512-65512] as PIM-NG-DOMAIN numbers. This range 3949 needs to be locally unique from the RIR-CORE-DOMAIN point of 3950 view or the CORE-DOMAIN of an entity or enterprise. 3952 o DOMAIN range [65513-65535] as PIM-NG-DOMAIN numbers for 3953 private, experimental and documentation use. 3955 o Domain range [4200000001-4294967293] as PIM-NG-Core-DOMAIN for 3956 private, experimental and documentation use. 3958 o Domain numbers 0 and 4294967294 are reserved. 3960 Now that the domain number classifications are explained, we are 3961 going to explain the rules and specifications that apply to the above 3962 classifications. 3964 The bellow specifications and rules apply to ALL-PIM-NG domains: 3966 1- All clients inside a domain MUST have the same domain number. 3968 2- All C-RPs inside a domain MUST have the same domain number, as 3969 the clients. 3971 3- All C-MAPPERs inside a domain MUST have the same domain number 3972 as the CLIENTs. 3974 4- All TRs inside a domain MUST have the same domain number as the 3975 C-MAPPER. 3977 5- Clients MUST only respond to or accept HELLO messages from a 3978 neighbor with matching domain number. 3980 6- Clients MUST only accept and respond to C-MAPPER introduction 3981 messages sent to 239.0.1.190, which has a matching domain 3982 number. 3984 7- C-RPs MUST only accept and respond to C-MAPPER introduction 3985 messages sent to 239.0.1.190 or unicast C-MAPPER introduction 3986 messages with matching domain number. 3988 8- C-RPs can only become peer with C-RPs inside the same domain, 3989 so a C-RP MUST NOT accept or respond to the C-RP introduction 3990 message sent to 239.0.1.189 from other domains. 3992 9- C-MAPPERs can become peer with C-MAPPERs from the same domain 3993 or from other domains. 3995 10- C-MAPPERs MUST BE the only means to exchange the information 3996 regarding the existing sources in each domain by exchanging A- 3997 MULTICAST MAPPING TABLES. 3999 11- IF a DOMAIN is needed to be connected to another domain it MUST 4000 be connected through one or more PIM-EDGE-ROUTERs (PER/PPER) to 4001 prevent the propagation of unnecessary multicast introduction 4002 traffic in each domain. In case an enterprise needs to divide 4003 its multicast domain in to 2 or more sub-domains, it is strongly 4004 advised to use PERs to prevent the fellow of unnecessary 4005 multicast introduction traffic of one domain to other domains. 4007 12- C-MAPPER'(s) MUST introduce all existing C-RPs and TRs they 4008 find inside the domain to ALL-PIM-NG-ROUTERs inside the domain 4009 (230.0.1.190). 4011 13- C-MAPPERs MUST remove any private DOMAIN, private CORE-DOMAIN 4012 or sub-domain number before advertising any multicast source 4013 globally or to be more specific to a peer C-MAPPER in another 4014 domain. 4016 The bellow specifications and rules apply to PIM-NG-DOMAINs: 4018 1- PIM-NG-DOMAIN number values MUST be unique from the connected 4019 PIM-NG-CORE-DOMAIN point of view .so the values MUST be assigned 4020 by a local organization or Regional Internet Registry who has a 4021 globally unique PIM-NG-CORE-DOMAIN number, in case the 4022 enterprise doesn't have a PIM-NG-CORE-DOMAIN number which is 4023 globally unique. 4025 2- A PIM-NG-DOMAIN can be either a public network or a private 4026 network which is connected to the public network by using the 4027 NETWORK ADDRESS TRANSLATION. And by private PIM-NG specification 4028 means that all the components of the PIM-NG domain such as C- 4029 MAPPERs and even sources can use private unicast addresses. 4031 3- An enterprise can use any PIM-NG-DOMAIN number from the 4032 classified range freely as long as it doesn't need to advertise 4033 its multicast sources globally and by advertise from now on we 4034 mean sending any existing multicast sources to a peer C-MAPPER 4035 inside a PIM-NG-CORE-DOMAIN with a globally unique domain number 4036 by sending A-MULTICAST-MAPPING-TABLE inside the unicast- 4037 encapsulated C-MAPPER introduction message. 4039 4- If an enterprise needs to advertise its multicast sources 4040 globally but does not wish to or doesn't need to apply to get a 4041 globally unique PIM-NG-CORE-DOMAIN number , it MUST apply to get 4042 a unique PIM-NG-DOMAIN number from the Regional Internet 4043 Registry and advertise its multicast sources through the 4044 Regional Internet Registry's PIM-NG-CORE-DOMAIN. 4046 5- If an enterprise with more than one PIM-NG-DOMAINs all 4047 connected through an Internet Service Provider(ISP) backbone 4048 ,doesn't need to advertise its multicast sources globally and 4049 only needs to use them internally , it doesn't not need to 4050 become connected to the ISP by making one or more C-MAPPERs peer 4051 with a C-MAPPER inside the ISP backbone ,due to the fact that 4052 PIM-NG specifications uses its special unicast introduction 4053 method to make C-MAPPERs in different domains peer alongside its 4054 RPF check method unique to PIM-NG ,and doesn't use MSDP. 4056 6- If a multicast source inside a PIM-NG-DOMAIN needs to be 4057 globally accessible it MUST be first advertised to a peer C- 4058 MAPPER inside an existing PIM-NG-CORE-DOMAIN. 4060 7- If an enterprise needs to divide its multicast domain into 2 or 4061 more multicast domains, without the need of applying to get more 4062 than one locally unique PIM-NG-DOMAIN number from the Regional 4063 Internet Registry, it can do so by dividing its multicast domain 4064 into 2 or more domains as sub-domains of the main domain which 4065 is assigned by the Regional Internet Registry. The related 4066 concepts will be discussed later. 4068 8- A PIM-NG-DOMAIN can be connected to a PIM-NG-CORE-DOMAIN 4069 through another PIM-NG-DOMAIN or even an existing PIM-SM domain 4070 and does not need to be directly connected to send join/prune 4071 messages or receive traffic for a multicast destination group. 4072 But in order to advertise its multicast sources globally it MUST 4073 be connected to either the neighbor PIM-NG-DOMAIN which is 4074 connected to a core domain or directly to the PIM-NG-CORE-DOMAIN 4075 and by connected PIM-NG specifications dictates that at least 4076 ONE C-MAPPER inside the PIM-NG-DOMAIN MUST be a peer with either 4077 a C-MAPPER inside the neighbor domain or inside the core domain. 4079 9- Normal domains can have one or more Tree-Roots(TR).if TR exists 4080 in a domain the join/prune messages MUST first be forwarded 4081 towards the existing TR, and then towards the source. 4083 10- If the network is consisted of PIM-NG-CORE-DOMAINs (CD) and a 4084 client is in need of sending join/prune towards a source which 4085 can be reached through an existing PIM-NG-CORE-DOMAIN, and TR or 4086 TRs are considered in each PIM-NG-DOMAIN, each client MUST first 4087 send its join request for a source towards the TR residing 4088 inside its domain and then after the join/prune message reached 4089 the local TR it MUST be forwarded towards the TR inside the PIM- 4090 NG-CORE-DOMAIN . So all clients residing inside PIM-NG-DOMAIN 4091 MUST have knowledge about the existence of the CORE-DOMAIN TR or 4092 TRs. 4094 11- When a PER/PPER receives join/prune message on an external 4095 interface which is connected to either another domain or public 4096 networks, destined for a source inside its domain or a TR inside 4097 an existing PIM-NG-CORE-DOMAIN or a source in another domain it 4098 MUST forward it first toward the closest TR inside its own 4099 domain by setting the R-BIT inside the source address field of 4100 the received join/prune and putting the address of the closest 4101 TR in the appropriate field and then the TR will forward the 4102 traffic towards the source or existing TR inside the PIM-NG- 4103 CORE-DOMAIN if it is dictated inside the join/prune message. 4104 This process will eliminate unnecessary join message traffic 4105 towards a source in case many CLIENTS will need the same 4106 specific traffic. Or a new CLIENT may ask to receive the same 4107 traffic. 4109 12- A C-MAPPER MUST add its domain number to the domain-set of any 4110 received multicast sources received from PEER-C-MAPPERs in other 4111 domains before advertising them to other PEER-C-MAPPERs in other 4112 domains. 4114 13- A C-MAPPER inside a PIM-NG-DOMAIN MUST add its domain number 4115 to the domain-set of any received multicast sources from other 4116 domains when advertising to a PEER-C-MAPPER inside the same 4117 domain. These additional prepended domain values will be use by 4118 C-MAPPERs inside the domain for RPF check. 4120 14- A C-MAPPER inside a PIM-NG-DOMAIN MUST add its domain number 4121 to the domain-set of any received multicast sources from peer C- 4122 MAPPERs inside the domain to a PEER-C-MAPPER inside the same 4123 domain. These additional prepended domain values will be use by 4124 C-MAPPERs inside the domain for RPF check. 4126 15- If a C-MAPPER loses its connectivity with a PEER-C-MAPPER 4127 inside other domains whether a PIM-NG-DOMAIN or a PIM-NG-CORE- 4128 DOMAIN it MUST NOT immediately remove the multicast sources 4129 received from that PEER-C-MAPPER .instead in such a case the C- 4130 MAPPER MUST set a 5 minute timer by-default which is called the 4131 source-suspension timer and inform other PEER-C-MAPPERs about 4132 the incident by sending AMMT with the sources it has been 4133 receiving from that PEER being entered as suspended. This way 4134 the C-RPs inside other domain will see the suspend flag and will 4135 know that they MUST NOT answer to client requests sent for those 4136 sources until further notice ,which will be either activating 4137 the sources again or removing them. 4139 16- If a C-MAPPER loses its connectivity with a PEER-C-MAPPER 4140 inside the same domain, it MUST only set the suspend flag for 4141 the sources that the lost PEER was receiving from outside 4142 domains. This is due to the fact that when inside a domain a C- 4143 MAPPER is dead C-RPs will use other existing C-MAPPERs 4144 immediately. So there will be no need to set the suspend flag 4145 for the sources that are being generated inside the domain. 4147 17- C-MAPPERs MUST remove any private DOMAIN or sub-domain number 4148 before advertising any multicast source to peer C-MAPPERs inside 4149 the domain or globally to a peer C-MAPPER in another domain. 4151 18- C-MAPPER or PPER with peers in other domains MUST remove the 4152 additional prepended 4154 The bellow specifications and rules apply to PIM-NG-CORE-DOMAIN (CD): 4156 1- PIM-NG-CORE-DOMAINs number MUST be globally unique to be able 4157 to advertise any multicast source meant to be used globally by 4158 any user connected to the World Wide Web. 4160 2- PIM-NG-CORE-DOMAIN number assignment MUST be done by an 4161 international organization such as IANA. 4163 3- A PIM-NG-CORE-DOMAIN can be simply consisted of one or more C- 4164 MAPPERs and PERs in the core of an enterprise network to 4165 advertise the multicast sources received from peer C-MAPPERs in 4166 connected PIM-NG-DOMAINs of the enterprise. Or can be the 4167 internet backbone of a country connecting the countries network 4168 infrastructure to other countries internet backbone. 4170 4- A PIM-NG-CORE-DOMAIN can be the backbone of an Internet Service 4171 Provider (ISP) from its customer's point of view. in this case 4172 if a customer has 2 different networks connected through an ISP, 4173 if it needs to advertise its multicast sources globally it will 4174 need to do it through the ISP's PIM-NG-CORE-DOMAIN if it doesn't 4175 wish or doesn't need to receive a unique core domain number, by 4176 peering at least one C-MAPPER in one of its domains with a C- 4177 MAPPER inside ISP backbone. 4179 5- A PIM-NG-CORE-DOMAIN can be either a public network or a 4180 private network which is connected to the public network by 4181 using the NETWORK ADDRESS TRANSLATION. And by private PIM-NG 4182 specification means that all the components of the PIM-NG domain 4183 such as C-MAPPERs and even sources can use private unicast 4184 addresses. 4186 6- If an enterprise does not wish to advertise its multicast 4187 sources globally but needs to use one or more PIM-NG-CORE- 4188 DOMAIN'(s) it can freely use a domain value from the private 4189 range. But in case they need to advertise any multicast source 4190 globally to be used by users connected to other PIM-NG-CORE- 4191 DOMAINs, it MUST apply to get a unique domain number. 4193 7- If an enterprise is using private PIM-NG-CORE-DOMAIN numbers 4194 for its internal use and needs to advertise its multicast 4195 sources globally without getting a unique PIM-NG-CORE-DOMAIN 4196 number, it can do so by applying to get a locally unique PIM-NG- 4197 DOMAIN number to advertise its multicast sources through the 4198 Regional Internet Registry's PIM-NG-CORE-DOMAIN. In this case 4199 the private core domain number must be set to be a sub-domain of 4200 the assigned PIM-NG-DOMAIN number, which the related concepts 4201 will be discussed later. 4203 8- CORE-DOMAIN C-MAPPERs are responsible for connecting different 4204 CORE-DOMAINs to each other. 4206 9- A C-MAPPER MUST add its domain number to the domain-set of any 4207 received multicast sources received from PEER-C-MAPPERs in other 4208 domains before advertising them to other PEER-C-MAPPERs in other 4209 domains. 4211 10- A C-MAPPER inside a PIM-NG-CORE-DOMAIN MUST add its domain 4212 number to the domain-set of any received multicast sources from 4213 other domains when advertising to a PEER-C-MAPPER inside the 4214 same domain. These additional prepended domain values will be 4215 use by C-MAPPERs inside the domain for RPF check. 4217 11- A C-MAPPER inside a PIM-NG-CORE-DOMAIN MUST add its domain 4218 number to the domain-set of any received multicast sources from 4219 peer C-MAPPERs inside the domain to a PEER-C-MAPPER inside the 4220 same domain. These additional prepended domain values will be 4221 use by C-MAPPERs inside the domain for RPF check. 4223 12- C-MAPPERs MUST remove any private DOMAIN or sub-domain number 4224 before advertising any multicast source globally or to be more 4225 specific to a peer C-MAPPER in another CORE-DOMAIN. 4227 13- A C-MAPPER MUST remove additional domains in domain-set of a 4228 received multicast source from a PIM-NG-DOMAIN, except the first 4229 domain number in the domain-set which shows the domain in which 4230 a source is generated, when advertising a multicast source to a 4231 neighbor PIM-NG-CORE-DOMAIN. 4233 14- A C-MAPPER MUST NOT remove additional domains from the domain- 4234 set of a received multicast source when advertising to PEER-C- 4235 MAPPERs inside a PIM-NG-DOMAIN. 4237 15- If a C-MAPPER loses its connectivity with a PEER-C-MAPPER 4238 either inside the same domain or other domains whether a PIM-NG- 4239 DOMAIN or a PIM-NG-CORE-DOMAIN it MUST NOT immediately remove 4240 the multicast sources received from that PEER-C-MAPPER .instead 4241 in such a case the C-MAPPER MUST set a 5 minute timer by-default 4242 which is called the source-suspension timer and inform other 4243 PEER-C-MAPPERs about the incident by setting the SUSPEND flag 4244 inside the A-MULTICAST-MAPPING-TABLE for the sources it has been 4245 receiving from that PEER and send the table with the suspend 4246 flag to other peers. This way the C-RPs inside other domain will 4247 see the suspend flag and will know that they MUST NOT answer to 4248 client requests sent for those sources until further notice 4249 ,which will be either activating the sources again or removing 4250 them. 4252 16- If a C-MAPPER loses its connectivity with a PEER-C-MAPPER 4253 inside the same domain, it MUST only set the suspend flag for 4254 the sources that the lost PEER was receiving from outside 4255 domains. This is due to the fact that when inside a domain a C- 4256 MAPPER is dead C-RPs will use other existing C-MAPPERs 4257 immediately. So there will be no need to set the suspend flag 4258 for the sources that are being generated inside the domain. 4260 17- CORE-DOMAIN C-MAPPER'(s) MUST introduce any existing CORE- 4261 DOMAIN TR'(s) to normal domains for further use. 4263 18- CORE-DOMAINs MUST have one or more TR'(s). 4265 4.6.1.2. PIM-EDGE-ROUTER (PER/PPER) 4267 As described in the previous section each domain is distinguished 4268 from the other domains by a unique domain number. 4270 Each domain MUST be completely isolated from the other domains, and 4271 in case for example all domains are located under one roof inside one 4272 network infrastructure and using one united dynamic routing protocol 4273 it is strongly advised to use PERs to reduce the propagation of 4274 unnecessary multicast introduction message of C-MAPPERs or C-RP'(s) 4275 in search of their peers. 4277 An example of such network can be an enterprise network trying to 4278 divide its current network infrastructure in to 2 or more PIM-NG 4279 multicast domains or Sub-Domains. If these connected multicast 4280 domains are not isolated somehow we will see unnecessary multicast 4281 traffic inside each domain, which in the PIM-NG case will be the 4282 multicast traffics related to C-MAPPER introduction messages to ALL- 4283 PIM-CLIENTs(239.0.1.190) or C-RP introduction messages(239.0.1.189) 4284 sent out to find PEER-C-RPs which are intended to circulate inside 4285 one domain and since PIM-NG-ROUTERs inside other domains wont react 4286 to such messages from other domains it will be a waste of network 4287 resources. 4289 Another example could be the World Wide Web itself, in which each 4290 multicast domain is connected to other multicast domains by either 4291 using one or more edge routers connected to other multicast domains 4292 by using MP-BGP or a simple tunnel between each 2 multicast domain to 4293 give multicast traffic transfer ability. And such designs are due to 4294 the fact that in reality not all routers between each multicast 4295 domain support the needs of multicast traffic transfer. 4297 Because of the above facts PIM-NG introduces the concept of PIM-EDGE- 4298 ROUTER with 2 different classifications: 4300 1- PIM-EDGE-ROUTER(PER):a PER is simply a PIM-NG-AWARE router that 4301 acts as the boundary between either 2 PIM-NG domains, Sub-Domain 4302 or a domain and outside networks and will control the propagation 4303 of unnecessary or unwanted PIM-NG introduction messages. 4305 2- PRIVATE-PIM-EDGE-ROUTER (PPER): a PPER is a PIM-NG-AWARE router at 4306 the edge of the network which is responsible for NETWORK ADDRESS 4307 TRANSLATION (NAT) operations. PPER is responsible of becoming peer 4308 with other PPERs in other domains in order to exchange AMMT'(s) 4309 between different private PIM-NG domains. It is seen as a normal 4310 C-MAPPER by other domains, and is seen as PPER by internal C- 4311 MAPPERs in a way that an existing C-MAPPER inside the domain will 4312 only exchange the contents of AMMT with a PPER and won't introduce 4313 it to the domain. 4315 Below specifications and rules apply to PIM-EDGE-ROUTERs (PER): 4317 o A PIM-NG-AWARE router connecting 2 or more PIM-NG multicast 4318 domains to each other is considered a PIM-EDGE-ROUTER(PER) 4320 o A PIM-EDGE-ROUTER connecting a public PIM-NG domain to other 4321 PIM-NG multicast domains is called a PER. And by public PIM-NG 4322 specifications means that either every PIM-NG-AWARE router 4323 inside the domain is using public class IPs or at least C- 4324 MAPPERs or ALL-SOURCES inside the domain use public IP 4325 addresses. In the case of public PIM-NG multicast domain ,if the 4326 domain is connected to other domains by a protocol capable of 4327 transferring multicast traffic ,such as MP-BGP it is advise to 4328 put the PER at the edge of the network. If PERs in separate 4329 domains are connected by using a tunnel, they can be placed 4330 anywhere. 4332 o PERs can use an interface loopback as their unicast address 4333 when introducing to C-MAPPERs or any other interface connected 4334 to the DOMAIN. 4336 o Since all interfaces of a PIM-NG-AWARE ROUTER are considered 4337 internal interfaces by default, a PIM-NG PER MUST have one or 4338 more external interfaces connected to the outside networks or 4339 domain. so a PER can have one or more interface inside domain[X] 4340 and one or more inside domain[Y]. 4342 o A PER MUST NOT forward any multicast introduction messages 4343 received on an internal interface to its external interface. 4344 Unless it is dictated to the PER to forward a specific multicast 4345 introduction which MUST BE done based on the domain number 4346 indicated in the introduction message. 4348 o A PER can act as the boundary between to C-MAPPER Mesh-Group 4349 Areas inside a domain to prevent the propagation of ACTIVE C- 4350 MAPPER introductions from one area to the other area. In this 4351 case the PER MUST BE configured to have one or more interface in 4352 each area. These areas are ONLY meaningful to the PER, so that 4353 the PER will not forward multicast introductions from one area 4354 to the other one. 4356 o A PER which is acting as the boundary between Sub-Domains, MUST 4357 know the main domain number in which it is resided and also the 4358 Sub-Domain numbers to which it is connected. This is duo to the 4359 fact that in some designs the need for multicasting in PIM-NG 4360 will need the PER to forward the ACTIVE C-MAPPER introduction 4361 messages sent to 239.0.1.190 in the main domain by checking the 4362 domain number of the received introduction messages. The 4363 concepts related to Sub-Domain are explained in section 4.6.5. . 4365 o A PER acts as the boundary between 2 domains, Sub-Domains and 4366 areas, so it MUST NOT forward multicast introduction messages 4367 sent to 239.0.1.188, 239.0.1.189, 239.0.1.190 received from one 4368 domain, Sub-Domain and area to the other. ONLY in case of Sub- 4369 Domain and Area a PER acting as the boundary between the 2 can 4370 forward such traffic and ONLY if it is dictated to do so. 4372 o A PER can act as a BORDER-PIM-NG-ROUTER (BPR) when connecting a 4373 PIM-NG domain to a PIM-SM domain. In such designs PER MUST have 4374 one or more hands or interfaces in PIM-NG domain and one or more 4375 hands in PIM-SM domain. 4377 o A PER MUST introduce itself to the closest C-MAPPER only in 4378 case, it has the role of a BPR too, so that the C-MAPPER starts 4379 sending AMMT to the PER. PER will use the contents of AMMT in 4380 the process of forwarding join/prune messages received from the 4381 connected PIM-SM network to the PIM-NG network. 4383 o If in a network design such as a network containing PIM-NG SUB- 4384 DOMAINs ,it is needed that the PER forwards the multicast 4385 traffic destined for 239.0.1.188 and 239.0.1.190 in the main 4386 domain ,it MUST become aware of the situation to be able to 4387 forward that specific traffic. 4389 o In case TR exists in the domain, each PER MUST set the R-BIT of 4390 the Source Unicast Address which shows that the join/prune 4391 message MUST be forwarded towards the TR first and put the 4392 address of the closest TR in the appropriate field before 4393 forwarding it in the domain. 4395 The bellow specifications and rules apply to PRIVATE-PIM-EDGE- 4396 ROUTERS (PPER): 4398 o A PIM-EDGE-ROUTER connecting a private PIM-NG multicast domain 4399 to other domains ,whether private or public ,and typically is 4400 responsible for doing the NETWORK ADDRESS TRANSLATION will 4401 introduce itself as a PRIVATE-PIM-EDGE-ROUTER(PPER) to the C- 4402 MAPPERs inside the domain. It will be done by the EDGE-ROUTER at 4403 the time of introducing itself to the C-MAPPER, and by setting 4404 the PRIVATE (P)-BIT in the introduction message. And by private 4405 PIM-NG specifications means that all components of the domain 4406 such as C-MAPPERs and even sources use private IP addresses, or 4407 at least some of the sources inside the domain are using private 4408 addresses which need to be accessed from the outside. 4410 o In a network design in which all C-MAPPERs inside the domain 4411 are using private unicest addresses, PPER is responsible of 4412 becoming PEER with other PPERs or C-MAPPERs in other domains in 4413 order to provide the ability of exchanging the information 4414 regarding the existing multicast sources in different domains, 4415 through exchanging the AMMT between PPERs or C-MAPPERs in other 4416 domains and C-MAPPERs inside their own domain. So in such a 4417 design a PPER is seen as a PEER-C-MAPPER by PPERs or C-MAPPERs 4418 in other domains and MUST also be configured as a C-MAPPER. 4420 o A PPER is seen as only a PPER by C-MAPPERs inside the domain 4421 and the information related to it such as the unicast address, 4422 MUST NOT be advertised inside the domain in C-MAPPER 4423 introduction messages sent to 239.0.1.190. Such information is 4424 only usable by existing C-MAPPER'(s). And C-MAPPER uses the 4425 information regarding PPER to send the contents of AMMT to the 4426 PPER'(s). 4428 o In designs in which at least one C-MAPPER inside the domain is 4429 using publicly routable IP address, and is configured to 4430 directly become peer with C-MAPPER'(s) or PPER'(s) in other 4431 domains on behalf of the domain a PPER may not need to play the 4432 role of C-MAPPER too, and will only play the role of PPER and 4433 receive the A-MULTICAST MAPPING TABLE for further use. 4435 o In a network design in which all C-MAPPERs inside the domain 4436 are using private unicast addresses ,PPER is responsible of 4437 becoming MSDP-PEER with RP'(s) inside any neighboring PIM-SM 4438 domain , in case each domain needs to become aware of the 4439 sources that are being generated in the other domain. 4441 o A PPER can act as a BORDER-PIM-NG-ROUTER (BPR) when connecting 4442 a private PIM-NG domain to a PIM-SM domain. In such designs PER 4443 MUST have one or more hands or interfaces in PIM-NG domain and 4444 one or more hands in PIM-SM domain. 4446 o Each PPER MUST send unicast introduction messages to the 4447 unicast address of the closest C-MAPPER, Introducing itself so 4448 that the C-MAPPERs can start sending their A-MULTICAST MAPPING 4449 TABLEs. 4451 o To find the closest C-MAPPER, a PPER MUST listen to the 4452 introduction messages sent by the C-MAPPER in the domain or in 4453 case of existing C-MAPPER Mesh-Groups the introduction messages 4454 sent by the Active C-MAPPER. 4456 o In case of a multicast domain with more than one C-MAPPER Mesh- 4457 Group isolated and separated in to 2 or more Mesh-Group areas by 4458 setting up boundaries using PERs, it is STRONGLY advised to 4459 statically introduce at least one C-MAPPER from other Mesh- 4460 Groups to the PPER. This is a MUST due to the fact that the PPER 4461 will definitely hear the introduction message of the active C- 4462 MAPPER in area it is resided in, but it needs to also be aware 4463 of at least one C-MAPPER from the other Mesh-Groups. 4465 o Each PPER MUST inform the C-MAPPERs inside the domain about the 4466 received multicast sources from other domains by sending the 4467 AMMT to the closest C-MAPPER to which it has introduced itself 4468 to in the first place. 4470 o When a PPER receives information regarding multicast sources 4471 inside its own domain, since it is at the edge of a private 4472 network it MUST first save the information related to the 4473 unicast address of each source with private IP address in a 4474 table specific to PPER called INTERNAL-MULTICAST-SOURCE TABLE 4475 (IMST) and then it MUST change the unicast address of the 4476 sources with its public unicast address before sending the AMMT 4477 to PEER PPERs or MSDP-PEERs. The process of changing source 4478 unicast address of multicast groups MUST be done based on an 4479 existing ACL or route-map, due to the fact that some multicast 4480 groups may use public unicast addresses, and we don't want 4481 ending up changing those addresses too. So if a source unicast 4482 address needs to be changed it MUST be chosen by an ACL. 4484 o If a PPER receives a join/prune message on an external 4485 interface with its own unicast address as the source of the 4486 multicast group, it MUST check the contents of IMST and find the 4487 real unicast address of the source that is originating traffic 4488 for multicast group (G) and replace it with the address inside 4489 the join/prune message and forward it to the domain. 4491 o If a domain is connected to outside networks through more than 4492 one PPERs , and each PPER is acting as a C-MAPPER to become peer 4493 with PPER'(s) or C-MAPPER'(S) in other domains on behalf of C- 4494 MAPPERs inside its domain , a mechanism MUST BE used so that all 4495 the PPERs use one united publicly routable IP address as the 4496 originator address of the sources that are originated inside the 4497 domain, and also in case there are multicast sources using 4498 private IP addresses that must be advertised to other domains, 4499 as the source unicast address of such multicast sources. This is 4500 due to the fact that we don't want to end up advertising our 4501 multicast sources with different originator address or source 4502 unicast addresses to other domains. So we advise that on each 4503 PPER a united publically routable address be configured as the 4504 originator address if the PPERs also have the role of C-MAPPER. 4506 o In case TR exists in the domain, each PPER MUST set the R-BIT 4507 of the Source Unicast Address which shows that the join/prune 4508 message MUST be forwarded towards the TR first and put the 4509 address of the closest TR in the appropriate field before 4510 forwarding it in the domain. 4512 o EACH PPER MUST change the originator unicast address of the 4513 sources created inside its domain with its own public address. 4515 This address or the originator unicast address will be used in 4516 case a PIM-SM domain is needed to become connected to a network 4517 of PIM-NG domains in the process of RPF check. 4519 o PPER MUST maintain connectivity with C-MAPPER through its 4520 unicast introduction messages and in case it loses its 4521 connectivity with the C-MAPPER and if SC-MAPPER exists, it MUST 4522 immediately query the SC-MAPPER. This is duo the fact that a 4523 PPER is acting as the C-MAPPER and any existing SC-MAPPER from 4524 the peer C-MAPPER's point of view. PPER MUST send periodic 4525 introductions every 30 seconds. 4527 0 1 2 3 4528 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 4529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4530 |PIM Ver| Type | Reserved | Checksum | 4531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4532 | D O M A I N | 4533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4534 |P|Z|B| reserved | 4535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4536 | EDGE unicast address | 4537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4538 | A-MULTICAST MAPPING TABLE | 4539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4540 Figure 39 PER introduction message 4542 o TYPE :EDGE 4544 o Z-BIT: whenever a PPER needs to inform a change about its 4545 connected neighbor DOMAINs to C-MAPPER it will set this BIT 4546 and then send the information. 4548 o P-BIT: when set indicates to the receiving C-MAPPER that it 4549 is a PPER. 4551 o B-BIT: Border-PIM-NG-ROUTER BIT is set when a PER has the 4552 role of BPR. 4554 +---------------------------------------------------+ 4555 |source address | Destination Group| source host | 4556 +---------------------------------------------------+ 4557 | | | | 4558 +---------------------------------------------------+ 4559 | | | | 4560 +---------------------------------------------------+ 4561 Figure 40 Internal Multicast Source Table 4563 4.6.1.3. Tree Root (TR) 4565 Up to this point of explaining PIM-NG specifications, although the 4566 existence of a component named TR was mentioned, clients were to make 4567 direct contact with a source and send their join message directly to 4568 the desired source. The processes have been explained this way to 4569 give a good understanding of the underlying processes. 4571 They still can, but to support the needs of multicasting, PIM-NG 4572 introduces the concept of TREE-ROOT (TR). This concept has been 4573 introduced, duo to the fact that, there might be many clients in each 4574 domain in need of listening to a particular multicast traffic and if 4575 they were all to send their join messages directly to that source or 4576 the TR residing in the core domain, the final result will be the 4577 waste of bandwidth and the waste of source and CORE-DOMAIN-TR 4578 resources. 4580 The below specifications apply to TR: 4582 o Each normal domain can have one or more TR'(s) which it is 4583 strongly advised to be used. 4585 o Each core-domain MUST have one or more TR'(s). 4587 o ALL-PIM-NG-TR'(s) MUST introduce themselves to the closest C- 4588 MAPPER by sending uicast introduction messages ,so that the C- 4589 MAPPER learns the TR's unicast address and introduce it to the 4590 domain . 4592 o If any core-domain is considered, the C-MAPPERs inside the 4593 core-domain MUST introduce any existing TR inside the core- 4594 domain to all normal domains connected to it so that the entire 4595 PIM-NG multicast network will become aware of the existence of 4596 core-domain TR'(s). 4598 o If a TR is receiving multicast traffic (G), and other TR'(s) 4599 exist in the domain, it MUST make the other TR'(s) aware of the 4600 traffic it is receiving by sending an introduction message 4601 containing the JOINED-GROUP-TABLE, to the unicast address of the 4602 other TR'(s) it receives from C-MAPPER inside PDTT. This is done 4603 due to fact that other clients may become interested in 4604 receiving such traffic later, so if they send their join to 4605 another TR which is closer to them and not aware of the 4606 multicast traffic, it can be double act of sending joins out of 4607 a domain and a waste of resources. 4609 o When a TR receives a join/prune message with the R-BIT of 4610 Source Unicast address being set, which means that the message 4611 MUST reach the desired TR first, it MUST check the address of 4612 the TR and if the address is its own address it MUST clear the 4613 R-BIT, which means that the message has reached the desired TR 4614 in the domain and then forward it towards the desired source. 4616 o If in a PIM-NG multicast domain more than one TR exists, and a 4617 TR receives a join/prune message for (S, G), before clearing the 4618 R-BIT and forwarding the message to the next hop, it MUST first 4619 check its JOINED-GROUPS TABLE to see if other TR'(s) has joined 4620 the SPT for that (S, G). and if an entry is found in the JOINED- 4621 GROUP table received from other TR'(s), then if and ONLY IF the 4622 cost of reaching the TR which already joined the SPT for (S, 4623 G)based on the calculations done by the underlying unicast 4624 routing protocol is better than the cost to reach the source, it 4625 MUST leave the R-BIT and MUST NOT clear it and MUST put the 4626 address of the TR which has already joined the SPT for (S,G) in 4627 the appropriate field and forward the join/prune message to the 4628 next hop in the best path towards that TR. Otherwise in case the 4629 cost of reaching the source is better than the cost of reaching 4630 the next TR which is already joined the SPT for (s, G), it MUST 4631 clear the R-BIT and forward the join/prune message to the next 4632 hop in the best path towards the source. 4634 o If an RP has the role of TR, receiving a join/prune message of 4635 (*, G, RPT) with the RP address as the TR address means that the 4636 RP MUST NOT send back the (S) for (G) to the client and MUST 4637 find that source unicast address of (G) in either MMT or AMMT 4638 and put the address in the appropriate field and forward the 4639 packet towards the source. 4641 o If a TR is also a C-RP, then TR introduction messages MUST NOT 4642 BE sent and only a C-RP introduction message with the TR-BIT set 4643 WILL be enough. 4645 o Each TR MUST maintain connectivity with the C-MAPPER by sending 4646 periodic introductions every 30 seconds. 4648 o If more than 1 TR exists within a domain in order to reduce the 4649 size of PDTT in C-MAPPER introduction messages sent to 4650 239.0.1.190 it is advised to use the ANYCAST concept in the 4651 Domain. to use the ANYCAST concept each TR MUST be configured 4652 with both the ANYCAST address which is used by all clients and 4653 introduced by C-MAPPER in its instruction messages and an 4654 additional unicast address which will be used in TR to C-MAPPER 4655 and TR to TR communications. If the ANYCAST concept is used the 4656 ANYCAST address MUST be defined on the C-MAPPER or Active C- 4657 MAPPER to be used in PDTT by C-MAPPER when sending introductions 4658 t0 239.0.1.190. 4660 o If the ANYCAST concept is used the C-MAPPER MUST send the 4661 unicast address of all existing TR'(s) that it finds to existing 4662 TR'(s) within its unicast introduction messages sent to TR'(s) 4663 for further use by TR'(s). 4665 At the end it must be noted that the TR do not need to be a separate 4666 component, and each existing C-MAPPER or C-RP in the domain is the 4667 best choice to also play the role of an TR. But PIM-NG specifications 4668 STRONGLY advise the use of C-RP if it is a must. 4670 0 1 2 3 4671 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 4672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4673 |PIM Ver| Type | Reserved | Checksum | 4674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4675 | D O M A I N | 4676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4677 |Z| reserved | 4678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4679 | TR unicast address | 4680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4681 | JOINED GROUP TABLE | 4682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4683 Figure 41 TR introduction message 4685 o Type : TR 4687 o Z-BIT: if set indicates to the receiver that there has been a 4688 change in the joined-group-table. 4690 +---------------------------+ 4691 | JOINED-GROUP1 | 4692 +---------------------------+ 4693 | MULTICAST GROUP (G) | 4694 +---------------------------+ 4695 | SOURCE UNICAST ADDRESS | 4696 +---------------------------+ 4697 | . | 4698 +---------------------------+ 4699 | JOINED-GROUP N | 4700 +---------------------------+ 4701 | MULTICAST GROUP (G | 4702 +---------------------------+ 4703 | SOURCE UNICAST ADDRESS | 4704 +---------------------------+ 4705 . Source Unicast address Field holds the unicast address of either 4706 a TR or Client who is joined a tree for (G). it is set to all 0s 4707 if the TR itself is joined to the Tree for (G) 4709 Figure 42 Joined-Groups table used by both TR'(s) and Clients 4711 4.6.1.4. Domain-set and RPF check 4713 PIM-NG Domain-Set is similar to BGP AS-Path sequence in a way that 4714 each C-MAPPER MUST add its PIM-NG domain number to the domain-set of 4715 any multicast source before advertising it to a peer C-MAPPER .so at 4716 the end Domain-Set of a multicast source is a string of domains a 4717 multicast source has passed to reach its current domain or better to 4718 say to reach the C-MAPPER inside the current domain. From this 4719 perspective Domain-Set can be called Domain-Path sequence. 4721 Domain-set is what a PIM-NG C-MAPPER uses to RPF check a multicast 4722 source it receives from its peer in other domains. Unlike the RPF 4723 check method used in PIM-SM and MSDP which has some limitations like: 4725 o The network of multicast domains cannot have a transitory AS, 4726 due to the fact that for a Source Active message to pass the 4727 RPF check, the first AS in best path to the originator RP MUST 4728 BE equal to the MSDP peer. So if a customer's Autonomous 4729 System is connected to an ISP's Autonomous system, the RP 4730 inside the customer network must be MSDP peer with the RP 4731 inside the ISP network. 4733 o Filtering SA messages can be a hard task, because of the RPF 4734 check rule in a way that, you cannot have a transitory AS 4735 between to autonomous systems. such a case can be seen when 4736 administrators does not wish to update all of the SAs or some 4737 of the SAs created inside their PIM-SM domain to the neighbor 4738 Autonomous System , but they need to update them to a MSDP- 4739 PEER in an Autonomous System which is (i.e.)2 AS away. 4741 o . . . 4743 The RPF check method used in PIM-NG provides the ability of having 4744 transitory Autonomous Systems. Examples of such designs are: 4746 o Different PIM-NG domains are connected by an ISP's backbone and 4747 the ISP is only needed to provide UNICAST-REACHABILITY between 4748 different PIM-NG domains or different Autonomous Systems. 4750 o an enterprise does not wish to update all of its multicast 4751 sources to the neighbor Autonomous System or PIM-NG multicast 4752 domain , but it needs all of its multicast sources to be 4753 advertised to an AS which can be reached through this AS. 4754 consider the bellow illustration in which (i.e.) AS1 needs to 4755 advertise its multicast sources to AS3 and AS4 but doesn't 4756 want AS2 to become aware of those multicast sources or at 4757 least part of the multicast sources : 4759 AS1 (D1) ----AS2 (D2) ----AS3 (D3) ----AS4 (D4) 4761 MSDP specifications suggest that such work cannot be done and 4762 there will be a RPF check failure. But in PIM-NG such a work 4763 can be done. 4765 So if a source (S) is generating multicast traffic (G) in AS1 which 4766 is assigned a PIM-NG domain number of 1(D1) in the above 4767 illustration, the C-MAPPER inside D1 will advertise the (S,G) with 4768 the domain-set (1) to the peer C-MAPPER in D2 and likewise the C- 4769 MAPPER in D2 will advertise the (S,G) to its peer in D3 with domain- 4770 set of (1,2) and at the end the C-MAPPER inside D4 will receive the 4771 (S,G) with domain-set (1,2,3). 4773 The bellow rules apply to the DOMAIN-SET: 4775 o Each C-MAPPER or PPER MUST add its domain number to the domain- 4776 set of a multicast source before advertising it to its peers in 4777 other domains. 4779 o If inside a domain , more than one C-MAPPER is considered, each 4780 C-MAPPER MUST add its domain number to the domain-set of a 4781 multicast source before advertising it to its peers inside the 4782 domain, unless the C-MAPPER MESH-GROUP concept is in use. This 4783 process is more like prepending the domain number to the domain- 4784 set. 4786 o If A C-MAPPER(i.e. C-MAPPER-A) is a member of more than one 4787 Mesh-Group, or a member of a Mesh-Group and also is peer with a 4788 C-MAPPER which is a member of another Mesh-Group, which in this 4789 case C-MAPPER-A is acting as a connection or bridge between the 4790 2 Mesh-Groups, and it receives an update regarding a multicast 4791 source from a peer inside the same Mesh-Group, it MUST prepend 4792 its Domain number to the Domain-Set of the multicast source 4793 before advertising it to its peers in other Mesh-Groups. 4795 o A C-MAPPER or PPER MUST remove any prepended domain numbers 4796 from the domain-set of a source received from C-MAPPERs inside 4797 the domain , before advertising the multicast source to a peer 4798 C-MAPPER or PPER in other domains. 4800 o Since the PIM-NG-DOMAIN numbers are only significant from a 4801 connected PIM-NG-CORE-DOMAIN point of view, C-MAPPERs or PPERs 4802 in a CORE-DOMAIN MUST remove any PIM-NG-DOMAIN number, EXCEPT 4803 the domain number associated to the domain in which a multicast 4804 source resides, from the domain-set of a multicast source before 4805 advertising it to C-MAPPERs or PPERs in other PIM-NG-CORE- 4806 DOMAINs. 4808 o C-MAPPERs or PPERs in a CORE-DOMAIN MUST NOT remove any PIM-NG- 4809 DOMAIN number from the domain-set of a multicast source before 4810 advertising it C-MAPPERs or PPERs in other PIM-NG-DOMAINs which 4811 are connected to it and need to receive the updates regarding 4812 those multicast sources. 4814 PIM-NG RPF check method uses the bellow rules: 4816 o The (S, G) update received in the AMMT with the shorter domain 4817 sequence in Domain-Set passes the RPF check. 4819 (S,G,D1) 4820 (S,G)AS1(D1)---------AS2(D2)-----------AS4(D4) 4821 | / 4822 | / 4823 (S,G,D1)| /(S,G,D1,D3) 4824 | / 4825 | / 4826 AS3(D3) 4828 Figure 43 Inter-domain connectivity and RPF check 4830 As shown in Figure 43 a multicast source (s) in AS1 with PIM-NG 4831 domain number 1(D1) is generating multicast traffic destined to 4832 (G) and the C-MAPPER in the domain is advertising the (S, G) to 4833 its peers in D2 and D3. C-MAPPERs in D2 and D3 receive the 4834 update. C-MAPPER in D3 advertises the (S, G) to its peer in D2 4835 with the domain-set (D1, D3). C-MAPPER in D2 receives 2 updates 4836 for (S,G) with different domain-sets , one is (D1) and the 4837 other is (D1,D3) . So at this point the update received from D1 4838 passes the RPF check and the update received from R3 fails the 4839 RPF check. 4840 o If there is a tie in the domain-set of a multicast source 4841 received from peers in 2 different domains , the update 4842 received from the sender in the best path towards the 4843 originator according to the unicast routing information MUST 4844 pass the RPF check. In the above example if D3 is connected to 4845 D4 by making a C-MAPPER from each domain peer with the other 4846 one, then C-MAPPER in D4 will receive the update about (S, G) 4847 with equal domain sets of (D1, D2) and (D1, D3), which in this 4848 case the update received from the C-MAPPER in D2 which is in 4849 the best path towards the originator C-MAPPER in D1 passes the 4850 RPF check. 4851 o If inside a domain more than one C-MAPPER exists and the MESH- 4852 GROUP concept is not used, the above rules MUST be followed. 4854 (S,G,D1) 4855 (S,G)C-MAPPER1-D1--------------C-MAPPER2-D1 4856 \ / 4857 \ / 4858 (S,G,D1)\ /(S,G,D1,D1) 4859 \ / 4860 \ / 4861 C-MAPPER3-D1 4862 Figure 44 Intra-Domain connectivity and RPF check 4864 As illustrated in Figure 44, C-MAPPER1 is advertising an update 4865 about a newly originated source (S,G) with domain-set (D1) to 4866 its peers C-MAPPER2 and C-MAPPER3.C-MAPPERs 2 and 3 receive the 4867 update and start advertising the update to each other , so at 4868 this point and after the advertisement C-MAPPER2(i.e.) receives 4869 another update for (S,G) from C-MAPPER3 with domain-set (D1,D1) 4870 and since the domain sequence of the second received update 4871 from C-MAPPER3 is longer than the one received from C-MAPPER1 , 4872 it fails the RPF check. 4873 o The above rules are applicable in different situations 4874 regarding RPF check, and bring so much flexibility to work with 4875 multicast sources and the updates regarding those sources. 4876 o If a C-MAPPER inside a CORE-DOMAIN receives an update about a 4877 multicast source from a peer C-MAPPER in a CORE-DOMAIN and ALSO 4878 from a peer C-MAPPER in a PIM-NG-DOMAIN , the update received 4879 from the peer in CORE-DOMAIN MUST pass the RPF check without 4880 considering the DOMAIN-SET. 4882 4.6.2. Inter-domain connectivity concepts 4884 PIM-NG Inter-domain connectivity is mainly focused on the processes 4885 involved in exchanging the information regarding multicast sources 4886 being originated in different multicast domains, as for now like PIM- 4887 SM, PIM-NG uses the underlying unicast routing protocol information 4888 in order to send join/prune messages from a client in need of 4889 receiving a multicast traffic to the final destination which can be a 4890 server generating the multicast traffic. 4892 Although, PIM-NG specification processes and features are designed in 4893 a way that makes it possible to use a multicast routing protocol 4894 unique to PIM-NG in order to send join/prune messages from a receiver 4895 client to the originator of a multicast traffic, but since it is out 4896 of the scope of this document ,we are going to only explain the 4897 processes related to connecting 2 multicast domains and exchange the 4898 A-MULTICAST MAPPING TABLE'(s) between them ,which shall be enough to 4899 find a source and through using the underlying unicast routing 4900 protocols information reach the source. 4902 The related concepts are going to be explained in 2 different 4903 sections, which are Public Domain connectivity and Private Domain 4904 Connectivity. 4906 4.6.2.1. Public Domains 4908 A public domain is considered by PIM-NG specifications to be either a 4909 domain in which C-MAPPERs and sources use public IP addresses or a 4910 domain divided in to 2 domains or sub-domains in which the unicast 4911 address of C-MAPPERs and existing multicast sources are known to the 4912 population, and there is no need to use a PPER and domains are 4913 separated by PER'(s) which act as the domain boundary. 4915 Concepts are explained in 2 different sections called inter-domain 4916 concepts and intra-domain concepts. Inter-domain section is focused 4917 of connectivity of 2 different PIM-NG domains in terms of exchanging 4918 information regarding originated multicast sources in each domain and 4919 the process in which a CLIENT sends join/prune message to a source. 4920 And intra-domain section which is the following section is focused 4921 mainly on the communication between any existing TR with C-MAPPER and 4922 finally clients, which is actually the only feature of PIM-NG 4923 specifications that hasn't been described yet. 4925 4.6.2.1.1. Intra-domain concepts 4927 As said before, TR is responsible of sending join messages on behalf 4928 of CLIENTs inside the domain to a source inside the domain or other 4929 domains. 4931 If CORE-DOMAIN implementations are considered and CORE-DOMAINs do 4932 exist, and the domain-set of a multicast source indicates that the 4933 source of the multicast traffic can be reached by passing a PIM-NG- 4934 CORE-DOMAIN then the client creating the join/prune message MUST set 4935 the C-BIT of source unicast address and put the address of the CORE- 4936 DOMAIN-TR in the appropriate field and then send the message to the 4937 next hop. 4939 But first a PIM-NG-AWARE-ROUTER inside each domain must be chosen to 4940 act as the TR. and as mentioned before; each existing C-MAPPER can 4941 take the role of a TR to, which eliminates the need for a separate 4942 router to be used. 4944 Commands such as the commands bellow are initiated on the chosen 4945 router: 4947 <#IP PIM-NG TR> 4949 <#IP PIM-NG SOURCE INTERFACE LOOPBACK X> 4951 <#IP PIM-NG DOMAIN [X]> 4953 <#IP PIM-NG INTERFACE X,Y,Z> 4955 The above command lines will tell the router that it is the TR of 4956 PIM-NG domain X ,and it should use its interface loopback defined in 4957 the command as the unicast address it is going to introduce itself 4958 with it to the C-MAPPER. 4960 Although it may seem useful to have backup TR in the domain, we 4961 advise the use of a new TR instead of backup TR for bringing both 4962 redundancy and high availability at the same time to the domain. So 4963 no back-up TR is considered .the only case which there might be a 4964 back up TR implementation is when a C-RP has the role of TR and a SC- 4965 RP is considered. 4967 In case C-RP'(s) is going to have the role of TR too, and the concept 4968 of ANYCAST-RP is in use in the domain, the following rules MUST be 4969 obeyed: 4971 o Since ANYCAST-RP concept causes the clients to contact the 4972 closest RP unicast address according to their unicast routing 4973 tables, if C-RP is going to act as a TR, then ALL-C-RPs in a 4974 multicast domain MUST be configured to act as a TR too. 4976 o The active C-MAPPER MUST become aware of the situation which 4977 can be done by a command line initiated on ALL-C-MAPPERs. So the 4978 active C-MAPPER introduces only one TR unicast address which 4979 will be the ANYCAST address used for C-RPs. 4981 o Each TR in this particular design MUST use 2 different 4982 addresses. One for the ANYCAST address and one for introducing 4983 itself to the closest C-MAPPER. The addresses MUST be the 4984 addresses used for C-RP processes which had been explained 4985 before. 4987 o C-MAPPERs then MUST introduce ALL the other TRs to each TR they 4988 find, inside the PDTT sent with the unicast-encapsulated 4989 introduction messages they send to each TR. This MUST be done so 4990 that TRs can send their JOIN-GROUP TABLE to each other. 4992 After the TR is configured it will do the following processes: 4994 1- It waits to hear the introduction message of the C-MAPPER sent to 4995 239.0.1.190 to learn its unicast address. 4997 2- As soon as TR receives the C-MAPPER introduction it will update 4998 its internal PDTT with the address of C-MAPPER and other 4999 information included in the table. 5001 3- TR starts to send unicast introduction messages to the unicast 5002 address of C-MAPPER, which includes its unicast address. 5004 4- TR will send these introductions as keep-alive messages every 5005 30sec to the C-MAPPER. 5007 5- If it's joined to any multicast group (G), and by joining we mean 5008 receiving traffic for that group, it MUST put an entry for that 5009 group in its JOINED-GROUP-TABLE for further use. 5011 6- If in the introduction received from the C-MAPPER it receives 5012 the address of other TRs, it MUST send its JOINED-GROUP-TABLE to 5013 other TRs by sending unicast TR introduction messages to the 5014 address of those TRs. This MUST be done so that if a new client in 5015 another side of the domain sends a join for the same group to 5016 another TR, the TR will only send a join for that group to the TR 5017 which is already receiving the traffic for the group (G). 5019 7- The introduction messages between different existing TRs are only 5020 sent at the time, there is a change in the JOINED-GROUP-TABLE by 5021 setting the Z-BIT. This is due to the fact that TR'(s) communicate 5022 with C-MAPPER and this communication and periodical introductions 5023 acts as a keep-alive so there will be no need for the TRs to send 5024 periodical introductions as Keep-Alive to each other. 5026 After the C-MAPPER receives an introduction from the TR it will: 5028 1- Update its PIM domain topology table, and send an introduction 5029 message to ALL-PIM-NG-CLIENTS for further use. 5031 2- C-MAPPER maintains connectivity with the TR by sending unicast 5032 acknowledgement every 30 second back to the TR in response to TR 5033 introduction. 5035 3- If ANYCAST concept is needed to be implemented in a domain with 5036 more than one TR , then the C-MAPPER MUST know the address used as 5037 the ANYCAST address and only send that address to ALL-PIM-NG- 5038 CLIENTs. 5040 4.6.2.1.2. Inter-domain concepts 5042 In a Public PIM-NG Multicast domain a C-MAPPER can directly become 5043 peer with a C-MAPPER in another domain. And ALL Multicast Sources use 5044 public IP addresses. The processes regarding to peering the C-MAPPERs 5045 are much like the processes related to peering C-MAPPERs inside the 5046 same domain. The only difference between the concepts is: 5048 o A C-MAPPER MUST NOT send a multicast C-MAPPER introduction 5049 message to find its peer in another domain. Instead a C- 5050 MAPPER'(s) MUST send a unicast-encapsulated C-MAPPER 5051 introduction message to the unicast address of its peer in 5052 another domain. 5054 Figure 45 which illustrates a multicast network with 2 public PIM-NG 5055 multicast domains will be used for further explainations. 5057 [Figure is presented in PDF version] 5059 Figure 45 network with 2 multicast domains 5061 For the sake of simplicity in explaining the processes lets accept 5062 the fact that , there is unicast reachability between the 2 domains 5063 by using either a dynamic routing protocol capable of carrying 5064 multicast traffic like MBGP or a tunnel between the 2 domains. 5066 The processes to connect the 2 multicast domains are as follows: 5068 o In Each domain a C-MAPPER which uses a publically routable 5069 unicast address MUST be chosen, so makes it possible to directly 5070 make the C-MAPPERs peers. 5072 o C-MAPPER-WEST (WEST from now one) becomes peer with C-MAPPER- 5073 EAST (EAST from now one) using the unicast address of EAST to 5074 send the introduction message. the same is done on east: 5076 <#IP PIM-NG PEER MAPPER DOMAIN 2 ADDRESS EAST> 5078 And on east: 5080 <#IP PIM-NG PEER MAPPER DOMAIN 1 ADDRESS WEST> 5082 o WEST starts sending unicast-encapsulated introduction messages 5083 to EAST every 30 seconds until it receives the unicast- 5084 encapsulated introduction message of EAST. 5086 o After receiving the first introduction message, both C- 5087 MAPPER'(s) MUST send their introduction messages periodically 5088 every 60 seconds to maintain connectivity with each other as 5089 keep-alive messages. 5091 o If any SC-MAPPER is considered in a domain, its address MUST be 5092 introduced to the peer in the introduction message. 5094 o If WEST needs to inform its peer which is EAST about a change 5095 in the contents of AMMT, it MUST set the ZTCN-BIT in the 5096 introduction message and send the AMMT. 5098 o WEST MUST add its domain number to the domain-set of any newly 5099 originated multicast sources before sending an update about it 5100 to EAST. The same MUST be done by EAST. 5102 o Each C-MAPPER will then send the received update from the peer 5103 to the C-RPs residing in the domain 5105 Now bellow the processes related to communication between clients and 5106 sources are explained: 5108 o A host (H1) in domain1 (D1) wants to receive the multicast 5109 traffic destined for 228.9.9.9(i.e.) which is being generated in 5110 domain2 (D2). 5112 o H1 shows its desire to receive the traffic through IGMP 5113 messages it sends to the upstream router. 5115 o Client 2 becomes aware that a host inside the network behind it 5116 needs to receive the traffic destined for 228.9.9.9. 5118 o Client2 checks its PDTT to find the closest C-RP, and chooses 5119 C-RP-EAST(i.e.).since the RP and existing TR are not the same , 5120 H1 MUST send a unicast-encapsulated request for source message 5121 to C-RP. 5123 o Client2 sends a unicast-encapsulated PIM-NG request message to 5124 the C-RP. And receives a unicast acknowledge from the C-RP 5125 containing the unicast address of the source generating the 5126 multicast traffic in the format of (10.2.2.10, 228.9.9.9). 5128 o Client2 creates a join/prune message for (10.2.2.10,228.9.9.9) 5129 and since a TR exists in the domain and the domain-set of the 5130 source received from the C-RP doesn't contain any CORE-DOMAIN in 5131 the path , H1 sets the R-BIT of source unicast address and puts 5132 the address of the TR(10.1.1.20) in the appropriate field which 5133 shows that the join/prune message MUST first be sent towards the 5134 TR and sends the join/prune message towards the next hop or PIM- 5135 NG neighbor and joins the (S,G,RPT) rooted at TR which is 5136 considered to be the best path to reach the source. 5138 o TR receives the join/prune message and clears the R-BIT and its 5139 unicast address from the TR unicast address field, and forwards 5140 the message towards the next hop in the best path towards the 5141 source. 5143 o PER-EAST in domain2 (D2) receives a join/prune message on its 5144 external interface for multicast group 228.9.9.9 and must 5145 forward it to the next hop in the best path towards the source 5146 which is 10.2.2.10. 5148 o Since a TR exists in the domain PER-EAST MUST set the R-BIT 5149 again and put the address of TR(10.2.2.20) in the appropriate 5150 field and forward the join/prune message towards the source and 5151 actually join the (S,G,RPT) rooted at TR. 5153 o The join/prune message reaches the TR in D2, and TR again 5154 clears both the R-BIT and the TR unicast address field and 5155 forwards the message to the next hope. 5157 o Finally join/prune message for multicast destination 228.9.9.9 5158 arrives at 10.2.2.10 and source becomes aware that a client 5159 somewhere is in need of receiving the traffic and it MUST join 5160 the Shortest path tree which is actually the current (S,G,RPT) 5161 rooted at the TRs in each domain. So at the end 10.2.2.10 starts 5162 forwarding the traffic. 5164 Now a new host in D1 which is going to be H2 needs to receive the 5165 same traffic: 5167 o H2 shows its interest through IGMP to the upstream router which 5168 is client3. 5170 o Client3 goes through the same process as client2 to find the 5171 source unicast address of (G) and receives it from closest C- 5172 RP. 5174 o Client3 sends the join/prune message towards the TR. 5176 o TR receives a join/prune message for (S,G) which it already 5177 joined the shortest path tree for it , so without forwarding 5178 the join/prune message any further ,TR starts to forward the 5179 traffic for (10.2.2.10,228.9.9.9) down the new SPT towards 5180 client3. 5182 4.6.2.2. Private domains 5184 A private domain is considered by PIM-NG specifications to be a 5185 multicast domain in which all multicast sources or at least some of 5186 the multicast sources use private IP addresses. 5188 In such a domain: 5190 o If the C-MAPPERs inside the domain use private IP addresses, 5191 then one or more PPER'(s) MUST act as the C-MAPPER to become 5192 peer with C-MAPPERs in other domains on behalf of the C- 5193 MAPPERs inside the domain. And also a mechanism MUST be used 5194 so that PPER'(s) use a united public IP address as the 5195 originator of the multicast sources originated inside the 5196 domain and also as the source unicast address of the sources 5197 using private IP addresses. 5199 o If C-MAPPER'(s) inside the domain use public IP addresses, then 5200 there is no need for PPER'(s) to have the role of C-MAPPER 5201 too. Although, there might be some multicast designs in which 5202 it is needed for the PPER'(s) to act as C-MAPPER too. In such 5203 domains with a C-MAPPER using public IP address, a mechanism 5204 MUST be used so that the PPER'(s) become aware of the unicast 5205 address that is used by C-MAPPER'(s) as the source unicast 5206 address of the multicast sources using private IP addresses. 5208 In Figure 36 a network, including 2 private PIM-NG multicast domains 5209 is illustrated as an example. In this example that is going to be 5210 used to explain the processes involved, Domain1 (D1 for simplicity) 5211 is a PIM-NG domain in which ALL multicast sources and the C-MAPPER 5212 use private IP addresses and Domain2 (D2 for simplicity) is a PIM-NG 5213 domain in which the C-MAPPER uses public IP address and is 5214 responsible to directly become peer with a C-MAPPER in D1 and a group 5215 of multicast sources use Public IP Addresses and a group use Private 5216 IP Addresses. 5218 In D1 PPER-WEST with the unicast address 192.168.1.10 is going to act 5219 as the C-MAPPER and will become peer with C-MAPPER-EAST (EAST for 5220 simplicity) with the unicast address 192.168.2.10. And in D2 EAST 5221 will become peer with PPER-WEST. 5223 [Figure is presented in PDF version] 5225 Figure 46 Multicast network with private PIM-NG domains 5227 Different processes regarding the advertisement of multicast sources 5228 being generated in each domain to the other domain, and how the 5229 join/prune message is going to reach its final destination, are going 5230 to be explained in the following sections. 5232 4.6.2.2.1. Intra-Domain processes 5234 Since most of the processes and concepts regarding the connection 5235 between C-MAPPERs, clients, C-RP and TR in a PIM-NG domain have been 5236 explained up to this point ,processes referred to as Intra-domain 5237 processes will be related to the unexplained parts which are 5238 processes a C-MAPPER and the PPER'(s) are involved in within the 5239 Domain which in our example are D1 and D2 .Before starting to explain 5240 the processes a C-MAPPER and a PER or PPER are involved in ,we are 5241 going to take a look at an example of the steps related to make the 5242 PER ready and after that an example of how to make a PPER ready : 5244 Bellow the processes related to preparing a PER is explained: 5246 o A PIM-NG-AWARE router is chosen to act as the PER. 5248 o a set of commands are initiated on the router: 5250 <#IP PIM-NG EDGE> 5252 <#IP PIM-NG DOMAIN [X]> 5254 <#IP PIM-NG EDGE SOURCE INTERFACE [TYPE] [NUMBER]> 5256 <# IP PIM-NG INTERFACE [type] [number] INTERNAL> 5258 <#IP PIM-NG INTERFACE [TYPE] [NUMBER] EXTERNAL> 5260 Or in case the PER is connected directly to 2 domains 5262 <#IP PIM-NG DOMAIN [X] INTERFACE [TYPE] [NUMBER]> 5264 <#IP PIM-NG DOMAIN[Y] INTERFACE [TYPE] [NUMBER]> 5266 Or incase a PER is acting as a BPR: 5268 <#IP PIM-NG DOMAIN [X] INTERFACE [TYPE] [NUMBER]> 5270 <#IP PIM-SM INTERFACE [TYPE] [NUMBER]> 5272 o The above set of commands tells the router that it is a PER 5273 inside domain-X .and it MUST bring the interfaces mentioned in 5274 the command set in to the game of PIM-NG. 5276 o Interfaces marked as internal are going to be the ones 5277 connected to the internal domain and the one marked with 5278 external are going to be the ones connected to the outside 5279 networks. 5281 o In case PER is placed right between 2 domains or sub-domains it 5282 MUST have one or more interface inside one domain and one or 5283 more interfaces inside the other domain. 5285 o If a PER is placed between a PIM-NG domain and PIM-SM domain, 5286 It MUST have one or more interfaces inside PIM-NG domain and one 5287 or more interfaces in the PIM-SM domain. Such design may be seen 5288 in enterprise networks migrating from PIM-SM t PIM-NG over a 5289 period of time or in network designs where a PIM-SM domain is 5290 going to be connected to a network of PIM-NG domains or 2 or 5291 more PIM-NG domains are suppose to be connected through either 5292 an ISP's backbone which is still using PIM-SM or a transitory AS 5293 using PIM-SM and the PIM-SM domain'(s)are to be used to forward 5294 the join/prune messages. Such a PER is called a BPR, and the PER 5295 MUST introduce itself to the closest C-MAPPER with the B-BIT in 5296 the introduction message being set. BPR concepts will be 5297 discussed in the appropriate section. 5299 Bellow the processes related to preparing a PPER are explained: 5301 o A PIM-NG-AWARE router at the edge of the domain is chosen to 5302 play the role of PPER. PPER-WEST and PPER-EAST in Figure 46. 5304 o The router MUST be configured and become aware of its role 5305 inside the domain and in case it is going to act as the C- 5306 MAPPER to become peer with other PPERs or C-MAPPERs in other 5307 domains. As before we are going to go through the steps by 5308 initiating some commands on the router to make the process of 5309 explanation easier: 5311 <#IP PIM-NG EDGE-PRIVATE> 5313 <# PIM-NG DOMAIN [X]> 5315 <# PIM-NG INTERFACE [TYPE] [NUMBER] INTERNAL> 5317 <# PIM-NG INTERFACE [TYPE] [NUMBER] EXTERNAL> 5319 <# PIM-NG EDGE SOURCE INTERFACE [TYPE] [NUMBER]> 5321 The above commands tells the router that it is PPER in a PIM- 5322 NG domain[X](D1/D2) .also the above commands dictates to the 5323 router that it has some internal interfaces which are 5324 connected to the inside network and some external interfaces 5325 which are connected to the outside world . 5327 One other thing that the router must become aware of is the 5328 address it must use when introducing itself as the PPER to the 5329 C-MAPPERs inside the domain which in our example is going to 5330 be 10.1.1.50 for PPER-WEST and 10.2.2.50 for PPER-EAST. This 5331 address MUST be an address known to the domain in which the 5332 PPER resides. And it is advised to use a loopback interface as 5333 the source. 5335 o If the PPER is supposed to act as a C-MAPPER too (PPER-WEST in 5336 Figure 46), it MUST become aware of the new role and also MUST 5337 know the address of its peers. one other thing that MUST be 5338 configured is the address that must be used as the C-MAPPER 5339 address which MUST be a public IP address : 5341 <#IP PIM-NG MAPPER> 5343 <# PIM-NG MAPPER SOURCE {INTERFACE [TYPE] [NUMBER]}|ADDR> 5345 <# PIM-NG PEER MAPPER DOMAIN[Y] PEER-ADDRESS [A.B.C.D]> 5347 Or if the peer PPER is a connected PIM-NG-AWARE router 5349 <# PIM-NG PEER MAPPER DOMAIN[Y] INTERFACE [TYPE] [NUMBER]> 5351 o The address that is going to be used in the process of finding 5352 and communicating with a peer PPER or C-MAPPER, will be used as 5353 the Originator Unicast Address and source unicast address of the 5354 multicast sources that are originated inside the domain the PPER 5355 resides and use a private IP address. In Figure 44 the address 5356 used for PPER-WEST is 192.168.1.10 in D1 and the address used 5357 for the C-MAPPER-EAST in D2 is 192.168.2.10. 5359 o If the domain is connected to other domains by more than one 5360 PPER a mechanism MUST be used so that if PPERs has the role of 5361 C-MAPPER they all use one united public IP address as the 5362 Originator and source unicast address of the sources that are 5363 originated inside the domain and use private addresses. This is 5364 due to the fact that we don't want to end up advertising our 5365 sources with different source unicast addresses or originator 5366 addresses ,so PIM-NG specification suggests to configure on all 5367 PPERs an IP address from the public IP address range that is 5368 assigned to the AS or network. This can be done by a command 5369 like: 5371 <#PIM-NG ORIGINATOR-ADDRESS [A.B.C.D]> 5373 o if a C-MAPPER inside the domain with public IP address is used 5374 to become peer with C-MAPPERs or PPERs in other domains and the 5375 PPERs doesn't have the role of C-MAPPER they MUST become aware 5376 of the IP address that the C-MAPPER is using as the originator 5377 and source unicast address of the multicast sources that are 5378 generated inside the domain and use private IP addresses. This 5379 MUST be done due to the fact that a PPER may receive a 5380 join/prune message for a multicast source inside the domain 5381 which its unicast address is the address of the C-MAPPER and 5382 will be routed towards the C-MAPPER and that MUST NOT be done. 5383 So we suggest dictating to PPERs that if they receive a 5384 join/prune message on an external interface with the address of 5385 the C-MAPPER as the source unicast address, it IS NOT meant to 5386 be forwarded towards the C-MAPPER and the address MUST be 5387 changed with the real address of the multicast source. this can 5388 be done by a command like the one mentioned above or: 5390 <#IP PIM-NG SOURCE-ADDRESS [A.B.C.D]> 5392 In Figure 46 this address is going to be 192.168.2.10 which is 5393 the address of C-MAPPER-EAST and MUST be set on PPER-EAST. 5395 Processes related to PER will be discussed later when a PIM-NG domain 5396 needs to be connected to a PIM-SM domain. So in this section only 5397 PPER related processes are going to be explained. 5399 o As soon as PPER is configured and becomes aware of its role in 5400 the domain, it MUST communicate with the closest C-MAPPER 5401 according to the information received in the C-MAPPER 5402 introduction message and incase there are more than one C-MAPPER 5403 in domain based on the information it finds inside the PDTT, by 5404 sending an EDGE introduction message. PPER MUST set the P-BIT in 5405 EDGE introduction message which indicates to the C-MAPPER that 5406 it is sent from a PPER. PPER MUST send its unicast address 5407 inside the message so that C-MAPPER'(s) can use it to 5408 communicate with the PPER. So both PPERs in figure 44 start 5409 introducing themselves to the C-MAPPERs inside the domain. 5411 o Each PPER MUST send the introduction messages every 30 seconds 5412 to the C-MAPPER which acts as the keep-alive message. 5414 o Both C-MAPPERs in D1 and D2 MUST start sending A-MMT'(s) to the 5415 PPERs of their domain. The received information will be used by 5416 PPERs differently, due to the fact that PPER-WEST is also a C- 5417 MAPPER and PPER-EAST is only PPER. 5419 o Both PPERs MUST save the information regarding multicast 5420 sources that are originated inside their domain in IMST for 5421 further use. 5423 o PPER-WEST which has the role of a C-MAPPER too MUST send any 5424 received information regarding the multicast sources being 5425 generated in D1 which it receives from C-MAPPER-WEST to C- 5426 MAPPER-EAST by setting the Z-BIT in the introduction message and 5427 sending the updates inside the A-MMT. If only some of multicast 5428 sources MUST be advertised, it can be done through filtering 5429 process. 5431 o Since ALL multicast sources inside D1 are using private IP 5432 addresses, those multicast sources that are needed to be 5433 advertised to D2 MUST be chosen through an ACL, so that at the 5434 time of updating to C-MAPPER-EAST, PPER-WEST changes the 5435 originator address and source unicast address of those sources 5436 with its own public unicast address which is 192.168.1.10 in 5437 Figure 46. 5439 This can be done by choosing the multicast source addresses 5440 needed to be advertised in an ACL and initiating a command line 5441 (i.e.) on PPER-WEST: 5443 <#IP PIM-NG ACL X ORIGINATOR-ADDRESS [SELF| (A.B.C.D)]> 5445 Which dictates to the PPER that it MUST change the originator 5446 address and source unicast address of multicast sources chosen 5447 by the ACL X(i.e.) with its own public IP address or incase 5448 there are more than one PPER with the address indicated by the 5449 command. 5451 o Since C-MAPPER-WEST is not peer with any C-MAPPER in other 5452 domains it MUST maintain connectivity with PPER'(s) of its 5453 domain in order to receive information regarding multicast 5454 sources in other domains and advertise multicast sources in its 5455 domain to other domains. 5457 o In D2, C-MAPPER-EAST is directly involved in the process of 5458 becoming peer with a C-MAPPER in another domain which is PPER- 5459 EAST, so it MUST only send the information regarding multicast 5460 sources being originated inside its domain to PPER-EAST, UNLESS 5461 it becomes aware that PPER-EAST is also BPR and connected to a 5462 PIM-SM domain, which in this case it MUST send the full A- 5463 MULTICAST MAPPING TABLE which may include multicast sources 5464 being originated in other domains. 5466 o Since C-MAPPER-EAST is going to advertise multicast sources 5467 originated inside the domain (D2) to its peer in D1, it MUST 5468 change the source unicast address of multicast sources 5469 originated inside D2 with private IP addresses, with its own 5470 public IP address which is 192.168.2.10 in Figure 44. It MUST be 5471 done based on an ACL or route-map like what had been done on 5472 PPER-WEST , since there are multicast sources in D2 with public 5473 source unicast address that their address must not be changed. 5475 o Since PPER-EAST is only acting as PPER it MUST become aware 5476 about the address the C-MAPPER is using as source unicast 5477 address when advertising multicast sources with private IP 5478 addresses to other domains, so that when it receives a 5479 join/prune message on its external interface with that source 5480 unicast address, it can act properly. This can be done by 5481 initiating a command line(i.e.) on PPER-EAST like: 5483 <#IP PIM-NG SOURCE-ADDRESS [A.B.C.D]> 5485 Instead of A.B.C.D, the public IP address being used by C-MAPPER 5486 in such process MUST BE used, which in our example is 5487 192.168.2.10. 5489 4.6.2.2.2. Inter-domain concepts 5491 Inter-domain connectivity concepts are mostly focused on the process 5492 of exchanging information regarding multicast sources between the 2 5493 domains and the process through which a CLIENT will send join/prune 5494 message for a multicast group inside another domain which is using a 5495 private IP address inside the destination domain. 5497 First the processes regarding the exchange of A-MULTICAST MAPPING 5498 TABLES between the 2 domains of Figure 46 will be explained and then 5499 to explain the process of sending the join/prune message and 5500 receiving multicast traffic, an example in which hosts in D1 are in 5501 need to receive multicast traffic which is generated in D2 will be 5502 explained. 5504 1- Exchanging AMMT between the 2 domains : 5506 o Since PPER-WEST has the role of C-MAPPER, it will become peer 5507 with C-MAPPER-EAST on behalf of the C-MAPPER-WEST. And C- 5508 MAPPER-EAST will become peer with PPER-WEST which is seen by 5509 C-MAPPER-EAST as C-MAPPER-WEST or the C-MAPPER residing in 5510 D1. 5512 o Both PPER-WEST and C-MAPPER-EAST MUST use the public unicast 5513 address of the other one to send unicast-encapsulated 5514 introduction messages to both introduce themselves to each 5515 other and exchange the contents of their A-MULTICAST MAPPING 5516 TABLEs which holds the information regarding multicast 5517 sources being originated in either of the domains. So PPER- 5518 WEST MUST use the unicast address 192.168.2.10 (Figure 46) 5519 which is the address of C-MAPPER-EAST, as its peer address. 5520 And C-MAPPER-EAST MUST use unicast address 192.168.1.10 5521 (Figure 46) as its peer address. 5523 o As explained before both PPER-WEST and C-MAPPER-EAST MUST do 5524 some modifications on the information regarding multicast 5525 sources generated inside their domains with private IP 5526 addresses before advertising them to the other domain. So 5527 considering Figure 46 , C-MAPPER-EAST MUST change the source 5528 unicast address of the source generating traffic for 5529 228.9.9.9 which is a private IP address with its own public 5530 address which is 192.168.2.10 , and send it to PPER-WEST. 5532 o The rest of the process of becoming peer C-MAPPERs is as 5533 before, in terms of sending unicast-encapsulated introduction 5534 message to the peer and maintaining connectivity with the 5535 peer by sending introduction messages every 60 seconds as 5536 Keep-Alive messages. 5538 o If any changes occur inside (i.e.) D1 regarding the multicast 5539 sources, PPER-WEST MUST first set the ZTCN-BIT and inform the 5540 change by sending its AMMT to C-MAPPER-EAST. 5542 o Also both PPER-WEST and C-MAPPER-EAST MUST add their domain 5543 number to the domain-set of any multicast source they are 5544 going to advertise to the other one. 5546 2- Sending join/prune message for a multicast group inside a private 5547 PIM-NG domain: 5549 o Considering Figure 46 as our example network, H1 and H2 in 5550 D1 need to receive multicast traffic destined for 228.9.9.9 5551 and 228.6.6.6 which are being originated in D2. 5553 o So H1 starts the process by sending an IGMP message to the 5554 upstream router. And the request will reach CLIENT2. 5556 o So CLIENT2 starts the process of finding the unicast address 5557 of the source generating traffic destined for 228.9.9.9 by 5558 sending a unicast-encapsulated request to the closest C-RP. 5560 o As the source generating the traffic destined for 228.9.9.9 5561 is using Private IP address within D2, C-MAPPER-EAST had 5562 changed the unicast address of the source with its own 5563 public IP address at the time of advertising to PPER-WEST. 5564 So C-RP will answer to the CLIENT2's request by sending 5565 back the unicast address of the source in the format of (S, 5566 G, domain-set) or (192.168.2.10, 228.9.9.9, 2). 5568 o Client 2 receives the C-RP acknowledge and sends a (S, G, 5569 RPT) join/prune message rooted at the TR to the next hop in 5570 the best path towards the TR. 5572 o TR receives the join/prune message. Clears both the R-BIT 5573 and its address from TR unicast address field and forwards 5574 the message to the next hop in the best path toward the 5575 source of multicast group 228.9.9.9 in D2. 5577 o PPER-EAST receives a join/prune message on its external 5578 interface with the SOURCE UNICAST ADDRESS of 192.168.2.10, 5579 and since PPER-EAST is told that this is the source address 5580 that is used for sources generating multicast traffic 5581 inside its domain (D2) which are using private IP addresses 5582 and not the real address of the source, it knows that some 5583 modifications MUST be done to the message before forwarding 5584 it to the next hop in the best path towards the existing TR 5585 in D2. 5587 o PPER-EAST MUST check the contents of IMST to find the real 5588 unicast address of the source generating traffic destined 5589 to 228.9.9.9, which is 10.2.2.10. 5591 o After finding the real unicast address of the source, PPER- 5592 EAST modifies the join/prune message by changing the source 5593 unicast address inside the message which is 192.168.2.10 5594 with the real address which is 10.2.2.10. 5596 o Since a TR exists inside the domain PPER-EAST MUST set the 5597 R-BIT of source unicast address and put the address of TR 5598 in the appropriate field and forwards the message to the 5599 next hop in the best path towards the TR. 5601 o TR receives the join/prune message and joins the (S, G, RPT) 5602 tree and after clearing both R-BIT and TR unicast address, 5603 forwards the message to the next hop in the best path 5604 towards 10.2.2.10. 5606 o 10.2.2.10 receives the join/prune message and joins the (S, 5607 G, RPT) tree and starts forwarding the traffic destined for 5608 228.9.9.9 down the tree towards the receiver which is 5609 client2 in D1. 5611 o Now H2 behind client3 in D1 shows interest in receiving 5612 multicast traffic destined for 228.6.6.6. 5614 o Client3 goes through the same process to receive the unicast 5615 address of the source generating traffic for 228.6.6.6. And 5616 after receiving the unicast address which is 192.168.2.50 5617 in the format of (S, G, Domain-set) or (192.168.2.50, 5618 228.6.6.6, 2), goes through the same process as client2 to 5619 send the join/prune message. 5621 o The join/prune message reaches PPER-EAST. Since the source 5622 unicast address is not changed, PPER-EAST MUST forward the 5623 packet to the next hop in the best path towards the 5624 existing TR, without any modifications. 5626 o TR receives the join/prune message and after clearing both 5627 R-BIT and TR unicast address field sends the message to the 5628 next hop in the best path towards 192.168.2.50. 5630 o 192.168.2.50 receives the join/prune message, and joins the 5631 (S, G, RPT) tree and starts forwarding the multicast 5632 traffic destined for 228.6.6.6 down the (S, G, RPT) tree 5633 which is considered to be the SPT towards the receiver in 5634 D1 which is client3. 5636 The above processes are involved in connecting 2 PIM-NG domains in 5637 order to both advertise multicast sources from one private domain to 5638 another and sending join/prune messages from one private domain to 5639 another domain. The related processes were explained through an 5640 example to both simplify the explanation process and understanding 5641 the need for PPER existence in PIM-NG specifications. 5643 In the next sections the concepts regarding PIM-NG-CORE-DOMAIN 5644 through an example will be explained, and after that 2 new concepts 5645 called PIM-NG SUB-DOMAIN and PIM-NG STUB-DOMAIN will be explained and 5646 defined. 5648 4.6.3. Core-Domain implementation 5650 Up to this point of PIM-NG specifications process explanation, almost 5651 all of the related concepts have been explained. Bellow we are going 5652 to list them to review what has been explained: 5654 o Interaction between a source and C-RP and how a source 5655 registers. 5657 o Interaction between a Client and a C-RP to find a source for a 5658 multicast group (G). 5660 o Interaction between a Client and a source. 5662 o The processes by which the PIM-NG population find the C-RP'(s) 5663 in a multicast domain. And the interaction between C-RP and C- 5664 MAPPER. 5666 o Interaction between TR and C-MAPPER. 5668 o C-MAPPER and C-RP interaction to exchange the information 5669 regarding registered multicast sources in a domain. 5671 o Interaction between C-MAPPERs inside the same domain and 5672 different PIM-NG domains, regarding the exchange of information 5673 related to existing multicast source in each domain. 5675 o Processes involved in connecting multiple PIM-NG multicast 5676 domains. 5678 o . . . 5680 One thing that has remained unexplained is related to a multicast 5681 network design in which PIM-NG-CORE-Domain with TR is considered. 5683 As explained earlier: 5685 o ONLY when a PIM-NG-DOMAIN is connected to the outside network 5686 through a PIM-NG-CORE-DOMAIN 5688 o And ONLY when it is receiving the information regarding 5689 existing multicast sources in other domains through the Core- 5690 Domain, and Core-Domain is consisted of TR'(s). 5692 a client MUST send, its join/prune message for a multicast source 5693 that can be reached through the Core-Domain cloud, first towards the 5694 TR inside to Core-Domain to join the (S,G,RPT) rooted at both any 5695 existing TR inside client's domain and then the TR inside the Core- 5696 Domain. 5698 The above mechanism will eliminate future join/prune messages for the 5699 same multicast source which might be sent from Clients in other 5700 domains. 5702 So with the above being said, a series of processes will be involved 5703 which are as follows: 5705 o A C-MAPPER'(s) inside a Core-Domain MUST introduce at least one 5706 TR to its peer C-MAPPER in connected PIM-NG-DOMAINs. 5708 o If a CORE-DOMAIN is consisted of more than one TR,PIM-NG 5709 specifications suggests the use of ANYCAST concept, so that the 5710 C-MAPPER'(s) inside the CORE-DOMAIN will only send one unified 5711 TR unicast address to peers in connected PIM-NG-DOMAINs, which 5712 reduces the amount of data being sent in C-MAPPER introduction 5713 message. 5715 o PIM-NG specifications suggests that the unicast address of the 5716 desired TR'(s) to be introduced to peers in PIM-NG-DOMAINs be 5717 dictated to C-MAPPER'(s). This process is actually a MUST as 5718 there might be TRs inside the CORE-DOMAIN cloud that are using 5719 private addresses or must not be introduced to connected PIM-NG- 5720 DOMAINs. 5722 o C-MAPPER'(s) inside the CORE-DOMAIN MUST introduce existing 5723 TR'(s) to peers in PIM-NG-DOMAINs, by sending the unicast 5724 address of the TR'(s) inside the CORE TOPOLOGY TABLE (CTT), 5725 which only contains the information regarding existing TR'(s) in 5726 the CORE-DOMAIN. 5728 o If a PIM-NG-DOMAIN is connected to a PIM-NG-CORE-DOMAIN through 5729 another PIM-NG-DOMAIN, the CTT MUST reach that domain too. For 5730 instance, if D1 is connected to D2 and D2 is connected to CORE- 5731 DOMAIN D10001, then C-MAPPER inside D2 MUST pass the received 5732 CTT to peer C-MAPPER in D1. This process is a MUST if D1 is 5733 receiving information regarding multicast sources in other 5734 domains through D2 and needs to reach outside sources. 5736 o A client in a PIM-NG-DOMAIN in need to receive a multicast 5737 traffic , that the associated DOMAIN-SET shows it can be reached 5738 through a CORE-DOMAIN , MUST use the information regarding the 5739 existing TR'(s) in CORE-DOMAIN at the time of creating 5740 join/prune message . This MUST be done by setting the C-BIT of 5741 source unicast address and putting the address of the CORE- 5742 DOMAIN-TR in the appropriate field, so that it will reach the TR 5743 inside the CORE-DOMAIN. The logic behind this process will be 5744 explained through an example multicast network. 5746 o After the join/prune message reaches the desired CORE-DOMAIN- 5747 TR, the TR'(s) MUST clear both the C-BIT and information inside 5748 the CORE DOMAIN Tree Root ADDRESS field and then forward the 5749 message to the next hop in the best path towards the source. 5751 Bellow the above processes and the logic behind the above behavior of 5752 PIM-NG specifications at the presence of CORE-DOMAIN-TR will be 5753 explained through an example. 5755 [Figure is presented in PDF version] 5757 Figure 47 core domain implementation 5759 In the multicast network design illustrated Figure 47 as an example 5760 we have 2 CORE-DOMAINs with domain numbers 10001 and 10002.D10001 is 5761 connected to D1, D2 and D3 and also connected to D10002, while D10002 5762 is connected to D1. 5764 A multicast source starts generating multicast traffic destined for 5765 (G) in D1 behind 10002 and the information regarding the source is 5766 passed from C-MAPPER in D1 to C-MAPPER in D10002 as (S, G) with 5767 domain-set (D1). (S, G) is advertised to D10001 by C-MAPPER in D10002 5768 as (S, G) with domain-set (D1, 10002). And finally the information 5769 regarding the multicast source reaches D1, D2 and D3 behind D10001 as 5770 (S, G) with domain-set (D1, 10002, 10001). 5772 As it is illustrated in Figure 47, D3 behind D10001 has direct 5773 unicast connectivity to D1 behind D10002 through a tunnel which is 5774 capable of carrying multicast traffic. 5776 As an example, a client/host in D3 shows interest in receiving 5777 multicast traffic destined for (G) and after receiving the unicast 5778 address of the source generating that traffic, it is going to create 5779 a join/prune message and send it towards the next hop in the best 5780 path towards the source. It is assumed in this example that the best 5781 path is the tunnel interface between D3 and D1. So if the join/prune 5782 message is going to be directed through the tunnel, what happens if 5783 for instance another client in (i.e.) D1 behind D10001 comes up later 5784 and asks to receive the same traffic?. Let's assume that the 5785 join/prune from client in D3 is directed through the tunnel and both 5786 the source in D1 and client in D3 join the SPT for (S, G). Now a new 5787 client in D1 behind D10001 comes up and sends a join/prune message 5788 towards the source in D1 behind D10002, and finally both the source 5789 in D1 and client in D1 behind D10001 join SPT for (S, G). At this 5790 point we see that the source has joined 2 different SPTs to send the 5791 traffic to almost the same destination up to D10001, which is 5792 considered by PIM-NG specifications a waste of resources. 5794 Instead of the above processes , since the domain-set associated with 5795 (S,G) indicates that the update regarding (S,G) passed through CORE- 5796 DOMAIN10001, the client in D3 MUST send its join/prune message in a 5797 way ,so that it will reach the CORE-DOMAIN ,by setting the C-BIT of 5798 the source unicast address filed in join/prune message and putting 5799 the address of the CORE-DOMAIN-TR it had received from the C-MAPPER 5800 in D3 in the appropriate field and then send the message to the next 5801 hop in the best path first towards any existing TR inside D3 and then 5802 after the message reaches the D3-TR and the R-BIT is cleared 5803 towards the CORE-DOMAIN-TR. 5805 This way, as the message reaches the next hop and the next hope sees 5806 that the R-BIT is set in case of existing TR in D3, and also sees 5807 that the C-BIT is set which indicates that the message MUST be first 5808 forwarded towards the CORE-DOMAIN-TR. 5810 the message reaches the CORE-DOMAIN-TR and the TR clears the C-BIT 5811 and forwards the message to the next hop in the best path towards the 5812 source .and finally the client in D3, the TR in D3, the TR in CORE- 5813 DOMAIN and the source join the (S, G, RPT) rooted at existing TRs in 5814 each domain which is considered the Shortest Path Tree by PIM-NG 5815 specifications, and source starts sending traffic to (G) down the 5816 SPT. 5818 Now if the client in D1 behind D10001 comes up and sends the 5819 join/prune message to receive the same traffic, the join/prune 5820 message will only need to go up to the CORE-DOMAIN-TR, and since the 5821 CORE-DOMAIN-TR has already joined the SPT for (S, G) it will start 5822 forwarding traffic destined for (G) down the SPT towards the client 5823 in D1. 5825 Although the above process may seem unnecessary, it MUST be done to 5826 reduce the amount of join/prune messages that might be sent towards a 5827 source from different domains behind a CORE-DOMAIN and ONLY MUST BE 5828 done whenever the domain-set associated with a multicast source 5829 indicates that it can be reached through a CORE-DOMAIN. 5831 [Figure is presented in PDF version] 5833 Figure 48 join/prune message being sent towards the source 5835 4.6.4. Multiple multicast domains scenario 5837 Up to this point of explaining PIM-NG specifications almost all of 5838 the concepts regarding registering a new multicast source, connecting 5839 2 multicast domains, advertising the information regarding a new 5840 multicast source to another domain and many other concepts unique to 5841 PIM-NG have been explained. Now in this section we are going to check 5842 most of the concepts regarding a multicast network consisted of 5843 multiple PIM-NG domains through an example. In Figure 49 a multicast 5844 network consisted of multiple PIM-NG-CORE-DOMAINs and PIM-NG-DOMAINs 5845 is illustrated. 5847 [Figure is presented in PDF version] 5849 Figure 49 network with multiple multicast domains 5851 In the illustrated network, you will see 5 PIM-NG-CORE-DOMAINs, 2 of 5852 which connected to some PIM-NG-DOMAINs. we have a PIM-NG-CORE-DOMAIN 5853 which is actually a SERVICE PROVIDER Autonomous System, a transitive 5854 multicast domain which is unique to PIM-NG as the nature of MSDP and 5855 its RPF check method doesn't allow PIM-SM to have a transitive 5856 multicast domain or Autonomous System, an AS which can be considered 5857 an enterprise network that divided its multicast domain in to 5858 multiple PIM-NG-DOMAINs which are all connected to outside world 5859 through the CORE-DOMAIN, and 2 other CORE-DOMAINs that are needed to 5860 make the explanation of RPF check concept and transitory AS/multicast 5861 domain easier. 5863 In Figure 49, the Service Provider network is shown as AS-64500 and 5864 DOMAIN-10001(D10001 from now on) which is a CORE-DOMAIN number, and 5865 is connected to its customer A with PIM-NG-DOMAIN number 1 which is 5866 assigned by the Service Provider to make the customer able of 5867 receiving multicast updates from outside and also send multicast 5868 updates to the outside world. Customer A has divided its network to 2 5869 domains using a private domain number for the second domain. Also the 5870 Service Provider network has another customer connected to it, which 5871 is named Customer B, which is using the SP's network to only connect 5872 its multicast domains and doesn't wish to advertise any multicast 5873 source to the outside world or receive any, and to be more specific 5874 it has a closed and private multicast domain. This D10001 is 5875 connected to another CORE-DOMAIN which is D10002 with AS number 5876 64501. 5878 D10002 is then connected to AS-64502 with DOMAIN number D-10003 which 5879 is assumed to be a transitive AS or multicast domain. D-10003 is only 5880 providing unicast reach ability so that the join/prune messages or 5881 multicast traffic can reach from one domain to other domains. Also 5882 please be noted that this transitive domain can be a PIM-SM domain 5883 which is only providing the unicast reach ability between PIM-NG 5884 domains. It is connected to AS-64503 with Domain number D-10004 and 5885 AS-64504 with Domain number D-10005. D-10004 is only being used to 5886 review the RPF check method used in PIM-NG and D-10005 is considered 5887 to be an organization's Autonomous System which has divided its 5888 multicast domain to multiple domains to have a better control over 5889 its multicast network. 5891 With the above being explained , now it's time to overview the 5892 involved concepts through Figure 50, which shows the network in 5893 Figure 49 but with the multicast sources being advertised from one 5894 domain to other domains. 5896 [Figure is presented in PDF version] 5898 Figure 50 multicast network and multicast advertisements 5900 As illustrated in Figure 50: 5902 o Since customer-B's multicast domain behind D10001 is assumed to 5903 be a private and closed multicast domain, the multicast 5904 sources originated inside its D1 will only be advertised to 5905 D20 which is also customer-B's multicast domain, and will not 5906 be advertised to outside world or better to say to the C- 5907 MAPPER inside D10001. And customer-B is only using multicast 5908 network of D10001 as a mean to exchange multicast traffic 5909 between its multicast domains. 5911 o As it is illustrated in Figure 50, customer-A's multicast 5912 domain is divided in to 2 multicast domains both connected to 5913 D10001 and since customer-A has some sources that needed to be 5914 globally accessible, it has received PIM-NG-DOMAIN number 5915 1(D1) from D10001 (Service Provider). Customer-A uses a 5916 private domain number (D9901) for its second domain, and as it 5917 is illustrated the C-MAPPERs inside D1 and D9901 are directly 5918 connected as a mean to exchange information regarding 5919 multicast sources internally. And D1 is using a PPER to 5920 connect to a C-MAPPER in D10001 in order to exchange 5921 information regarding multicast sources globally/externally. 5923 o A multicast source inside D9901 is originating multicast 5924 traffic destined for (G), and the update about it is 5925 advertised to the peer C-MAPPER in D1 as (S2, G2, D9901). And 5926 since the domain number 9901 is a private domain number, the 5927 PPER in D1 will remove D9901 from the domain-set of (S2,G2) 5928 before advertising it to the C-MAPPER in D10001,and sends the 5929 update as (S2,G2,D1). 5931 o C-MAPPER in D10001 receives the update and advertises it to its 5932 peer in D10002 as (S2, G2, D1, 10001). The C-MAPPER in D10002 5933 is also peer with C-MAPPERs in D10003, D10004 and D10005. As 5934 illustrated in Figure 50, a multicast source (S3) comes up in 5935 D10002 and starts generating traffic destined for (G3). So the 5936 C-MAPPER in D10002 starts advertising information about this 5937 new source too its peers as (S3, G3, D10002). 5939 o D10003 is assumed to be a transitive domain only providing 5940 multicast reachability between D10002, 10004 and 10005. And as 5941 it is illustrated in Figure 50, C-MAPPER in D10002 is only 5942 advertising information about multicast sources that are 5943 generated inside its domain and not those generated in D10001. 5944 This being said, C-MAPPER in D10002 advertises the multicast 5945 source created in its domain as (S3, G3, 10002) to C-MAPPER in 5946 D10003. 5948 o D10004 and D10005 need to receive the multicast updates 5949 completely, so the C-MAPPER in D10002 peers with C-MAPPER'(s) 5950 or PPER'(s) in D10004 and D10005 and starts sending updates 5951 about multicast sources it knows as (S2,G2,D1,D10001,D10002) 5952 and (S3,G3,D10002) to them. 5954 o Up to this point, C-MAPPER in D10004 and PPER in D10005 as 5955 illustrated in Figure 50 have received the updates. Now the C- 5956 MAPPER in D10004 starts to advertise the received updates to 5957 its peer in D10005. So it advertises them as 5958 (S2,G2,D1,D10001,D10002,D10004) and (S3,G3,D10002,D10004) to 5959 D10005. 5961 o PPER in D10005 receives the updates from its peer in D10004 and 5962 since it has received an update from its peer in D10002, about 5963 the same multicast sources, it starts the RPF check mechanism. 5965 o PPER in D10005, first, compares the DOMAIN-SET of the 2 5966 received updates and the result of the comparison will be 5967 that, the updates received from D10004 will fail the RPF 5968 check. This is due to the fact that the domain set of the 5969 received updates from D10004 are longer than the ones received 5970 from D10002. 5972 o At the end the PPER in D10005 sends the updates to the closest 5973 C-MAPPER inside its domain and the C-MAPPER in D10005 5974 advertises those updates to its peers in D1 and D2. 5976 As explained above, PIM-NG specifications allow the existence of 5977 transitive multicast domain or Autonomous Systems, which due to the 5978 MSDP RPF check nature hasn't been totally implementable. 5980 And also because of the unique RPF check method used by PIM-NG, the 5981 control over filtering the updates about multicast sources is 5982 easier and more enhanced. Which is also mostly because of the RPF 5983 check method used by PIM-NG which allows the existence of 5984 transitory domains or an intermediary multicast domain which only 5985 needs to receive partial updates, like D10003 in Figure 48. 5987 In the following sections, the remaining concepts of PIM-NG 5988 regarding multiple multicast domain connectivity such as SUB-DOMIAN 5989 and PIM-SM-COMPATIBILITY, and controlling the updates received from 5990 a PIM-NG-DOMAIN to improve the security of the multicast network by 5991 STUB-DOMAIN concept will be explained. 5993 4.6.5. PIM-NG Sub-Domain 5995 PIM-NG Sub-Domain concept is introduced to cover 2 areas: 5997 o To control the propagation of multicast traffic inside one 5998 multicast domain, which from this perspective the Sub-Domain 5999 concept is more like dividing a multicast domain in to different 6000 areas. 6002 o To give the administrators a robust control over a multicast 6003 domain, by dividing it in to different sub-domains. And make 6004 modifications in one sub-domain in a way that no multicast 6005 source updates are accepted from that part of the domain 6006 through using the concept of Stub-Domain, which will be 6007 discussed later, or do FILTEING on the multicast sources that 6008 are usable in a Sub-Domain. 6010 Bellow specifications and rules apply to PIM-NG Sub-Domain: 6012 o A PIM-NG Domain can be divided to up to 254 Sub-domains. This 6013 number is derived from the maximum number of available C- 6014 MAPPERs inside a PIM-NG domain. As said before C-MAPPERs can 6015 have up to 255 different groups and the fact that each C- 6016 MAPPER is already a member of the main PIM-NG domain, gives us 6017 the equation 255-1=254. 6019 o The sub-domain numbers MUST be different from the main domain 6020 number, so that, the C-MAPPER introduction messages meant for 6021 the main domain won't be read by the components of each Sub- 6022 Domain. 6024 o If a PIM-NG domain is divided in to Sub-Domains, all the C-RPs, 6025 TR'(s) and clients resided is a Sub-Domain MUST only be 6026 configured with Sub-Domain number to use it as their domain 6027 number. 6029 o The only components of a PIM-NG domain which MUST be aware of 6030 both the main PIM-NG domain number and the Sub-Domain number 6031 they reside in are C-MAPPERs, PER'(s), PPER'(s) and TR'(s). 6033 o Since the main purpose of dividing a PIM-NG Domain to Sub- 6034 Domains is to have a better control over the propagation of 6035 the information regarding the existing multicast sources, in a 6036 way that either a Sub-Domain doesn't receive the information 6037 regarding specific multicast sources or in a Sub-Domain no 6038 sources are allowed to do exist and send register messages to 6039 C-RPs in the Sub-Domain, any mechanism used such as filtering 6040 or defining a Sub-Domain as an STUB-Domain, MUST BE applied 6041 within Sub-Domains and at the time the information regarding 6042 multicast sources are advertised within the Sub-Domain to 6043 existing C-RP'(s). 6045 o PIM-NG specification suggests the use of one or more PER'(s) as 6046 the boundary between each 2 Sub-Domain to limit the 6047 propagation of multicast introductions sent by C-MAPPER'(s) 6048 and C-RP'(s) in each Sub-Domain. 6050 o If in a PIM-NG multicast domain , only one C-MAPPER is 6051 considered, then the multicast domain can be divided to ONLY 2 6052 Sub-Domains and the C-MAPPER MUST act as the PER or boundary 6053 between the 2 Sub-Domains with one hand in each Sub-Domain.in 6054 this case the C-MAPPER MUST NOT forward the multicast 6055 introduction messages of one Sub-Domain to the other one. 6057 o If in PIM-NG SUB-DOMAINs, redundancy and high availability of 6058 the C-MAPPERs are needed to be considered, then each SUB- 6059 DOMAIN CAN use as many C-MAPPERs within the Sub-Domain to 6060 support the needs of multicasting in the Sub-Domain But ONLY 2 6061 C-MAPPERs, MUST BE and ARE allowed to be both a member of the 6062 main domain and the Sub-Domain.and the rest of the C-MAPPERs 6063 will only be a member of the Sub-Domain. So if it is not 6064 needed, PIM-NG specifications STRONGLY suggests using 2 C- 6065 MAPPERs in each Sub-Domain.so if redundancy must be considered 6066 the number of Sub-Domains will reduce to 127. 6068 o In the case of redundant C-MAPPERs in each Sub-Domain, the 6069 Mesh-Group concept described in section 4.5.2 MUST BE used 6070 inside each Sub-Domain so only the active C-MAPPER will be 6071 able to send introduction messages destined to 239.0.1.190. so 6072 first C-MAPPERs MUST send their multicast introductions 6073 destined to 239.0.1.188 using the Sub-Domain number, to find 6074 their peers if the dynamic methods are in use and elect the 6075 active C-MAPPER within the Sub-Domain and after that they MUST 6076 send multicast introductions using their main domain number to 6077 find their peers in the main domain if the dynamic methods are 6078 in use. 6080 o As explained in section 4.5.2. , a PIM-NG domain CAN use up to 6081 25 C-MAPPER Mesh-Groups. In this case each 10 C-MAPPER within 6082 either 10 or 5 Sub-Domains, CAN form a C-MAPPER Mesh-Group in 6083 the main domain. for instance, if a PIM-NG multicast domain 6084 with domain number D1, is divided in to 10 Sub-Domains(Sub- 6085 Domain 2-11), with each Sub-Domain including 2 C-MAPPERs for 6086 redundancy and high availability, C-MAPPERs inside Sub-Domains 6087 2-6 can form Mesh-Group1 in D1 and C-MAPPERs in Sub-Domains 7- 6088 11 can form Mesh-Group2 in D1. 6090 o When a C-MAPPER is a member of the main domain and also a Sub- 6091 Domain, The concept of Active and Standby C-MAPPER in a mesh 6092 group described in section 4.5.2.1. , MUST BE applied to each 6093 Sub-Domain and depending on the needs of the PIM-NG multicast 6094 domain the Active and Standby C-MAPPER concept CAN be applied 6095 in the main domain. So for instance, if D1 is divided into 2 6096 Sub-Domains (Sub-Domain 2-3) with 2 C-MAPPERs in each Sub- 6097 Domain being a member of both the PIM-NG domain and the Sub- 6098 Domain, C-MAPPERs in Sub-Domains2 will form Mesh-Group1 in 6099 Sub-Domain2 and C-MAPPERs in Sub-Domain3 will form Mesh-Group1 6100 in Sub-Domain3. And ALL 4 C-MAPPERs as C-MAPPERs of Domain1 6101 will either form MeSh-Group1 in Domain1 to begin the process 6102 of Active C-MAPPER election in Domain1 between the 4 of them 6103 or simply will become peer C-MAPPERs in Domain1 to exchange 6104 their A-Multicast Mapping Tables and other information needed. 6106 o The Mesh-Groups in the main domain (i.e. D1) are formed to 6107 elect the ACTIVE C-MAPPER ONLY under these circumstances: 6109 1. If a PIM-NG domain which is divided to Sub-Domains, is 6110 connected to outside world or other PIM-NG domains or a 6111 PIM-SM domain by using the PPER concept, and since 6112 PPER'(s) MUST communicate with the closest C-MAPPER in 6113 the PIM-NG domain to receive the full AMMT which is being 6114 exchanged between the C-MAPPERs in the main domain, ONLY 6115 IF the needs of multicast Domain DICTATES TO USE the 6116 dynamic method for the communication of PPER'(s) with C- 6117 MAPPER'(s) in the Domain, then the C-MAPPERs MUST form 6118 Mesh-Group'(s) in the PIM-NG Domain and the active C- 6119 MAPPER MUST ONLY introduce existing C-MAPPERs in the main 6120 domain in its introduction messages sent to 239.0.1.190. 6122 2. If a PIM-NG domain which is divided to Sub-Domains, is 6123 connected to a PIM-SM domain by using the PER concept, 6124 and since in such design PER'(s) MUST communicate with 6125 the closest C-MAPPER in the PIM-NG domain to receive the 6126 full AMMT which is being exchanged between the C-MAPPERs 6127 in the main domain, ONLY IF the needs of multicast Domain 6128 DICTATES TO USE the dynamic method for the communication 6129 of PER'(s) with C-MAPPER'(s) in the Domain, then the C- 6130 MAPPERs MUST form Mesh-Group'(s) in the PIM-NG Domain and 6131 the active C-MAPPER MUST ONLY introduce existing C- 6132 MAPPERs in the main domain in its introduction messages 6133 sent to 239.0.1.190. 6135 o If Mesh-Group'(s) are formed in the main domain so that through 6136 an election the ACTIVE C-MAPPER starts introducing in the main 6137 domain, then ONLY the PER'(s) acting as the boundary between 6138 Sub-Domains MUST be dictated to pass the introduction messages 6139 sent to 239.0.1.190 which are generated ONLY BY the ACTIVE C- 6140 MAPPER in the main domain and NOT Sub-Domains. 6142 o If a PIM-NG Domain which is divided to Sub-Domains is connected 6143 to other Domains using PPER concept or is connected to a PIM- 6144 SM domain, To reduce the bandwidth and network resources 6145 consumption IF the needs of multicasting in the Domain does 6146 not dictate to use the dynamic methods for the communication 6147 between PPER'(s) or PER'(s) and C-MAPPERs, PIM-NG 6148 specifications Strongly SUGGESTS to statically introduce C- 6149 MAPPER'(s) to each PPER or PER through command initiation on 6150 PPER'(s) and PER'(s). 6152 o If the C-MAPPERs are statically introduced to PER'(s) and 6153 PPER'(s), then a mechanism MUST be used so that the C-MAPPERs 6154 which are member of a Mesh-Group in the main domain, don't 6155 elect the Active C-MAPPER. This way the C-MAPPERs which are 6156 members of the Mesh-Group in the main domain will only 6157 exchange their AMMT'(s) and if needed the information 6158 regarding the existing TR'(s). and Since no Active C-MAPPER is 6159 elected the PER'(s) acting as boundary between the Sub-Domains 6160 MUST NOT be dictated to forward the C-MAPPER introductions 6161 sent to 239.0.1.190 which are generated by the ACTIVE in the 6162 main domain. So PIM-NG specification SUGGESTS doing above 6163 through command initiation as an option. 6165 o Also in case that the C-MAPPER'(s) are introduced to PER'(s) or 6166 PPER'(s) statically, PIM-NG specifications SUGGESTS that the 6167 C-MAPPERs in the main domain simply become peer and don't form 6168 Mesh-Groups, which eliminates the need to use the above 6169 mentioned mechanism. 6171 o With the above concepts, each C-MAPPER within each Mesh-Group 6172 in the main domain, will inform ALL the other members of the 6173 Mesh-Group as soon as any changes occurs within a Sub-Domain. 6175 o If in a PIM-NG Domain divided to Sub-Domains, the C-MAPPERs are 6176 to form Mesh-Group'(s) in the main domain through dynamic 6177 method explained in section 4.5.2. , the PER'(s) acting as the 6178 boundary between Sub-Domains MUST BE dictated to forward the 6179 C-MAPPER introduction messages destined to 239.0.1.188 and 6180 generated ONLY by C-MAPPERs in the main domain. so if Domain1 6181 is divided to Sub-Domains 2 and 3, then the PER'(s) between 6182 Sub-Domain2 and Sub-Domain3 MUST BE dictated to forward the C- 6183 MAPPER introduction messages destined to 239.0.1.188 with 6184 Domain-Value set to1 (Domain1). 6186 o To reduce the bandwidth and network resources consumption in 6187 the above case, in which C-MAPPERs are to form Mesh-Group'(s) 6188 in the main domain, PIM-NG Specifications Suggests to peer the 6189 C-MAPPERs using the unicast Address of each C-MAPPER and not 6190 the GROUP number of C-MAPPERs which will eventually make the 6191 C-MAPPERs to send multicast introductions to 239.0.1.188 to 6192 find their peers. This being said, the dynamic method is still 6193 the preferred method IF the network infrastructure and 6194 resources can support ALL the needs of PIM-NG multicast 6195 Domain. 6197 o If in the main domain, the C-MAPPER Mesh-Group concept is 6198 implemented with more than one Mesh-Group, then it is advised 6199 to ONLY peer 2 C-MAPPERs from each Mesh-Group with 2 C-MAPPERs 6200 from the other Mesh-Group'(s). The peering of C-MAPPERs inside 6201 different Mesh-Groups formed in the Main domain MUST BE done 6202 using the static method and there MUST be a boundary between 6203 the 2 Mesh-Groups. For instance, if D1 is divided in to 10 6204 Sub-Domains (Sub-Domains 2-11) and C-MAPPERs in Sub-Domains2-6 6205 are forming Mesh-Group1 and C-MAPPERs in Sub-Domains7-11 are 6206 forming Mesh-Group2, then 2 C-MAPPERs from Mesh-Group1 will 6207 become peer with 2 C-MAPPERs in Mesh-Group2 using the static 6208 method to bring redundancy to the entire domain. and it is 6209 STRONGLY advised by PIM-NG specifications to use a PER as the 6210 boundary between Sub-Domains 2-6 and Sun-Domains 7-11 so that 6211 no multicast introduction messages will be forwarded from the 6212 side including Sub-Domains 2-6 to the side including Sub- 6213 Domains 7-11. The above method of connecting different Mesh- 6214 Groups will become necessary in designs with more than 2 Sub- 6215 Domains and many C-MAPPERs in use to reduce the amount of 6216 introduction message traffic in the domain. 6218 o Each Sub-Domain MUST BE treated as a PIM-NG Domain, in which 6219 all the components of the domain including Clients, C-RP'(s), 6220 TR'(s) and C-MAPPER'(s) use the same domain or better to say 6221 Sub-Domain number with the C-MAPPER'(s) and TR'(s) as the only 6222 components being the member of the main domain and Sub-Domain. 6223 So clients, C-RPs and TR'(S) inside a Sub-Domain MUST only 6224 listen to C-MAPPER introduction messages with the same domain 6225 number. 6227 o Since each Sub-Domain MUST BE treated as a separate Domain, 6228 each Sub-Domain can have up to 255 C-RP and TRs if needed, and 6229 the all the PIM-NG specifications and rules that apply to 6230 exiting C-RP'(s) and TR'(s) in a single multicast domain, are 6231 applicable here. 6233 o C-MAPPERs in a Sub-Domain MUST become peer with other C-MAPPERs 6234 in other Sub-Domains using their main domain number, in order 6235 to advertise the information regarding multicast sources 6236 inside their Sub-Domain to other Sub-domains. So if (i.e.) if 6237 we have C-MAPPER-A and C-MAPPER-B inside D1, and C-MAPPER-A is 6238 a member of sub-Domain-2(SD2) and C-MAPPER-B is a member of 6239 SD-3 , then C-MAPPER-A MUST become peer with C-MAPPER-B which 6240 is inside D1 and not D3. 6242 o As explained in section 4.5.2. ,when there are more than one C- 6243 MAPPER in a PIM-NG domain , each STC-MAPPER MUST send the 6244 information regarding newly found C-RPs or TR'(s) to the 6245 active C-MAPPER in the domain ,so that the active C-MAPPER 6246 will be able to introduce the C-RPs or TRs to the PIM-NG 6247 population by sending introduction messages to 239.0.1.190. 6248 but PIM-NG specifications dictates that in multicast design 6249 including Sub-Domain implementation ,C-MAPPERs MUST NOT send 6250 the information regarding the existing C-RPs in their Sub- 6251 Domain to other C-MAPPERs from different Sub-Domain'(s). And 6252 this is due to the fact that each Sub-Domain MUST BE treated 6253 as a separate Domain. so such information MUST only be 6254 exchanged within the Sub-Domain. 6256 o If TR'(s) are considered in a PIM-NG domain which is divided 6257 into Sub-Domains, since the communication between the TR and a 6258 client is limited to the join/prune messages, then C-MAPPERs 6259 in different Sub-Domains MUST send the information regarding 6260 TR'(s) they find inside their Sub-Domain to their peer C- 6261 MAPPERs which are resided in other Sub-Domains so that : 6263 1. Clients in other Sub-Domains become aware of the 6264 existence of TR and use its unicast address to send the 6265 join/prune message towards the closest TR. 6267 2. TR'(s) will find each other to communicate regarding the 6268 exchange of JOINED-GROUP TABLE. 6270 o In case of existing TR'(s) in a PIM-NG domain divided to Sub- 6271 Domains, PIM-NG specifications STRONGLY suggests : 6273 1. To Use a separate router as the TR if applicable 6274 2. To Use the ANYCAST concept to introduce the existing TR'(s) 6275 to the clients. 6277 3. NOT TO use C-RP'(s) as the TR if possible, due to the fact 6278 that in this case because of the method used by PIM-NG to 6279 send a join/prune message when C-RP and TR are both the 6280 same, there might be some issues if the C-RPs in one Sub- 6281 Domain go offline and after this the clients in this Sub- 6282 Domain may chose to send their join/prune messages toward an 6283 TR/C-RP resided in another Sub-Domain which doesn't have the 6284 full A-MULTICAST MAPPING TABLE, because of multicast source 6285 filtering in that Sub-Domain. 6287 4. That if the design needs dictates to use C-RP'(s) as TR'(s) 6288 in each Sub-Domain, the TR ANYCAST address used in each Sub- 6289 Domain be different from other Sub-Domains, and C-MAPPERs be 6290 dictated through command initiation as an option NOT TO send 6291 the information regarding the TR'(s) in their Sub-Domain to 6292 other C-MAPPERs which are resided in other Sub-Domains. This 6293 way each single Sub-Domain will totally act as a separate 6294 Domain. 6296 o If more than one TR exists in a PIM-NG Domain which is divided 6297 to Sub-Domains, and the information regarding the TRs is being 6298 exchanged among C-MAPPER so that the clients become aware of 6299 the existence of TR'(s) and also TR'(s) can communicate with 6300 each other using the dynamic method, then TR'(s) MUST use 6301 their main domain number when sending introductions containing 6302 JOINED-GROUPS TABLE to each other and not the SUB-Domain 6303 number, as the only thing that 2 TR CAN share and HAVE in 6304 common is the main domain number. 6306 o TR'(s) MUST introduce themselves to the ACTIVE C-MAPPER in the 6307 Sub-Domain and not an ACTIVE C-MAPPER in the main domain. 6309 o Each C-MAPPER MUST send the information regarding new multicast 6310 sources being originated inside its Sub-Domain to their peer 6311 C-MAPPER'(s) by exchanging the contents of A-MULTICAST MAPPING 6312 TABLE. 6314 o C-MAPPER'(s) that are both a member of a Sub-Domain and the 6315 main domain, MUST remove the Sub-Domain number from the 6316 domain-set of multicast sources inside their Sub-Domain, 6317 before advertising them to their peer C-MAPPER(s)in other Sub- 6318 Domains or outside their multicast domain. After the deletion 6319 of Sub-Domain number, ALL the rules and specifications related 6320 to Domain-Set and RPF check will be applied. This is due to 6321 the fact that from other C-MAPPERs point of view, whether in 6322 the same PIM-NG domain (i.e. D1) or another PIM-NG domain 6323 (i.e. D2) the updates MUST be seen as generated in D1. 6325 o If any FILTERING in regards to multicast sources needed to be 6326 done, so that a Sub-Domain does not receive the information 6327 regarding an specific multicast source or a group of multicast 6328 sources, it MUST ONLY BE done within each Sub-Domain in a way 6329 that the C-MAPPER'(s) within a Sub-Domain which ARE a member 6330 of the main domain do the filtering on the contents of A- 6331 MULTICAST MAPPING TABLE at the time of advertising to C- 6332 MAPPERs that are only a member of the Sub-Domain or C-RP'(s) 6333 within the Sub-Domain. 6335 o C-MAPPERs in a PIM-NG Domain which is divided to Sub-Domains 6336 MUST exchange the full A-MULTICAST MAPPING TABLE between 6337 themselves without any filtering, and as said above any 6338 filtering MUST ONLY BE done within each Sub-Domain at the time 6339 of advertising to C-RPs within a Sub-Domain. This MUST be done 6340 so that any PER'(s) or PPER'(s) connecting the PIM-NG Domain 6341 to other domain'(s) or PIM-SM domain'(s) receive the full A- 6342 MULTICAST MAPPING TABLE. 6344 o If a PER is placed between 2 PIM-NG Sub-Domains to isolate 6345 them, then the PER MUST know the main domain number it is 6346 resided in. this is a MUST so that where ever the needs of 6347 multicasting dictates the PER will forward the C-MAPPER 6348 introduction messages which are meant to be heard by C-MAPPERs 6349 and PER or PPERs in the main domain. 6351 o If Sub-Domains are isolated from each other by using PER'(s)and 6352 the dynamic C-MAPPER peering methods are used among different 6353 Sub-Domains, then each PER MUST be dictated to let the C- 6354 MAPPER introduction messages destined to 239.0.1.188 and are 6355 meant to finding other C-MAPPER in the main domain ,to be 6356 forwarded from one Sub-domain to the other. As explained 6357 above, up to 2 C-MAPPERs from each Sub-Domain with total 6358 number of 10 C-MAPPERs are allowed to form C-MAPPER Mesh-Group 6359 in the main domain to propagate the information regarding 6360 multicast sources in each Sub-Domain, so it is vital that the 6361 C-MAPPER introduction messages meant for the main Domain are 6362 forwarded by the PER. 6364 o If the C-MAPPERs in existing Sub-Domain have formed more than 6365 one Mesh-Group in the main domain , PIM-NG specifications 6366 STRONGLY suggests that the PER'(s) between the 2 Mesh-Group 6367 areas DO NOT pass the C-MAPPER introduction messages sent to 6368 239.0.1.188 from one Mesh-Group area to the other. This is 6369 needed to be taken in to consideration when the number of C- 6370 MAPPERs and mesh groups in a multicast domain increase, to 6371 limit the propagation of such traffic. So as explained above 6372 it is STRONGLY suggested to choose at least 2 C-MAPPERs from 6373 each Mesh-Group and make them peer with C-MAPPERs in other 6374 Mesh-Groups using the static methods. consider the bellow 6375 design in which Domain1(D1) is divided in to 4 Sub- 6376 Domains(SD2-5) : 6378 [Figure is presented in PDF version] 6380 Figure 51 Mesh-Groups and C-MAPPER peering 6382 o If a PIM-NG domain divided to Sub-Domains is connected to a 6383 PIM-SM domain and the 2 domains are separated by a PER which is 6384 acting as the BORDER-PIM-ROUTER(BPR) too, then the PER MUST 6385 become aware of both main PIM-NG domain number and the PIM-NG 6386 Sub-Domain number it resides in, and introduce itself to the 6387 closest C-MAPPER in the main domain if the dynamic method is in 6388 use or to any C-MAPPER that is statically introduced to the PER 6389 using the main domain number and not the Sub-Domain number. 6391 o If a PIM-NG domain is divided to Sub-Domains, and the PIM-NG 6392 domain is connected to other PIM-NG domains using PPER'(s), then 6393 the PPER MUST know both the main domain number and the Sub- 6394 Domain number it is resided in, and MUST automatically 6395 communicate with the closest C-MAPPER in the main Domain and 6396 not the Sub-Domain, if the dynamic method is in use and the 6397 ACTIVE C-MAPPER within the main domain is chosen to introduce 6398 all existing C-MAPPERs in the PIM-NG domain by sending 6399 introductions destined to 239.0.1.190, or communicate with any 6400 C-MAPPER that is introduced to it in the main domain. 6402 o When a C-MAPPER in a PIM-NG Domain which is divided to Sub- 6403 Domains with multicast source filtering being applied to Sub- 6404 Domains, receives a PER or PPER introduction, it MUST exchange 6405 the full A-MULTICAST MAPPING TABLE with the PER or PPER so that 6406 the PER or PPER has a complete knowledge about existing 6407 multicast sources. This is why such PER or PPER MUST introduce 6408 itself to the C-MAPPERs within the main domain and not the sub- 6409 domain. as explained earlier each Sub-Domain can have as many C- 6410 MAPPERs as needed but only 2 of them are allowed to be a member 6411 of both main domain and Sub-Domain, and if such PER or PPER 6412 introduces itself to the closest C-MAPPER within a Sub-Domain 6413 that multicast source filtering is applied in it, there is a 6414 possibility that the PER or PPER introduces itself to a C-MAPPER 6415 which is only a member of the Sub-Domain and doesn't have the 6416 full A-MULTICAST MAPPING TABLE. 6418 o If a PIM-NG domain is divided to Sub-Domains and the existing 6419 C-MAPPERs within each Sub-Domain are to form C-MAPPER Mesh-Group 6420 with other C-MAPPERs in other Sub-Domains in the main domain 6421 using the dynamic method used by PIM-NG specifications , the 6422 PERs acting as the boundary between Sub-Domains MUST forward the 6423 C-MAPPER introduction messages sent to 239.0.1.188 and 6424 239.0.1.190(active C-MAPPER introduction). This is advised to be 6425 done through command initiation as an option. 6427 o If a PIM-NG domain which is divided to Sub-Domains is connected 6428 to other PIM-NG domains using PPER concept, and the C-MAPPERs in 6429 PIM-NG domain are forming Mesh-Groups then the PERs acting as 6430 the boundary between the Sub-Domains MUST pass the introduction 6431 message of ACTIVE C-MAPPER in the main domain sent to 6432 239.0.1.190, so that the PPER connecting the PIM-NG domain to 6433 other PIM-NG domains will automatically learn the address of the 6434 C-MAPPERs and communicate with them. 6436 o If a PIM-NG domain which is divided to Sub-Domains is connected 6437 to a PIM-SM domain, and the C-MAPPERs in PIM-NG domain are 6438 forming Mesh-Groups then the PERs acting as the boundary between 6439 the Sub-Domains MUST pass the introduction message of ACTIVE C- 6440 MAPPER in the main domain sent to 239.0.1.190, so that the PER 6441 connecting the PIM-NG domain to PIM-SM domain will automatically 6442 learn the address of the C-MAPPERs and communicate with them. 6444 o If in a PIM-NG Domain which is divided to Sub-Domains and 6445 connected to outside Domains using PPER'(s) or PIM-SM domains 6446 using PER'(s) which act as BPR, more than one C-MAPPER Mesh- 6447 Group is considered , Since it is STRONGLY suggested by PIM-NG 6448 specifications to use a PER between the 2 Mesh-Group area, so 6449 that the ACTIVE C-MAPPER introductions of one area IS NOT 6450 forwarded to other areas, PIM-NG specifications SUGGESTs to 6451 statically introduce at least 2 C-MAPPERs from other Mesh-Groups 6452 that such PER or PPER is not resided in the associated area to 6453 the PER or PPER so that if the connection between the PER or 6454 PPER with the C-MAPPERs inside the closer Mesh-Group area is 6455 lost, the PER or PPERs will be able to communicate with the C- 6456 MAPPERs in other areas. 6458 [Figure is presented in PDF version] 6460 Figure 52 PPER and PER communication with C-MAPPER 6462 As explained above throughout different rules and specifications that 6463 apply to PIM-NG Sub-Domain'(s), the Sub-Domain concept is introduced 6464 to give administrators and designers the ability to divide the 6465 multicast domain to different areas and provide a robust control over 6466 the propagation or advertisement of the multicast sources within each 6467 area or better to say Sub-Domain or as a security feature treat a 6468 Sub-Domain in a way that no multicast source registration is allowed 6469 in an specific area or Sub-Domain by applying the STUB-DOMAIN concept 6470 to that Sub-Domain . In Figure 53 a PIM-NG domain divided to Sub- 6471 Domains is illustrated. 6473 [Figure is presented in PDF version] 6475 Figure 53 Sample PIM-NG domain Divided to Sub-Domains 6477 4.6.6. PIM-NG Stub-Domain 6479 PIM-NG introduces the STUB-DOMAIN concept as a security feature when 6480 dealing with multiple PIM-NG Domains or PIM-NG Sub-Domains. Through 6481 implementing the STUB-DOMAIN concept, a PIM-NG Domain or Sub-Domain 6482 is treated as a multicast domain in which only receivers for 6483 multicast traffic exist. 6485 The bellow specifications and rules apply to a PIM-NG STUB-DOMAIN: 6487 o A STUB-DOMAIN is a domain in which, no multicast source exists. 6489 o A STUB-DOMAIN is a domain in which, ONLY multicast traffic 6490 receivers MUST exist. 6492 o If a Domain is considered to be STUB-DOMAIN, the C-RP'(s) 6493 within the Domain MUST BE dictated NOT TO accept any source 6494 register messages. To do so PIM-NG specifications Suggests that, 6495 at the time of configuring the domain number in which a C-RP 6496 exists, the C-RP be dictated that the domain it is resided in is 6497 a STUB-DOMAIN. 6499 o If a Domain is considered to be a STUB-DOMAIN, the C-MAPPERs 6500 inside the Domain MUST BE dictated NOT TO accept any multicast 6501 source advertisement from existing C-RP'(s), or better to say 6502 the C-MAPPER'(s) inside a STUB-DOMAIN MUST NOT receive any AMMT 6503 from the C-RP'(s) inside the domain, and if any A-MULTICAST 6504 MAPPING TABLE is received from C-RP'(s) it MUST NOT be accepted. 6506 o If a PIM-NG Domain is divided to PIM-NG Sub-Domains, and one or 6507 more Sub-Domain'(s) MUST be treated as a STUB-DOMAIN, then ALL 6508 C-RP'(s) inside such Sub-Domain'(s) MUST become aware about the 6509 situation, so that they WILL NOT accept any source register 6510 messages. 6512 o If a PIM-NG Domain is divided to PIM-NG Sub-Domains, and one or 6513 more Sub-Domain'(s) MUST be treated as a STUB-DOMAIN, then C- 6514 MAPPER'(s) inside such Sub-Domain'(s) MUST NOT accept any AMMT 6515 from the C-RP'(s) inside the Sub-Domain. 6517 o If 2 separate PIM-NG multicast domains (i.e. D1 and D2) are 6518 connected and one of them (i.e. D1) is considered by the other 6519 Domain (i.e. D2) a STUB-DOMAIN, then the C-MAPPER'(s) or 6520 PPER'(s) in the Domain which is not a Stub-Domain (i.e. D2) MUST 6521 NOT accept any multicast source advertisements from the peer C- 6522 MAPPERs in the Domain that is considered a STUB-DOMAIN (i.e. 6523 D1). PIM-NG specifications suggests that this be done at the 6524 time of introducing the peer C-MAPPERs.for instance by 6525 initiating a command like this : 6527 <#IP PIM-NG PEER MAPPER DOMAIN[value] MAPPER-ADDR[X.Y.Z.W] STUB> 6529 o No AMMT MUST BE received or accepted from a peer C-MAPPER which 6530 is considered to be in a STUB-DOMAIN. 6532 o The C-RP'(s) inside a STUB-DOMAIN MUST only receive AMMT from 6533 C-MAPPER'(s) in the domain and MUST NOT generate any AMMT. 6535 o Since as dictated by PIM-NG specifications NO advertisements 6536 regarding multicast sources can be accepted from a STUB-DOMAIN, 6537 In a multicast network design with a STUB-DOMAIN in the middle 6538 of 2 normal domains PIM-NG specifications suggest 2 different 6539 approaches: 6541 1. If possible, C-MAPPER'(s) from the normal Domains MUST 6542 become peer with each other and also the C-MAPPER'(s) in 6543 the STUB-DOMAIN, so that the C-MAPPER'(s) in the normal 6544 Domains can exchange information regarding multicast 6545 sources originated in their domains and only advertise 6546 them to the C-MAPPER'(s) in the middle domain. in this 6547 method the STUB-DOMAIN acts as a transitory multicast 6548 domain and actually is used by the normal domains as a 6549 path to send join/prune messages and receive the desired 6550 multicast traffic. 6552 2. If it is not possible to make the C-MAPPERs in normal 6553 domains peer with each other, PIM-NG specifications 6554 suggest to use a mechanism as an optional feature in 6555 regards to STUB-DOMAIN, so that the C-MAPPER'(s) in 6556 normal domains become peer with the C-MAPPER'(s) in the 6557 STUB-DOMAIN and accept receiving advertisements 6558 regarding multicast sources or better to say accept the 6559 received AMMT from C-MAPPER'(s) in the STUB-DOMAIN, BUT 6560 filter any information regarding multicast sources that 6561 are generated within the STUB-DOMAIN. 6563 o The above approach is unique to PIM-NG because of its unique 6564 RPF check method, which allows the existence of transitory 6565 multicast domains or Autonomous Systems. The above 6566 explanations can be seen in Figure 54. 6568 o If a PIM-NG domain is connected to a PIM-SM domain, and the 6569 PIM-SM domain is considered to be a STUB-DOMAIN, PIM-NG 6570 specifications follows 2 different approaches: 6572 1. If the PIM-SM domain is between 2 PIM-NG domains, the 6573 C-MAPPER'(s) which is becoming MSDP-PEER with RP'(s) in 6574 the PIM-SM domain MUST BE dictated not to accept any 6575 Source Active messages from their MSDP-PEER'(s). And C- 6576 MAPPERs within the PIM-NG domains MUST become peer with 6577 each other. 6579 2. if the PIM-NG domain is connected to a network of PIM- 6580 SM domains and the directly connected PIM-SM domain must 6581 be considered a STUB-DOMAIN, the C-MAPPER'(s) in the 6582 PIM-NG domain MUST be dictated as an optional feature to 6583 perform filtering on the received Source Active messages 6584 received from the MSDP-PEER in the STUB-DOMAIN, so that 6585 any source with the originator address equal to the 6586 address of the MSDP-PEER is filtered. 6588 [Figure is presented in PDF version] 6590 Figure 54 Stub-Domain as the transitory multicast domain 6592 The above specifications and rules apply to a PIM-NG STUB-DOMAIN. and 6593 the reason that the Stub-Domain concept is explained as a part of the 6594 concepts related to PIM-NG and multiple multicast domains, is that 6595 this concept is only meaningful and applicable when we are dealing 6596 with multiple multicast domains, and the STUB-DOMAIN concept can be 6597 used as a security measure when dealing with multicast domains that 6598 no multicast source'(s) are expected to be advertised from them, to 6599 eliminate the possibility of existing attackers. 6601 4.7. PIM-NG Bidirectional logic 6603 One of PIM-NG's features that can make it by far a suitable candidate 6604 for scenarios with huge number of sources and receivers for the same 6605 multicast group and specially data centers is its Bidirectional PIM 6606 logic. Current implementation and concept cannot allow for the 6607 existence of redundant roots per bidirectional tree which is a 6608 desirable factor especially in data centers where we can face a huge 6609 number of receivers and sources for the same multicast group (G). 6610 Other than redundant roots being able to benefit from redundant trees 6611 per bidirectional group can be considered another desirable factor 6612 which currently needs to use other protocols in conjunction with PIM- 6613 SM. 6615 PIM-NG can provide both redundant roots per bidirectional tree and 6616 redundant trees per multicast group by making use of some of the 6617 processes and specifications which has been explained up to this 6618 point alongside its unique Bidirectional logic. 6620 In addition to the above PIM-NG introduces a new method of 6621 Bidirectional multicast group discovery unique to PIM-NG called 6622 Bidirectional Group Auto Sense mechanism which allows a multicast 6623 domain to automatically sense the existence of Bidirectional Groups 6624 and change the logic of the domain for those groups to Bidirectional. 6626 In the following sections different concepts and specifications of 6627 PIM-NG bidirectional logic will be discussed. 6629 4.7.1. Requirements 6631 . For Bidirectional PIM-NG logic to be implemented in a well 6632 organized manner at least 1 TR MUST do exist in a PIM-NG multicast 6633 domain. 6635 . All PIM-NG aware routers MUST be Bidirectional PIM aware too by 6636 default. 6638 4.7.2. Bidirectional Multicast Group Discovery 6640 Before getting involved in how Bidirectional trees are formed, we 6641 need to understand how Bidirectional Multicast Groups within a Domain 6642 are discovered so we will be able to deliver the desired traffic 6643 destined for (G) from sources to receivers. 6645 PIM-NG uses 2 different methods for Bidirectional source discovery 6646 which are called Manual mode and autosense mode. No matter what type 6647 is used it is mandatory that a PIM-NG domain in which the 6648 bidirectional logic is going to be used have 1 or more TR'(s). That 6649 being said at least 1 TR MUST exist in such domains. 6651 4.7.2.1. Manual Mode 6653 Bidirectional Multicast source discovery manual mode specifications 6654 are as follows: 6656 1- In this mode The Bidirectional Multicast Group'(s) are defined and 6657 configured manually on the existing C-MAPPER or Active C-MAPPER if 6658 more than 1 C-MAPPER is considered. 6660 2- For this mode to be activated the Active C-MAPPER MUST be 6661 configured appropriately by the administrator and the C-MAPPER 6662 MUST inform all the population by setting the B-BIT in its 6663 introduction messages sent to 239.0.1.190. 6665 3- After the Groups with Bidirectional logic are defined and 6666 configured on the C-MAPPER, the C-MAPPER MUST notify the entire 6667 population of PIM-NG aware routers about the existence of such 6668 Groups so that the domain's logic will change to Bidirectional for 6669 those group'(s). This is done by the C-MAPPER through sending a 6670 special table called "Bidirectional Groups Table (BGT)" in its 6671 introduction messages sent to 239.0.1.190. 6673 +--------------------------------------+ 6674 |Bidirectional Group| TR Group |R-flag | 6675 +--------------------------------------+ 6676 | | | | 6677 +--------------------------------------+ 6678 | | | | 6679 +--------------------------------------+ 6680 Figure 55 Bidirectional Groups Table (BGT) 6682 . R-Flag: set by a C-RP or C-MAPPER to inform the C-MAPPER to 6683 remove a multicast group from its BGT table. If this flag is 6684 set it means that the group is not active anymore. 6686 Figure 55 shows the format of BGT in which C-MAPPER announces the 6687 Multicast Groups for which the logic of the Domain MUST change to 6688 Bidirectional. Also the C-MAPPER announces a TR group which 6689 defaults to 0 and its use will be discussed further when there are 6690 lots of TR'(s) in a multicast domain and the needs of multicasting 6691 dictates to use a handful of TRs for different sets of 6692 Bidirectional Multicast groups as the ROOT. So for the sake of 6693 simplicity it assumed that there are not so many TRs. 6695 4- After the C-MAPPER sends BGT in its introduction messages all the 6696 PIM-NG aware routers will know about any multicast group that must 6697 be treated as a Bidirectional Group and sources and receivers will 6698 immediately join the SPT rooted at the closest TR for that 6699 group'(s) without registering with C-RP'(s). 6701 5- In scenarios with SUB-Domains implemented it is possible to filter 6702 any desired Bidirectional Multicast group from being updated to 6703 the Active C-MAPPER within each Sub-Domain by the Active C-MAPPER 6704 in the main domain. 6706 6- BGT MUST BE exchanged between neighbor clients when a new client 6707 is added at the time of synchronization. 6709 7- If a Group (G) is removed the C-MAPPER MUST announces this event 6710 by sending the BGT and setting the R-Flag for that (G). 6712 8- In scenarios with Core Domain implementations, in which 1 or more 6713 Domains are connected to a Core domain and senders and receivers 6714 are distributed in different domains, Bidirectional Groups MUST be 6715 configured and defined on an Active C-MAPPER within the Core 6716 Domain and then be updated to C-MAPPERs inside connected Domains. 6718 9- When Bidirectional groups are defined on C-MAPPERs within a core 6719 domain, PIM-NG strongly advises to update it based on domains in 6720 which any sender or receiver of Group G exists. to make it more 6721 clear it must be said that it is suggested to use a mechanism 6722 through which it will be possible to send the BGT to desired C- 6723 MAPPER neighbors within connected domains or if needed to all the 6724 C-MAPPERs. This way senders and receivers within any desired 6725 domain can join the Bidirectional tree for group G within their 6726 domain and eventually the tree in the core domain. 6728 10-If 2 PIM-NG multicast domains are going to communicate using 6729 Bidirectional PIM, then at least one C-MAPPER in any one of the 6730 domains MUST be configured with appropriate Bidirectional 6731 information and pass the information to the other C-MAPPER by 6732 exchanging BGT. 6734 11-When a Bidirectional Group is removed from the BGT of a C-MAPPER 6735 the C-MAPPER MUST notify all the population of PIM-NG aware 6736 routers within its domain and in case of domains connected to a 6737 core domain all the C-MAPPERs within each domain or desired domain 6738 about the change by sending a BGT with the R-Flag of the removed 6739 Multicast Group being set to 1. 6741 This process is much like what is happing in current implementations 6742 except for the fact that it allows for the existence of many TR's 6743 within a domain and thus redundant roots per Bidirectional group, 6744 which will be discussed later. 6746 4.7.2.2. Autosense mechanism 6748 PIM-NG allows a multicast domain to automatically sense the existence 6749 of Bidirectional groups and change the logic of the Domain for such 6750 groups. This is accomplished due to the fact that the Source registry 6751 mechanism and the processes through which a client finds the source 6752 of a multicast address are performed in a complete different and 6753 innovative way than current implementations. 6755 As explained in chapter 4.2. PIM-NG uses a new mechanism for 6756 registering the source and the way a client or end host finds its 6757 desired multicast source. Involved mechanisms like saving the 6758 information of active sources in MMT by C-RP'(s) and also the unicast 6759 nature of Source discovery messages sent from clients to C-RP'(s) 6760 provides the ability of keep track of existing multicast sources and 6761 receivers or better to say how many receivers and sources do exist 6762 for the same multicast group. 6764 By definition a Bidirectional Multicast Group is a group for which 6765 lots of simultaneous senders and receivers do exist or better to say 6766 it is a group for which a sender is also a receiver. 6768 PIM-NG Bidirectional specifications with regards to Autosense are as 6769 follows 6771 1- Autosense is the default mode of PIM-NG Bidirectional logic. 6773 2- Autosense is suitable for any type of multicast domain and MUST 6774 only be used when there is only one multicast domain. That being 6775 said it is not advised to use it in scenarios with multiple 6776 domains connected to or through a core domain. For such scenarios 6777 it is suggested to ONLY use the Manual mode. 6779 3- In PIM-NG a multicast group G for which at least 1 unicast address 6780 is seen by C-RP as both the source and receiver IS considered a 6781 Bidirectional multicast group. So in a PIM-NG domain with 6782 Bidirectional Source Autosense discovery mechanism activated on 6783 its C-RPs and C-MAPPER'(s) when a C-RP receives a Request for 6784 source type of message for multicast group G from a client whose 6785 unicast address is also registered as the source of that same 6786 multicast Group G the C-RP becomes aware that it is dealing with a 6787 Bidirectional multicast group and thus it immediately informs the 6788 closest C-MAPPER about it by sending the so called Bidirectional 6789 Groups Table in its unicast introductions to the C-MAPPER 6790 containing the multicast Group with both the TR group and R-Flag 6791 fields being set to 0. 6793 4- As soon as a Multicast Group (G) is announced as a Bidirectional 6794 Multicast Group, the Logic of the Domain for that (G) MUST change 6795 to Bidirectional and Sources and receivers MUST immediately join 6796 the SPT rooted at closest TR or better to say receivers which are 6797 also considered sources will send their join to the TR as the 6798 Source. 6800 5- The C-RP'(s) MUST send the BGT to C-MAPPER immediately whenever it 6801 senses a change by setting the ZTCN bit in its message. 6803 6- Receiving the message containing the BGT from a C-RP, the C-MAPPER 6804 MUST immediately inform all the existing Clients by sending an 6805 introduction message containing the BGT to 239.0.1.190. 6807 7- When the Active C-MAPPER receives an introduction from either a C- 6808 RP or other C-MAPPERs containing BGT it MUST immediately inform 6809 all the other C-MAPPERs it is in contact with so that all the C- 6810 MAPPERs become aware of the situation. 6812 8- If more than 1 C-MAPPER exists and due to the fact that in such 6813 cases and with regards to chapter 4.5.2. The Active C-MAPPER is 6814 responsible for all the introductions sent to 239.0.1.190, any C- 6815 MAPPER that receives a BGT showing a change MUST inform the Active 6816 C-MAPPER. So in case of multiple C-MAPPERs each C-MAPPER receiving 6817 a BGT with the R-Flag being set, MUST inform the Active and if the 6818 Active doesn't receive a BGT with the associated R-Flag of 6819 Bidirectional group (G) not beibg set which shows that there are 6820 still senders and receivers, in the next 15+2 minutes it MUST 6821 inform all the population about the change and removal of that 6822 group from Bidirectional logic. 6824 9- If the SUB-Domain concept is implemented the Active C-MAPPER in 6825 the main domain MUST inform all C-MAPPERs inside Sub-Domains by 6826 sending BGT to them. 6828 10- In scenarios with SUB-Domains implemented it is possible to 6829 filter any desired Bidirectional Multicast group from being 6830 updated to the Active C-MAPPER within each Sub-Domain by the 6831 Active C-MAPPER in the main domain. 6833 11- BGT MUST BE exchanged between neighbor clients when a new client 6834 is added at the time of synchronization. 6836 12- When the Autosense mechanism is used, it is possible to remove a 6837 multicast group from the Bidirectional logic or announce it 6838 deactivated. This can be done by defining the group (G) on the C- 6839 MAPPER or Active C-MAPPER and introduce it to population by 6840 setting the R-Flag in the BGT. 6842 13- If a PIM-NG aware router senses that it is in ideal state for a 6843 Bidirectional Group for 60 minutes or better to say it hasn't 6844 received any updates from the C-MAPPER about group (G) nor it has 6845 been part of the Bidirectional Tree for that (G) it MUST remove it 6846 from its internal BGT and change its logic until further notice 6847 from the C-MAPPER. 6849 14- Each TR MUST send an empty BGT to the closest C-MAPPER every 10 6850 minutes to the C-MAPPER. This empty table is a sign that all the 6851 groups that are announced by the C-MAPPER are active. And 6852 eventually C-MAPPERs MUST inform the Active C-MAPPER about the 6853 situation. 6855 15- If a TR is pruned from the Bidirectional Tree of group (G)or 6856 better to say it is not part of the Bidirectional tree of (G) for 6857 20 minutes it announces this to C-MAPPER by sending the BGT and 6858 putting an entry for that group (G) in the table plus setting the 6859 R-Flag for that group 6861 16- If C-MAPPER or Active C-MAPPER doesn't receive a BGT from at 6862 least one TR showing that all the announced Bidirectional Groups 6863 are active for 50 minutes or 5 times to the default time TRs must 6864 send their periodical messages containing BGT to C-MAPPER , it 6865 MUST announce that (G) not active by sending a BGT and setting the 6866 associated R-Flag of that Group so that all the population will 6867 remove that group until further notice or better to say until at 6868 least one source for that group becomes active. 6870 17- If a PIM-NG aware router doesn't need to be anymore part of the 6871 Bidirectional Tree for (G) it will send a Prune to upstream 6872 routers and all the rules with regards to a prune message and 6873 shared networks in which more than one router are connected 6874 through a shared media are applicable. 6876 4.7.3. Redundant TRs 6878 This section is dedicated to talk about a special feature of PIM-NG 6879 Bidirectional logic which makes it possible to use multiple redundant 6880 Tree Roots per bidirectional Multicast group and eventually as it is 6881 described later to have redundant Bidirectional Trees per multicast 6882 group rooted at existing TRs. 6884 In a PIM-NG multicast domain with at least 2 TRs, it is possible to 6885 use either all existing TRs in a redundant manner or use a handful of 6886 TRs and associate them with 1 set of bidirectional multicast groups 6887 and associate other TRs to other groups depending on the needs of 6888 multicasting. 6890 Both of the above mentioned factors are desirable in dense 6891 environments with many senders and receivers for the same G and 6892 residing in different parts of the domain. In the following sections 6893 I am going to explain the 2 different approaches PIM-NG provides with 6894 regards to existing TRs and redundancy of Tree Roots. 6896 4.7.3.1. ANYCAST Approach 6898 As the name suggests, this method uses the ANYCAST concept with 6899 regards to the available TRs within a multicast domain and how they 6900 are introduced by the C-MAPPER. 6902 By using this method it doesn't matter how many TRs exist in a PIM-NG 6903 multicast domain, because the C-MAPPER updates only one unicast 6904 address for existing TRs in its PDTT with the TR group field being 6905 set to 0. 6907 As soon as Clients receive the information about the unicast address 6908 of the TRs and with regards to Bidirectional logic explained so far, 6909 each client immediately joins the SPT for G rooted at the closest TR 6910 by setting the source unicast address to the unicast address of the 6911 TR and also setting the R-bit of the source address which indicates 6912 that the join message should be forwarded towards the TR. 6914 PIM-NG specifications dictates that a join message in which the 6915 source unicast address and Tree Root addresses are the same is a sign 6916 of a Bidirectional join message and thus in addition to the Multicast 6917 group address received in BGT tells intermediary clients that their 6918 logic MUST change to Bidirectional for such messages. 6920 At the end of above procedure each client that needs to be part of 6921 the Bidirectional Tree for G joins the SPT rooted at the closest TR. 6923 4.7.3.2. TR Grouping 6925 There are scenarios in which it is not desirable to use all the 6926 available TRs in Bidirectional processes or it is needed to use some 6927 of the available TRs as the redundant roots of a set of Bidirectional 6928 Groups and other TRs for other sets. 6930 PIM-NG makes such implementation possible through its well mannered 6931 design in a way that it is now possible to consider any one of the 6932 bellow approaches that suits well: 6934 1- Use the ANYCAST method of TR introduction alongside the Grouping 6935 of TRs. In this approach all the TRs are introduced for normal 6936 multicast routing using the ANYCAST address and a selected group 6937 of TRs can be introduced in addition to the ANYCAST with their 6938 unicast address used for communication between TRs and C-MAPPERs 6939 alongside their TR group which is manually configured on the 6940 Active C-MAPPER. In such case clients MUST only use the TRs with 6941 TR Group number other than 0 when dealing with Bidirectional 6942 multicast groups. 6944 2- Use only Grouping of TRs. In this approach only the unicast 6945 address of available TRs are updated by the C-MAPPER alongside 6946 their TR group which is set manually on the Active C-MAPPER. It is 6947 also possible to use more than one Anycast Address when using TR 6948 Grouping. In this manner each group of TRs will be assigned a 6949 separate and unique Anycast Address which will eventually reduced 6950 the size and entries of PDTT. 6952 Both of the above methods are usable, although, the second approach 6953 will result in huge amount of data in PDTT updated by C-MAPPER. No 6954 matter which method is used clients will use the groupings ONLY when 6955 dealing with Bidirectional multicast groups. 6957 For this method to be implemented a series of processes MUST take 6958 place which are listed below: 6960 1- TRs MUST be manually grouped on the C-MAPPER or the Active C- 6961 MAPPER. This is done by simply assigning a group number with a 6962 value between 0 and 255 to each desired set of TRs, with value 0 6963 being reserved for introducing TRs using ANYCAST method and value 6964 255 reserved for introducing a TR which is part of all 6965 Bidirectional Groups. This group value is used later by clients at 6966 the time of choosing which TR they must send their join towards as 6967 the root of the Bidirectional tree. 6969 2- A TR which is part of all TR groups which is introduced to the 6970 population by TR group value of 255, is called Bidirectional 6971 Translator TR and is used later in inter-domain Bidirectional 6972 connectivity. 6974 3- Then the C-MAPPER MUST update the groupings in its PDTT when 6975 sending its introduction to 239.0.1.190 by setting the TR Group 6976 field associated with each TR to the configured value and send it 6977 to all the population of PIM-NG aware routers so that even 6978 existing TRs will become aware of this groupings. 6980 4- A mapping between existing and activated Bidirectional Multicast 6981 groups and the configured TR Groups on the Active C-MAPPER MUST be 6982 done either through manual configuration or an algorithm which 6983 through a hashing mechanism assigns and maps each set of 6984 Bidirectional multicast group to a TR group. It is suggested to 6985 use the automated method through the proposed algorithm which is 6986 useful when dealing with the Autosense mechanism of Bidirectional 6987 source discovery or big multicast domains. 6989 5- Finally when the C-MAPPER is going to notify the PIM-NG population 6990 about activated Bidirectional Groups by sending the BGT in its 6991 introduction messages, it MUST set the TR Group field associated 6992 to each Bidirectional Multicast group with the related and mapped 6993 TR group. 6995 6- Clients will receive the mappings in the BGT and since they know 6996 which TR belongs to which Group because they have received it 6997 before in PDTT sent by C-MAPPER, they eventually know which TR 6998 should be used as the root of each Tree and will use the unicast 6999 address of the appropriate TR which is the closest one to them to 7000 join SPT. 7002 7- A TR CAN BE a member of multiple groups and a C-MAPPER MUST send 7003 the groupings as individual entries in its PDTT. The only 7004 exception is for Bidirectional translator TR'(s) that are 7005 identified by TR group 255. 7007 8- If a TR which is member of a group is lost and by lost PIM-NG 7008 specifications means the loss of connectivity between TR and C- 7009 MAPPER in a way it is sensed by C-MAPPER, the C-MAPPER MUST choose 7010 a suitable TR to replace the lost TR and automatically update it 7011 by sending the unicast address of the new TR and associated group 7012 in its PDTT. By suitable, PIM-NG specifications means the closest 7013 TR to the current TR based on the information found in RIB. 7015 9- If the above happens and a TR from a group is lost and a new TR is 7016 chosen automatically and the chosen TR is already member of other 7017 TR group'(s), then C-MAPPER MUST update all the Groups the TR is a 7018 member of in its PDTT as separate entries again. This is a MUST as 7019 if a TR is a member of group A and it is also chosen to become a 7020 member of group B, if the C-MAPPER send an update with only an 7021 entry for group B, clients MUST and will take it as if the TR can 7022 be used ONLY for Bidirectional Groups with associated TR group B. 7024 10-If a lost TR part of a TR group becomes alive again, the C-MAPPER 7025 MUST send an update including PDTT with an entry for the activated 7026 TR and removing the TR which was automatically chosen as its 7027 replacement. 7029 4.7.4. Bidirectional Tree formation 7031 Tree formation can be considered the most important part of PIM-NG 7032 Bidirectional logic as it provides the ability to benefit from 7033 redundant Roots per Bidirectional Tree and eventually redundant 7034 Bidirectional trees per multicast group. 7036 The basic rule of Bidirectional PIM with regards to tree formation 7037 and joining the SPT rooted at the TR applies to PIM-NG too, except 7038 for the fact that in PIM-NG actually no shared path tree exists and 7039 join messages carry the unicast address of a TR as the source of 7040 multicast group in (S, G) format. So in the following sections I will 7041 explain the process through which a Bidirectional Tree is formed 7042 between TRs and the how clients join the Tree rooted at the closest 7043 TR. 7045 4.7.4.1. Tree formation between TRs 7047 As described before in a PIM-NG domain each TR knows the unicast 7048 address of other TRs because they receive it from the C-MAPPER. This 7049 address is not the ANYCAST address but the address used by TRs to 7050 introduce themselves to the closest C-MAPPER and communicate with the 7051 C-MAPPER and other TRs to exchange their joined groups table. 7053 Because of the above feature of PIM-NG with regards to TRs, it is 7054 very easy to make the TRs join a Tree using the unicast address of 7055 other TRs as the source address of a multicast group (G). 7057 The above approach works well in normal PIM-NG multicast 7058 communications because it might be needed to forward a received join 7059 message towards a TR which already joined the SPT for (S, G) and is 7060 closer than the source itself and can be placed anywhere in the 7061 domain, but when it comes to Bidirectional communications and tree 7062 formation between the TRs PIM-NG's approach is a little different. 7064 PIM-NG specifications and processes with regards to Tree formation 7065 between TRs are as follows: 7067 1- If a TR receives a join message for Bidirectional Group (G) it 7068 MUST first check the contents of its internal Joined Groups Table 7069 which indicates all the multicast groups other TRs residing in the 7070 domain already joined the Tree for. 7072 2- If an entry matching Bidirectional group (G) is found in the 7073 Joined Groups table, TR MUST forward the received join message 7074 towards the TR which is already joined the Bidirectional Tree for 7075 (G) by changing the Source unicast address and TR unicast address 7076 of the join message with the unicast address of the TR which is 7077 already joined the Bidirectional Tree for (G) without touching the 7078 R-Bit. 7080 3- If multiple entries matching Bidirectional group (G) are found, TR 7081 MUST forward the join message towards the closest TR. 7083 4- If a TR receives a join message for a Bidirectional Group (G) and 7084 ONLY if there are no entries matching Bidirectional Group (G) in 7085 joined Groups table, it MUST inform other TRs by updating its 7086 Joined Groups table and send it in its introduction message to 7087 other TRs. 7089 5- If the ANYCAST TR approach is used the Joined Groups table MUST be 7090 sent to all the existing TRs. 7092 6- If the TR grouping approach is used, the Joined Groups Table MUST 7093 be sent to all the TRs that are member of the same group and 7094 specifically to Bidirectional Translator TR'(s) which are a member 7095 of all existing Groups and are used in Inter-Domain connectivity. 7097 7- The above method will form a distributed Bidirectional Tree for 7098 group (G) with multiple TRs as the Roots of the tree and more 7099 importantly this tree is formed whenever it is demanded and won't 7100 waste much bandwidth. 7102 8- Please refer to section 4.7.5. For information about Bidirectional 7103 Tree formation between different PIM-NG multicast domains. 7105 Through the above approach and process at the end a Bidirectional 7106 Tree with multiple TRs as its redundant roots forms nicely between 7107 existing TRs whether the ANYCAST approach or the TR grouping approach 7108 is used. All the TRs are working redundantly which provides higher 7109 Bidirectional communications speed due to the fact that each client 7110 can simply get connected to its closest TR. This approach is mostly 7111 beneficial in dense environments such as data centers where we are 7112 dealing with high number of senders and receivers who are in 7113 different parts of the domain. 7115 Also needless to say this approach provides the possibility of inter- 7116 domain Bidirectional connectivity wherever applicable with bellow 7117 specifications: 7119 1- A C-MAPPER in the remote multicast domain or core domain MUST 7120 become aware of the activated Bidirectional Groups through 7121 receiving a BGT from its neighbor or manual configuration. To make 7122 it clear the 2 domains MUST be neighbors or better to say a 7123 neighbor ship between C-MAPPERs in desired domains MUST be 7124 established. 7126 4.7.4.2. Completing the Tree formation 7128 Final stage of a full Bidirectional Tree formation will be clients to 7129 join the Tree for (G). 7131 Each Client with need to send and receive the traffic of 7132 Bidirectional Multicast group (G) MUST join the SPT rooted at the 7133 closest TR. 7135 If the ANYCAST approach is used then each client MUST use the ANYCAST 7136 address as the Root address and also unicast address of the source 7137 for (G) when sending the join message. And in case of TR grouping the 7138 unicast address of the closest TR associated to (G) with respect to 7139 the information it has received from C-MAPPER in BGT and PDTT. 7141 At the end a distributed redundant Bidirectional tree with regards to 7142 the Roots and Tree formation between clients and Roots will form 7143 which covers an entire domain and is a feature desirable in dense 7144 environments. 7146 [Figure is presented in PDF version] 7148 Figure 56 Bidirectional Tree formation with ANYCAST TR Address 7150 [Figure is presented in PDF version] 7152 Figure 57 Bidirectional Tree formation with TR grouping 7154 4.7.5. Inter-Domain Bidirectional connectivity rules 7156 1- As described previously a C-MAPPER in a core domain MUST introduce 7157 existing TR'(s) within its domain to their neighboring C-MAPPERs 7158 in connected domain'(s). This procedure is a MUST in Bidirectional 7159 logic to help TR'(s) in domains communicate with TR'(s) in core 7160 domains to exchange their joined groups table. 7162 2- C-MAPPER'(s) within PIM-NG domains MUST introduce at least one TR 7163 to their neighbors alongside the associated Domain number so that 7164 the TR is distinguishable. This is done by exchanging the unicast 7165 address of selected TR'(s) in PDTT. PIM-NG specifications dictates 7166 that the ONLY time a C-MAPPER uses its PDTT to send any 7167 information to its neighbors in other domains is when 7168 Bidirectional logic is being used and only the information of 7169 TR'(s) MUST be exchanged between C-MAPPER'(s) in normal domains or 7170 between a C-MAPPER in a normal domain and a C-MAPPER in the core 7171 domain. 7173 3- Unicast address of any TR that is received in PDTT from a neighbor 7174 C-MAPPER in another domain MUST only be sent to existing TRs and 7175 not all the population alongside the Domain number value 7176 associated to the TR to make the TR distinguishable. This is 7177 different from what happens with TRs in a core domain because as 7178 it had been explained the unicast address of TR'(s) within a core 7179 domain received in Core Domain topology Table MUST be sent to all 7180 the population by the C-MAPPER or Active C-MAPPER. 7182 4- When dealing with inter-domain Bidirectional connectivity 7183 scenarios, PIM-NG STRONGLY advises to use ANYCAST method explained 7184 in chapter 4.7.3.1. In all the involved domains to ease the 7185 processes. 7187 5- As explained before it is also possible to update selected TRs to 7188 other domains through manual configuration. This being said, if in 7189 a domain TR grouping method is and must be used, then one or more 7190 TRs must be chosen to act as Bidirectional Translator TR with TR 7191 group number of 255 and the unicast address of the Bidirectional 7192 translators MUST be updated in either PDTT or Core Domain Topology 7193 Table. This is due to the fact that only a TR which is part of all 7194 TR groups or better to say can be aware of all active or to be 7195 active Bidirectional Groups can be involved in inter-domain 7196 connectivity. 7198 6- The joined groups table exchanged between TR's in different 7199 multicast domains MUST only contain the information regarding 7200 Bidirectional Groups. 7202 7- If the TR grouping approach is used, ONLY the Bidirectional 7203 Translator TR'(S) MUST send Joined Groups Table to TR'(s) in other 7204 domains when dealing with Bidirectional Groups. This is due to the 7205 fact a Translator TR is the only TR within a PIM-NG domain to know 7206 about all the active multicast groups and will receive the Joined 7207 Groups Table from all existing TRs member of any available TR 7208 group. 7210 8- When a TR receives a join for (G) from a client and there is no 7211 entry for (G) in its Joined Groups Table matching (G) it MUST 7212 inform other TRs. 7214 9- If the ANYCAST approach is used then TRs in other domains will 7215 receive the Joined Groups table too and if they receive a join 7216 from a client they will forward the join towards TR'(s) in other 7217 domains which are already joined the Bidirectional Tree for (G). 7219 10- If TR grouping is used and since only the Translator TR is 7220 allowed to communicate with TRs in other Domains, the joined 7221 Groups table MUST be sent to the Translator TR and Translator TR 7222 MUST inform TRs in other Domains no matter if it is already joined 7223 the Bidirectional tree for (G) or not. 7225 11- When a PER or PPER receives a join for a Bidirectional Group form 7226 outside its domain and the TR grouping is used, it MUST forward it 7227 towards the closest Translator TR. 7229 12- When a PER or PPER receives a join for a Bidirectional Group form 7230 outside its domain and the ANYCAST approach is used, it MUST 7231 forward it towards the closest TR. 7233 13- When a Translator TR receives a join for Bidirectional Group (G) 7234 it MUST forward the join towards the closest TR already joined the 7235 tree for (G) based on the TR grouping information associated with 7236 the TRs and its internal Joined Groups Table mappings. This is why 7237 it is called a Translator as it allows to connect a domain in 7238 which ANYCAST is used to a domain in which TR grouping is used or 7239 the other way around or to connect domains with different TR 7240 groupings in use. 7242 14- When a Translator TR receives a join message for (G) and ONLY if 7243 there are no entries matching (G) in its Joined Groups Table it 7244 MUST inform other TRs based on TR grouping and mappings to 7245 Bidirectional Groups. 7247 15- Since by definition a TR only accepts control plain packets from 7248 TRs inside its domain, a mechanism MUST be taken into 7249 consideration with regards to ONLY Bidirectional logic so that 7250 TR's accept Joined Groups Table from desired TRs with regards to 7251 the domain in which they reside. This can be simply a manual 7252 configuration through which a TR becomes aware of to which TR in 7253 which Multicast domain it can send Joined Groups table and from 7254 which TRs it can accept such table. 7256 16- It is STRONGLY advised not to use the Autosense mechanism 7257 explained in(4.7.2.2. ) when dealing with Inter-domain 7258 connectivity. 7260 17- If in involved domains the Autosense mechanism (4.7.2.2. ) is 7261 needed to be implemented, then C-MAPPERs in involved domains MUST 7262 exchange their BGTs to inform each other about any changes. 7264 18- If Autosense mechanism is implemented and Bidirectional group (G) 7265 is needed to become deactivated totally, it MUST only be done 7266 within the domain the C-MAPPER or Active C-MAPPER is resided and 7267 it MUST NOT be announced to C-MAPPERs in other domains.. 7269 At the end through all the above specifications, definitions and 7270 concepts PIM-NG provides the ability to easily benefit from having a 7271 distributed Bidirectional Tree for group (G) with redundant Tree 7272 ROOTs and Redundant Trees. This behavior is one of the many features 7273 it provides and is specifically beneficial for data centers or 7274 whatever multicast domain with huge number of distributed multicast 7275 sources and receivers for the same group (G). 7277 Also as explained it also provides the possibility to bring the 7278 Inter-Domain connectivity concept with regards to Bidirectional Tree 7279 which makes it a good choice for such scenarios. 7281 4.8. PIM-SM compatibility 7283 Up to this point of explaining different concepts of PIM-NG as a new 7284 multicast protocol, almost ALL aspects of PIM-NG specifications have 7285 been covered. 7287 Now it is time to make it compatible with its predecessor PIM-SM, so 7288 that PIM-NG multicast domains can be connected to PIM-SM domains or a 7289 network of PIM-SM domains. Compatibility of PIM-NG with PIM-SM is 7290 related to the bellow fields: 7292 o Exchanging the information regarding the multicast sources 7293 originated in either the PIM-NG Domain'(s) or PIM-SM Domain'(s), 7294 so that receivers can find the source for their desired 7295 multicast traffic and send join/prune messages towards the 7296 desired multicast source, whether it is inside a PIM-NG Domain 7297 or PIM-SM Domain. 7299 o The transformation of PIM-NG join/prune messages to PIM-SM 7300 messages so that routers that are only PIM-SM aware will be able 7301 to forward the join/prune messages to the final destination. 7303 o The transformation of PIM-SM join/prune messages to PIM-NG 7304 join/prune messages so that the join/prune message can be 7305 forwarded according to PIM-NG specifications within the network 7306 of PIM-NG Domains. 7308 In the following sections, different concepts, specifications and 7309 rules in regards to connecting a PIM-NG multicast domain to a PIM-SM 7310 multicast domain will be discussed. First the concepts regarding the 7311 exchange of information regarding originated multicast sources in the 7312 form of Source Active (SA) messages will be discussed and after that 7313 the concepts related to sending join/prune messages will be 7314 discussed. 7316 4.8.1. PIM-SM compatibility and SA messages 7318 As described by RFC 3610[9], the information regarding originated 7319 multicast sources MUST be exchanged between RPs that are MSDP peer. 7320 And such information is sent from one RP to another RP, in a Source 7321 Active (SA) message, which contains: 7323 o Originator address or the unicast address of the originating RP 7325 o Source address or the unicast address of the source generating 7326 the traffic 7328 o Group address the source sends data to 7330 And In PIM-NG as described in section 4.5. , the information 7331 regarding newly originated multicast sources is carried inside AMMT 7332 and between peer C-MAPPERs using unicast-encapsulated C-MAPPER 7333 introductions, which contains: 7335 o Originator address or the unicast address of the originating RP 7337 o Source address or the unicast address of the source generating 7338 the traffic 7340 o Group address the source sends data to 7342 o Domain-Set 7344 As it has been described, the format of AMMT and the information 7345 related to newly originated multicast sources is similar to the 7346 contents of SA messages used by PIM-SM MSDP peers, which makes it 7347 easier to connect a PIM-NG Domain or a network of PIM-NG multicast 7348 domains to a PIM-SM Domain or a network of PIM-SM multicast Domains. 7349 And by connecting in this section PIM-NG specifications refers to the 7350 exchange of information regarding multicast sources. 7352 The rules, concepts and specifications regarding compatibility of 7353 PIM-NG and PIM-SM are as follows: 7355 o Depending on whether we are dealing with a public or private 7356 PIM-NG domain, a C-MAPPER or PPER in the PIM-NG Domain MUST BE 7357 chosen to become MSDP-PEER with an RP in the PIM-SM Domain. 7359 o All the rules that apply to MSDP [9] MUST be applied when a C- 7360 MAPPER or PPER becomes MSDP-PEER with an RP. 7362 o Whenever a C-MAPPER which is also MSDP-PEER with an RP, 7363 receives an update regarding newly originated multicast sources 7364 inside the AMMT from a PEER C-MAPPER and needs to advertise the 7365 received update to the MSDP-PEER'(s): 7367 1. It MUST remove the DOMAIN-SET of any multicast sources 7368 that are to be advertised to the MSDP-PEER'(s) 7370 2. It MUST create a Source Active message containing 7371 information regarding ALL multicast sources that are to be 7372 advertised to the MSDP-PEER'(s). 7374 3. The SA message contains ONLY: 7376 o Originator address 7378 o Source unicast address 7380 o Group destination 7382 Which is exactly what an SA carries. 7384 o Then the C-MAPPER MUST send the SA message to its MSDP-PEER'(s) 7385 the way explained by MSDP specifications [9] to bring 7386 compatibility to PIM-SM. 7388 o Because of the RPF method used by MSDP, the C-MAPPER or PPER 7389 which is becoming MSDP-PEER with an RP MUST reside in the first 7390 Autonomous System in the best path towards the AS in which the 7391 originator C-MAPPER exists. 7393 o As explained by PIM-NG specifications, each multicast source 7394 has a Domain-Set associated with it, which shows that in which 7395 domain a source is being originated and also is used for PIM-NG 7396 RPF check. So when a C-MAPPER receives an SA message from a 7397 MSDP-PEER (RP), and needs to advertise the information to a PEER 7398 C-MAPPER, it MUST add the following to the Domain-Set: 7400 1. Its own domain number 7402 2. A value equal to letter "S" which shows that this source 7403 is received from a network of PIM-SM Domain'(s). So if C- 7404 MAPPER in Domain1 receives an update for (S, G) from its 7405 MSDP-PEER, and needs to update it to its PEER C-MAPPER'(s), 7406 it MUST modify the Domain-Set as explained and advertise 7407 the associated Domain-set as (D S, 1). 7409 o If a C-MAPPER receives an update for (S,G) from a MSDP-PEER, 7410 and an update for the same (S,G) from a peer C-MAPPER which the 7411 associated Domain-Set indicates that (S,G) is originated inside 7412 a PIM-NG Domain and not a PIM-SM domain, then the update 7413 received from the peer C-MAPPER MUST pass the RPF check. 7415 o If a C-MAPPER receives an update for (S,G) from a MSDP-PEER, 7416 and an update for the same (S,G) from a peer C-MAPPER which the 7417 associated Domain-Set indicates that (S,G) is originated inside 7418 a PIM-SM Domain and not a PIM-NG domain, then the update 7419 received from the MSDP-PEER MUST pass the RPF check. 7421 o If a C-MAPPER receives an update from a peer C-MAPPER regarding 7422 sources that MUST be considered as SUSPENDED, the C-MAPPER MUST 7423 NOT send any SA message to MSDP-PEER'(s) until the suspension 7424 time is over and the multicast sources are either deleted or 7425 active again. 7427 o If a C-MAPPER loses its connectivity with its MSDP-PEER, it 7428 MUST start the suspension timer and send an update about the 7429 suspended multicast sources to peer C-MAPPER, and if after the 7430 suspension duration which defaults to 5 minutes, the connection 7431 with the MSDP-PEER is not established again, it MUST delete the 7432 received multicast sources from that MSPD-PEER and inform peer 7433 C-MAPPER'(s).or if it has been receiving updates regarding those 7434 sources from a peer C-MAPPER or MSDP-PEER it MUST put the 7435 received updates from those peers in it's a-MULTICAST MAPPING 7436 TABLE and inform its PEER'(s). 7438 o . 7440 4.8.2. PIM-SM compatibility and join/prune messages 7442 A PIM-NG multicast Domain is connected to a PIM-SM multicast Domain, 7443 using a PER or PPER to isolate the 2 multicast Domains and prevent 7444 the propagation of multicast introduction messages of PIM-NG Domain 7445 in to PIM-SM Domain and also to prevent the propagation of PIM-SM 7446 multicast traffic related to BSR[9] and RP'(s) within the PIM-SM 7447 domain. 7449 As mentioned in different parts of PIM-NG specifications, a PER or 7450 PPER which acts as boundary between a PIM-NG Multicast Domain and a 7451 PIM-SM Multicast Domain is called a BORDER-PIM-ROUTER(BPR). And the 7452 responsibility of exchanging join/prune messages between the 2 7453 Domains is on the BPR. But due to the fact that PIM-NG uses its own 7454 version of join/prune message which is different from that of PIM-SM 7455 in parts related to the Tree Root UNICAST ADDRESS, a BPR MUST modify 7456 the join/prune messages received from a PIM-SM Domain and likewise it 7457 MUST do the same when forwarding join/prune messages from a PIM-NG 7458 Domain to a PIM-SM Domain. 7460 Bellow specifications, concepts and rules apply when a join/prune 7461 message is forwarded from a PIM-NG domain to a PIM-SM domain and 7462 likewise from a PIM-SM Domain to a PIM-NG Domain: 7464 o If a PER is chosen to act as a BPR, then as soon as the PER is 7465 configured and becomes aware that it is connected to a PIM-SM 7466 Multicast Domain, it MUST introduce itself to the closest C- 7467 MAPPER within the PIM-NG Multicast Domain. The BPR introduction 7468 is done by the PER and through sending a unicast-encapsulated 7469 introduction message (4.6.1.2. ) to the closest C-MAPPER or any 7470 C-MAPPER that is introduced to the PER. The type of the 7471 introduction message is set to BPR, and the B-BIT in the 7472 introduction message MUST BE set which indicates to the 7473 receiving C-MAPPER that it's Domain is connected to a PIM-SM 7474 Domain and it MUST start sending the full AMMT to the PER. 7476 o If a PPER is chosen to act as BPR the introduction process as 7477 the BPR is not needed due to the fact that the PPER MUST 7478 introduce itself to the closest C-MAPPER or any C-MAPPER that is 7479 introduced to it as soon as it is configured to be a PPER. 7481 o A BPR has 2 types of interfaces: 7483 1. Internal: an internal interface is connected to the PIM- 7484 NG Domain. 7486 2. External: an external interface is connected to the PIM- 7487 SM Domain. 7489 o A BPR MUST convert any PIM-NG join/prune messages for (S,G) it 7490 receives from within the PIM-NG Domain or better to say on an 7491 internal interface to a PIM-SM join/prune message, before 7492 forwarding it on an external interface which is connected to a 7493 PIM-SM Domain. The conversion process is not time consuming, due 7494 to the fact that the PIM-NG join/prune messages are designed to 7495 be similar to PIM-SM join/prune messages as much as possible. 7497 o A BPR MUST convert the join/prune messages it receives on an 7498 external interface connected to a PIM-SM Domain, ONLY under 7499 these conditions: 7501 1. At least one TR MUST do exist in the PIM-NG Domain. 7503 2. If no TR exists inside the PIM-NG Domain, then For each 7504 (S,G) in the join/prune message, the BPR MUST first check 7505 it's AMMT which it receives from the C-MAPPER'(s) inside 7506 the PIM-NG Domain. And ONLY IF: 7508 o It finds an entry inside the AMMT for the (S,G). 7510 o The Domain-Set associated with the (S, G) indicates 7511 that the (S, G) is reachable via a connected PIM-NG- 7512 CORE-DOMAIN, or better to say the update regarding 7513 the (S,G) is passed through a PIM-NG-CORE-DOMAIN. 7515 The BPR MUST convert the PIM-SM join/prune message to PIM-NG 7516 join/prune message, and fill out the required fields related 7517 to the TR UNICAST ADDRESS and CORE TR UNICAST ADDRESS. 7519 o If none of the above conditions are meat, PIM-NG specifications 7520 STRONGLY ADVISES that the BPR DO NOT convert the PIM-SM 7521 join/prune message and only forward it to the next hop in the 7522 best path towards the source. 7524 o The above being said, ALL PIM-NG-AWARE routers MUST BE PIM-SM 7525 Compatible in parts mostly related to forwarding join/prune 7526 messages. 7528 o if a BPR receives a join/prune message for (G) on an external 7529 interface connected to PIM-SM with the S-BIT of SOURCE UNICAST 7530 ADDRESS being set, which means that the join/prune is a PIM 7531 version 1 type of message it MUST NOT convert the PIM-SM 7532 join/prune to PIM-NG join/prune. 7534 4.9. Loop prevention 7536 In order to have a loop free multicast domain PIM-NG suggest the use 7537 of Reverse Path Forwarding check(RPF)to prevent any loops from 7538 occurring. 7540 Such loops can be under one of the bellow categories: 7542 o C-MAPPER multicast introduction or notification messages 7543 destined to 239.0.1.190 and sent to ALL-PIM-NG-AWARE routers 7544 within a multicast domain. 7546 o C-MAPPER multicast introductions destined to 239.0.1.188 which 7547 is used by existing C-MAPPER'(s) to find either a backup or peer 7548 C-MAPPER. 7550 o C-RP multicast introductions destined to 239.0.1.189 which is 7551 used by existing C-RP'(s) to find either a backup or peer C-RP. 7553 o Loops occurring due to a join/prune message which is sent hop 7554 by hop towards an existing source by a client which needs to 7555 join the SPT for (S, G) in scenarios which clients are connected 7556 to each other through switches and within a LAN. 7558 To eliminate and prevent such loops PIM-NG uses the RPF check method 7559 and concept used by PIM-SM which is the best current practice. And 7560 since no shared tree (*, G, rpt) rooted at RP forms in PIM-NG there 7561 won't be any need for such RPF check although since PIM-NG-AWARE 7562 routers are by default PIM-SM compatible it MUST be considered. 7564 The bellow rules MUST be applied to prevent any loops by the unwanted 7565 propagation of such multicast introductions: 7567 o PIM-NG boundary routers such as PER, PPER, BPR or EDGE- 7568 CLIENT'(S) MUST NOT forward such introduction messages to 7569 other domain'(s) in case of PER, PPER and BPR and down the 7570 MULTI-ACCESS network in case of EDGE-CLIENT'(S). 7572 o C-MAPPER'(S) which receive an introduction message destined to 7573 either 239.0.1.190 or 239.0.1.188 with the source address 7574 being equal to C-MAPPER'(s) address MUST discard the packet 7575 and NOT forward any further. 7577 o C-RP'(S) which receive an introduction message destined to 7578 either 239.0.1.189 with the source address being equal to C- 7579 MAPPER'(s) address MUST discard the packet and NOT forward any 7580 further. 7582 4.10. DR election and PIM Assert Message 7584 PIM-NG specifications suggest using the processes and concepts 7585 introduced and defined by PIM-SM [7] with regards to Assert messages 7586 and DR election as the best current practice when dealing with 7587 scenarios and topologies involving multi-access LAN'(s). 7589 The only place that the DR election is different from that of PIM-SM 7590 is in implementations and topologies in which EDGE-CLIENT'(s) are 7591 considered at the edge of a multi-access network which allows the 7592 administrators to dictate the DR for the Multi-Access network by 7593 manipulating the priority of Edge-Clients. So the Edge-Client with 7594 higher priority becomes the DR for the entire Multi-Access network. 7596 5. Security Considerations 7598 This section is going to cover some of the security concerns related 7599 to PIM-NG specifications covered in this document, and possible 7600 solutions for those security issues. As this document is an earlier 7601 version of PIM-NG specifications, only related security issues are 7602 going to be covered. 7604 5.1. Attacks based on forged messages 7606 The extent of possible damages depends on the type of messages that 7607 are forged. PIM-NG processes use different kinds of messages like 7608 link-local messages, multicast messages and unicast messages. And 7609 each type of message will be discussed separately. 7611 5.1.1. Unicast forged messages 7613 As Register, join and leave messages alongside C-RP introduction 7614 messages sent to C-MAPPER are forwarded by intermediate routers to 7615 their destination using normal IP forwarding, without authentication 7616 there is a high possibility for an attacker anywhere inside the 7617 network, to forge these messages .the effects of such forgery can be 7618 as follows: 7620 1- By forging a register message an attacker can inject forged 7621 traffic into the RP and to the entire PIM-NG domain. 7623 2- By forging join message ,an attacker may become able to act as the 7624 man in the middle and receive a traffic that is not meant for that 7625 receiver .or traffic can be delivered to parts of the network that 7626 no legitimate receivers exists ,which can cause waste of bandwidth. 7628 3- By forging leave message, an attacker can prevent a legitimate 7629 receiver from receiving the traffic it needs. 7631 4- By forging a C-RP introduction message sent to the C-MAPPER, an 7632 attacker can become a real threat to the entire domain, by 7633 injecting false information to the domain. 7635 5- By forging a TR introduction message sent to C-MAPPER, an attacker 7636 can become a real threat to the domain, by becoming a man in the 7637 middle and receive a copy of all the multicast traffic that is 7638 passing through the TR or by dropping the received join/prunes 7639 which can cause the connectivity problems. 7641 5.1.2. Forged link local messages 7643 As Forged Hello messages are sent to link-local ALL-PIM-ROUTERS and 7644 are not forwarded by the compliant router, they can cause problems 7645 such as: 7647 1- If the source of forged message is inside a Multi-access LAN or to 7648 be more specific a local client, it can give an attacker the 7649 possibility of playing the role of an EDGE-CLIENT, and prevent the 7650 legitimate receivers from receiving the desired traffic or reaching 7651 the desired sources. 7653 2- By forging a Hello message an unauthorized client may become able 7654 to play the role of designated router (DR) for a LAN and become 7655 responsible for forwarding traffic on behalf of local members or 7656 hosts. This can prevent hosts from receiving the desired traffic. 7658 3- By forging a Hello message, an unauthorized router in a PIM-NG 7659 domain can become part of the domain and cause damages such as 7660 preventing its neighbors from receiving C-MAPPER introductions or 7661 injecting false information inside the PIM domain topology table. 7663 5.1.3. Forged multicast messages 7665 C-MAPPER introduction messages sent to ALL-PIM-NG clients , MAPPER 7666 introduction messages sent to ALL-PIM-NG-MAPPERs in order to finding 7667 the PEER-C_MAPPERs or SC-MAPPERs and C-RP introduction messages sent 7668 to ALL-PIM-NG-RPs are PIM-NG multicast messages required for the 7669 processes of PIM-NG. But an attacker might become able to forge such 7670 messages and cause damages. The damages that can be done to a PIM-NG 7671 domain are as follows: 7673 1- By forging a C-MAPPER introduction message sent to ALL-PIM-NG- 7674 CLIENTS (239.0.1.190), an attacker can inject false information in 7675 to the domain, by either injecting false data into the PIM domain 7676 topology table. 7678 2- By forging a C-MAPPER introduction message sent to ALL-PIM-NG- 7679 CLIENTS, an attacker can take the role of C-MAPPER and introduce 7680 itself to C-RPs and finally , can cause the clients not to be able 7681 to find the existing C-RPs , and prevent them from receiving the 7682 desired traffic. 7684 3- By forging MAPPER introduction message sent to ALL-PIM-MAPPERs ,an 7685 attacker can become able to take the role of ACTIVE C-MAPPER in the 7686 process of ACTIVE-C-MAPPER election, and also become peer with 7687 other C-MAPPER'(s) and cause damage to the domain by injecting 7688 false data into the A-MULTCAST MAPPING table. 7690 4- By forging RP introduction message sent to ALL-PIM-RPs, an 7691 attacker can be able to take the role of C-RP in the process of C- 7692 RP election or become the ACTIVE C-RP in a C-RP Mesh-Group and also 7693 become peer with other existing C-RP'(s) in search of its peer and 7694 cause problems by injecting false data in to either MULTICAST 7695 MAPPING table or A-MULTICAST MAPPING TABLE. And preventing 7696 legitimate receivers from receiving the desired traffic. 7698 5.2. Non-cryptographic authentication mechanisms 7700 A PIM-NG router should provide an option to limit the set of 7701 neighbors from which it accepts join/prune, Assert, and hello 7702 messages, by either static configuration of IP addresses or an IPSEC 7703 security association CAN be used. And a PIM-NG router should not 7704 accept protocol messages from a router from which it has not yet 7705 received a valid hello message. Also a PIM-NG router SHOULD NOT 7706 accept any hello message from a router that is not within the same 7707 PIM-NG Domain unless it is a PIM-EDGE-ROUTER acting as the boundary 7708 between different PIM-NG Domains. 7710 A Designated Router MUST NOT register-encapsulate a packet and send 7711 it to the C-RP if the source address of the packet is not a legal 7712 address for the subnet on which the packet was received. Similarly, a 7713 PIM EDGE-CLIENT MUST NOT accept a register message from its 7714 downstream PIM-NG Clients, if the source address of the register 7715 message is not a legal address for the subnet on which the register 7716 message is received. 7718 A Designated Router MUST NOT accept a C-RP acknowledge packet whose 7719 IP source address is not a valid C-RP address for the local Domain. 7720 Similarly, a PIM EDGE-CLIENT MUST NOT accept a C-RP acknowledge 7721 packet whose IP source address is not a valid C-RP address for the 7722 local Domain. 7724 A mechanism MUST be considered as an option so that a C-RP restricts 7725 the range of source addresses from which it accepts Register- 7726 Encapsulated packets. Also it is STRONGLY advised to consider a 7727 mechanism through which a C-RP restricts the range of source 7728 addresses from which it accepts C-MAPPER or C-RP introduction 7729 messages, so that a possible attacker cannot send such messages or 7730 such messages from unknown ranges are not accepted. Also as explained 7731 throughout PIM-NG specifications a C-RP MUST NOT accept source 7732 register, C-RP, C-MAPPER messages with different Domain number from 7733 the one dictated to the C-RP. 7735 A mechanism MUST be considered as an option so that a C-MAPPER 7736 restricts the range of source addresses from which it accepts 7737 unicast-encapsulated C-MAPPER, C-RP, PER, PPER, and TR messages 7738 within the same Domain, due to the fact that if dynamic methods 7739 explained by PIM-NG specifications are used if this ranges are not 7740 restricted an attacker may try to introduce itself to the C-MAPPER as 7741 a legitimate component of a PIM-NG Domain. As explained throughout 7742 the PIM-NG specifications, a C-MAPPER MUST ONLY accept C-RP, TR, PER 7743 and PPER introduction messages that carry the same Domain number as 7744 the Domain number dictated to the C-MAPPER. 7746 All options that restrict the range of addresses from which packets 7747 are accepted MUST default to allowing all packets. 7749 5.3. Authentication 7751 Like PIM-SM [7], PIM-NG specifications recommends to use IPSEC [4] 7752 transport mode using the Authentication Header (AH) to prevent the 7753 above attacks against PIM. 7755 The proposed methods of protecting: 7757 o Link-Local Multicast Messages 7759 o Unicast register messages 7761 By PIM-NG, are the methods recommended by PIM-SM Specifications [7] 7762 as the best current method of protecting the above PIM messages. 7764 Since PIM-NG uses processes different from that of PIM-SM in parts 7765 related to: 7767 o The unicast C-RP acknowledge to the DR instead of sending 7768 register stop message. 7770 o Unicast introduction messages, sent from C-RP to C-MAPPER. 7772 o Unicast introduction messages, sent between the C-RPs. 7774 o Unicast introduction messages, sent between the C-MAPPERs. 7776 o Unicast introduction messages, sent from BPR, PPER, and any 7777 existing TR to C-MAPPER. 7779 o Unicast introduction messages, sent between existing TRs. 7781 a mechanism MUST BE taken in to consideration to protect such 7782 messages. 7784 With the above being said, PIM-NG recommends to use, the Register 7785 Message protection method and Register-Stop protection mechanism 7786 recommended by PIM-SM[7] which is considered the best current method 7787 of protecting unicast Messages. 7789 5.3.1. Protecting Multicast Introduction Message 7791 One important security threat to a PIM Domain that is not covered is 7792 related to the multicast messages sent from a C-MAPPER to all PIM-NG 7793 routers which is similar to the process related to BSR[9]. since when 7794 in a PIM Domain the dynamic methods of finding RP (PIM-SM), C-RP 7795 (PIM-NG) are in use, the multicast messages sent from a C-MAPPER or 7796 BSR play the main role in the process of introducing existing C-RP or 7797 RP to all PIM-NG or PIM-SM routers, a mechanism MUST be taken in to 7798 consideration so that a PIM-NG CLIENT or simply put a PIM router 7799 doesn't accept an unauthorized C-MAPPER introduction message. 7801 in order to protect such a message, PIM-NG recommends that an SA and 7802 SPI be defined on existing legitimate C-MAPPERs and on all PIM-NG 7803 routers by the network administrator to authenticate such multicast 7804 messages. So if an unauthorized C-MAPPER multicast introduction 7805 message is received by the first PIM-NG-AWARE router, it will be 7806 rejected (dropped without process) and won't be forwarded any 7807 further. 7809 5.4. Denial-Of-Service attacks 7811 There are number of denial-of-service attacks against PIM-NG that can 7812 be caused by generating false PIM-NG protocol messages or false 7813 traffic. Using the authentication methods can prevent some, but not 7814 all, of these attacks. Some of the most possible attacks are: 7816 o Sending packets to many different group addresses quickly can 7817 be considered a denial-of-attack, which can cause many register 7818 packets, loading the DR, the C-RP, the C-MAPPERs when more than 7819 one C-MAPPER exists and finally the routers between these 7820 components. 7822 o Many forged join messages can cause many multicast trees to be 7823 set up and consume network resources. 7825 o With regards to PIM-NG, many forged join messages can cause 7826 many Request For Source messages that will be sent from a CLIENT 7827 to the C-RP, and can be considered a denial of service attack. 7829 To reduce the possibility of the creation of unwanted register 7830 messages, if applicable, PIM-NG specifications STRONGLY suggest using 7831 the STUB-DOMAIN concept (4.5.6) in Domains that no multicast source 7832 is supposed to exist. 7834 6. IANA Considerations 7836 6.1. PIM-NG multicast destination group addresses 7838 PIM-NG processes require to use 3 multicast addresses from the 7839 internetwork control block (RFC 5771[2]).for the simplicity of 7840 explanation process in this documents these 3 addresses are chosen 7841 from the scoped multicast ranges. The addresses are needed for the 7842 bellow processes: 7844 o Destination group address used for C-MAPPER introduction 7845 process. The multicast introduction message is sent to ALL-PIM- 7846 NG routers. 7848 o Destination group address used for C-MAPPER introduction 7849 process so that C-MAPPERs can find each other dynamically. The 7850 multicast introduction message is sent to ALL-PIM-NG C-MAPPERs. 7852 o Destination group address used for C-RP introduction process so 7853 that C-RPs can find each other dynamically. The multicast 7854 introduction message is sent to ALL-PIM-NG C-RPs. 7856 These addresses are needed to be assigned by IANA after this document 7857 is approved. 7859 6.2. PIM-NG packets and values of type field 7861 New type values in PIM-NG packet header and new packet formats 7862 designed specifically for PIM-NG to support the needs of the 7863 different processes of PIM-NG, and will need to be reviewed by the 7864 experts and assignments need to be made. 7866 6.3. PIM-NG Domain numbers 7868 The PIM-NG Domain number field is considered as a 32 bit field to 7869 support the future needs of multicasting, in regards to PIM-NG 7870 Multicast Protocol. 7872 Domain Number (4.6.1.1) has a vital role in PIM-NG processes and 7873 functionality, which provides the possibility of using Sub-Domain 7874 concept as a security feature. Also it MUST BE noted that through 7875 using the Domain numbers, PIM-NG is able to use a unique RPF method 7876 and a simple multicast domain isolation and separation method, which 7877 provides many features in comparison to the previous versions of PIM 7878 protocol. 7880 CORE-DOMAIN assignments are needed to be done by IANA as the 7881 controlling entity, so that, no conflict can happen as explained 7882 throughout this document. 7884 7. Conclusions 7886 PIM-NG is a multicast protocol that , although may seem to have lots 7887 of features compared to previous protocols like PIM-SM, but through 7888 its many features and processes, provides a robust and sound control 7889 over the propagation of the information regarding the existing 7890 multicast sources. Its processes are enhanced, so that a host in 7891 search of the source of a multicast traffic can communicate with the 7892 desired source as fast as possible, by eliminating the need to 7893 necessarily join the RPT rooted at an RP within a multicast domain. 7895 Also duo to its unique method of RPF check provides the ability of 7896 implementing transitory multicast domains which was not implementable 7897 before. And because of using the Domain concept provides many 7898 features in parts related to security and controlling over the 7899 propagation of multicast information inside a PIM-NG multicast 7900 Domain. 7902 8. References 7904 8.1. Normative References 7906 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 7907 Levels", BCP 14, RFC 2119, March 1997. 7909 [2] Cotton, M., L. Vegoda and D. Meyer, "IANA Guidelines for IPV4 7910 Multicast Address Assignments", RFC 5771, March 2010. 7912 [3] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 7913 Thyagarajan, "Internet Group Management Protocol, version 3", 7914 RFC 3376, October 2002. 7916 [4] Kent, S. and K. Seo, "Security Architecture for the Internet 7917 Protocol", RFC 4301, December 2005. 7919 [5] Narten, T. and H. Alvetrand, "Guildlines for Writing an IANA 7920 considerations section in RFCs", BCP 26, RFC 5226, May 2008. 7922 [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 7923 RFC 4607, August 2006. 7925 8.2. Informative References 7927 [7] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 7928 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 7929 Protocol Specification (Revised)", RFC 4601, August 2006. 7931 [8] Fenner, B. and D. Meyer, "Multicast Source Discovery 7932 Protocol (MSDP)", RFC 3618, October 2003. 7934 [9] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap 7935 Router (BSR) Mechanism for PIM Sparse Mode", Work in Progress, 7936 May 2006. 7938 [10] Hardjono, T. and B. Weis, "The Multicast Group Security 7939 Architecture", RFC 3740, March 2004. 7940 [11] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 7941 "Bidirectional Protocol Independent Multicast" (BIDIR-PIM), RFC 7942 5015, October 2007. 7944 [12] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 7945 Rendezvous Point (RP) mechanism using Protocol Independent 7946 Multicast (PIM) and Multicast Source Discovery Protocol 7947 (MSDP)", RFC 3446, January 2003. 7948 [13] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent 7949 Multicast - Sparse Mode (PIM-SM) Multicast Routing Security 7950 Issues and Enhancements", RFC 4609, August 2006. 7952 9. Acknowledgments 7954 The author would like to thank Mr.Reza Izadi for his review and kind 7955 comments, corrections and support throughout the process of designing 7956 and writing different concepts of PIM-NG Multicast Protocol. Also the 7957 author would like to thank Mr.Stig Venas for his review and comments 7958 which helped to make this draft complete. 7960 This document was prepared using 2-Word-v2.0.template.dot. 7962 Authors' Addresses 7964 Saeed Sami 7965 P.O.BOX 1466955316 7966 Unit.2 7967 No.44 th Saadatabad 27 .St 7968 Khovardin.Blvd 7969 Sanat.SQ 7970 Tehran. Iran 7972 Phone: +989123844205 7973 Email: sami@ssami.biz 7974 sami@ragsa.ir 7975 sami.biz.email@gmail.com