| < draft-ietf-pim-dm-new-v2-04.txt | draft-ietf-pim-dm-new-v2-05.txt > | |||
|---|---|---|---|---|
| Internet Engineering Task Force PIM WG | Internet Engineering Task Force PIM WG | |||
| INTERNET DRAFT Andrew Adams (NextHop Technolgies) | INTERNET DRAFT Andrew Adams (NextHop Technolgies) | |||
| draft-ietf-pim-dm-new-v2-04.txt Jonathan Nicholas (ITT A/CD) | draft-ietf-pim-dm-new-v2-05.txt Jonathan Nicholas (ITT A/CD) | |||
| William Siadak (NextHop Technologies) | William Siadak (NextHop Technologies) | |||
| September 2003 | June 2004 | |||
| Expires March 2004 | Expires December 2004 | |||
| Protocol Independent Multicast - Dense Mode (PIM-DM): | Protocol Independent Multicast - Dense Mode (PIM-DM): | |||
| Protocol Specification (Revised) | Protocol Specification (Revised) | |||
| Status of this Document | Status of this Document | |||
| This document is an Internet Draft and is in full conformance with all | This document is an Internet Draft and is in full conformance with all | |||
| provisions of Section 10 of RFC 2026. | provisions of Section 10 of RFC 2026. | |||
| Internet Drafts are working documents of the Internet Engineering Task | Internet Drafts are working documents of the Internet Engineering Task | |||
| skipping to change at page 1, line 33 ¶ | skipping to change at page 1, line 34 ¶ | |||
| time. It is inappropriate to use Internet Drafts as reference material | time. It is inappropriate to use Internet Drafts as reference material | |||
| or to cite them other than as "work in progress." | or to cite them other than as "work in progress." | |||
| The list of current Internet Drafts can be accessed at | The list of current Internet Drafts can be accessed at | |||
| http://www.ietf.org/ietf/lid-abstracts.txt. | http://www.ietf.org/ietf/lid-abstracts.txt. | |||
| The list of Internet Draft Shadow Directories can be accessed at | The list of Internet Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This document is a product of the IETF PIM WG. Comments should be | This document is a product of the IETF PIM WG. Comments should be | |||
| addressed to the authors, or the WG's mailing list at | addressed to the authors, or the WG's mailing list at pim@ietf.org. | |||
| pim@catarina.usc.edu. | ||||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| Abstract | Abstract | |||
| This document specifies Protocol Independent Multicast - Dense Mode | This document specifies Protocol Independent Multicast - Dense Mode | |||
| (PIM-DM). PIM-DM is a multicast routing protocol that uses the | (PIM-DM). PIM-DM is a multicast routing protocol that uses the | |||
| underlying unicast routing information base to flood multicast datagrams | underlying unicast routing information base to flood multicast datagrams | |||
| to all multicast routers. Prune messages are used to prevent future | to all multicast routers. Prune messages are used to prevent future | |||
| messages from propagating to routers with no group membership | messages from propagating to routers with no group membership | |||
| information. | information. | |||
| skipping to change at page 3, line 22 ¶ | skipping to change at page 1, line 118 ¶ | |||
| 5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . 48 | 5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . 48 | |||
| 5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . 49 | 5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . 49 | |||
| 5.3. Source Specific Multicast (SSM) Interactions . . . . . . . . 49 | 5.3. Source Specific Multicast (SSM) Interactions . . . . . . . . 49 | |||
| 5.4. Multicast Group Scope Boundary Interactions . . . . . . . . 49 | 5.4. Multicast Group Scope Boundary Interactions . . . . . . . . 49 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 | |||
| 6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . 49 | 6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . 49 | |||
| 6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . 50 | 6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . 50 | |||
| 7. Security Considerations. . . . . . . . . . . . . . . . . . . 50 | 7. Security Considerations. . . . . . . . . . . . . . . . . . . 50 | |||
| 7.1. Attacks Based on Forged Messages . . . . . . . . . . . . . . 50 | 7.1. Attacks Based on Forged Messages . . . . . . . . . . . . . . 50 | |||
| 7.2. Non-cryptographic Authentication Mechanisms . . . . . . . . 51 | 7.2. Non-cryptographic Authentication Mechanisms . . . . . . . . 51 | |||
| 7.3. Authentication Using IPsec . . . . . . . . . . . . . . . . . 51 | 7.3. Authentication Using IPsec . . . . . . . . . . . . . . . . . 52 | |||
| 7.4. Denial of Service Attacks . . . . . . . . . . . . . . . . . 52 | 7.4. Denial of Service Attacks . . . . . . . . . . . . . . . . . 53 | |||
| 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 | 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 | |||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 54 | ||||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . . 54 | ||||
| 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 55 | ||||
| 1. Introduction | 1. Introduction | |||
| This specification defines a multicast routing algorithm for multicast | This specification defines a multicast routing algorithm for multicast | |||
| groups that are densely distributed across a network. This protocol | groups that are densely distributed across a network. This protocol | |||
| does not have a topology discovery mechanism often used by a unicast | does not have a topology discovery mechanism often used by a unicast | |||
| routing protocol. It employs the same packet formats sparse mode PIM | routing protocol. It employs the same packet formats sparse mode PIM | |||
| (PIM-SM) uses. This protocol is called PIM - Dense Mode. The | (PIM-SM) uses. This protocol is called PIM - Dense Mode. The | |||
| foundation of this design was largely built on Deering's early work on | foundation of this design was largely built on Deering's early work on | |||
| IP multicast routing [1]. | IP multicast routing [11]. | |||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be | |||
| interpreted as described in RFC 2119 and indicate requirement levels for | interpreted as described in RFC 2119 and indicate requirement levels for | |||
| compliant PIM-DM implementations. | compliant PIM-DM implementations. | |||
| 2.1. Definitions | 2.1. Definitions | |||
| skipping to change at page 5, line 18 ¶ | skipping to change at page 1, line 186 ¶ | |||
| A (+) B | A (+) B | |||
| is the union of two sets A and B. | is the union of two sets A and B. | |||
| A (-) B | A (-) B | |||
| are the elements of set A that are not in set B. | are the elements of set A that are not in set B. | |||
| NULL | NULL | |||
| is the empty set or list. | is the empty set or list. | |||
| Note that (+) and (-) operators are NOT commutative, and must be | Note that operations MUST be conducted in the order specified. This is | |||
| conducted in the order specified. | due to the fact that (-) is not a true difference operator because B is | |||
| not necessarily a subset of A. That is, A (+) B (-) C = A (-) C (+) B | ||||
| is not a true statement unless C is a subset of both A and B. | ||||
| In addition we use C-like syntax: | In addition we use C-like syntax: | |||
| = denotes assignment of a variable. | = denotes assignment of a variable. | |||
| == denotes a comparison for equality. | == denotes a comparison for equality. | |||
| != denotes a comparison for inequality. | != denotes a comparison for inequality. | |||
| Braces { and } are used for grouping. | Braces { and } are used for grouping. | |||
| 3. PIM-DM Protocol Overview | 3. PIM-DM Protocol Overview | |||
| skipping to change at page 6, line 13 ¶ | skipping to change at page 1, line 231 ¶ | |||
| mode protocols. | mode protocols. | |||
| In order to minimize repeated flooding of datagrams and subsequent | In order to minimize repeated flooding of datagrams and subsequent | |||
| pruning associated with a particular (S,G) pair, PIM-DM uses a state | pruning associated with a particular (S,G) pair, PIM-DM uses a state | |||
| refresh message. This message is sent by the router(s) directly | refresh message. This message is sent by the router(s) directly | |||
| connected to the source and is propagated throughout the network. When | connected to the source and is propagated throughout the network. When | |||
| received by a router on its RPF interface, the state refresh message | received by a router on its RPF interface, the state refresh message | |||
| causes an existing prune state to be refreshed. | causes an existing prune state to be refreshed. | |||
| Compared with multicast routing protocols with built in topology | Compared with multicast routing protocols with built in topology | |||
| discovery mechanisms (e.g. DVMRP [2]) PIM-DM has a simplified design and | discovery mechanisms (e.g. DVMRP [12]) PIM-DM has a simplified design | |||
| is not hard-wired into a specific topology discovery protocol. However, | and is not hard-wired into a specific topology discovery protocol. | |||
| such a simplification does incur more overhead by causing flooding and | However, such a simplification does incur more overhead by causing | |||
| pruning to occur on some links that could be avoided if sufficient | flooding and pruning to occur on some links that could be avoided if | |||
| topology information were available, i.e. to decide whether an interface | sufficient topology information were available, i.e. to decide whether | |||
| leads to any downstream members of a particular group. Additional | an interface leads to any downstream members of a particular group. | |||
| overhead is chosen in favor of the simplification and flexibility gained | Additional overhead is chosen in favor of the simplification and | |||
| by not depending on a specific topology discovery protocol. | flexibility gained by not depending on a specific topology discovery | |||
| protocol. | ||||
| PIM-DM differs from PIM-SM in two essential ways: 1) There are no | PIM-DM differs from PIM-SM in two essential ways: 1) There are no | |||
| periodic joins transmitted, only explicitly triggered prunes and grafts. | periodic joins transmitted, only explicitly triggered prunes and grafts. | |||
| 2) There is no Rendezvous Point (RP). This is particularly important in | 2) There is no Rendezvous Point (RP). This is particularly important in | |||
| networks that cannot tolerate a single point of failure. (An RP is the | networks that cannot tolerate a single point of failure. (An RP is the | |||
| root of a shared multicast distribution tree. For more details see [3]). | root of a shared multicast distribution tree. For more details see [4]). | |||
| 4. Protocol Specification | 4. Protocol Specification | |||
| The specification of PIM-DM is broken into several parts: | The specification of PIM-DM is broken into several parts: | |||
| * Section 4.1 details the protocol state stored. | * Section 4.1 details the protocol state stored. | |||
| * Section 4.2 specifies the data packet forwarding rules. | * Section 4.2 specifies the data packet forwarding rules. | |||
| * Section 4.3 specifies generation and processing of Hello messages. | * Section 4.3 specifies generation and processing of Hello messages. | |||
| * Section 4.4 specifies the Join, Prune and Graft generation and | * Section 4.4 specifies the Join, Prune and Graft generation and | |||
| processing rules. | processing rules. | |||
| skipping to change at page 22, line 43 ¶ | skipping to change at page 1, line 1042 ¶ | |||
| Prune(S,G) Downstream state machine on interface I MUST transition | Prune(S,G) Downstream state machine on interface I MUST transition | |||
| to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and | to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and | |||
| MUST be initialized to the received Prune_Hold_Time minus | MUST be initialized to the received Prune_Hold_Time minus | |||
| J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has | J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has | |||
| more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) | more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) | |||
| message multicast by the upstream router to a LAN with itself as the | message multicast by the upstream router to a LAN with itself as the | |||
| Upstream Neighbor. Its purpose is to add additional reliability so | Upstream Neighbor. Its purpose is to add additional reliability so | |||
| that if a Join that should have overridden the Prune is lost locally | that if a Join that should have overridden the Prune is lost locally | |||
| on the LAN, then the PruneEcho(S,G) may be received and trigger a | on the LAN, then the PruneEcho(S,G) may be received and trigger a | |||
| new Join message . A PruneEcho(S,G) is OPTIONAL on an interface | new Join message . A PruneEcho(S,G) is OPTIONAL on an interface | |||
| with only one PIM neighbor. In addition, the router MUST evaluate any | with only one PIM neighbor. In addition, the router MUST evaluate | |||
| possible transitions in the Upstream(S,G) state machine. | any possible transitions in the Upstream(S,G) state machine. | |||
| RPF_Interface(S) becomes interface I | RPF_Interface(S) becomes interface I | |||
| The upstream interface for S has changed. The Prune(S,G) Downstream | The upstream interface for S has changed. The Prune(S,G) Downstream | |||
| state machine on interface I MUST transition to the NoInfo (NI) | state machine on interface I MUST transition to the NoInfo (NI) | |||
| state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. | state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. | |||
| 4.4.2.3. Transitions from the Prune (P) State | 4.4.2.3. Transitions from the Prune (P) State | |||
| When the Prune(S,G) Downstream state machine is in the Pruned (P) state, | When the Prune(S,G) Downstream state machine is in the Pruned (P) state, | |||
| the following events may trigger a transition. | the following events may trigger a transition. | |||
| skipping to change at page 32, line 20 ¶ | skipping to change at page 1, line 1497 ¶ | |||
| Assert(S,G) to interface I, store its own address and metric as the | Assert(S,G) to interface I, store its own address and metric as the | |||
| Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time. | Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time. | |||
| Receive Preferred Assert or State Refresh | Receive Preferred Assert or State Refresh | |||
| The received Assert or State Refresh has a better metric than this | The received Assert or State Refresh has a better metric than this | |||
| router's and therefore the Assert state machine MUST transition to | router's and therefore the Assert state machine MUST transition to | |||
| the "I am Assert Loser" state and store the Assert Winner's address | the "I am Assert Loser" state and store the Assert Winner's address | |||
| and metric. If the metric was received in an Assert, the router MUST | and metric. If the metric was received in an Assert, the router MUST | |||
| set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was | set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was | |||
| received in a State Refresh, the router MUST set the Assert Timer | received in a State Refresh, the router MUST set the Assert Timer | |||
| (AT(S,G,I)) to three times the received State Refresh Interval. The | (AT(S,G,I)) to three times the received State Refresh Interval. If | |||
| router MUST also multicast a Prune(S,G) to the Assert winner with a | CouldAssert(S,G,I) == TRUE, the router MUST also multicast a | |||
| Prune Hold Time equal to the Assert Timer and evaluate any changes | Prune(S,G) to the Assert winner with a Prune Hold Time equal to the | |||
| in its Upstream(S,G) state machine. | Assert Timer and evaluate any changes in its Upstream(S,G) state | |||
| machine. | ||||
| 4.6.4.2. Transitions from Winner State | 4.6.4.2. Transitions from Winner State | |||
| When in "I am Assert Winner" state, the following events trigger | When in "I am Assert Winner" state, the following events trigger | |||
| transitions: | transitions: | |||
| An (S,G) data packet arrives on downstream interface I | An (S,G) data packet arrives on downstream interface I | |||
| An (S,G) data packet arrived on a downstream interface. The Assert | An (S,G) data packet arrived on a downstream interface. The Assert | |||
| state machine remains in the "I am Assert Winner" state. The router | state machine remains in the "I am Assert Winner" state. The router | |||
| MUST send an Assert(S,G) to interface I and set the Assert Timer | MUST send an Assert(S,G) to interface I and set the Assert Timer | |||
| skipping to change at page 34, line 40 ¶ | skipping to change at page 1, line 1617 ¶ | |||
| received, the router MUST respond with a GraftAck(S,G). | received, the router MUST respond with a GraftAck(S,G). | |||
| 4.6.5. Rationale for Assert Rules | 4.6.5. Rationale for Assert Rules | |||
| The following is a summary of the rules for generating and processing | The following is a summary of the rules for generating and processing | |||
| Assert messages. It is not intended to be definitive (the state | Assert messages. It is not intended to be definitive (the state | |||
| machines and pseudocode provide the definitive behavior). Instead it | machines and pseudocode provide the definitive behavior). Instead it | |||
| provides some rationale for the behavior. | provides some rationale for the behavior. | |||
| 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) | 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) | |||
| on behalf all downstream members. | on behalf of all downstream members. | |||
| 2. PIM messages are directed towards to the RPF' neighbor and not to the | 2. PIM messages are directed towards to the RPF' neighbor and not to the | |||
| regular RPF neighbor. | regular RPF neighbor. | |||
| 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) | 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) | |||
| directed to it initiates a new Assert negotiation so the downstream | directed to it initiates a new Assert negotiation so the downstream | |||
| router can correct its RPF'(S). | router can correct its RPF'(S). | |||
| 4. An Assert winner for (S,G) sends a cancelling assert when it is about | 4. An Assert winner for (S,G) sends a cancelling assert when it is about | |||
| to stop forwarding on an (S,G) entry. Example: if a router is being | to stop forwarding on an (S,G) entry. Example: if a router is being | |||
| taken down, then a canceling assert is sent. | taken down, then a canceling assert is sent. | |||
| 4.7. PIM Packet Formats | 4.7. PIM Packet Formats | |||
| All PIM-DM packets use the same format as PIM-SM packets. All PIM | All PIM-DM packets use the same format as PIM-SM packets. In the event | |||
| control messages have IP protocol number 103. All PIM-DM messages MUST | of a discrepancy, PIM-SM [4] should be considered the definitive | |||
| be sent with a TTL of 1. All PIM-DM messages except Graft and Graft Ack | specification. All PIM control messages have IP protocol number 103. | |||
| messages MUST be sent to the ALL-PIM-ROUTERS group. Graft messages | All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages | |||
| SHOULD be unicast to the RPF'(S). Graft Ack messages MUST be unicast to | except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS | |||
| the sender of the Graft. | group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack | |||
| messages MUST be unicast to the sender of the Graft. | ||||
| The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS | The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS | |||
| group is 'ff02::d'. | group is 'ff02::d'. | |||
| 4.7.1. PIM Header | 4.7.1. PIM Header | |||
| All PIM control messages have the following header: | All PIM control messages have the following header: | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| skipping to change at page 36, line 18 ¶ | skipping to change at page 1, line 1690 ¶ | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Addr Family | Encoding Type | Unicast Address | | Addr Family | Encoding Type | Unicast Address | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | |||
| Addr Family | Addr Family | |||
| The PIM Address Family of the 'Unicast Address' field of this address. | The PIM Address Family of the 'Unicast Address' field of this address. | |||
| Values of 0-127 are as assigned by the IANA for Internet Address | Values of 0-127 are as assigned by the IANA for Internet Address | |||
| Families in [6]. Values 128-250 are reserved to be assigned by the | Families in [9]. Values 128-250 are reserved to be assigned by the | |||
| IANA for PIM specific Address Families. Values 251-255 are designated | IANA for PIM specific Address Families. Values 251-255 are designated | |||
| for private use. As there is no assignment authority for this space, | for private use. As there is no assignment authority for this space, | |||
| collisions should be expected. | collisions should be expected. | |||
| Encoding Type | Encoding Type | |||
| The type of encoding used with a specific Address Family. The value | The type of encoding used with a specific Address Family. The value | |||
| '0' is reserved for this field, and represents the native encoding of | '0' is reserved for this field, and represents the native encoding of | |||
| the Address Family | the Address Family | |||
| Unicast Address | Unicast Address | |||
| skipping to change at page 36, line 51 ¶ | skipping to change at page 1, line 1723 ¶ | |||
| | Group Multicast Address | | Group Multicast Address | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | |||
| Addr Family | Addr Family | |||
| As described above. | As described above. | |||
| Encoding Type | Encoding Type | |||
| As described above. | As described above. | |||
| B | B | |||
| Indicates the group range should use Bidirectional PIM [14]. | Indicates the group range should use Bidirectional PIM [16]. | |||
| Transmitted as zero, ignored upon receipt. | Transmitted as zero, ignored upon receipt. | |||
| Reserved | Reserved | |||
| Transmitted as zero. Ignored upon receipt. | Transmitted as zero. Ignored upon receipt. | |||
| Z | Z | |||
| Indicates the group range is an admin scope zone. This is used in the | Indicates the group range is an admin scope zone. This is used in the | |||
| Bootstrap Router Mechanism [15] only. For all other purposes, this bit | Bootstrap Router Mechanism [18] only. For all other purposes, this bit | |||
| is set to zero and ignored on receipt. | is set to zero and ignored on receipt. | |||
| Mask Len | Mask Len | |||
| The mask length field is 8 bits. The value is the number of | The mask length field is 8 bits. The value is the number of | |||
| contiguous on bits left justified used as a mask, which combined with | contiguous on bits left justified used as a mask, which combined with | |||
| the address, describes a range of addresses. It is less than or equal | the address, describes a range of addresses. It is less than or equal | |||
| to the address length in bits for the given Address Family and | to the address length in bits for the given Address Family and | |||
| Encoding Type. If the message is sent for a single address then the | Encoding Type. If the message is sent for a single address then the | |||
| mask length MUST equal the address length. PIM-DM routers MUST only | mask length MUST equal the address length. PIM-DM routers MUST only | |||
| send for a single address. | send for a single address. | |||
| skipping to change at page 38, line 10 ¶ | skipping to change at page 1, line 1786 ¶ | |||
| Mask Len | Mask Len | |||
| As described above. PIM-DM routers MUST only send for a single | As described above. PIM-DM routers MUST only send for a single | |||
| source address. | source address. | |||
| Source Address | Source Address | |||
| The source address. | The source address. | |||
| 4.7.5. Hello Message Format | 4.7.5. Hello Message Format | |||
| The PIM Hello message has the following format: | The PIM Hello message, as defined by PIM-SM [4], has the following | |||
| format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |PIM Ver| Type | Reserved | Checksum | | |PIM Ver| Type | Reserved | Checksum | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Option Type | Option Length | | | Option Type | Option Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Option Value | | | Option Value | | |||
| | ... | | | ... | | |||
| skipping to change at page 38, line 49 ¶ | skipping to change at page 1, line 1826 ¶ | |||
| 1 Hello Hold Time | 1 Hello Hold Time | |||
| 2 LAN Prune Delay | 2 LAN Prune Delay | |||
| 3-16 Reserved | 3-16 Reserved | |||
| 17 To be assigned by IANA | 17 To be assigned by IANA | |||
| 18 Deprecated and SHOULD NOT be used | 18 Deprecated and SHOULD NOT be used | |||
| 19 DR Priority (PIM-SM Only) | 19 DR Priority (PIM-SM Only) | |||
| 20 Generation ID | 20 Generation ID | |||
| 21 State Refresh Capable | 21 State Refresh Capable | |||
| 22 Bidir Capable | 22 Bidir Capable | |||
| 23-65000 To be assigned by IANA | 23-65000 To be assigned by IANA | |||
| 65001-65535 Reserved for Private Use [7] | 65001-65535 Reserved for Private Use [9] | |||
| Unknown options SHOULD be ignored. | Unknown options SHOULD be ignored. | |||
| 4.7.5.1. Hello Hold Time Option | 4.7.5.1. Hello Hold Time Option | |||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Type = 1 | Length = 2 | | | Type = 1 | Length = 2 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Hold Time | | | Hold Time | | |||
| skipping to change at page 40, line 37 ¶ | skipping to change at page 1, line 1896 ¶ | |||
| | Version = 1 | Interval | Reserved | | | Version = 1 | Interval | Reserved | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| The Interval field is the router's configured State Refresh Interval in | The Interval field is the router's configured State Refresh Interval in | |||
| seconds. The Reserved field is set to zero and ignored upon reception. | seconds. The Reserved field is set to zero and ignored upon reception. | |||
| The State Refresh Capable option MUST be used by State Refresh capable | The State Refresh Capable option MUST be used by State Refresh capable | |||
| PIM-DM routers. | PIM-DM routers. | |||
| 4.7.6. Join/Prune Message Format | 4.7.6. Join/Prune Message Format | |||
| PIM Join/Prune messages have the following format: | PIM Join/Prune messages, as defined in PIM-SM [4], have the following | |||
| format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |PIM Ver| Type | Reserved | Checksum | | |PIM Ver| Type | Reserved | Checksum | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Upstream Neighbor Address (Encoded Unicast Format) | | | Upstream Neighbor Address (Encoded Unicast Format) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Reserved | Num Groups | Hold Time | | | Reserved | Num Groups | Hold Time | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 42, line 42 ¶ | skipping to change at page 1, line 1995 ¶ | |||
| in section 4.7.4. | in section 4.7.4. | |||
| Prune Source Address 1..n | Prune Source Address 1..n | |||
| This list contains the sources from which the sending router does not | This list contains the sources from which the sending router does not | |||
| wish to receive multicast messages for the given group on this | wish to receive multicast messages for the given group on this | |||
| interface. The addresses use the Encoded Source address format given | interface. The addresses use the Encoded Source address format given | |||
| in section 4.7.4. | in section 4.7.4. | |||
| 4.7.7. Assert Message Format | 4.7.7. Assert Message Format | |||
| PIM Assert Messages have the following format: | PIM Assert Messages, as defined in PIM-SM [4], have the following | |||
| format: | ||||
| 0 1 2 3 | 0 1 2 3 | |||
| 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 | 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| |PIM Ver| Type | Reserved | Checksum | | |PIM Ver| Type | Reserved | Checksum | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Multicast Group Address (Encoded Group Format) | | | Multicast Group Address (Encoded Group Format) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Source Address (Encoded Unicast Format) | | | Source Address (Encoded Unicast Format) | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 44, line 39 ¶ | skipping to change at page 1, line 2082 ¶ | |||
| Multicast Group Address | Multicast Group Address | |||
| The multicast group address in the Encoded Multicast address format | The multicast group address in the Encoded Multicast address format | |||
| given in section 4.7.3. | given in section 4.7.3. | |||
| Source Address | Source Address | |||
| The address of the data source in the Encoded Unicast address format | The address of the data source in the Encoded Unicast address format | |||
| given in section 4.7.2. | given in section 4.7.2. | |||
| Originator Address | Originator Address | |||
| The address of the first hop router in the Encoded Source address | The address of the first hop router in the Encoded Unicast address | |||
| format given in section 4.7.4. | format given in section 4.7.2. | |||
| R | R | |||
| The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon | The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon | |||
| receipt. | receipt. | |||
| Metric Preference | Metric Preference | |||
| The preference value assigned to the unicast routing protocol that | The preference value assigned to the unicast routing protocol that | |||
| provided the route to the source. | provided the route to the source. | |||
| Metric | Metric | |||
| skipping to change at page 48, line 32 ¶ | skipping to change at page 1, line 2278 ¶ | |||
| 5. Protocol Interaction Considerations | 5. Protocol Interaction Considerations | |||
| PIM-DM is designed to be independent of underlying unicast routing | PIM-DM is designed to be independent of underlying unicast routing | |||
| protocols and will interact only to the extent needed to perform RPF | protocols and will interact only to the extent needed to perform RPF | |||
| checks. It is generally assumed that multicast area and autonomous | checks. It is generally assumed that multicast area and autonomous | |||
| system boundaries will correspond to the same boundaries for unicast | system boundaries will correspond to the same boundaries for unicast | |||
| routing, though a deployment which does not follow this assumption is | routing, though a deployment which does not follow this assumption is | |||
| not precluded by this specification. | not precluded by this specification. | |||
| In general, PIM-DM interactions with other multicast routing protocols | In general, PIM-DM interactions with other multicast routing protocols | |||
| should be in compliance with RFC 2715 [11]. Other specific | should be in compliance with RFC 2715 [7]. Other specific | |||
| interactions are noted below. | interactions are noted below. | |||
| 5.1. PIM-SM Interactions | 5.1. PIM-SM Interactions | |||
| PIM-DM is not intended to interact directly with PIM-SM, even though | PIM-DM is not intended to interact directly with PIM-SM, even though | |||
| they share a common packet format. It is particularly important to note | they share a common packet format. It is particularly important to note | |||
| that a router cannot differentiate between a PIM-DM neighbor and a | that a router cannot differentiate between a PIM-DM neighbor and a | |||
| PIM-SM neighbor based on Hello messages. | PIM-SM neighbor based on Hello messages. | |||
| In the event that a PIM-DM router becomes a neighbor of a PIM-SM router | In the event that a PIM-DM router becomes a neighbor of a PIM-SM router | |||
| skipping to change at page 49, line 13 ¶ | skipping to change at page 1, line 2305 ¶ | |||
| not. Such an implementation is outside the scope of this document. | not. Such an implementation is outside the scope of this document. | |||
| 5.2. IGMP Interactions | 5.2. IGMP Interactions | |||
| PIM-DM will forward received multicast data packets to neighboring host | PIM-DM will forward received multicast data packets to neighboring host | |||
| group members in all cases except when the PIM-DM router is in an Assert | group members in all cases except when the PIM-DM router is in an Assert | |||
| Loser state on that interface. Note that a PIM Prune message is not | Loser state on that interface. Note that a PIM Prune message is not | |||
| permitted to prevent the delivery of messages to a network with group | permitted to prevent the delivery of messages to a network with group | |||
| members. | members. | |||
| A PIM-DM Router MAY use the DR Priority option described in PIM-SM [3] | A PIM-DM Router MAY use the DR Priority option described in PIM-SM [13] | |||
| to elect an IGMP v1 querier. | to elect an IGMP v1 querier. | |||
| 5.3. Source Specific Multicast (SSM) Interactions | 5.3. Source Specific Multicast (SSM) Interactions | |||
| PIM-DM makes no special considerations for SSM [9]. All Prunes and | PIM-DM makes no special considerations for SSM [14]. All Prunes and | |||
| Grafts within the protocol are for a specific source, so no additional | Grafts within the protocol are for a specific source, so no additional | |||
| checks need be made. | checks need be made. | |||
| 5.4. Multicast Group Scope Boundary Interactions | 5.4. Multicast Group Scope Boundary Interactions | |||
| While multicast group scope boundaries are generally identical to | While multicast group scope boundaries are generally identical to | |||
| routing area boundaries, it is conceivable that a routing area might be | routing area boundaries, it is conceivable that a routing area might be | |||
| partitioned for a particular multicast group. PIM-DM routers MUST NOT | partitioned for a particular multicast group. PIM-DM routers MUST NOT | |||
| send any messages concerning a particular group across that group's | send any messages concerning a particular group across that group's | |||
| scope boundary. | scope boundary. | |||
| skipping to change at page 49, line 43 ¶ | skipping to change at page 1, line 2335 ¶ | |||
| The PIM Address Family field was chosen to be 8 bits as a tradeoff | The PIM Address Family field was chosen to be 8 bits as a tradeoff | |||
| between packet format and use of the IANA assigned numbers. When the | between packet format and use of the IANA assigned numbers. When the | |||
| PIM packet format was designed, only 15 values were assigned for Address | PIM packet format was designed, only 15 values were assigned for Address | |||
| Families and large numbers of new Address Families were not envisioned, | Families and large numbers of new Address Families were not envisioned, | |||
| 8 bits seemed large enough. However, the IANA assigns Address Families | 8 bits seemed large enough. However, the IANA assigns Address Families | |||
| in a 16 bit value. Therefore, the PIM Address Family is allocated as | in a 16 bit value. Therefore, the PIM Address Family is allocated as | |||
| follows: | follows: | |||
| Values 0 through 127 are designated to have the same meaning as IANA | Values 0 through 127 are designated to have the same meaning as IANA | |||
| assigned Address Family Numbers [6]. | assigned Address Family Numbers [9]. | |||
| Values 128 through 250 are designated to be assigned by the IANA based | Values 128 through 250 are designated to be assigned by the IANA based | |||
| upon IESG approval as defined in [7]. | upon IESG approval as defined in [8]. | |||
| Values 251 through 255 are designated for Private Use, as defined in | Values 251 through 255 are designated for Private Use, as defined in | |||
| [7]. | [8]. | |||
| 6.2. PIM Hello Options | 6.2. PIM Hello Options | |||
| Values 17 through 65000 are to be assigned by the IANA. Since the space | Values 17 through 65000 are to be assigned by the IANA. Since the space | |||
| is large, they may be assigned as First Come First Served as defined in | is large, they may be assigned as First Come First Served as defined in | |||
| [7]. Such assignments are valid for one year, and may be renewed. | [8]. Such assignments are valid for one year, and may be renewed. | |||
| Permanent assignments require a specification as defined in [7]. | Permanent assignments require a specification as defined in [8]. | |||
| 7. Security Considerations | 7. Security Considerations | |||
| The IPsec authentication header [8] MAY be used to provide data | The IPsec authentication header [10] MAY be used to provide data | |||
| integrity protection and groupwise data origin authentication of PIM | integrity protection and groupwise data origin authentication of PIM | |||
| protocol messages. Authentication of PIM messages can protect against | protocol messages. Authentication of PIM messages can protect against | |||
| unwanted behaviors caused by unauthorized or altered PIM messages. In | unwanted behaviors caused by unauthorized or altered PIM messages. In | |||
| any case, a PIM router SHOULD NOT accept and process PIM messages from | any case, a PIM router SHOULD NOT accept and process PIM messages from | |||
| neighbors unless a valid Hello message has been received from that | neighbors unless a valid Hello message has been received from that | |||
| neighbor. | neighbor. | |||
| We should note that PIM-DM has no rendezvous point, and therefore no | We should note that PIM-DM has no rendezvous point, and therefore no | |||
| single point of failure that may be vulnerable. It is further worth | single point of failure that may be vulnerable. It is further worth | |||
| noting that because PIM-DM uses unicast routes provided by an unknown | noting that because PIM-DM uses unicast routes provided by an unknown | |||
| skipping to change at page 51, line 41 ¶ | skipping to change at page 1, line 2424 ¶ | |||
| from which it will accept PIM-DM messages. Either static configuration | from which it will accept PIM-DM messages. Either static configuration | |||
| of IP addresses or an IPSec security association may be used. All | of IP addresses or an IPSec security association may be used. All | |||
| options that restrict the range of addresses from which packets are | options that restrict the range of addresses from which packets are | |||
| accepted MUST default to allowing all packets. | accepted MUST default to allowing all packets. | |||
| Furthermore, a PIM router SHOULD NOT accept protocol messages from a | Furthermore, a PIM router SHOULD NOT accept protocol messages from a | |||
| router from which it has not yet received a valid Hello message. | router from which it has not yet received a valid Hello message. | |||
| 7.3. Authentication Using IPsec | 7.3. Authentication Using IPsec | |||
| The IPSec [8] transport mode using the Authentication Header (AH) is the | The IPSec [10] transport mode using the Authentication Header (AH) is | |||
| recommended method to prevent the above attacks in PIM. The specific AH | the recommended method to prevent the above attacks in PIM. The | |||
| authentication algorithm and parameters, including the choice of | specific AH authentication algorithm and parameters, including the | |||
| authentication algorithm and the choice of key, are configured by the | choice of authentication algorithm and the choice of key, are configure | |||
| network administrator. The Encapsulating Security Payload (ESP) MAY also | by the network administrator. The Encapsulating Security Payload (ESP) | |||
| be used to provide both encryption and authentication of PIM protocol | MAY also be used to provide both encryption and authentication of PIM | |||
| messages. When IPsec authentication is used, a PIM router SHOULD reject | protocol messages. When IPsec authentication is used, a PIM router | |||
| (drop without processing) any unauthorized PIM protocol messages. | SHOULD reject (drop without processing) any unauthorized PIM protocol | |||
| messages. | ||||
| To use IPSec, the administrator of a PIM network configures each PIM | To use IPSec, the administrator of a PIM network configures each PIM | |||
| router with one or more Security Associations and associated SPI(s) that | router with one or more Security Associations and associated Security | |||
| are used by senders to sign PIM protocol messages and are used by | Parameters Indices that are used by senders to sign PIM protocol | |||
| receivers to authenticate received PIM protocol messages. This document | messages and are used by receivers to authenticate received PIM protocol | |||
| does not describe protocols for establishing Security Associations. It | messages. This document does not describe protocols for establishing | |||
| assumes that manual configuration of Security Associations is performed, | Security Associations. It assumes that manual configuration of Security | |||
| but it does not preclude the use of some future negotiation protocol | Associations is performed, but it does not preclude the use of some | |||
| such as GDOI [15] to establish Security Associations. | future negotiation protocol such as GDOI [17] to establish Security | |||
| Associations. | ||||
| The network administrator defines a Security Association (SA) and | The network administrator defines a Security Association (SA) and | |||
| Security Parameters Index (SPI) that is to be used to authenticate all | Security Parameters Index (SPI) that is to be used to authenticate all | |||
| PIM-DM protocol messages from each router on each link in a PIM-DM | PIM-DM protocol messages from each router on each link in a PIM-DM | |||
| domain. | domain. | |||
| Note that if the same SA is used by different sending routers on | In order to avoid the problem of allocating individual keys for each | |||
| the same link, it will not be possible to authenticate the individual | neighbor on a link to each individual router, it is acceptable to | |||
| sender precisely and anti-replay mechanisms would prevent the | establish only one authentication key for all PIM-DM routers on a link. | |||
| acceptance of legitimate PIM-DM messages, so IPSec's Replay Protection | This will not specifically authenticate the individual router sending | |||
| would need to be disabled. | the message, but will assure that the sender is a PIM-DM router on that | |||
| link. If this method is used, the receiver of the message MUST ignore | ||||
| the received sequence number, thus disabling anti-replay mechanisms. | ||||
| The effects of disabling anti-replay mechanisms are essentially the same | ||||
| as the effects of forged messages described in section 7.1 with the | ||||
| additional protection that the forger can only reuse legitimate | ||||
| messages. | ||||
| The Security Policy Database at a PIM-DM router should be configured to | The Security Policy Database at a PIM-DM router should be configured to | |||
| ensure that all incoming and outgoing PIM-DM packets use the SA | ensure that all incoming and outgoing PIM-DM packets use the SA | |||
| associated with the interface to which the packet is sent. Note that, | associated with the interface to which the packet is sent. Note that, | |||
| according to [8], there is nominally a different Security Association | according to [10], there is nominally a different Security Association | |||
| Database (SAD) for each router interface. Thus, the selected Security | Database (SAD) for each router interface. Thus, the selected Security | |||
| Association for an inbound PIM-DM packet can vary depending on the | Association for an inbound PIM-DM packet can vary depending on the | |||
| interface on which the packet arrived. This fact allows the network | interface on which the packet arrived. This fact allows the network | |||
| administrator to use different authentication methods for each link, | administrator to use different authentication methods for each link, | |||
| even though the destination address is the same for most PIM-DM packets, | even though the destination address is the same for most PIM-DM packets, | |||
| regardless of interface. | regardless of interface. | |||
| 7.4. Denial of Service Attacks | 7.4. Denial of Service Attacks | |||
| There are a number of possible denial of service attacks against PIM | There are a number of possible denial of service attacks against PIM | |||
| skipping to change at page 53, line 40 ¶ | skipping to change at page 1, line 2526 ¶ | |||
| David Meyer, and Liming Wei. Additional features for state refresh | David Meyer, and Liming Wei. Additional features for state refresh | |||
| were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. | were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. | |||
| This revision was undertaken to incorporate some of the lessons learned | This revision was undertaken to incorporate some of the lessons learned | |||
| during the evolution of the PIM-SM specification and early deployments | during the evolution of the PIM-SM specification and early deployments | |||
| of PIM-DM. | of PIM-DM. | |||
| Thanks the PIM Working Group for their comments. | Thanks the PIM Working Group for their comments. | |||
| 10. References | 10. References | |||
| [1] S.E. Deering, "Multicast Routing in a Datagram Internetwork", | 10.1 Normative References | |||
| [1] S.E. Deering, "Host Extensions for IP Multicasting", March 1989, | ||||
| RFC 1112. | ||||
| [2] W.Fenner, "Internet Group Management Protocol, Version 2", | ||||
| November 1997, RFC 2236. | ||||
| [3] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, | ||||
| "Internet Group Management Protocol, Version 3", | ||||
| October 2002, RFC 3376. | ||||
| [4] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, | ||||
| M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol | ||||
| Independent Multicast-Sparse Mode (PIM-SM): Protocol | ||||
| Specification", June 1998, RFC 2362. | ||||
| [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) | ||||
| Specification", December 1998, RFC 2460. | ||||
| [6] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery | ||||
| (MLD) for IPv6", October 1999, RFC 2710. | ||||
| [7] D. Thaler, "Interoperability Rules for Multicast Routing | ||||
| Protocols", October 1999, RFC 2715. | ||||
| [8] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | ||||
| Considerations Section in RFCs", October 1998, RFC 2434. | ||||
| [9] IANA, "Address Family Numbers", linked from | ||||
| http://www.iana.org/numbers.html. | ||||
| [10] S. Kent, R. Atkinson, "Security Architecture for the Internet | ||||
| Protocol", November 1998, RFC 2401. | ||||
| 10.2 Informative References | ||||
| [11] S.E. Deering, "Multicast Routing in a Datagram Internetwork", | ||||
| Ph.D. Thesis, Electrical Engineering Dept., Stanford University, | Ph.D. Thesis, Electrical Engineering Dept., Stanford University, | |||
| December 1991. | December 1991. | |||
| [2] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast | [12] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast | |||
| Routing Protocol", November 1988, RFC 1075 | Routing Protocol", November 1988, RFC 1075 | |||
| [3] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol | [13] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol | |||
| Independent Multicast - Sparse Mode (PIM-SM)", | Independent Multicast - Sparse Mode (PIM-SM): Protocol | |||
| draft-ietf-pim-sm-v2-new-07.txt, work in progress. | Specification (Revised)", draft-ietf-pim-sm-v2-new-09.txt, | |||
| work in progress. | ||||
| [4] S.E. Deering, "Host Extensions for IP Multicasting", March 1989, | [14] H.Holbrook, B. Cain, "Source Specific Multicast for IP", | |||
| draft-ietf-ssm-arch-04.txt, work in progress. | ||||
| [15] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol | ||||
| Independent Multicast MIB for IPv4", October 2000, RFC 2934 | ||||
| [16] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional | ||||
| Protocol Independent Multicast", draft-ietf-pim-bidir-06.txt, | ||||
| work in progress. | ||||
| [17] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group Domain of | ||||
| Interpretation", July 2003, RFC 3547. | ||||
| [18] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router | ||||
| (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, | ||||
| work in progress. | ||||
| 11. Full Copyright Statement | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| This document and translations of it may be copied and furnished to | ||||
| others, and derivative works that comment on or otherwise explain it | ||||
| or assist in its implementation may be prepared, copied, published and | ||||
| distributed, in whole or in part, without restriction of any kind, | ||||
| provided that the above copyright notice and this paragraph are | ||||
| included on all such copies and derivative works. However, this | ||||
| document itself may not be modified in any way, such as by removing | ||||
| the copyright notice or references to the Internet Society or other | ||||
| internet organizations, except as needed for the purpose of | ||||
| developing Internet standards in which case the procedures for | ||||
| copyrights defined in the Internet Standards process must be | ||||
| followed, or as required to translate it into languages other than | ||||
| English. | ||||
| The limited permissions granted above are perpetual and will not be | ||||
| revoked by the Internet Society or its successors or assigns. | ||||
| This document and the information contained herein is provided on an | ||||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Internet Engineering Task Force PIM WG | ||||
| INTERNET DRAFT Andrew Adams (NextHop Technolgies) | ||||
| draft-ietf-pim-dm-new-v2-05.txt Jonathan Nicholas (ITT A/CD) | ||||
| William Siadak (NextHop Technologies) | ||||
| June 2004 | ||||
| Expires December 2004 | ||||
| Protocol Independent Multicast - Dense Mode (PIM-DM): | ||||
| Protocol Specification (Revised) | ||||
| Status of this Document | ||||
| This document is an Internet Draft and is in full conformance with all | ||||
| provisions of Section 10 of RFC 2026. | ||||
| Internet Drafts are working documents of the Internet Engineering Task | ||||
| Force (IETF), its areas, and its working groups. Note that other groups | ||||
| may also distribute working documents as Internet Drafts. | ||||
| Internet Drafts are draft documents valid for a maximum of six months | ||||
| and may be updated, replaced, or obsoleted by other documents at any | ||||
| time. It is inappropriate to use Internet Drafts as reference material | ||||
| or to cite them other than as "work in progress." | ||||
| The list of current Internet Drafts can be accessed at | ||||
| http://www.ietf.org/ietf/lid-abstracts.txt. | ||||
| The list of Internet Draft Shadow Directories can be accessed at | ||||
| http://www.ietf.org/shadow.html. | ||||
| This document is a product of the IETF PIM WG. Comments should be | ||||
| addressed to the authors, or the WG's mailing list at pim@ietf.org. | ||||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| Abstract | ||||
| This document specifies Protocol Independent Multicast - Dense Mode | ||||
| (PIM-DM). PIM-DM is a multicast routing protocol that uses the | ||||
| underlying unicast routing information base to flood multicast datagrams | ||||
| to all multicast routers. Prune messages are used to prevent future | ||||
| messages from propagating to routers with no group membership | ||||
| information. | ||||
| Table of Contents | ||||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
| 2.2. Pseudocode Notation . . . . . . . . . . . . . . . . . . . . 5 | ||||
| 3. PIM-DM Protocol Overview . . . . . . . . . . . . . . . . . . 5 | ||||
| 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 | ||||
| 4.1. PIM Protocol State . . . . . . . . . . . . . . . . . . . . . 6 | ||||
| 4.1.1. General Purpose State . . . . . . . . . . . . . . . . . . . 7 | ||||
| 4.1.2. (S,G) State . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
| 4.1.3. State Summarization Macros . . . . . . . . . . . . . . . . . 8 | ||||
| 4.2. Data Packet Forwarding Rules . . . . . . . . . . . . . . . . 10 | ||||
| 4.3. Hello Messages . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
| 4.3.1. Sending Hello Messages . . . . . . . . . . . . . . . . . . . 10 | ||||
| 4.3.2. Receiving Hello Messages . . . . . . . . . . . . . . . . . . 11 | ||||
| 4.3.3. Hello Message Hold Time . . . . . . . . . . . . . . . . . . 11 | ||||
| 4.3.4. Handling Router Failures . . . . . . . . . . . . . . . . . . 11 | ||||
| 4.3.5. Reducing Prune Propagation Delay on LANs . . . . . . . . . . 12 | ||||
| 4.4. PIM-DM Prune, Join and Graft Messages . . . . . . . . . . . 13 | ||||
| 4.4.1. Upstream Prune, Join and Graft Messages . . . . . . . . . . 13 | ||||
| 4.4.1.1. Transitions from the Forwarding (F) State . . . . . . . . . 16 | ||||
| 4.4.1.2. Transitions from the Pruned (P) State . . . . . . . . . . . 17 | ||||
| 4.4.1.3. Transitions from the AckPending (AP) State . . . . . . . . . 18 | ||||
| 4.4.2. Downstream Prune, Join and Graft Messages . . . . . . . . . 19 | ||||
| 4.4.2.1. Transitions from the NoInfo State . . . . . . . . . . . . . 21 | ||||
| 4.4.2.2. Transitions from the PrunePending (PP) State . . . . . . . . 22 | ||||
| 4.4.2.3. Transitions from the Prune (P) State . . . . . . . . . . . . 23 | ||||
| 4.5. State Refresh . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
| 4.5.1. Forwarding of State Refresh Messages . . . . . . . . . . . . 24 | ||||
| 4.5.2. State Refresh Message Origination . . . . . . . . . . . . . 25 | ||||
| 4.5.2.1. Transitions from the NotOriginator (NO) State . . . . . . . 27 | ||||
| 4.5.2.2. Transitions from the Originator (O) State . . . . . . . . . 27 | ||||
| 4.6. PIM Assert Messages . . . . . . . . . . . . . . . . . . . . 28 | ||||
| 4.6.1. Assert Metrics . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
| 4.6.2. AssertCancel Messages . . . . . . . . . . . . . . . . . . . 29 | ||||
| 4.6.3. Assert State Macros . . . . . . . . . . . . . . . . . . . . 29 | ||||
| 4.6.4. (S,G) Assert Message State Machine . . . . . . . . . . . . . 29 | ||||
| 4.6.4.1. Transitions from NoInfo State . . . . . . . . . . . . . . . 31 | ||||
| 4.6.4.2. Transitions from Winner State . . . . . . . . . . . . . . . 32 | ||||
| 4.6.4.3. Transitions from Loser State . . . . . . . . . . . . . . . . 33 | ||||
| 4.6.5. Rationale for Assert Rules . . . . . . . . . . . . . . . . . 34 | ||||
| 4.7. PIM Packet Formats . . . . . . . . . . . . . . . . . . . . . 35 | ||||
| 4.7.1. PIM Header . . . . . . . . . . . . . . . . . . . . . . . . . 35 | ||||
| 4.7.2. Encoded Unicast Address . . . . . . . . . . . . . . . . . . 36 | ||||
| 4.7.3. Encoded Group Address . . . . . . . . . . . . . . . . . . . 36 | ||||
| 4.7.4. Encoded Source Address . . . . . . . . . . . . . . . . . . . 37 | ||||
| 4.7.5. Hello Message Format . . . . . . . . . . . . . . . . . . . . 38 | ||||
| 4.7.5.1. Hello Hold Time Option . . . . . . . . . . . . . . . . . . . 39 | ||||
| 4.7.5.2. LAN Prune Delay Option . . . . . . . . . . . . . . . . . . . 39 | ||||
| 4.7.5.3. Generation ID Option . . . . . . . . . . . . . . . . . . . . 40 | ||||
| 4.7.5.4. State Refresh Capable Option . . . . . . . . . . . . . . . . 40 | ||||
| 4.7.6. Join/Prune Message Format . . . . . . . . . . . . . . . . . 40 | ||||
| 4.7.7. Assert Message Format . . . . . . . . . . . . . . . . . . . 42 | ||||
| 4.7.8. Graft Message Format . . . . . . . . . . . . . . . . . . . . 43 | ||||
| 4.7.9. Graft Ack Message Format . . . . . . . . . . . . . . . . . . 43 | ||||
| 4.7.10. State Refresh Message Format . . . . . . . . . . . . . . . . 44 | ||||
| 4.8. PIM-DM Timers . . . . . . . . . . . . . . . . . . . . . . . 45 | ||||
| 5. Protocol Interaction Considerations . . . . . . . . . . . . 48 | ||||
| 5.1. PIM-SM Interactions . . . . . . . . . . . . . . . . . . . . 48 | ||||
| 5.2. IGMP Interactions . . . . . . . . . . . . . . . . . . . . . 49 | ||||
| 5.3. Source Specific Multicast (SSM) Interactions . . . . . . . . 49 | ||||
| 5.4. Multicast Group Scope Boundary Interactions . . . . . . . . 49 | ||||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 | ||||
| 6.1. PIM Address Family . . . . . . . . . . . . . . . . . . . . . 49 | ||||
| 6.2. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . 50 | ||||
| 7. Security Considerations. . . . . . . . . . . . . . . . . . . 50 | ||||
| 7.1. Attacks Based on Forged Messages . . . . . . . . . . . . . . 50 | ||||
| 7.2. Non-cryptographic Authentication Mechanisms . . . . . . . . 51 | ||||
| 7.3. Authentication Using IPsec . . . . . . . . . . . . . . . . . 52 | ||||
| 7.4. Denial of Service Attacks . . . . . . . . . . . . . . . . . 53 | ||||
| 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53 | ||||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 | ||||
| 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 | ||||
| 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 54 | ||||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . . 54 | ||||
| 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 55 | ||||
| 1. Introduction | ||||
| This specification defines a multicast routing algorithm for multicast | ||||
| groups that are densely distributed across a network. This protocol | ||||
| does not have a topology discovery mechanism often used by a unicast | ||||
| routing protocol. It employs the same packet formats sparse mode PIM | ||||
| (PIM-SM) uses. This protocol is called PIM - Dense Mode. The | ||||
| foundation of this design was largely built on Deering's early work on | ||||
| IP multicast routing [11]. | ||||
| 2. Terminology | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be | ||||
| interpreted as described in RFC 2119 and indicate requirement levels for | ||||
| compliant PIM-DM implementations. | ||||
| 2.1. Definitions | ||||
| Multicast Routing Information Base (MRIB) | ||||
| This is the multicast topology table, which is typically derived from | ||||
| the unicast routing table, or routing protocols such as MBGP that | ||||
| carry multicast-specific topology information. PIM-DM uses the MRIB | ||||
| to make decisions regarding RPF interfaces. | ||||
| Tree Information Base (TIB) | ||||
| This is the collection of state maintained by a PIM router and created | ||||
| by receiving PIM messages and IGMP information from local hosts. It | ||||
| essentially stores the state of all multicast distribution trees at | ||||
| that router. | ||||
| Reverse Path Forwarding (RPF) | ||||
| RPF is a multicast forwarding mode where a data packet is accepted for | ||||
| forwarding only if it is received on an interface used to reach the | ||||
| source in unicast. | ||||
| Upstream Interface | ||||
| Interface towards the source of the datagram. Also known as the RPF | ||||
| Interface. | ||||
| Downstream Interface | ||||
| All interfaces that are not the upstream interface, including the | ||||
| router itself. | ||||
| (S,G) Pair | ||||
| Source S and destination group G associated with an IP packet. | ||||
| 2.2. Pseudocode Notation | ||||
| We use set notation in several places in this specification. | ||||
| A (+) B | ||||
| is the union of two sets A and B. | ||||
| A (-) B | ||||
| are the elements of set A that are not in set B. | ||||
| NULL | ||||
| is the empty set or list. | ||||
| Note that operations MUST be conducted in the order specified. This is | ||||
| due to the fact that (-) is not a true difference operator because B is | ||||
| not necessarily a subset of A. That is, A (+) B (-) C = A (-) C (+) B | ||||
| is not a true statement unless C is a subset of both A and B. | ||||
| In addition we use C-like syntax: | ||||
| = denotes assignment of a variable. | ||||
| == denotes a comparison for equality. | ||||
| != denotes a comparison for inequality. | ||||
| Braces { and } are used for grouping. | ||||
| 3. PIM-DM Protocol Overview | ||||
| This section provides an overview of PIM-DM behavior. It is intended as | ||||
| an introduction to how PIM-DM works, and is NOT definitive. For the | ||||
| definitive specification, see Section 4 - Protocol Specification. | ||||
| PIM-DM assumes that when a source starts sending, all downstream systems | ||||
| want to receive multicast datagrams. Initially, multicast datagrams are | ||||
| flooded to all areas of the network. PIM-DM uses RPF to prevent looping | ||||
| of multicast datagrams while flooding. If some areas of the network do | ||||
| not have group members, PIM-DM will prune off the forwarding branch by | ||||
| instantiating prune state. | ||||
| Prune state has a finite lifetime. When that lifetime expires, data | ||||
| will again be forwarded down the previously pruned branch. | ||||
| Prune state is associated with an (S,G) pair. When a new member for a | ||||
| group G appears in a pruned area, a router can "graft" toward the source | ||||
| S for the group, thereby turning the pruned branch back into a | ||||
| forwarding branch. | ||||
| The broadcast of datagrams followed by pruning of unwanted branches is | ||||
| often referred to as a flood and prune cycle and is typical of dense | ||||
| mode protocols. | ||||
| In order to minimize repeated flooding of datagrams and subsequent | ||||
| pruning associated with a particular (S,G) pair, PIM-DM uses a state | ||||
| refresh message. This message is sent by the router(s) directly | ||||
| connected to the source and is propagated throughout the network. When | ||||
| received by a router on its RPF interface, the state refresh message | ||||
| causes an existing prune state to be refreshed. | ||||
| Compared with multicast routing protocols with built in topology | ||||
| discovery mechanisms (e.g. DVMRP [12]) PIM-DM has a simplified design | ||||
| and is not hard-wired into a specific topology discovery protocol. | ||||
| However, such a simplification does incur more overhead by causing | ||||
| flooding and pruning to occur on some links that could be avoided if | ||||
| sufficient topology information were available, i.e. to decide whether | ||||
| an interface leads to any downstream members of a particular group. | ||||
| Additional overhead is chosen in favor of the simplification and | ||||
| flexibility gained by not depending on a specific topology discovery | ||||
| protocol. | ||||
| PIM-DM differs from PIM-SM in two essential ways: 1) There are no | ||||
| periodic joins transmitted, only explicitly triggered prunes and grafts. | ||||
| 2) There is no Rendezvous Point (RP). This is particularly important in | ||||
| networks that cannot tolerate a single point of failure. (An RP is the | ||||
| root of a shared multicast distribution tree. For more details see [4]). | ||||
| 4. Protocol Specification | ||||
| The specification of PIM-DM is broken into several parts: | ||||
| * Section 4.1 details the protocol state stored. | ||||
| * Section 4.2 specifies the data packet forwarding rules. | ||||
| * Section 4.3 specifies generation and processing of Hello messages. | ||||
| * Section 4.4 specifies the Join, Prune and Graft generation and | ||||
| processing rules. | ||||
| * Section 4.5 specifies the State Refresh generation and forwarding | ||||
| rules. | ||||
| * Section 4.6 specifies the Assert generation and processing rules. | ||||
| * Section 4.7 gives details on PIM-DM Packet Formats. | ||||
| * Section 4.8 summarizes PIM-DM timers and their defaults. | ||||
| 4.1. PIM Protocol State | ||||
| This section specifies all the protocol states that a PIM-DM | ||||
| implementation should maintain in order to function correctly. We term | ||||
| this state the Tree Information Base or TIB, as it holds the state of | ||||
| all the multicast distribution trees at this router. In this | ||||
| specification, we define PIM-DM mechanisms in terms of the TIB. | ||||
| However, only a very simple implementation would actually implement | ||||
| packet forwarding operations in terms of this state. Most | ||||
| implementations will use this state to build a multicast forwarding | ||||
| table, which would then be updated when the relevant state in the TIB | ||||
| changes. | ||||
| Unlike PIM-SM, PIM-DM does not maintain a keepalive timer associated | ||||
| with each (S,G) route. Within PIM-DM, route and state information | ||||
| associated with an (S,G) entry MUST be maintained as long as any timer | ||||
| associated with that (S,G) entry is active. When no timer associated | ||||
| with an (S,G) entry is active, all information concerning that (S,G) | ||||
| route may be discarded. | ||||
| Although we specify precisely the state to be kept, this does not mean | ||||
| that an implementation of PIM-DM needs to hold the state in this form. | ||||
| This is actually an abstract state definition, which is needed in order | ||||
| to specify the router's behavior. A PIM-DM implementation is free to | ||||
| hold whatever internal state it requires, and will still be conformant | ||||
| with this specification so long as it results in the same externally | ||||
| visible protocol behavior as an abstract router that holds the following | ||||
| state. | ||||
| 4.1.1. General Purpose State | ||||
| A router stores the following non-group-specific state: | ||||
| For each interface: | ||||
| Hello Timer (HT) | ||||
| State Refresh Capable | ||||
| LAN Delay Enabled | ||||
| Propagation Delay (PD) | ||||
| Override Interval (OI) | ||||
| Neighbor State: | ||||
| For each neighbor: | ||||
| Information from neighbor's Hello | ||||
| Neighbor's Gen ID. | ||||
| Neighbor's LAN Prune Delay | ||||
| Neighbor's Override Interval | ||||
| Neighbor's State Refresh Capability | ||||
| Neighbor Liveness Timer (NLT) | ||||
| 4.1.2. (S,G) State | ||||
| For every source/group pair (S,G), a router stores the following state: | ||||
| (S,G) state: | ||||
| For each interface: | ||||
| Local Membership: | ||||
| State: One of {"NoInfo", "Include"} | ||||
| PIM (S,G) Prune State: | ||||
| State: One of {"NoInfo" (NI), "Pruned" (P), "PrunePending" (PP)} | ||||
| Prune Pending Timer (PPT) | ||||
| Prune Timer (PT) | ||||
| (S,G) Assert Winner State: | ||||
| State: One of {"NoInfo" (NI), "I lost Assert" (L), | ||||
| "I won Assert" (W)} | ||||
| Assert Timer (AT) | ||||
| Assert winner's IP Address | ||||
| Assert winner's Assert Metric | ||||
| Upstream interface-specific: | ||||
| Graft/Prune State: | ||||
| State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F), | ||||
| "AckPending" (AP) } | ||||
| GraftRetry Timer (GRT) | ||||
| Override Timer (OT) | ||||
| Prune Limit Timer (PLT) | ||||
| Originator State: | ||||
| Source Active Timer (SAT) | ||||
| State Refresh Timer (SRT) | ||||
| 4.1.3. State Summarization Macros | ||||
| Using the state defined above, the following "macros" are defined and | ||||
| will be used in the descriptions of the state machines and pseudocode in | ||||
| the following sections. | ||||
| The most important macros are those defining the outgoing interface list | ||||
| (or "olist") for the relevant state. | ||||
| immediate_olist(S,G) = pim_nbrs (-) prunes(S,G) (+) | ||||
| ( pim_include(*,G) (-) pim_exclude(S,G) ) (+) | ||||
| pim_include(S,G) (-) lost_assert(S,G) (-) | ||||
| boundary(G) | ||||
| olist(S,G) = immediate_olist(S,G) (-) RPF_interface(S) | ||||
| The macros pim_include(*,G) and pim_include(S,G) indicate the interfaces | ||||
| to which traffic might be forwarded or not forwarded because of hosts | ||||
| that are local members on those interfaces. | ||||
| pim_include(*,G) = {all interfaces I such that: | ||||
| local_receiver_include(*,G,I)} | ||||
| pim_include(S,G) = {all interfaces I such that: | ||||
| local_receiver_include(S,G,I)} | ||||
| pim_exclude(S,G) = {all interfaces I such that: | ||||
| local_receiver_exclude(S,G,I)} | ||||
| The macro RPF_interface(S) returns the RPF interface for source S. That | ||||
| is to say, it returns the interface used to reach S as indicated by the | ||||
| MRIB. | ||||
| The macro local_receiver_include(S,G,I) is true if the IGMP module or | ||||
| other local membership mechanism has determined that there are local | ||||
| members on interface I that desire to receive traffic sent specifically | ||||
| by S to G. | ||||
| The macro local_receiver_include(*,G,I) is true if the IGMP module or | ||||
| other local membership mechanism has determined that there are local | ||||
| members on interface I that desire to receive all traffic sent to G. | ||||
| Note that this determination is expected to account for membership joins | ||||
| initiated on or by the router. | ||||
| The macro local_receiver_exclude(S,G,I) is true if | ||||
| local_receiver_include(*,G,I) is true but none of the local members | ||||
| desire to receive traffic from S. | ||||
| The set pim_nbrs is the set of all interfaces on which the router has at | ||||
| least one active PIM neighbor. | ||||
| The set prunes(S,G) is the set of all interfaces on which the router has | ||||
| received Prune(S,G) messages: | ||||
| prunes(S,G) = {all interfaces I such that | ||||
| DownstreamPState(S,G,I) is in Pruned state} | ||||
| The set lost_assert(S,G) is the set of all interfaces on which the | ||||
| router has lost an (S,G) Assert. | ||||
| lost_assert(S,G) = {all interfaces I such that | ||||
| lost_assert(S,G,I) == TRUE} | ||||
| boundary(G) = {all interfaces I with an administratively scoped | ||||
| boundary for group G} | ||||
| The following pseudocode macro definitions are also used in many places | ||||
| in the specification. Basically RPF' is the RPF neighbor towards a | ||||
| source unless a PIM-DM Assert has overridden the normal choice of | ||||
| neighbor. | ||||
| neighbor RPF'(S,G) { | ||||
| if ( I_Am_Assert_loser(S, G, RPF_interface(S) )) { | ||||
| return AssertWinner(S, G, RPF_interface(S) ) | ||||
| } else { | ||||
| return MRIB.next_hop( S ) | ||||
| } | ||||
| } | ||||
| The macro I_Am_Assert_loser(S, G, I) is true if the Assert state machine | ||||
| (in section 4.6) for (S,G) on interface I is in the "I am Assert Loser" | ||||
| state. | ||||
| 4.2. Data Packet Forwarding Rules | ||||
| The PIM-DM packet forwarding rules are defined below in pseudocode. | ||||
| iif is the incoming interface of the packet. | ||||
| S is the source address of the packet. | ||||
| G is the destination address of the packet (group address). | ||||
| RPF_interface(S) is the interface the MRIB indicates would be used to | ||||
| route packets to S. | ||||
| First, an RPF check MUST be performed to determine whether the packet | ||||
| should be accepted based on TIB state and the interface on which that | ||||
| the packet arrived. Packets that fail the RPF check MUST NOT be | ||||
| forwarded and the router will conduct an assert process for the (S,G) | ||||
| pair specified in the packet. Packets for which a route to the source | ||||
| cannot be found MUST be discarded. | ||||
| If the RPF check has been passed, an outgoing interface list is | ||||
| constructed for the packet. If this list is not empty, then the packet | ||||
| MUST be forwarded to all listed interfaces. If the list is empty, then | ||||
| the router will conduct a prune process for the (S,G) pair specified in | ||||
| the packet. | ||||
| On receipt on a data packet from S addressed to G on interface iif: | ||||
| if (iif == RPF_interface(S) AND UpstreamPState(S,G) != Pruned) { | ||||
| oiflist = olist(S,G) | ||||
| } else { | ||||
| oiflist = NULL | ||||
| } | ||||
| forward packet on all interfaces in oiflist | ||||
| This pseudocode employs the following "macro" definition: | ||||
| UpstreamPState(S,G) is the state of the Upstream(S,G) state machine in | ||||
| section 4.4.1. | ||||
| 4.3. Hello Messages | ||||
| This section describes the generation and processing of Hello messages. | ||||
| 4.3.1. Sending Hello Messages | ||||
| PIM-DM uses Hello messages to detect other PIM routers. Hello messages | ||||
| are sent periodically on each PIM enabled interface. Hello messages are | ||||
| multicast to the ALL-PIM-ROUTERS group. When PIM is enabled on an | ||||
| interface or a router first starts, the Hello Timer (HT) MUST be set to | ||||
| random value between 0 and Triggered_Hello_Delay. This prevents | ||||
| synchronization of Hello messages if multiple routers are powered on | ||||
| simultaneously. | ||||
| After the initial Hello message, a Hello message MUST be sent every | ||||
| Hello_Period. A single Hello timer MAY be used to trigger sending | ||||
| Hello messages on all active interfaces. The Hello Timer SHOULD NOT be | ||||
| reset except when it expires. | ||||
| 4.3.2. Receiving Hello Messages | ||||
| When a Hello message is received, the receiving router SHALL record the | ||||
| receiving interface, the sender and any information contained in | ||||
| recognized options. This information is retained for a number of | ||||
| seconds in the Hold Time field of the Hello Message. If a new Hello | ||||
| message is received from a particular neighbor N, the Neighbor Liveness | ||||
| Timer (NLT(N,I)) MUST be reset to the newly received Hello Holdtime. If | ||||
| a Hello message is received from a new neighbor, the receiving router | ||||
| SHOULD send its own Hello message after a random delay between 0 and | ||||
| Triggered_Hello_Delay. | ||||
| 4.3.3. Hello Message Hold Time | ||||
| The Hold Time in the Hello Message should be set to a value that can | ||||
| reasonably be expected to keep the Hello active until a new Hello | ||||
| message is received. On most links, this will be 3.5 times the value of | ||||
| Hello_Period. | ||||
| If the Hold Time is set to '0xffff', the receiving router MUST NOT time | ||||
| out that Hello message. This feature might be used for on-demand links | ||||
| to avoid keeping the link up with periodic Hello messages. | ||||
| If a Hold Time of '0' is received, the corresponding neighbor state is | ||||
| expired immediately. When a PIM router takes an interface down or | ||||
| changes IP address, a Hello message with a zero Hold Time SHOULD be sent | ||||
| immediately (with the old IP address if the IP address is changed) to | ||||
| cause any PIM neighbors to remove the old information immediately. | ||||
| 4.3.4. Handling Router Failures | ||||
| If a Hello message is received from an active neighbor with a different | ||||
| Generation ID (GenID), the neighbor has restarted and may not contain | ||||
| the correct (S,G) state. A Hello message SHOULD be sent after a random | ||||
| delay between 0 and Triggered_Hello_Delay (see 4.8) before any other | ||||
| messages are sent. If the neighbor is downstream, the router MAY | ||||
| replay the last State Refresh message for any (S,G) pairs for which it | ||||
| is the Assert Winner indicating Prune and Assert status to the | ||||
| downstream router. These State Refresh messages SHOULD be sent out | ||||
| immediately after the Hello message. If the neighbor is the upstream | ||||
| neighbor for an (S,G) entry, the router MAY cancel its Prune Limit | ||||
| Timer to permit sending a prune and reestablishing a Pruned state in the | ||||
| upstream router. | ||||
| Upon startup, a router MAY use any State Refresh messages received | ||||
| within Hello_Period of its first Hello message on an interface to | ||||
| establish state information. The State Refresh source will be the | ||||
| RPF'(S), and Prune status for all interfaces will be set according to | ||||
| the Prune Indicator bit in the State Refresh message. If the Prune | ||||
| Indicator is set, the router SHOULD set the PruneLimitTimer to | ||||
| Prune_Holdtime and set the PruneTimer on all downstream interfaces to | ||||
| the State Refresh's Interval times two. The router SHOULD then | ||||
| propagate the State Refresh as described in section 4.5.1. | ||||
| 4.3.5. Reducing Prune Propagation Delay on LANs | ||||
| If all routers on a LAN support the LAN Prune Delay option, then the PIM | ||||
| routers on that LAN will use the values received to adjust their | ||||
| J/P_Override_Interval on that interface and the interface is LAN Delay | ||||
| Enabled. Briefly, to avoid synchronization of Prune Override (Join) | ||||
| messages when multiple downstream routers share a multi-access link, | ||||
| sending of such messages is delayed by a small random amount of time. | ||||
| The period of randomization is configurable and has a default value of 3 | ||||
| seconds. | ||||
| Each router on the LAN expresses its view of the amount of randomization | ||||
| necessary in the Override Interval field of the LAN Prune Delay option. | ||||
| When all routers on a LAN use the LAN Prune Delay Option, all routers on | ||||
| the LAN MUST set their Override_Interval to the largest Override value | ||||
| on the LAN. | ||||
| The LAN Delay inserted by a router in the LAN Prune Delay option | ||||
| expresses the expected message propagation delay on the link and SHOULD | ||||
| be configurable by the system administrator. When all routers on a link | ||||
| use the LAN Prune Delay Option, all routers on the LAN MUST set | ||||
| Propagation Delay to the largest LAN Delay on the LAN. | ||||
| PIM implementers should enforce a lower bound on the permitted values | ||||
| for this delay to allow for scheduling and processing delays within | ||||
| their router. Such delays may cause received messages to be processed | ||||
| later as well as triggered messages to be sent later than intended. | ||||
| Setting this LAN Prune Delay to too low a value may result in temporary | ||||
| forwarding outages because a downstream router will not be able to | ||||
| override a neighbor's prune message before the upstream neighbor stops | ||||
| forwarding. | ||||
| 4.4. PIM-DM Prune, Join and Graft Messages | ||||
| This section describes the generation and processing of PIM-DM Join, | ||||
| Prune and Graft messages. Prune messages are sent towards the upstream | ||||
| neighbor for S to indicate that traffic from S addressed to group G is | ||||
| not desired. In the case of two downstream routers A and B, where A | ||||
| wishes to continue receiving data and B does not, A will send a Join in | ||||
| response to B's Prune to override the Prune. This is the only situation | ||||
| in PIM-DM in which a Join message is used. Finally, a Graft message is | ||||
| used to re-join a previously pruned branch to the delivery tree. | ||||
| 4.4.1. Upstream Prune, Join and Graft Messages | ||||
| The Upstream(S,G) state machine for sending Prune, Graft and Join | ||||
| messages is given below. There are three states. | ||||
| Forwarding (F) | ||||
| This is the starting state of the Upsteam(S,G) state machine. The | ||||
| state machine is in this state if it just started or if | ||||
| oiflist(S,G) != NULL. | ||||
| Pruned(P) | ||||
| The set, olist(S,G), is empty. The router will not forward data | ||||
| from S addressed to group G. | ||||
| AckPending(AP) | ||||
| The router was in the Pruned(P) state but a transition has occurred | ||||
| in the Downstream(S,G) state machine for one of this (S,G) entry's | ||||
| outgoing interfaces indicating that traffic from S addressed to G | ||||
| should again be forwarded. A Graft message has been sent to RPF'(S) | ||||
| but a Graft Ack message has not yet been received. | ||||
| In addition there are three state-machine-specific timers: | ||||
| GraftRetry Timer (GRT(S,G)) | ||||
| This timer is set when a Graft is sent upstream. If a corresponding | ||||
| GraftAck is not received before the timer expires, then another | ||||
| Graft is sent and the GraftRetry Timer is reset. The timer is | ||||
| stopped when a Graft Ack message is received. This timer is normally | ||||
| set to Graft_Retry_Period (see 4.8). | ||||
| Override Timer (OT(S,G)) | ||||
| This timer is set when a Prune(S,G) is received on the upstream | ||||
| interface where olist(S,G) != NULL. When the timer expires, a | ||||
| Join(S,G) message is sent on the upstream interface. This timer is | ||||
| normally set to t_override (see 4.8). | ||||
| Prune Limit Timer (PLT(S,G)) | ||||
| This timer is used to rate-limit Prunes on a LAN. It is only used | ||||
| when the Upstream(S,G) state machine is in the Pruned state. A Prune | ||||
| cannot be sent if this timer is running. This timer is normally set | ||||
| to t_limit (see 4.8). | ||||
| +-------------+ +-------------+ | ||||
| | | olist == NULL | | | ||||
| | Forward |----------------------->| Pruned | | ||||
| | | | | | ||||
| +-------------+ +-------------+ | ||||
| ^ | ^ | | ||||
| | | | | | ||||
| | |RPF`(S) Changes olist == NULL| | | ||||
| | | | | | ||||
| | | +-------------+ | | | ||||
| | +-------->| |----------+ | | ||||
| | | AckPending | | | ||||
| +-------------| |<-------------+ | ||||
| Rcv GraftAck OR +-------------+ olist != NULL | ||||
| Rcv State Refresh | ||||
| With (P==0) OR | ||||
| S Directly Connect | ||||
| Figure 1: Upstream Interface State Machine | ||||
| In tabular form, the state machine is defined as follows: | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | | Previous State | | ||||
| | +------------+------------+------------+ | ||||
| | Event | Forwarding | Pruned | AckPending | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Data packet arrives on | ->P Send | ->P Send | N/A | | ||||
| | RPF_Interface(S) AND | Prune(S,G) | Prune(S,G) | | | ||||
| | olist(S,G) == NULL AND |Set PLT(S,G)|Set PLT(S,G)| | | ||||
| | PLT(S,G) not running | | | | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | State Refresh(S,G) received | ->F Set | ->P Reset |->AP Set | | ||||
| | from RPF`(S) AND | OT(S,G) | PLT(S,G) | OT(S,G) | | ||||
| | Prune Indicator == 1 | | | | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | State Refresh(S,G) received | ->F | ->P Send |->F Cancel | | ||||
| | from RPF`(S) AND | | Prune(S,G) | GRT(S,G) | | ||||
| | Prune Indicator == 0 AND | |Set PLT(S,G)| | | ||||
| | PLT(S,G) not running | | | | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | See Join(S,G) to RPF'(S) | ->F Cancel | ->P |->AP Cancel | | ||||
| | | OT(S,G) | | OT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | See Prune(S,G) | ->F Set | ->P |->AP Set | | ||||
| | | OT(S,G) | | OT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | OT(S,G) Expires | ->F Send | N/A |->AP Send | | ||||
| | | Join(S,G) | | Join(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | | Previous State | | ||||
| | +------------+------------+------------+ | ||||
| | Event | Forwarding | Pruned | AckPending | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | olist(S,G)->NULL | ->P Send | N/A |->P Send | | ||||
| | | Prune(S,G) | | Prune(S,G) | | ||||
| | |Set PLT(S,G)| |Set PLT(S,G)| | ||||
| | | | | Cancel | | ||||
| | | | | GRT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | olist(S,G)->non-NULL | N/A | ->AP Send | N/A | | ||||
| | | | Graft(S,G) | | | ||||
| | | |Set GRT(S,G)| | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | RPF'(S) Changes AND | ->AP Send | ->AP Send |->AP Send | | ||||
| | olist(S,G) != NULL | Graft(S,G) | Graft(S,G) | Graft(S,G) | | ||||
| | |Set GRT(S,G)|Set GRT(S,G)|Set GRT(S,G)| | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | RPF'(S) Changes AND | ->P | ->P Cancel |->P Cancel | | ||||
| | olist(S,G) == NULL | | PLT(S,G) | GRT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | S becomes directly connected | ->F | ->P |->F Cancel | | ||||
| | | | | GRT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | GRT(S,G) Expires | N/A | N/A |->AP Send | | ||||
| | | | | Graft(S,G) | | ||||
| | | | |Set GRT(S,G)| | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Receive GraftAck(S,G) from | ->F | ->P |->F Cancel | | ||||
| | RPF'(S) | | | GRT(S,G) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| The transition event "RcvGraftAck(S,G)" implies receiving a Graft Ack | ||||
| message targeted to this router's address on the incoming interface for | ||||
| the (S,G) entry. If the destination address is not correct, the state | ||||
| transitions in this state machine must not occur. | ||||
| 4.4.1.1. Transitions from the Forwarding (F) State | ||||
| When the Upstream(S,G) state machine is in the Forwarding (F) state, the | ||||
| following events may trigger a transition: | ||||
| Data Packet arrives on RPF_Interface(S) AND olist(S,G) == NULL AND S | ||||
| NOT directly connected | ||||
| The Upstream(S,G) state machine MUST transition to the Pruned (P) | ||||
| state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit | ||||
| seconds. | ||||
| State Refresh(S,G) Received from RPF'(S) | ||||
| The Upstream(S,G) state machine remains in a Forwarding state. If | ||||
| the received State Refresh has the Prune Indicator bit set to one, | ||||
| this router must override the upstream router's Prune state after a | ||||
| short random interval. If OT(S,G) is not running and the Prune | ||||
| Indicator bit equals one, the router MUST set OT(S,G) to t_override | ||||
| seconds. | ||||
| See Join(S,G) to RPF'(S) | ||||
| This event is only relevant if RPF_interface(S) is a shared medium. | ||||
| This router sees another router on RPF_interface(S) send a Join(S,G) | ||||
| to RPF'(S,G). If the OT(S,G) is running, then it means that the | ||||
| router had scheduled a Join to override a previously received Prune. | ||||
| Another router has responded more quickly with a Join and so the | ||||
| local router SHOULD cancel its OT(S,G), if it is running. The | ||||
| Upstream(S,G) state machine remains in the Forwarding (F) state. | ||||
| See Prune(S,G) AND S NOT directly connected | ||||
| This event is only relevant if RPF_interface(S) is a shared medium. | ||||
| This router sees another router on RPF_interface(S) send a | ||||
| Prune(S,G). As this router is in Forwarding state, it must | ||||
| override the Prune after a short random interval. If OT(S,G) is not | ||||
| running, the router MUST set OT(S,G) to t_override seconds. The | ||||
| Upstream(S,G) state machine remains in Forwarding (F) state. | ||||
| OT(S,G) Expires AND S NOT directly connected | ||||
| The OverrideTimer (OT(S,G)) expires. The router MUST send a | ||||
| Join(S,G) to RPF'(S) to override a previously detected prune. The | ||||
| Upstream(S,G) state machine remains in the Forwarding (F) state. | ||||
| olist(S,G) -> NULL AND S NOT directly connected | ||||
| The Upstream(S,G) state machine MUST transition to the Pruned (P) | ||||
| state, send a Prune(S,G) to RPF'(S) and set PLT(S,G) to t_limit | ||||
| seconds. | ||||
| RPF'(S) Changes AND olist(S,G) is non-NULL AND S NOT directly | ||||
| connected | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine MUST | ||||
| transition to the AckPending (AP) state, unicast a Graft to the new | ||||
| RPF'(S) and set the GraftRetry Timer (GRT(S,G)) to | ||||
| Graft_Retry_Period. | ||||
| RPF'(S) Changes AND olist(S,G) is NULL | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine MUST | ||||
| transition to the Pruned (P) state. | ||||
| 4.4.1.2. Transitions from the Pruned (P) State | ||||
| When the Upstream(S,G) state machine is in the Pruned (P) state, the | ||||
| following events may trigger a transition: | ||||
| Data arrives on RPF_interface(S) AND PLT(S,G) not running AND S NOT | ||||
| directly connected | ||||
| Either another router on the LAN desires traffic from S addressed to | ||||
| G or a previous Prune was lost. In order to prevent generating a | ||||
| Prune(S,G) in response to every data packet, the PruneLimit Timer | ||||
| (PLT(S,G)) is used. Once the PLT(S,G) expires, the router needs to | ||||
| send another prune in response to a data packet not received | ||||
| directly from the source. A Prune(S,G) MUST be sent to RPF'(S) and | ||||
| the PLT(S,G) MUST be set to t_limit. | ||||
| State Refresh(S,G) Received from RPF'(S) | ||||
| The Upstream(S,G) state machine remains in a Pruned state. If the | ||||
| State Refresh has its Prune Indicator bit set to zero and PLT(S,G) | ||||
| is not running, a Prune(S,G) MUST be sent to RPF'(S) and the | ||||
| PLT(S,G) MUST be set to t_limit. If the State Refresh has its Prune | ||||
| Indicator bit set to one, the router MUST reset PLT(S,G) to t_limit. | ||||
| See Prune(S,G) to RPF'(S) | ||||
| A Prune(S,G) is seen on RPF_interface(S) to RPF'(S). The | ||||
| Upstream(S,G) state machine stays in the Pruned (P) state. The | ||||
| router MAY reset its PLT(S,G) to the value in the Holdtime field of | ||||
| the received message if greater than the current value of the | ||||
| PLT(S,G). | ||||
| olist(S,G)->non-NULL AND S NOT directly connected | ||||
| The set of interfaces defined by the olist(S,G) macro becomes | ||||
| non-empty indicating traffic from S addressed to group G must be | ||||
| forwarded. The Upstream(S,G) state machine MUST cancel PLT(S,G), | ||||
| transition to the AckPending (AP) state and unicast a Graft message | ||||
| to RPF'(S). The Graft Retry Timer (GRT(S,G)) MUST be set to | ||||
| Graft_Retry_Period. | ||||
| RPF'(S) Changes AND olist(S,G) == non-NULL AND S NOT directly | ||||
| connected | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine MUST | ||||
| cancel PLT(S,G), transition to the AckPending (AP) state, send a | ||||
| Graft unicast to the new RPF'(S) and set the GraftRetry Timer | ||||
| (GRT(S,G)) to Graft_Retry_Period. | ||||
| RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine stays | ||||
| in the Pruned (P) state and MUST cancel the PLT(S,G) timer. | ||||
| S becomes directly connected | ||||
| Unicast routing changed so that S is directly connected. The | ||||
| Upstream(S,G) state machine remains in the Pruned (P) state. | ||||
| 4.4.1.3. Transitions from the AckPending (AP) State | ||||
| When the Upstream(S,G) state machine is in the AckPending (AP) state, | ||||
| the following events may trigger a transition: | ||||
| State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 1 | ||||
| The Upstream(S,G) state machine remains in an AckPending state. The | ||||
| router must override the upstream router's Prune state after a short | ||||
| random interval. If OT(S,G) is not running and the Prune Indicator | ||||
| bit equals one, the router MUST set OT(S,G) to t_override seconds. | ||||
| State Refresh(S,G) Received from RPF'(S) with Prune Indicator == 0 | ||||
| The router MUST cancel its GraftRetry Timer (GRT(S,G)) and | ||||
| transition to the Forwarding (F) state. | ||||
| See Join(S,G) to RPF'(S,G) | ||||
| This event is only relevant if RPF_interface(S) is a shared medium. | ||||
| This router sees another router on RPF_interface(S) send a Join(S,G) | ||||
| to RPF'(S,G). If the OT(S,G) is running, then it means that the | ||||
| router had scheduled a Join to override a previously received Prune. | ||||
| Another router has responded more quickly with a Join and so the | ||||
| local router SHOULD cancel its OT(S,G), if it is running. The | ||||
| Upstream(S,G) state machine remains in the AckPending (AP) state. | ||||
| See Prune(S,G) | ||||
| This event is only relevant if RPF_interface(S) is a shared medium. | ||||
| This router sees another router on RPF_interface(S) send a | ||||
| Prune(S,G). As this router is in AckPending (AP) state, it must | ||||
| override the Prune after a short random interval. If OT(S,G) is not | ||||
| running, the router MUST set OT(S,G) to t_override seconds. The | ||||
| Upstream(S,G) state machine remains in AckPending (AP) state. | ||||
| OT(S,G) Expires | ||||
| The OverrideTimer (OT(S,G)) expires. The router MUST send a | ||||
| Join(S,G) to RPF'(S). The Upstream(S,G) state machine remains in | ||||
| the AckPending (AP) state. | ||||
| olist(S,G) -> NULL | ||||
| The set of interfaces defined by the olist(S,G) macro becomes null | ||||
| indicating traffic from S addressed to group G should no longer be | ||||
| forwarded. The Upstream(S,G) state machine MUST transition to the | ||||
| Pruned (P) state. A Prune(S,G) MUST be multicast to the | ||||
| RPF_interface(S) with RPF'(S) named in the upstream neighbor field. | ||||
| The GraftRetry Timer (GRT(S,G)) MUST be cancelled and PLT(S,G) MUST | ||||
| be set to t_limit seconds. | ||||
| RPF'(S) Changes AND olist(S,G) does not become NULL AND S NOT directly | ||||
| connected | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine stays | ||||
| in the AckPending (AP) state. A Graft MUST be unicast to the new | ||||
| RPF'(S) and the GraftRetry Timer (GRT(S,G)) reset to | ||||
| Graft_Retry_Period. | ||||
| RPF'(S) Changes AND olist(S,G) == NULL AND S NOT directly connected | ||||
| Unicast routing or Assert state causes RPF'(S) to change, including | ||||
| changes to RPF_Interface(S). The Upstream(S,G) state machine MUST | ||||
| transition to the Pruned (P) state. The GraftRetry Timer (GRT(S,G)) | ||||
| MUST be cancelled. | ||||
| S becomes directly connected | ||||
| Unicast routing has changed so that S is directly connected. The | ||||
| GraftRetry Timer MUST be cancelled and the Upstream(S,G) state | ||||
| machine MUST transition to the Forwarding(F) state. | ||||
| GRT(S,G) Expires | ||||
| The GraftRetry Timer (GRT(S,G)) expires for this (S,G) entry. The | ||||
| Upstream(S,G) state machine stays in the AckPending (AP) state. | ||||
| Another Graft message for (S,G) SHOULD be unicasted to RPF'(S) and | ||||
| the GraftRetry Timer (GRT(S,G)) reset to Graft_Retry_Period. It is | ||||
| RECOMMENDED that the router retry a configured number of times | ||||
| before ceasing retries. | ||||
| See GraftAck(S,G) from RPF'(S) | ||||
| A GraftAck is received from RPF'(S). The GraftRetry Timer MUST be | ||||
| cancelled and the Upstream(S,G) state machine MUST transition to the | ||||
| Forwarding(F) state. | ||||
| 4.4.2 Downstream Prune, Join and Graft Messages | ||||
| The Prune(S,G) Downstream state machine for receiving Prune, Join and | ||||
| Graft messages on interface I is given below. This state machine MUST | ||||
| always be in the NoInfo state on the upstream interface. It contains | ||||
| three states. | ||||
| NoInfo(NI) | ||||
| The interface has no (S,G) Prune state and neither the Prune timer | ||||
| (PT(S,G,I)) nor the PrunePending timer ((PPT(S,G,I)) is running. | ||||
| PrunePending(PP) | ||||
| The router has received a Prune(S,G) on this interface from a | ||||
| downstream neighbor and is waiting to see whether the prune will be | ||||
| overridden by another downstream router. For forwarding purposes, | ||||
| the PrunePending state functions exactly like the NoInfo state. | ||||
| Pruned(P) | ||||
| The router has received a Prune(S,G) on this interface from a | ||||
| downstream neighbor and the Prune was not overridden. Data from S | ||||
| addressed to group G is no longer being forwarded on this interface. | ||||
| In addition there are two timers: | ||||
| PrunePending Timer (PPT(S,G,I)) | ||||
| This timer is set when a valid Prune(S,G) is received. Expiry of | ||||
| the PrunePending Timer (PPT(S,G,I)) causes the interface to | ||||
| transition to the Pruned state. | ||||
| Prune Timer (PT(S,G,I)) | ||||
| This timer is set when the PrunePending Timer (PT(S,G,I)) expires. | ||||
| Expiry of the Prune Timer (PT(S,G,I)) causes the interface to | ||||
| transition to the NoInfo (NI) state, thereby allowing data from S | ||||
| addressed to group G to be forwarded on the interface. | ||||
| +-------------+ +-------------+ | ||||
| | | PPT Expires | | | ||||
| |PrunePending |----------------------->| Pruned | | ||||
| | | | | | ||||
| +-------------+ +-------------+ | ||||
| | ^ | | ||||
| | | | | ||||
| | |Rcv Prune | | ||||
| | | | | ||||
| | | +-------------+ | | ||||
| | +---------| | | | ||||
| | | NoInfo |<-------------+ | ||||
| +------------>| | Rcv Join/Graft OR | ||||
| Rcv Join/Graft OR +-------------+ PT Expires OR | ||||
| RPF_Interface(S)->I RPF_Interface(S)->I | ||||
| Figure 2: Downstream Interface State Machine | ||||
| In tabular form, the state machine is: | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | | Previous State | | ||||
| + +------------+------------+------------+ | ||||
| | Event | No Info | PrunePend | Pruned | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Receive Prune(S,G) |->PP Set |->PP |->P Reset | | ||||
| | | PPT(S,G,I) | | PT(S,G,I) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Receive Join(S,G) |->NI |->NI Cancel |->NI Cancel | | ||||
| | | | PPT(S,G,I) | PT(S,G,I) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Receive Graft(S,G) |->NI Send |->NI Send |->NI Send | | ||||
| | | GraftAck | GraftAck | GraftAck | | ||||
| | | | Cancel | Cancel | | ||||
| | | | PPT(S,G,I) | PT(S,G,I) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | PPT(S,G) Expires | N/A |->P Set | N/A | | ||||
| | | | PT(S,G,I) | | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | PT(S,G) Expires | N/A | N/A |->NI | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | RPF_Interface(S) becomes I |->NI |->NI Cancel |->NI Cancel | | ||||
| | | | PPT(S,G,I) | PT(S,G,I) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Send State Refresh(S,G) out I |->NI |->PP |->P Reset | | ||||
| | | | | PT(S,G,I) | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| The transition events "Receive Graft(S,G)", "Receive Prune(S,G)" and | ||||
| "Receive Join(S,G)" denote receiving a Graft, Prune or Join message in | ||||
| which this router's address on I is contained in the message's upstream | ||||
| neighbor field. If the upstream neighbor field does not match this | ||||
| router's address on I, then these state transitions in this state | ||||
| machine must not occur. | ||||
| 4.4.2.1. Transitions from the NoInfo State | ||||
| When the Prune(S,G) Downstream state machine is in the NoInfo (NI) | ||||
| state, the following events may trigger a transition: | ||||
| Receive Prune(S,G) | ||||
| A Prune(S,G) is received on interface I with the upstream neighbor | ||||
| field set to the router's address on I. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the PrunePending | ||||
| (PP) state. The PrunePending Timer (PPT(S,G,I)) MUST be set to | ||||
| J/P_Override_Interval if the router has more than one neighbor on I. | ||||
| If the router has only one neighbor on interface I, then it SHOULD | ||||
| set the PPT(S,G,I) to zero, effectively transitioning immediately to | ||||
| the Pruned (P) state. | ||||
| Receive Graft(S,G) | ||||
| A Graft(S,G) is received on the interface I with the upstream | ||||
| neighbor field set to the router's address on I. The Prune(S,G) | ||||
| Downstream state machine on interface I stays in the NoInfo (NI) | ||||
| state. A GraftAck(S,G) MUST be unicasted to the originator of the | ||||
| Graft(S,G) message. | ||||
| 4.4.2.2. Transitions from the PrunePending (PP) State | ||||
| When the Prune(S,G) downstream state machine is in the PrunePending (PP) | ||||
| state, the following events may trigger a transition. | ||||
| Receive Join(S,G) | ||||
| A Join(S,G) is received on interface I with the upstream neighbor | ||||
| field set to the router's address on I. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the NoInfo (NI) | ||||
| state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. | ||||
| Receive Graft(S,G) | ||||
| A Graft(S,G) is received on interface I with the upstream neighbor | ||||
| field set to the router's address on I. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the NoInfo (NI) | ||||
| state and MUST unicast a Graft Ack message to the Graft originator. | ||||
| The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. | ||||
| PPT(S,G,I) Expires | ||||
| The PrunePending Timer (PPT(S,G,I)) expires indicating that no | ||||
| neighbors have overridden the previous Prune(S,G) message. The | ||||
| Prune(S,G) Downstream state machine on interface I MUST transition | ||||
| to the Pruned (P) state. The Prune Timer (PT(S,G,I)) is started and | ||||
| MUST be initialized to the received Prune_Hold_Time minus | ||||
| J/P_Override_Interval. A PruneEcho(S,G) MUST be sent on I if I has | ||||
| more than one PIM neighbor. A PruneEcho(S,G) is simply a Prune(S,G) | ||||
| message multicast by the upstream router to a LAN with itself as the | ||||
| Upstream Neighbor. Its purpose is to add additional reliability so | ||||
| that if a Join that should have overridden the Prune is lost locally | ||||
| on the LAN, then the PruneEcho(S,G) may be received and trigger a | ||||
| new Join message . A PruneEcho(S,G) is OPTIONAL on an interface | ||||
| with only one PIM neighbor. In addition, the router MUST evaluate | ||||
| any possible transitions in the Upstream(S,G) state machine. | ||||
| RPF_Interface(S) becomes interface I | ||||
| The upstream interface for S has changed. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the NoInfo (NI) | ||||
| state. The PrunePending Timer (PPT(S,G,I)) MUST be cancelled. | ||||
| 4.4.2.3. Transitions from the Prune (P) State | ||||
| When the Prune(S,G) Downstream state machine is in the Pruned (P) state, | ||||
| the following events may trigger a transition. | ||||
| Receive Prune(S,G) | ||||
| A Prune(S,G) is received on the interface I with the upstream | ||||
| neighbor field set to the router's address on I. The Prune(S,G) | ||||
| Downstream state machine on interface I remains in the Pruned (P) | ||||
| state. The Prune Timer (PT(S,G,I)) SHOULD be reset to the holdtime | ||||
| contained in the Prune(S,G) message if it is greater than the | ||||
| current value. | ||||
| Receive Join(S,G) | ||||
| A Join(S,G) is received on the interface I with the upstream | ||||
| neighbor field set to the router's address on I. The Prune(S,G) | ||||
| downstream state machine on interface I MUST transition to the | ||||
| NoInfo (NI) state. The Prune Timer (PT(S,G,I)) MUST be cancelled. | ||||
| The router MUST evaluate any possible transitions in the | ||||
| Upstream(S,G) state machine. | ||||
| Receive Graft(S,G) | ||||
| A Graft(S,G) is received on interface I with the upstream neighbor | ||||
| field set to the router's address on I. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the NoInfo (NI) | ||||
| state and send a Graft Ack back to the Graft's source. The Prune | ||||
| Timer (PT(S,G,I)) MUST be cancelled. The router MUST evaluate any | ||||
| possible transitions in the Upstream(S,G) state machine. | ||||
| PT(S,G,I) Expires | ||||
| The Prune Timer (PT(S,G,I)) expires indicating that it is again time | ||||
| to flood data from S addressed to group G onto interface I. The | ||||
| Prune(S,G) Downstream state machine on interface I MUST transition | ||||
| to the NoInfo (NI) state. The router MUST evaluate any possible | ||||
| transitions in the Upstream(S,G) state machine. | ||||
| RPF_Interface(S) becomes interface I | ||||
| The upstream interface for S has changed. The Prune(S,G) Downstream | ||||
| state machine on interface I MUST transition to the NoInfo (NI) | ||||
| state. The PruneTimer (PT(S,G,I)) MUST be cancelled. | ||||
| Send State Refresh(S,G) out interface I | ||||
| The router has refreshed the Prune(S,G) state on interface I. The | ||||
| router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime from | ||||
| an active Prune received on interface I. The Holdtime used SHOULD | ||||
| be the largest active one, but MAY be the most recently received | ||||
| active Prune Holdtime. | ||||
| 4.5. State Refresh | ||||
| This section describes the major portions of the state refresh | ||||
| mechanism. | ||||
| 4.5.1. Forwarding of State Refresh Messages | ||||
| When a State Refresh message, SRM, is received, it is forwarded | ||||
| according to the following pseudo-code. | ||||
| if (iif != RPF_interface(S)) | ||||
| return; | ||||
| if (RPF'(S) != srcaddr(SRM)) | ||||
| return; | ||||
| if (StateRefreshRateLimit(S,G) == TRUE) | ||||
| return; | ||||
| for each interface I in pim_nbrs { | ||||
| if (TTL(SRM) == 0 OR (TTL(SRM) - 1) < Threshold(I)) | ||||
| continue; /* Out of TTL, skip this interface */ | ||||
| if (boundary(I,G)) | ||||
| continue; /* This interface is scope boundary, skip it */ | ||||
| if (I == iif) | ||||
| continue; /* This is the incoming interface, skip it */ | ||||
| if (lost_assert(S,G,I) == TRUE) | ||||
| continue; /* Let the Assert Winner do State Refresh */ | ||||
| Copy SRM to SRM'; /* Make a copy of SRM to forward */ | ||||
| if (I contained in prunes(S,G)) { | ||||
| set Prune Indicator bit of SRM' to 1; | ||||
| if StateRefreshCapable(I) == TRUE | ||||
| set PT(S,G) to largest active holdtime read from a Prune message | ||||
| accepted on I; | ||||
| } else { | ||||
| set Prune Indicator bit of SRM' to 0; | ||||
| } | ||||
| set srcaddr(SRM') to my_addr(I); | ||||
| set TTL of SRM' to TTL(SRM) - 1; | ||||
| set metric of SRM' to metric of unicast route used to reach S; | ||||
| set pref of SRM' to preference of unicast route used to reach S; | ||||
| set mask of SRM' to mask of route used to reach S; | ||||
| if (AssertState == NoInfo) { | ||||
| set Assert Override of SRM' to 1; | ||||
| } else { | ||||
| set Assert Override of SRM' to 0; | ||||
| } | ||||
| transmit SRM' on I; | ||||
| } | ||||
| The pseudocode above employs the following macro definitions. | ||||
| Boundary(I,G) evaluates to TRUE if an administratively scoped boundary | ||||
| for group G is configured on interface I. | ||||
| StateRefreshCapable(I) evaluates to TRUE if all neighbors on an | ||||
| interface use the State Refresh option. | ||||
| StateRefreshRateLimit(S,G) evaluates to TRUE if the time elapsed since | ||||
| the last received StateRefresh(S,G) is less than the configured | ||||
| RefreshLimitInterval. | ||||
| TTL(SRM) returns the TTL contained in the State Refresh Message, SRM. | ||||
| This is different from the TTL contained in the IP header. | ||||
| Threshold(I) returns the minimum TTL that a packet must have before it | ||||
| can be transmitted on interface I. | ||||
| srcaddr(SRM) returns the source address contained in the network | ||||
| protocol (e.g. IPv4) header of the State Refresh Message, SRM. | ||||
| my_addr(I) returns this node's network (e.g. IPv4) address on interface | ||||
| I. | ||||
| 4.5.2 State Refresh Message Origination | ||||
| This section describes the origination of State Refresh messages. These | ||||
| messages are generated periodically by the PIM-DM router that is | ||||
| directly connected to a source. One Origination(S,G) state machine | ||||
| exists per (S,G) entry in a PIM-DM router. | ||||
| The Origination(S,G) state machine has the following states: | ||||
| NotOriginator(NO) | ||||
| This is the starting state of the Origination(S,G) state machine. | ||||
| While in this state a router will not originate State Refresh | ||||
| messages for the (S,G) pair. | ||||
| Originator(O) | ||||
| When in this state the router will periodically originate State | ||||
| Refresh messages. Only routers which are directly connected to S | ||||
| may transition to this state. | ||||
| In addition there are two state-machine-specific timers: | ||||
| State Refresh Timer (SRT(S,G)) | ||||
| This timer is controls when State Refresh messages are generated. | ||||
| The timer is initially set when that Origination(S,G) state machine | ||||
| transitions to the O state. It is cancelled when the | ||||
| Origination(S,G) state machine transitions to the NO state. This | ||||
| timer is normally set to StateRefreshInterval (see 4.8). | ||||
| Source Active Timer (SAT(S,G)) | ||||
| This timer is first set when the Origination(S,G) state machine | ||||
| transitions to the O state and is reset on the receipt of every | ||||
| data packet from S addressed to group G. When it expires, the | ||||
| Origination(S,G) state machine transitions to the NO state. This | ||||
| timer is normally set to SourceLifetime (see 4.8). | ||||
| +-------------+ Rcv Directly From S +-------------+ | ||||
| | |----------------------->| | | ||||
| |NotOriginator| | Originator | | ||||
| | |<-----------------------| | | ||||
| +-------------+ SAT Expires OR +-------------+ | ||||
| S NOT Direct Connect | ||||
| Figure 3: State Refresh State Machine | ||||
| In tabular form, the state machine is defined as follows: | ||||
| +----------------------------------------------------------------------+ | ||||
| | | Previous State | | ||||
| | +---------------+-------------------+ | ||||
| | Event | NotOriginator | Originator | | ||||
| +----------------------------------+---------------+-------------------+ | ||||
| | Receive Data from S AND | ->O | ->O Reset | | ||||
| | S directly connected | Set SRT(S,G) | SAT(S,G) | | ||||
| | | Set SAT(S,G) | | | ||||
| +----------------------------------+---------------+-------------------+ | ||||
| | SRT(S,G) Expires | N/A | ->O Send | | ||||
| | | | StateRefresh(S,G) | | ||||
| | | | Reset SRT(S,G) | | ||||
| +----------------------------------+---------------+-------------------+ | ||||
| | SAT(S,G) Expires | N/A | ->NO Cancel | | ||||
| | | | SRT(S,G) | | ||||
| +----------------------------------+---------------+-------------------+ | ||||
| | S no longer directly connected | ->NO | ->NO | | ||||
| | | | Cancel SRT(S,G) | | ||||
| | | | Cancel SAT(S,G) | | ||||
| +----------------------------------+---------------+-------------------+ | ||||
| 4.5.2.1. Transitions from the NotOriginator (NO) State | ||||
| When the Originating(S,G) state machine is in the NotOriginator (NO) | ||||
| state, the following event may trigger a transition: | ||||
| Data Packet received from directly connected Source S addressed to | ||||
| group G | ||||
| The router MUST transition to an Originator (O) state, set SAT(S,G) | ||||
| to SourceLifetime, and set SRT(S,G) to StateRefreshInterval. The | ||||
| router SHOULD record the TTL of the packet for use in State Refresh | ||||
| messages. | ||||
| 4.5.2.2. Transitions from the Originator (O) State | ||||
| When the Originating(S,G) state machine is in the Originator (O) state, | ||||
| the following events may trigger a transition: | ||||
| Receive Data Packet from S addressed to G | ||||
| The router remains in the Originator (O) state and MUST reset | ||||
| SAT(S,G) to SourceLifetime. The router SHOULD increase its recorded | ||||
| TTL to match the TTL of the packet, if the packet's TTL is larger | ||||
| than the previously recorded TTL. | ||||
| SRT(S,G) Expires | ||||
| The router remains in the Originator (O) state and MUST reset | ||||
| SRT(S,G) to StateRefreshInterval. The router MUST also generate | ||||
| State Refresh messages for transmission as described in the State | ||||
| Refresh Forwarding rules (section 4.5.1) except for the TTL. If the | ||||
| TTL of data packets from S to G are being recorded, then the TTL of | ||||
| each State Refresh message is set to the highest recorded TTL. | ||||
| Otherwise, the TTL is set to the configured State Refresh TTL. Let | ||||
| I denote the interface over which a State Refresh message is being | ||||
| sent. If the Prune(S,G) Downstream state machine for I is in the | ||||
| NoInfo (NI) state, then the Prune-Indicator bit MUST be set to 0 in | ||||
| the State Refresh message being sent over I. Otherwise the | ||||
| Prune-Indicator bit MUST be set to 1. | ||||
| SAT(S,G) Expires | ||||
| The router MUST cancel the SRT(S,G) timer and transition to the | ||||
| NotOriginator (NO) state. | ||||
| S is no longer directly connected | ||||
| The router MUST transition to the NotOriginator (NO) state and | ||||
| cancel both the SAT(S,G) and SRT(S,G). | ||||
| 4.6. PIM Assert Messages | ||||
| 4.6.1. Assert Metrics | ||||
| Assert metrics are defined as: | ||||
| struct assert_metric { | ||||
| metric_preference; | ||||
| route_metric; | ||||
| ip_address; | ||||
| }; | ||||
| When comparing assert_metrics, the metric_preference and route_metric | ||||
| field are compared in order, where the first lower value wins. If all | ||||
| fields are equal, the IP address of the router that sourced the Assert | ||||
| message is used as a tie-breaker, with the highest IP address winning. | ||||
| An Assert metric for (S,G) to include in (or compare against) an Assert | ||||
| message sent on interface I should be computed using the following | ||||
| pseudocode: | ||||
| assert_metric | ||||
| my_assert_metric(S,G,I) { | ||||
| if (CouldAssert(S,G,I) == TRUE) { | ||||
| return spt_assert_metric(S,G,I) | ||||
| } else { | ||||
| return infinite_assert_metric() | ||||
| } | ||||
| } | ||||
| spt_assert_metric(S,I) gives the Assert metric we use if we're sending | ||||
| an Assert based on active (S,G) forwarding state: | ||||
| assert_metric | ||||
| spt_assert_metric(S,I) { | ||||
| return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)} | ||||
| } | ||||
| MRIB.pref(X) and MRIB.metric(X) are the routing preference and routing | ||||
| metrics associated with the route to a particular (unicast) destination | ||||
| X, as determined by the MRIB. my_addr(I) is simply the router's network | ||||
| (e.g. IP) address that is associated with the local interface I. | ||||
| infinite_assert_metric() gives the Assert metric we need to send an | ||||
| Assert but doesn't match (S,G) forwarding state: | ||||
| assert_metric | ||||
| infinite_assert_metric() { | ||||
| return {1,infinity,infinity,0} | ||||
| } | ||||
| 4.6.2. AssertCancel Messages | ||||
| An AssertCancel(S,G) message is simply an Assert message for (S,G) with | ||||
| infinite metric. The Assert winner sends such a message when it changes | ||||
| its upstream interface to this interface. Other routers will see this | ||||
| metric, causing those with forwarding state to send their own Asserts | ||||
| and re-establish an Assert winner. | ||||
| AssertCancel messages are simply an optimization. The original Assert | ||||
| timeout mechanism will allow a subnet to eventually become consistent; | ||||
| the AssertCancel mechanism simply causes faster convergence. No special | ||||
| processing is required for an AssertCancel message, since it is simply | ||||
| an Assert message from the current winner. | ||||
| 4.6.3. Assert State Macros | ||||
| The macro lost_assert(S,G,I), is used in the olist computations of | ||||
| section 4.1.3, and is defined as follows: | ||||
| bool lost_assert(S,G,I) { | ||||
| if ( RPF_interface(S) == I ) { | ||||
| return FALSE | ||||
| } else { | ||||
| return (AssertWinner(S,G,I) != me AND | ||||
| (AssertWinnerMetric(S,G,I) is better than | ||||
| spt_assert_metric(S,G,I))) | ||||
| } | ||||
| } | ||||
| AssertWinner(S,G,I) defaults to NULL and AssertWinnerMetric(S,G,I) | ||||
| defaults to Infinity when in the NoInfo state. | ||||
| 4.6.4. (S,G) Assert Message State Machine | ||||
| The (S,G) Assert state machine for interface I is shown in Figure 4. | ||||
| There are three states: | ||||
| NoInfo (NI) | ||||
| This router has no (S,G) Assert state on interface I. | ||||
| I am Assert Winner (W) | ||||
| This router has won an (S,G) Assert on interface I. It is now | ||||
| responsible for forwarding traffic from S destined for G via | ||||
| interface I. | ||||
| I am Assert Loser (L) | ||||
| This router has lost an (S,G) Assert on interface I. It must not | ||||
| forward packets from S destined for G onto interface I. | ||||
| In addition there is also an Assert Timer (AT(S,G,I)) that is used to | ||||
| time out Assert state. | ||||
| +-------------+ +-------------+ | ||||
| | | Rcv Pref Assert or SR | | | ||||
| | Winner |----------------------->| Loser | | ||||
| | | | | | ||||
| +-------------+ +-------------+ | ||||
| ^ | ^ | | ||||
| | | Rcv Pref Assert or| | | ||||
| | |AT Expires OR State Refresh| | | ||||
| | |CouldAssert->FALSE | | | ||||
| | | | | | ||||
| | | +-------------+ | | | ||||
| | +-------->| |----------+ | | ||||
| | | No Info | | | ||||
| +-------------| |<-------------+ | ||||
| Rcv Data from dnstrm +-------------+ Rcv Inf Assert from Win OR | ||||
| OR Rcv Inferior Assert Rcv Inf SR from Winner OR | ||||
| OR Rcv Inferior SR AT Expires OR | ||||
| CouldAssert Changes OR | ||||
| Winner's NLT Expires | ||||
| Figure 4: Assert State Machine | ||||
| In tabular form the state machine is defined as follows: | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | | Previous State | | ||||
| | +------------+------------+------------+ | ||||
| | Event | No Info | Winner | Loser | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | An (S,G) Data packet received | ->W Send | ->W Send | ->L | | ||||
| | on downstream interface | Assert(S,G)| Assert(S,G)| | | ||||
| | | Set | Set | | | ||||
| | | AT(S,G,I) | AT(S,G,I) | | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | Receive Inferior (Assert OR | N/A | N/A |->NI Cancel | | ||||
| | State Refresh) from Assert | | | AT(S,G,I) | | ||||
| | Winner | | | | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | Receive Inferior (Assert OR | ->W Send | ->W Send | ->L | | ||||
| | State Refresh) from non-Assert| Assert(S,G)| Assert(S,G)| | | ||||
| | Winner AND CouldAssert==TRUE | Set | Set | | | ||||
| | | AT(S,G,I) | AT(S,G,I) | | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | | Previous State | | ||||
| | +------------+------------+------------+ | ||||
| | Event | No Info | Winner | Loser | | ||||
| +-------------------------------+------------+------------+------------+ | ||||
| | Receive Preferred Assert OR | ->L Send | ->L Send | ->L Set | | ||||
| | State Refresh | Prune(S,G) | Prune(S,G) | AT(S,G,I) | | ||||
| | | Set | Set | | | ||||
| | | AT(S,G,I) | AT(S,G,I) | | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | Send State Refresh | ->NI | ->W Reset | N/A | | ||||
| | | | AT(S,G,I) | | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | AT(S,G) Expires | N/A | ->NI | ->NI | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | CouldAssert -> FALSE | ->NI |->NI Cancel |->NI Cancel | | ||||
| | | | AT(S,G,I) | AT(S,G,I) | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | CouldAssert -> TRUE | ->NI | N/A |->NI Cancel | | ||||
| | | | | AT(S,G,I) | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | Winner's NLT(N,I) Expires | N/A | N/A |->NI Cancel | | ||||
| | | | | AT(S,G,I) | | ||||
| +-------------------------------+--------------------------------------+ | ||||
| | Receive Prune(S,G), Join(S,G) | ->NI | ->W | ->L Send | | ||||
| | or Graft(S,G) | | | Assert(S,G)| | ||||
| +-------------------------------+--------------------------------------+ | ||||
| Terminology: | ||||
| A "preferred assert" is one with a better metric than the current | ||||
| winner. An "inferior assert" is one with a worse metric than | ||||
| my_assert_metric(S,G,I). | ||||
| The state machine uses the following macro: | ||||
| CouldAssert(S,G,I) = (RPF_interface(S) != I) | ||||
| 4.6.4.1. Transitions from NoInfo State | ||||
| When in NoInfo state, the following events may trigger transitions: | ||||
| An (S,G) data packet arrives on downstream interface I | ||||
| An (S,G) data packet arrived on a downstream interface. It is | ||||
| optimistically assumed that this router will be the Assert winner | ||||
| for this (S,G). The Assert state machine MUST transition to the "I | ||||
| am Assert Winner" state, send an Assert(S,G) to interface I, store | ||||
| its own address and metric as the Assert Winner and set the | ||||
| Assert_Timer (AT(S,G,I) to Assert_Time, thereby initiating the | ||||
| Assert negotiation for (S,G). | ||||
| Receive Inferior (Assert OR State Refresh) AND | ||||
| CouldAssert(S,G,I)==TRUE | ||||
| An Assert or State Refresh is received for (S,G) that is inferior | ||||
| to our own assert metric on interface I. The Assert state machine | ||||
| MUST transition to the "I am Assert Winner" state, send an | ||||
| Assert(S,G) to interface I, store its own address and metric as the | ||||
| Assert Winner and set the Assert Timer (AT(S,G,I)) to Assert_Time. | ||||
| Receive Preferred Assert or State Refresh | ||||
| The received Assert or State Refresh has a better metric than this | ||||
| router's and therefore the Assert state machine MUST transition to | ||||
| the "I am Assert Loser" state and store the Assert Winner's address | ||||
| and metric. If the metric was received in an Assert, the router MUST | ||||
| set the Assert Timer (AT(S,G,I)) to Assert_Time. If the metric was | ||||
| received in a State Refresh, the router MUST set the Assert Timer | ||||
| (AT(S,G,I)) to three times the received State Refresh Interval. If | ||||
| CouldAssert(S,G,I) == TRUE, the router MUST also multicast a | ||||
| Prune(S,G) to the Assert winner with a Prune Hold Time equal to the | ||||
| Assert Timer and evaluate any changes in its Upstream(S,G) state | ||||
| machine. | ||||
| 4.6.4.2. Transitions from Winner State | ||||
| When in "I am Assert Winner" state, the following events trigger | ||||
| transitions: | ||||
| An (S,G) data packet arrives on downstream interface I | ||||
| An (S,G) data packet arrived on a downstream interface. The Assert | ||||
| state machine remains in the "I am Assert Winner" state. The router | ||||
| MUST send an Assert(S,G) to interface I and set the Assert Timer | ||||
| (AT(S,G,I) to Assert_Time. | ||||
| Receive Inferior Assert or State Refresh | ||||
| An (S,G) Assert is received containing a metric for S that is worse | ||||
| metric than this router's metric for S. Whoever sent the Assert is | ||||
| in error. The router MUST send an Assert(S,G) to interface I and | ||||
| reset the Assert Timer (AT(S,G,I)) to Assert_Time. | ||||
| Receive Preferred Assert or State Refresh | ||||
| An (S,G) Assert or State Refresh is received that has a better | ||||
| metric than this router's metric for S on interface I. The Assert | ||||
| state machine MUST transition to "I am Assert Loser" state and | ||||
| store the new Assert Winner's address and metric. If the metric was | ||||
| received in an Assert, the router MUST set the Assert Timer | ||||
| (AT(S,G,I)) to Assert_Time. If the metric was received in a State | ||||
| Refresh, the router MUST set the Assert Timer (AT(S,G,I)) to three | ||||
| times the State Refresh Interval. The router MUST also multicast a | ||||
| Prune(S,G) to the Assert winner with a Prune Hold Time equal to the | ||||
| Assert Timer and evaluate any changes in its Upstream(S,G) state | ||||
| machine. | ||||
| Send State Refresh | ||||
| The router is sending a State Refresh(S,G) message on interface I. | ||||
| The router MUST set the Assert Timer (AT(S,G,I)) to three times the | ||||
| State Refresh Interval contained in the State Refresh(S,G) message. | ||||
| AT(S,G,I) Expires | ||||
| The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state machine | ||||
| MUST transition to the NoInfo (NI) state. | ||||
| CouldAssert(S,G,I) -> FALSE | ||||
| This router's RPF interface changed so as to make CouldAssert(S,G,I) | ||||
| become false. This router can no longer perform the actions of the | ||||
| Assert winner, and so the Assert state machine MUST transition to | ||||
| NoInfo (NI) state, send an AssertCancel(S,G) to interface I, cancel | ||||
| the Assert Timer (AT(S,G,I)) and remove itself as the Assert Winner. | ||||
| 4.6.4.3. Transitions from Loser State | ||||
| When in "I am Assert Loser" state, the following transitions can occur: | ||||
| Receive Inferior Assert or State Refresh from Current Winner | ||||
| An Assert or State Refresh is received from the current Assert | ||||
| winner that is worse than this router's metric for S (typically the | ||||
| winner's metric became worse). The Assert state machine MUST | ||||
| transition to NoInfo (NI) state and cancel AT(S,G,I). The router | ||||
| MUST delete the previous Assert Winner's address and metric and | ||||
| evaluate any possible transitions to its Upstream(S,G) state | ||||
| machine. Usually this router will eventually re-assert and win when | ||||
| data packets from S have started flowing again. | ||||
| Receive Preferred Assert or State Refresh | ||||
| An Assert or State Refresh is received that has a metric better than | ||||
| or equal to that of the current Assert winner. The Assert state | ||||
| machine remains in Loser (L) state. If the metric was received in | ||||
| an Assert, the router MUST set the Assert Timer (AT(S,G,I)) to | ||||
| Assert_Time. If the metric was received in a State Refresh, the | ||||
| router MUST set the Assert Timer (AT(S,G,I)) to three times the | ||||
| received State Refresh Interval. If the metric is better than the | ||||
| current Assert Winner, the router MUST store the address and metric | ||||
| of the new Assert Winner and if CouldAssert(S,G,I) == TRUE, the | ||||
| router MUST multicast a Prune(S,G) to the new Assert winner. | ||||
| AT(S,G,I) Expires | ||||
| The (S,G) Assert Timer (AT(S,G,I)) expires. The Assert state | ||||
| machine MUST transition to NoInfo (NI) state. The router MUST | ||||
| delete the Assert Winner's address and metric. If CouldAssert == | ||||
| TRUE, the router MUST evaluate any possible transitions to its | ||||
| Upstream(S,G) state machine. | ||||
| CouldAssert -> FALSE | ||||
| CouldAssert has become FALSE because interface I has become the RPF | ||||
| interface for S. The Assert state machine MUST transition to NoInfo | ||||
| (NI) state, cancel AT(S,G,I) and delete information concerning the | ||||
| Assert Winner on I. | ||||
| CouldAssert -> TRUE | ||||
| CouldAssert has become TRUE because interface I used to be the RPF | ||||
| interface for S, and now it is not. The Assert state machine MUST | ||||
| transition to NoInfo (NI) state, cancel AT(S,G,I) and delete | ||||
| information concerning the Assert Winner on I. | ||||
| Current Assert Winner's NeighborLiveness Timer Expires | ||||
| The current Assert winner's NeighborLiveness Timer (NLT(N,I)) has | ||||
| expired. The Assert state machine MUST transition to the NoInfo | ||||
| (NI) state, delete the Assert Winner's address and metric, and | ||||
| evaluate any possible transitions to its Upstream(S,G) state | ||||
| machine. | ||||
| Receive Prune(S,G), Join(S,G) or Graft(S,G) | ||||
| A Prune(S,G), Join(S,G) or Graft(S,G) message was received on | ||||
| interface I with its upstream neighbor address set to the router's | ||||
| address on I. The router MUST send an Assert(S,G) on the receiving | ||||
| interface I to initiate an Assert negotiation. The Assert state | ||||
| machine remains in the Assert Loser(L) state. If a Graft(S,G) was | ||||
| received, the router MUST respond with a GraftAck(S,G). | ||||
| 4.6.5. Rationale for Assert Rules | ||||
| The following is a summary of the rules for generating and processing | ||||
| Assert messages. It is not intended to be definitive (the state | ||||
| machines and pseudocode provide the definitive behavior). Instead it | ||||
| provides some rationale for the behavior. | ||||
| 1. The Assert winner for (S,G) must act as the local forwarder for (S,G) | ||||
| on behalf of all downstream members. | ||||
| 2. PIM messages are directed towards to the RPF' neighbor and not to the | ||||
| regular RPF neighbor. | ||||
| 3. An Assert loser that receives a Prune(S,G), Join(S,G) or Graft(S,G) | ||||
| directed to it initiates a new Assert negotiation so the downstream | ||||
| router can correct its RPF'(S). | ||||
| 4. An Assert winner for (S,G) sends a cancelling assert when it is about | ||||
| to stop forwarding on an (S,G) entry. Example: if a router is being | ||||
| taken down, then a canceling assert is sent. | ||||
| 4.7. PIM Packet Formats | ||||
| All PIM-DM packets use the same format as PIM-SM packets. In the event | ||||
| of a discrepancy, PIM-SM [4] should be considered the definitive | ||||
| specification. All PIM control messages have IP protocol number 103. | ||||
| All PIM-DM messages MUST be sent with a TTL of 1. All PIM-DM messages | ||||
| except Graft and Graft Ack messages MUST be sent to the ALL-PIM-ROUTERS | ||||
| group. Graft messages SHOULD be unicast to the RPF'(S). Graft Ack | ||||
| messages MUST be unicast to the sender of the Graft. | ||||
| The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS | ||||
| group is 'ff02::d'. | ||||
| 4.7.1. PIM Header | ||||
| All PIM control messages have the following header: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |PIM Ver| Type | Reserved | Checksum | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| PIM Ver | ||||
| PIM version number is 2. | ||||
| Type | ||||
| Types for specific PIM messages. Available types are: | ||||
| 0 = Hello | ||||
| 1 = Register (PIM-SM only) | ||||
| 2 = Register Stop (PIM-SM only) | ||||
| 3 = Join/Prune | ||||
| 4 = Bootstrap (PIM-SM only) | ||||
| 5 = Assert | ||||
| 6 = Graft | ||||
| 7 = Graft Ack | ||||
| 8 = Candidate RP Advertisement (PIM-SM only) | ||||
| 9 = State Refresh | ||||
| Reserved | ||||
| Set to zero on transmission. Ignored upon receipt. | ||||
| Checksum | ||||
| The checksum is standard IP checksum, i.e. the 16 bit one's complement | ||||
| of the one's complement sum of the entire PIM message. For computing | ||||
| checksum, the checksum field is zeroed. | ||||
| For IPv6, the checksum also includes the IPv6 "pseudo-header", as | ||||
| specified in RFC 2460, section 8.1 [13]. | ||||
| 4.7.2. Encoded Unicast Address | ||||
| An Encoded Unicast Address has the following format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Addr Family | Encoding Type | Unicast Address | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | ||||
| Addr Family | ||||
| The PIM Address Family of the 'Unicast Address' field of this address. | ||||
| Values of 0-127 are as assigned by the IANA for Internet Address | ||||
| Families in [9]. Values 128-250 are reserved to be assigned by the | ||||
| IANA for PIM specific Address Families. Values 251-255 are designated | ||||
| for private use. As there is no assignment authority for this space, | ||||
| collisions should be expected. | ||||
| Encoding Type | ||||
| The type of encoding used with a specific Address Family. The value | ||||
| '0' is reserved for this field, and represents the native encoding of | ||||
| the Address Family | ||||
| Unicast Address | ||||
| The unicast address as represented by the given Address Family and | ||||
| Encoding Type. | ||||
| 4.7.3. Encoded Group Address | ||||
| An Encoded Group address has the following format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Group Multicast Address | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | ||||
| Addr Family | ||||
| As described above. | ||||
| Encoding Type | ||||
| As described above. | ||||
| B | ||||
| Indicates the group range should use Bidirectional PIM [16]. | ||||
| Transmitted as zero, ignored upon receipt. | ||||
| Reserved | ||||
| Transmitted as zero. Ignored upon receipt. | ||||
| Z | ||||
| Indicates the group range is an admin scope zone. This is used in the | ||||
| Bootstrap Router Mechanism [18] only. For all other purposes, this bit | ||||
| is set to zero and ignored on receipt. | ||||
| Mask Len | ||||
| The mask length field is 8 bits. The value is the number of | ||||
| contiguous on bits left justified used as a mask, which combined with | ||||
| the address, describes a range of addresses. It is less than or equal | ||||
| to the address length in bits for the given Address Family and | ||||
| Encoding Type. If the message is sent for a single address then the | ||||
| mask length MUST equal the address length. PIM-DM routers MUST only | ||||
| send for a single address. | ||||
| Group Multicast Address | ||||
| The address of the multicast group. | ||||
| 4.7.4. Encoded Source Address | ||||
| An Encoded Source address has the following format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Source Address | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | ||||
| Addr Family | ||||
| As described above. | ||||
| Encoding Type | ||||
| As described above. | ||||
| Rsrvd | ||||
| Reserved. Transmitted as zero. Ignored upon receipt. | ||||
| S | ||||
| The Sparse Bit. Set to 0 for PIM-DM. Ignored upon receipt. | ||||
| W | ||||
| The Wild Card Bit. Set to 0 for PIM-DM. Ignored upon receipt. | ||||
| R | ||||
| The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon | ||||
| receipt. | ||||
| Mask Len | ||||
| As described above. PIM-DM routers MUST only send for a single | ||||
| source address. | ||||
| Source Address | ||||
| The source address. | ||||
| 4.7.5. Hello Message Format | ||||
| The PIM Hello message, as defined by PIM-SM [4], has the following | ||||
| format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |PIM Ver| Type | Reserved | Checksum | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Option Type | Option Length | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Option Value | | ||||
| | ... | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Option Type | Option Length | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Option Value | | ||||
| | ... | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| PIM Ver, Type, Reserved, Checksum | ||||
| Described above. | ||||
| Option Type | ||||
| The type of option given in the Option Value field. Available types | ||||
| are: | ||||
| 0 Reserved | ||||
| 1 Hello Hold Time | ||||
| 2 LAN Prune Delay | ||||
| 3-16 Reserved | ||||
| 17 To be assigned by IANA | ||||
| 18 Deprecated and SHOULD NOT be used | ||||
| 19 DR Priority (PIM-SM Only) | ||||
| 20 Generation ID | ||||
| 21 State Refresh Capable | ||||
| 22 Bidir Capable | ||||
| 23-65000 To be assigned by IANA | ||||
| 65001-65535 Reserved for Private Use [9] | ||||
| Unknown options SHOULD be ignored. | ||||
| 4.7.5.1. Hello Hold Time Option | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type = 1 | Length = 2 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Hold Time | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Hold Time is the number of seconds a receiver MUST keep the neighbor | ||||
| reachable. If the Hold Time is set to '0xffff', the receiver of this | ||||
| message never times out the neighbor. This may be used with dial-on- | ||||
| demand links, to avoid keeping the link up with periodic Hello messages. | ||||
| Furthermore, if the Holdtime is set to '0', the information is timed out | ||||
| immediately. The Hello Hold Time option MUST be used by PIM-DM routers. | ||||
| 4.7.5.2. LAN Prune Delay Option | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type = 2 | Length = 4 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |T| LAN Prune Delay | Override Interval | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| The LAN_Prune_Delay option is used to tune the prune propagation delay | ||||
| on multi-access LANs. The T bit is used by PIM-SM and SHOULD be set to 0 | ||||
| by PIM-DM routers and ignored upon receipt. The LAN Delay and Override | ||||
| Interval fields are time intervals in units of milliseconds and are used | ||||
| to tune the value of the J/P Override Interval and its derived timer | ||||
| values. Section 4.3.5 describes how these values affect the behavior of | ||||
| a router. The LAN Prune Delay SHOULD be used by PIM-DM routers. | ||||
| 4.7.5.3. Generation ID Option | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type = 20 | Length = 4 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Generation ID | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Generation ID is a random value for the interface on which the Hello | ||||
| message is sent. The Generation ID is regenerated whenever PIM | ||||
| forwarding is started or restarted on the interface. The Generation ID | ||||
| option MAY be used by PIM-DM routers. | ||||
| 4.7.5.4. State Refresh Capable Option | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Type = 21 | Length = 4 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Version = 1 | Interval | Reserved | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| The Interval field is the router's configured State Refresh Interval in | ||||
| seconds. The Reserved field is set to zero and ignored upon reception. | ||||
| The State Refresh Capable option MUST be used by State Refresh capable | ||||
| PIM-DM routers. | ||||
| 4.7.6. Join/Prune Message Format | ||||
| PIM Join/Prune messages, as defined in PIM-SM [4], have the following | ||||
| format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |PIM Ver| Type | Reserved | Checksum | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Upstream Neighbor Address (Encoded Unicast Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Reserved | Num Groups | Hold Time | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Multicast Group Address 1 (Encoded Group Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Number of Joined Sources | Number of Pruned Sources | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Joined Source Address 1 (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Joined Source Address n (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Pruned Source Address 1 (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Pruned Source Address n (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Multicast Group Address m (Encoded Group Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Number of Joined Sources | Number of Pruned Sources | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Joined Source Address 1 (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Joined Source Address n (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Pruned Source Address 1 (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | . | | ||||
| | . | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Pruned Source Address n (Encoded Source Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| PIM Ver, Type, Reserved, Checksum | ||||
| Described above. | ||||
| Upstream Neighbor Address | ||||
| The address of the upstream neighbor. The format for this address is | ||||
| given in the Encoded Unicast address in section 4.7.2. PIM-DM routers | ||||
| MUST set this field to the RPF next hop. | ||||
| Reserved | ||||
| Transmitted as zero. Ignored upon receipt. | ||||
| Hold Time | ||||
| The number of seconds a receiving PIM-DM router MUST keep a Prune | ||||
| state alive, unless removed by a Join or Graft message. If the Hold | ||||
| Time is '0xffff', the receiver MUST NOT remove the Prune state unless | ||||
| a corresponding Join or Graft message is received. The Hold Time is | ||||
| ignored in Join messages. | ||||
| Number of Groups | ||||
| Number of multicast group sets contained in the message. | ||||
| Multicast Group Address | ||||
| The multicast group address in the Encoded Multicast address format | ||||
| given in section 4.7.3. | ||||
| Number of Joined Sources | ||||
| Number of Join source addresses listed for a given group. | ||||
| Number of Pruned Sources | ||||
| Number of Prune source addresses listed for a given group. | ||||
| Join Source Address 1..n | ||||
| This list contains the sources from which the sending router wishes to | ||||
| continue to receive multicast messages for the given group on this | ||||
| interface. The addresses use the Encoded Source address format given | ||||
| in section 4.7.4. | ||||
| Prune Source Address 1..n | ||||
| This list contains the sources from which the sending router does not | ||||
| wish to receive multicast messages for the given group on this | ||||
| interface. The addresses use the Encoded Source address format given | ||||
| in section 4.7.4. | ||||
| 4.7.7. Assert Message Format | ||||
| PIM Assert Messages, as defined in PIM-SM [4], have the following | ||||
| format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |PIM Ver| Type | Reserved | Checksum | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Multicast Group Address (Encoded Group Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Source Address (Encoded Unicast Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |R| Metric Preference | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Metric | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| PIM Ver, Type, Reserved, Checksum | ||||
| Described above. | ||||
| Multicast Group Address | ||||
| The multicast group address in the Encoded Multicast address format | ||||
| given in section 4.7.3. | ||||
| Source Address | ||||
| The source address in the Encoded Unicast address format given in | ||||
| section 4.7.2. | ||||
| R | ||||
| The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon | ||||
| receipt. | ||||
| Metric Preference | ||||
| The preference value assigned to the unicast routing protocol that | ||||
| provided the route to the source. | ||||
| Metric | ||||
| The cost metric of the unicast route to the source. The metric is in | ||||
| units applicable to the unicast routing protocol used. | ||||
| 4.7.8. Graft Message Format | ||||
| PIM Graft messages use the same format as Join/Prune messages except the | ||||
| Type field is set to 6. The source address MUST be in the Join section | ||||
| of the message. The Hold Time field SHOULD be zero and SHOULD be | ||||
| ignored when a Graft is received. | ||||
| 4.7.9. Graft Ack Message Format | ||||
| PIM Graft Ack messages are identical in format to the received Graft | ||||
| message except the Type field is set to 7. The Upstream Neighbor | ||||
| Address field SHOULD be set to the sender of the Graft message and | ||||
| SHOULD be ignored upon receipt. | ||||
| 4.7.10. State Refresh Message Format | ||||
| PIM State Refresh Messages have the following format: | ||||
| 0 1 2 3 | ||||
| 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 | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |PIM Ver| Type | Reserved | Checksum | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Multicast Group Address (Encoded Group Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Source Address (Encoded Unicast Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Originator Address (Encoded Unicast Format) | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| |R| Metric Preference | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Metric | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| | Masklen | TTL |P|N|O|Reserved | Interval | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| PIM Ver, Type, Reserved, Checksum | ||||
| Described above. | ||||
| Multicast Group Address | ||||
| The multicast group address in the Encoded Multicast address format | ||||
| given in section 4.7.3. | ||||
| Source Address | ||||
| The address of the data source in the Encoded Unicast address format | ||||
| given in section 4.7.2. | ||||
| Originator Address | ||||
| The address of the first hop router in the Encoded Unicast address | ||||
| format given in section 4.7.2. | ||||
| R | ||||
| The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon | ||||
| receipt. | ||||
| Metric Preference | ||||
| The preference value assigned to the unicast routing protocol that | ||||
| provided the route to the source. | ||||
| Metric | ||||
| The cost metric of the unicast route to the source. The metric is in | ||||
| units applicable to the unicast routing protocol used. | ||||
| Masklen | ||||
| The length of the address mask of the unicast route to the source. | ||||
| TTL | ||||
| Time To Live of the State Refresh message. Decremented each time the | ||||
| message is forwarded. Note that this is different from the IP Header | ||||
| TTL, which is always set to 1. | ||||
| P | ||||
| Prune indicator flag. This MUST be set to 1 if the State Refresh is | ||||
| to be sent on a Pruned interface. Otherwise, it MUST be set to 0. | ||||
| N | ||||
| Prune Now flag. This SHOULD be set to 1 by the State Refresh | ||||
| originator on every third State Refresh message and SHOULD be ignored | ||||
| upon receipt. This is for compatibility with earlier versions of | ||||
| state refresh. | ||||
| O | ||||
| Assert Override flag. This SHOULD be set to 1 by upstream routers on | ||||
| a LAN if the Assert Timer (AT(S,G)) is not running and SHOULD be | ||||
| ignored upon receipt. This is for compatibility with earlier versions | ||||
| of state refresh. | ||||
| Reserved | ||||
| Set to zero and ignored upon receipt. | ||||
| Interval | ||||
| Set by the originating router to the interval (in seconds) between | ||||
| consecutive State Refresh messages for this (S,G) pair. | ||||
| 4.8. PIM-DM Timers | ||||
| PIM-DM maintains the following timers. All timers are countdown timers | ||||
| - they are set to a value and count down to zero, at which point they | ||||
| typically trigger an action. Of course they can just as easily be | ||||
| implemented as count-up timers, where the absolute expiry time is stored | ||||
| and compared against a real-time clock, but the language in this | ||||
| specification assumes that they count downwards towards zero. | ||||
| Global Timers | ||||
| Hello Timer: HT | ||||
| Per interface (I): | ||||
| Per neighbor (N): | ||||
| Neighbor Liveness Timer: NLT(N,I) | ||||
| Per (S,G) Pair: | ||||
| (S,G) Assert Timer: AT(S,G,I) | ||||
| (S,G) Prune Timer: PT(S,G,I) | ||||
| (S,G) PrunePending Timer: PPT(S,G,I) | ||||
| Per (S,G) Pair: | ||||
| (S,G) Graft Retry Timer: GRT(S,G) | ||||
| (S,G) Upstream Override Timer: OT(S,G) | ||||
| (S,G) Prune Limit Timer: PLT(S,G) | ||||
| (S,G) Source Active Timer: SAT(S,G) | ||||
| (S,G) State Refresh Timer: SRT(S,G) | ||||
| When timer values are started or restarted, they are set to default | ||||
| values. The following tables summarize those default values. | ||||
| Timer Name: Hello Timer (HT) | ||||
| +----------------------+--------+--------------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +----------------------+--------+--------------------------------------+ | ||||
| |Hello_Period | 30 sec | Periodic interval for hello messages | | ||||
| +----------------------+--------+--------------------------------------+ | ||||
| |Triggered_Hello_Delay | 5 sec | Random interval for initial Hello | | ||||
| | | | message on bootup or triggered Hello | | ||||
| | | | message to a rebooting neighbor | | ||||
| +----------------------+--------+--------------------------------------+ | ||||
| Hello message are sent on every active interface once every Hello_Period | ||||
| seconds. At system power-up, the timer is initialized to | ||||
| rand(0,Triggered_Hello_Delay) to prevent synchronization. When a new or | ||||
| rebooting neighbor is detected, a responding Hello is sent within | ||||
| rand(0,Triggered_Hello_Delay). | ||||
| Timer Name: Neighbor Liveness Timer (NLT(N,I)) | ||||
| +-------------------+-----------------+--------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +-------------------+-----------------+--------------------------------+ | ||||
| | Hello Holdtime | From message | Hold Time from Hello Message | | ||||
| +-------------------+-----------------+--------------------------------+ | ||||
| Timer Name: PrunePending Timer (PPT(S,G,I)) | ||||
| +-----------------------+---------------+------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +-----------------------+---------------+------------------------------+ | ||||
| | J/P_Override_Interval | OI(I) + PD(I) | Short time after a Prune to | | ||||
| | | | allow other routers on the | | ||||
| | | | LAN to send a Join | | ||||
| +-----------------------+---------------+------------------------------+ | ||||
| The J/P_Override_Interval is the sum of the interface's | ||||
| Override_Interval (OI(I)) and Propagation_Delay (PD(I)). If all routers | ||||
| on a LAN are using the LAN Prune Delay option, both parameters MUST be | ||||
| set to the largest value on the LAN. Otherwise, the Override_Interval | ||||
| (OI(I)) MUST be set to 2.5 seconds and the Propagation_Delay (PD(I)) | ||||
| MUST be set to 0.5 seconds. | ||||
| Timer Name: Prune Timer (PT(S,G,I)) | ||||
| +----------------+----------------+------------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +----------------+----------------+------------------------------------+ | ||||
| | Prune Holdtime | From message | Hold Time read from Prune Message | | ||||
| +----------------+----------------+------------------------------------+ | ||||
| Timer Name: Assert Timer (AT(S,G,I)) | ||||
| +--------------------------+---------+---------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +--------------------------+---------+---------------------------------+ | ||||
| | Assert Time | 180 sec | Period after last assert before | | ||||
| | | | assert state is timed out | | ||||
| +--------------------------+---------+---------------------------------+ | ||||
| Note that for historical reasons, the Assert message lacks a Holdtime | ||||
| field. Thus changing the Assert Time from the default value is not | ||||
| recommended. If all members of a LAN are state refresh enabled, the | ||||
| Assert Time will be three times the received RefreshInterval(S,G). | ||||
| Timer Name: Graft Retry Timer (GRT(S,G)) | ||||
| +--------------------+-------+-----------------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +--------------------+-------+-----------------------------------------+ | ||||
| | Graft_Retry_Period | 3 sec | In the absence of receipt of a GraftAck | | ||||
| | | | message, the time before retransmission | | ||||
| | | | of a Graft message | | ||||
| +--------------------+-------+-----------------------------------------+ | ||||
| Timer Name: Upstream Override Timer (OT(S,G)) | ||||
| +------------+----------------+----------------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +------------+----------------+----------------------------------------| | ||||
| | t_override | rand(0, OI(I)) | Randomized delay to prevent response | | ||||
| | | | implosion when sending a join message | | ||||
| | | | to override someone else's prune | | ||||
| +------------+----------------+----------------------------------------+ | ||||
| t_override is a random value between 0 and the interface's | ||||
| Override_Interval (OI(I)). If all routers on a LAN are using the LAN | ||||
| Prune Delay option, the Override_Interval (OI(I)) MUST be set to the | ||||
| largest value on the LAN. Otherwise, the Override_Interval (OI(I)) MUST | ||||
| be set to 2.5 seconds. | ||||
| Timer Name: Prune Limit Timer (PLT(S,G)) | ||||
| +------------+--------------------+------------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +------------+--------------------+------------------------------------| | ||||
| | t_limit | Equal to the Prune | Used to prevent Prune storms on a | | ||||
| | | Holdtime sent | LAN | | ||||
| +------------+--------------------+------------------------------------+ | ||||
| Timer Name: Source Active Timer (SAT(S,G)) | ||||
| +----------------+-------------------+---------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +----------------+-------------------+---------------------------------+ | ||||
| | SourceLifetime | Default: 210 secs | Period of time after receiving | | ||||
| | | | a multicast message a directly | | ||||
| | | | attached router will continue | | ||||
| | | | to send State Refresh messages | | ||||
| +----------------+-------------------+---------------------------------+ | ||||
| Timer Name: State Refresh Timer (SRT(S,G)) | ||||
| +-----------------+------------------+---------------------------------+ | ||||
| | Value Name | Value | Explanation | | ||||
| +-----------------+------------------+---------------------------------+ | ||||
| | RefreshInterval | Default: 60 secs | Interval between successive | | ||||
| | | | state refresh messages | | ||||
| +-----------------+------------------+---------------------------------+ | ||||
| 5. Protocol Interaction Considerations | ||||
| PIM-DM is designed to be independent of underlying unicast routing | ||||
| protocols and will interact only to the extent needed to perform RPF | ||||
| checks. It is generally assumed that multicast area and autonomous | ||||
| system boundaries will correspond to the same boundaries for unicast | ||||
| routing, though a deployment which does not follow this assumption is | ||||
| not precluded by this specification. | ||||
| In general, PIM-DM interactions with other multicast routing protocols | ||||
| should be in compliance with RFC 2715 [7]. Other specific | ||||
| interactions are noted below. | ||||
| 5.1. PIM-SM Interactions | ||||
| PIM-DM is not intended to interact directly with PIM-SM, even though | ||||
| they share a common packet format. It is particularly important to note | ||||
| that a router cannot differentiate between a PIM-DM neighbor and a | ||||
| PIM-SM neighbor based on Hello messages. | ||||
| In the event that a PIM-DM router becomes a neighbor of a PIM-SM router | ||||
| they will effectively form a simplex link with the PIM-DM router sending | ||||
| all multicast messages to the PIM-SM router while the PIM-SM router | ||||
| sends no multicast messages to the PIM-DM router. | ||||
| The common packet format permits a hybrid PIM-SM/DM implementation that | ||||
| would use PIM-SM when a rendezvous point is known and PIM-DM when one is | ||||
| not. Such an implementation is outside the scope of this document. | ||||
| 5.2. IGMP Interactions | ||||
| PIM-DM will forward received multicast data packets to neighboring host | ||||
| group members in all cases except when the PIM-DM router is in an Assert | ||||
| Loser state on that interface. Note that a PIM Prune message is not | ||||
| permitted to prevent the delivery of messages to a network with group | ||||
| members. | ||||
| A PIM-DM Router MAY use the DR Priority option described in PIM-SM [13] | ||||
| to elect an IGMP v1 querier. | ||||
| 5.3. Source Specific Multicast (SSM) Interactions | ||||
| PIM-DM makes no special considerations for SSM [14]. All Prunes and | ||||
| Grafts within the protocol are for a specific source, so no additional | ||||
| checks need be made. | ||||
| 5.4. Multicast Group Scope Boundary Interactions | ||||
| While multicast group scope boundaries are generally identical to | ||||
| routing area boundaries, it is conceivable that a routing area might be | ||||
| partitioned for a particular multicast group. PIM-DM routers MUST NOT | ||||
| send any messages concerning a particular group across that group's | ||||
| scope boundary. | ||||
| 6. IANA Considerations | ||||
| 6.1. PIM Address Family | ||||
| The PIM Address Family field was chosen to be 8 bits as a tradeoff | ||||
| between packet format and use of the IANA assigned numbers. When the | ||||
| PIM packet format was designed, only 15 values were assigned for Address | ||||
| Families and large numbers of new Address Families were not envisioned, | ||||
| 8 bits seemed large enough. However, the IANA assigns Address Families | ||||
| in a 16 bit value. Therefore, the PIM Address Family is allocated as | ||||
| follows: | ||||
| Values 0 through 127 are designated to have the same meaning as IANA | ||||
| assigned Address Family Numbers [9]. | ||||
| Values 128 through 250 are designated to be assigned by the IANA based | ||||
| upon IESG approval as defined in [8]. | ||||
| Values 251 through 255 are designated for Private Use, as defined in | ||||
| [8]. | ||||
| 6.2. PIM Hello Options | ||||
| Values 17 through 65000 are to be assigned by the IANA. Since the space | ||||
| is large, they may be assigned as First Come First Served as defined in | ||||
| [8]. Such assignments are valid for one year, and may be renewed. | ||||
| Permanent assignments require a specification as defined in [8]. | ||||
| 7. Security Considerations | ||||
| The IPsec authentication header [10] MAY be used to provide data | ||||
| integrity protection and groupwise data origin authentication of PIM | ||||
| protocol messages. Authentication of PIM messages can protect against | ||||
| unwanted behaviors caused by unauthorized or altered PIM messages. In | ||||
| any case, a PIM router SHOULD NOT accept and process PIM messages from | ||||
| neighbors unless a valid Hello message has been received from that | ||||
| neighbor. | ||||
| We should note that PIM-DM has no rendezvous point, and therefore no | ||||
| single point of failure that may be vulnerable. It is further worth | ||||
| noting that because PIM-DM uses unicast routes provided by an unknown | ||||
| routing protocol, it may suffer collateral effects if the unicast | ||||
| routing protocol is attacked. | ||||
| 7.1. Attacks Based on Forged Messages | ||||
| The extent of possible damage depends on the type of counterfeit | ||||
| messages accepted. We next consider the impact of possible forgeries. A | ||||
| forged PIM-DM message is link local, and can only reach a LAN if it was | ||||
| sent by a local host or if it was allowed onto the LAN by a compromised | ||||
| or non-compliant router. | ||||
| 1. A forged a Hello message can cause multicast traffic to be delivered | ||||
| to links where there are no legitimate requestors, potentially | ||||
| wasting bandwidth on that link. On a multi-access LAN, the effects | ||||
| are limited without the capability to forge a Join message since | ||||
| other routers will Prune the link if the traffic is not desired. | ||||
| 2. A forged Join/Prune message can cause multicast traffic to be | ||||
| delivered to links where there are no legitimate requestors, | ||||
| potentially wasting bandwidth on that link. A forged Prune message | ||||
| on a multi-access LAN is generally not a significant attack in PIM, | ||||
| because any legitimately joined router on the LAN would override the | ||||
| Prune with a Join before the upstream router stops forwarding data | ||||
| to the LAN. | ||||
| 3. A forged Graft message can cause multicast traffic to be delivered to | ||||
| links where there are no legitimate requestors, potentially wasting | ||||
| bandwidth on that link. In principle, Graft messages could be sent | ||||
| multiple hops since they are unicast to the upstream router. This | ||||
| should not be a problem since the remote forger should have no way | ||||
| to get a Hello message to the target of the attack. Without a valid | ||||
| Hello message, the receiving router SHOULD NOT accept the Graft. | ||||
| 4. A forged GraftAck message has no impact since it will be ignored | ||||
| unless the router has recently sent a Graft to its upstream router. | ||||
| 5. By forging an Assert message on a multi-access LAN, an attacker could | ||||
| cause the legitimate forwarder to stop forwarding traffic to the LAN. | ||||
| Such a forgery would prevent any hosts downstream of that LAN from | ||||
| receiving traffic. | ||||
| 6. A forged State Refresh message on a multi-access LAN would have the | ||||
| same impact as a forged Assert message, having the same general | ||||
| functions. In addition, forged State Refresh messages would be | ||||
| propagated downstream and might be used in a denial of service | ||||
| attack. Therefore, a PIM-DM router SHOULD rate limit State Refresh | ||||
| messages propagated. | ||||
| 7.2. Non-cryptographic Authentication Mechanisms | ||||
| A PIM-DM router SHOULD provide an option to limit the set of neighbors | ||||
| from which it will accept PIM-DM messages. Either static configuration | ||||
| of IP addresses or an IPSec security association may be used. All | ||||
| options that restrict the range of addresses from which packets are | ||||
| accepted MUST default to allowing all packets. | ||||
| Furthermore, a PIM router SHOULD NOT accept protocol messages from a | ||||
| router from which it has not yet received a valid Hello message. | ||||
| 7.3. Authentication Using IPsec | ||||
| The IPSec [10] transport mode using the Authentication Header (AH) is | ||||
| the recommended method to prevent the above attacks in PIM. The | ||||
| specific AH authentication algorithm and parameters, including the | ||||
| choice of authentication algorithm and the choice of key, are configure | ||||
| by the network administrator. The Encapsulating Security Payload (ESP) | ||||
| MAY also be used to provide both encryption and authentication of PIM | ||||
| protocol messages. When IPsec authentication is used, a PIM router | ||||
| SHOULD reject (drop without processing) any unauthorized PIM protocol | ||||
| messages. | ||||
| To use IPSec, the administrator of a PIM network configures each PIM | ||||
| router with one or more Security Associations and associated Security | ||||
| Parameters Indices that are used by senders to sign PIM protocol | ||||
| messages and are used by receivers to authenticate received PIM protocol | ||||
| messages. This document does not describe protocols for establishing | ||||
| Security Associations. It assumes that manual configuration of Security | ||||
| Associations is performed, but it does not preclude the use of some | ||||
| future negotiation protocol such as GDOI [17] to establish Security | ||||
| Associations. | ||||
| The network administrator defines a Security Association (SA) and | ||||
| Security Parameters Index (SPI) that is to be used to authenticate all | ||||
| PIM-DM protocol messages from each router on each link in a PIM-DM | ||||
| domain. | ||||
| In order to avoid the problem of allocating individual keys for each | ||||
| neighbor on a link to each individual router, it is acceptable to | ||||
| establish only one authentication key for all PIM-DM routers on a link. | ||||
| This will not specifically authenticate the individual router sending | ||||
| the message, but will assure that the sender is a PIM-DM router on that | ||||
| link. If this method is used, the receiver of the message MUST ignore | ||||
| the received sequence number, thus disabling anti-replay mechanisms. | ||||
| The effects of disabling anti-replay mechanisms are essentially the same | ||||
| as the effects of forged messages described in section 7.1 with the | ||||
| additional protection that the forger can only reuse legitimate | ||||
| messages. | ||||
| The Security Policy Database at a PIM-DM router should be configured to | ||||
| ensure that all incoming and outgoing PIM-DM packets use the SA | ||||
| associated with the interface to which the packet is sent. Note that, | ||||
| according to [10], there is nominally a different Security Association | ||||
| Database (SAD) for each router interface. Thus, the selected Security | ||||
| Association for an inbound PIM-DM packet can vary depending on the | ||||
| interface on which the packet arrived. This fact allows the network | ||||
| administrator to use different authentication methods for each link, | ||||
| even though the destination address is the same for most PIM-DM packets, | ||||
| regardless of interface. | ||||
| 7.4. Denial of Service Attacks | ||||
| There are a number of possible denial of service attacks against PIM | ||||
| that can be caused by generating false PIM protocol messages or even by | ||||
| generating false data traffic. Authenticating PIM protocol traffic | ||||
| prevents some, but not all of these attacks. The possible attacks | ||||
| include: | ||||
| * Sending packets to many different group addresses quickly can be a | ||||
| denial of service attack in and of itself. These messages will | ||||
| initially be flooded throughout the network before they are pruned | ||||
| back. The maintenance of state machines and State Refresh messages | ||||
| will be a continual drain on network resources. | ||||
| * Forged State Refresh messages sent quickly could be propagated by | ||||
| downstream routers, creating a potential denial of service attack. | ||||
| Therefore, a PIM-DM router SHOULD rate limit State Refresh messages | ||||
| propagated. | ||||
| 8. Authors' Addresses | ||||
| Andrew Adams | ||||
| NextHop Technologies | ||||
| 825 Victors Way, Suite 100 | ||||
| Ann Arbor, MI 48108-2738 | ||||
| ala@nexthop.com | ||||
| Jonathan Nicholas | ||||
| ITT Industries | ||||
| Aerospace/Communications Division | ||||
| 100 Kingsland Rd | ||||
| Clifton, NJ 07014 | ||||
| jonathan.nicholas@itt.com | ||||
| William Siadak | ||||
| NextHop Technologies | ||||
| 825 Victors Way, Suite 100 | ||||
| Ann Arbor, MI 48108-2738 | ||||
| wfs@nexthop.com | ||||
| 9. Acknowledgments | ||||
| The major features of PIM-DM were originally designed by Stephen | ||||
| Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ahmed Helmy, | ||||
| David Meyer, and Liming Wei. Additional features for state refresh | ||||
| were designed by Dino Farinacci, Isidor Kouvelas and Kurt Windisch. | ||||
| This revision was undertaken to incorporate some of the lessons learned | ||||
| during the evolution of the PIM-SM specification and early deployments | ||||
| of PIM-DM. | ||||
| Thanks the PIM Working Group for their comments. | ||||
| 10. References | ||||
| 10.1 Normative References | ||||
| [1] S.E. Deering, "Host Extensions for IP Multicasting", March 1989, | ||||
| RFC 1112. | RFC 1112. | |||
| [5] W.Fenner, "Internet Group Management Protocol, Version 2", | [2] W.Fenner, "Internet Group Management Protocol, Version 2", | |||
| November 1997, RFC 2236. | November 1997, RFC 2236. | |||
| [6] IANA, "Address Family Numbers", linked from | [3] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, | |||
| http://www.iana.org/numbers.html. | "Internet Group Management Protocol, Version 3", | |||
| October 2002, RFC 3376. | ||||
| [7] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | [4] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, | |||
| M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol | ||||
| Independent Multicast-Sparse Mode (PIM-SM): Protocol | ||||
| Specification", June 1998, RFC 2362. | ||||
| [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) | ||||
| Specification", December 1998, RFC 2460. | ||||
| [6] S. Deering, W. Fenner, B. Haberman, "Multicast Listener Discovery | ||||
| (MLD) for IPv6", October 1999, RFC 2710. | ||||
| [7] D. Thaler, "Interoperability Rules for Multicast Routing | ||||
| Protocols", October 1999, RFC 2715. | ||||
| [8] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA | ||||
| Considerations Section in RFCs", October 1998, RFC 2434. | Considerations Section in RFCs", October 1998, RFC 2434. | |||
| [8] S. Kent, R. Atkinson, "Security Architecture for the Internet | [9] IANA, "Address Family Numbers", linked from | |||
| http://www.iana.org/numbers.html. | ||||
| [10] S. Kent, R. Atkinson, "Security Architecture for the Internet | ||||
| Protocol", November 1998, RFC 2401. | Protocol", November 1998, RFC 2401. | |||
| [9] H.Holbrook, B. Cain, "Source Specific Multicast for IP", | 10.2 Informative References | |||
| draft-ietf-ssm-arch-01.txt, work in progress. | ||||
| [10] B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan, | [11] S.E. Deering, "Multicast Routing in a Datagram Internetwork", | |||
| "Internet Group Management Protocol, Version 3", | Ph.D. Thesis, Electrical Engineering Dept., Stanford University, | |||
| October 2002, RFC 3376. | December 1991. | |||
| [11] D. Thaler, "Interoperability Rules for Multicast Routing | [12] D. Waitzman, B.Partridge, S.Deering, "Distance Vector Multicast | |||
| Protocols", October 1999, RFC 2715 | Routing Protocol", November 1988, RFC 1075 | |||
| [12] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol | [13] W. Fenner, M. Handley, H.Holbrook, I. Kouvelas, "Protocol | |||
| Independent Multicast MIB for IPv4", October 2000, RFC 2934 | Independent Multicast - Sparse Mode (PIM-SM): Protocol | |||
| Specification (Revised)", draft-ietf-pim-sm-v2-new-09.txt, | ||||
| work in progress. | ||||
| [13] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) | [14] H.Holbrook, B. Cain, "Source Specific Multicast for IP", | |||
| Specification", December 1998, RFC 2460. | draft-ietf-ssm-arch-04.txt, work in progress. | |||
| [14] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional | [15] K.McCloghrie, D.Farinacci, D.Thaler, B.Fenner, "Protocol | |||
| Protocol Independent Multicast", draft-ietf-pim-bidir-04.txt, | Independent Multicast MIB for IPv4", October 2000, RFC 2934 | |||
| [16] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional | ||||
| Protocol Independent Multicast", draft-ietf-pim-bidir-06.txt, | ||||
| work in progress. | work in progress. | |||
| [15] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group Domain of | [17] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group Domain of | |||
| Interpretation", July 2003, RFC 3547. | Interpretation", July 2003, RFC 3547. | |||
| [18] W. Fenner, M. Handley, R. Kermode, D. Thaler, "Bootstrap Router | ||||
| (BSR) Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, | ||||
| work in progress. | ||||
| 11. Full Copyright Statement | ||||
| Copyright (C) The Internet Society (2004). All Rights Reserved. | ||||
| This document and translations of it may be copied and furnished to | ||||
| others, and derivative works that comment on or otherwise explain it | ||||
| or assist in its implementation may be prepared, copied, published and | ||||
| distributed, in whole or in part, without restriction of any kind, | ||||
| provided that the above copyright notice and this paragraph are | ||||
| included on all such copies and derivative works. However, this | ||||
| document itself may not be modified in any way, such as by removing | ||||
| the copyright notice or references to the Internet Society or other | ||||
| internet organizations, except as needed for the purpose of | ||||
| developing Internet standards in which case the procedures for | ||||
| copyrights defined in the Internet Standards process must be | ||||
| followed, or as required to translate it into languages other than | ||||
| English. | ||||
| The limited permissions granted above are perpetual and will not be | ||||
| revoked by the Internet Society or its successors or assigns. | ||||
| This document and the information contained herein is provided on an | ||||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| End of changes. 50 change blocks. | ||||
| 97 lines changed or deleted | 2750 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||