idnits 2.17.1 draft-kouvelas-pim-refresh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 1999) is 9195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-pim-v2-dm-01 -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2362 (ref. '2') (Obsoleted by RFC 4601, RFC 5059) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 Internet Draft cisco Systems 4 Expiration Date: August, 1999 I. Kouvelas 5 cisco Systems 6 K. Windisch 7 University of Oregon 8 February 23, 1999 10 State Refresh in PIM-DM 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 1. Introduction 34 This proposal extends the PIM-DM [1] protocol specification by intro- 35 ducing the PIM State-Refresh control message. 37 When an (S,G) entry is created in a router for a directly connected 38 source, if the interface directly connected to the source is the 39 incoming interface for the entry, a new timer is started: the State- 40 Refresh-Timer [SRT(S,G)]. The State-Refresh-Timer controls periodic 41 transmission of the PIM State-Refresh message, which is propagated 42 hop-by-hop down the (S,G) RPF tree. When received by a router on the 43 RPF interface, the State-Refresh message causes existing prune state 44 to be refreshed. 46 Addition of this heartbeat message solves many of the current 47 problems with PIM-DM. It prevents the periodic timeout of prune state 48 in routers, greatly reducing the re-flooding of multicast traffic 49 down the pruned branches that expire periodically. It also causes 50 topology changes to be realised quicker than the traditional 3 minute 51 timeout. 53 2. Sending State-Refresh 55 For a given (S,G) tree, State-Refresh messages will be originated by 56 all routers that use an interface directly connected to the source as 57 the RPF interface for the source. Upon expiry of their (S,G) State- 58 Refresh-Timers the PIM State-Refresh message will be sent on all 59 PIM-DM interfaces with active PIM neighbors, except the interface 60 connecting the source. 62 In addition, when the SRT(S,G) expires, the following timers are 63 refreshed: SRT(S,G) is restarted with it's default value, and all 64 (S,G) pruned interface timers are refreshed. 66 Stopping transmission of State-Refresh messages is controlled by the 67 expiry of the (S,G) entry timer. The entry timer is not reset upon 68 expiry of the SRT(S,G) timer and is only updated when data packets 69 for the group are received, as in normal PIM-DM operation. 71 All other routers will send refresh only when receiving one from a 72 neighbor, as described below. 74 State-Refresh messages are multicast using address 224.0.0.13 (ALL- 75 PIM ROUTERS group) with protocol number equal to PIMv2 and a TTL of 76 1. The IP source address is set to the outgoing interface address and 77 is rewritten hop-by-hop when forwarding. 79 The State-Refresh message also contains the source and group the mes- 80 sage is referring to, the originator address (for debugging pur- 81 poses), routing information required by the assert mechanism, a TTL 82 value for scope control (different from header TTL) and a Prune- 83 Indicator flag described below. The routing information, TTL and 84 branch indicator can be rewritten hop-by-hop. 86 The TTL value in the message is initially set by the originating 87 router to the value of the largest TTL observed in data packets from 88 the source so far. The TTL value will be decremented by downstream 89 routers forwarding the State-Refresh message. Routers will only for- 90 ward the State-Refresh message if the value of the TTL in the message 91 is greater than 0 and larger than the configured local threshold. 92 This will prevent State-Refresh messages from reaching areas of the 93 network where data packets have not already created (S,G) state. 95 The Prune-Indicator flag is cleared when the message is transmitted 96 on an outgoing interface in forwarding state and set when the message 97 is transmitted on a pruned interface. This mechanism is required to 98 recover from situations where loss of consecutive refresh messages 99 has caused an inconsistency in prune state on a branch of the (S,G) 100 tree. 102 3. Receiving State-Refresh 104 PIM State-Refresh messages are RPF flooded down the (S,G) tree using 105 the data source address included in the message to determine the RPF 106 neighbor. When a PIM State-Refresh message is received for a given 107 (S,G), the following steps are taken: 109 o Whenever a (S,G) State-Refresh message is received on the interface 110 for RPF(S) by a router with no existing (S,G) entry, an (S,G) entry 111 should be created. If the Prune-Indicator flag in the message indi- 112 cates a forwarding branch, then all non-iif interfaces with PIM 113 neighbors are set to forwarding state in the new entry. Otherwise, 114 the new entry is created with prune state on all non-iif inter- 115 faces. 117 o If the (S,G) State-Refresh message was received on an interface 118 other than RPF(S) by a router with no existing (S,G) entry, then 119 the message is ignored. If the receiving interface corresponds to 120 a LAN the message may still be processed according to the normal 121 PIM Assert rules described in [1]. 123 o If the State-Refresh message was received on a (S,G) non-iif inter- 124 face then the message is ignored. If the receiving interface 125 corresponds to a LAN the message may still be processed according 126 to the normal PIM Assert rules described in [1]. 128 o If the State-Refresh was received on the (S,G) incoming interface 129 from a PIM router other than the upstream neighbor (i.e, RPF neigh- 130 bor or Assert winner), then the State-Refresh message is ignored. 131 However, the message is still processed according to the normal PIM 132 Assert rules described in [1]. 134 o If the State-Refresh was received on the (S,G) incoming interface 135 from the upstream neighbor (i.e, RPF neighbor or Assert winner), 136 then all (S,G) pruned interface timers are refreshed. Further, if 137 (S,G) is a negative cache entry, then the entry timer is also 138 refreshed to its default value. 140 o If the State-Refresh was received on the (S,G) incoming interface 141 from the upstream neighbor (i.e, RPF neighbor or Assert winner) and 142 the Prune-Indicator flag in the message is set, indicating that it 143 was forwarded down a pruned branch, but the local (S,G) entry is 144 not a negative cache entry, then the Prune-Indicator flag in the 145 message is cleared and a Graft is sent upstream. 147 o If the State-Refresh was received on the (S,G) incoming interface 148 from the upstream neighbor (i.e, RPF neighbor or Assert winner), 149 then the Refresh message is retransmitted on all PIM interfaces 150 other than the (S,G) incoming interface, provided that the TTL in 151 the message is greater than 0 and larger then the configured thres- 152 hold for the interface and that the interface does not have multi- 153 cast boundary addresses configured for the group specified in the 154 message. The IP header specifies the outgoing interface address as 155 the source and the Refresh Packet is rewritten with the local 156 router's preference, metric and mask for reaching S. If the (S,G) 157 entry has prune state for the interface on which the refresh mes- 158 sage is being sent, the Prune-Indicator flag in the message is set 159 to indicate a pruned branch. The TTL in the forwarded message is 160 one less than that of the received message. 162 4. State-Refresh Message Packet Format 164 This section described the details of the packet format for the PIM 165 DM State-Refresh Message. As with all PIM control messages, the 166 State-Refresh message uses protocol number 103. It is multicast hop- 167 by-hop to the `ALL-PIM-ROUTERS' group `224.0.0.13'. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 |PIM Ver| Type | Reserved | Checksum | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Encoded-Group Address | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Encoded-Unicast-Source Address | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Encoded-Unicast-Originator Address | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 |R| Metric Preference | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Metric | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Masklen | TTL |P| Reserved | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 PIM Version, Reserved, Checksum 188 Described in [2]. 190 Type 191 State-Refresh message type value is TBD. See [2] for types 192 of other PIM control messages. 194 Encoded-Group Address 195 The group address to which the data packets were addressed, 196 and which triggered the State-Refresh-Timer. Format 197 described in [2]. 199 Encoded-Unicast-Source Address 200 The address of the data packet source. Format described in 201 [2]. 203 Encoded-Unicast-Originator Address 204 The address of the first hop router that originated the 205 State-Refresh message. Format described in [2]. 207 Metric Preference, Metric, Masklen 208 Preference value assigned to the unicast routing protocol 209 that provided the route to Host address, the metric in units 210 applicable to the unicast routing protocol and the mask 211 length used (needed for assert logic as described in [1]). 213 TTL 214 This is set by the originating router to the TTL observed in 215 the data packets for the group and is decremented each time 216 the State-Refresh message is forwarded. 218 P 219 The Prune-Indicator flag. This is set if the State-Refresh 220 message was forwarded on a pruned interface and cleared oth- 221 erwise. 223 Reserved 224 Set to zero and ignored upon receipt. 226 5. Handling Router Failures 228 PIM Hello messages will contain a Generation ID (GenID) in a Hello 229 option. When a PIM Hello is received from an existing neighbor and 230 the GenID differs from the previous ID, the neighbor has restarted 231 and may not contain (S,G) state. In order to recreate the missing 232 state, for each (S,G), all routers upstream of the failed router 233 (i.e. those receiving the Hello on a non-iif) can send a new (S,G) 234 PIM State-Refresh message on the interface that the Hello message was 235 received. In order to avoid a burst of incoming State-Refresh mes- 236 sages at the recovering router, transmission of messages for dif- 237 ferent (S,G) entries has to be randomly spaced over a period of time. 238 The duration of this period can be configured locally and a default 239 value of 3 seconds is recommended. The Prune-Indicator flag of the 240 State-Refresh message should be set to indicate if the recovering 241 router is on a forwarding or pruned branch of the (S,G) tree. 243 6. Compatibility with Legacy PIM Routers 245 In order to enable incremental deployment of State-Refresh capable 246 routers, additional mechanisms have to be used to prevent holes in 247 the distribution tree. These can be created when grafts are not ori- 248 ginated from legacy routers that have timed out prune state whereas 249 State-Refresh capable routers higher up the tree have maintained 250 prune state for the branch. 252 Legacy routers are detected through the use of a new capability indi- 253 cator in PIM Hello messages that can be used to inform neighbors 254 whether a router is State-Refresh capable. 256 The only protocol modification that is required to enable interopera- 257 bility is in the procedures for packet reception: 259 o When a State-Refresh message is received on the (S,G) incoming 260 interface from the upstream neighbor (i.e, RPF neighbor or Assert 261 winner), then all (S,G) prune timers are refreshed except those 262 leading to legacy routers. Further if all outgoing interfaces lead- 263 ing to State-Refresh capable routers are pruned then the entry 264 timer is refreshed to its default value. 266 This will allow the prune state of the outgoing interface leading to 267 the legacy router to timeout and change to forwarding state. As the 268 entry timer will be updated by State-Refresh messages, the entry will 269 persist even after the transition. If the entry was a negative cache 270 entry a graft will be sent upstream as a result. 272 The above modifications will enable prune state to persist in sub- 273 trees of a source distribution tree that fulfill the following two 274 conditions: 276 a) The subtree is entirely State-Refresh capable. 278 b) The path from the source to the subtree in entirely State-Refresh 279 capable. 281 A subtree of the source distribution tree routed at a legacy router 282 as well as the path from the source to the subtree will not benefit 283 from State-Refresh messages and will experience traditional dense 284 mode flood and prune behavior. 286 7. References 288 [1] Deering, et al., "Protocol Independent Multicast Version 2 Dense Mode 289 Specification", draft-ietf-pim-v2-dm-01.txt, November 1998. 290 [2] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- 291 SM): Protocol Specification", RFC 2362, June 1998. 293 8. Acknowledgments 295 The authors would like to acknowledge Tony Speakman (cisco) and Lim- 296 ing Wei (cisco) for their comments and contributions to this specifi- 297 cation. 299 9. Author Information 301 Dino Farinacci 302 cisco Systems, Inc. 303 dino@cisco.com 305 Isidor Kouvelas 306 cisco Systems, Inc. 307 kouvelas@cisco.com 309 Kurt Windisch 310 Advanced Network Technolgy Center 311 University of Oregon 312 kurtw@antc.uoregon.edu