idnits 2.17.1 draft-anish-pim-stream-discovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4601], [RFC6559]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2015) is 3210 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 (-02) exists of draft-anish-reliable-pim-registers-00 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Downref: Normative reference to an Experimental RFC: RFC 6559 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Protocol Independent Multicast (pim) A. Peter, Ed. 3 Internet-Draft R. Kebler 4 Intended status: Standards Track V. Nagarajan 5 Expires: January 7, 2016 Juniper Networks, Inc. 6 July 6, 2015 8 PIM source discovery in Last-Hop-Router 9 draft-anish-pim-stream-discovery-01 11 Abstract 13 This specification introduces a mechanism in PIM-SM [RFC4601] for the 14 Last-Hop-Router (LHR) router to discover the stream information. 15 Once this mechanism is available the complications of the shared tree 16 procedures can be avoided. 18 The document introduces a hard-state, reliable transport for the 19 information about multicast streams active in the network. 21 This specification uses the existing PIM reliability mechanisms 22 defined by PIM Over Reliable Transport [RFC6559]. This is simply a 23 means to transmit reliable PIM messages and does not require the 24 support for Join/Prune messages over PORT as defined in [RFC6559]. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 7, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. LHR Source Discovery Overview . . . . . . . . . . . . . . . . 3 68 3. Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. New Hello Optional TLV's . . . . . . . . . . . . . . . . 4 70 4. Reliable Connection setup . . . . . . . . . . . . . . . . . . 5 71 4.1. Active LHR . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Anycast RP's . . . . . . . . . . . . . . . . . . . . . . . . 5 73 5.1. Anycast-RP change . . . . . . . . . . . . . . . . . . . . 5 74 5.1.1. Anycast-RP state mirroring . . . . . . . . . . . . . 5 75 6. Multicast Stream Liveness . . . . . . . . . . . . . . . . . . 6 76 7. PORT message . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7.1. PORT stream Receiver-Interest message TLV . . . . . . . . 6 78 7.1.1. Group prefix record . . . . . . . . . . . . . . . . . 8 79 8. Management Considerations . . . . . . . . . . . . . . . . . . 8 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 9.1. PIM PORT Message Type . . . . . . . . . . . . . . . . . . 9 82 9.2. PIM PORT Receiver-Interest message type . . . . . . . . . 9 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 10.1. Targeted Hello Threats . . . . . . . . . . . . . . . . . 9 85 10.2. TCP or SCTP security threats . . . . . . . . . . . . . . 10 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 88 11.2. Informative References . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 The existing specification for PIM-SM [RFC4601], requires a shared 94 tree (*,G) tree to be setup for each multicast group as the LHR does 95 not have the information about the sources active for the given 96 group. Once the LHR starts receiving traffic on this shared tree, it 97 would discover the source and may switch to source path. Once source 98 path is established the RP shared tree is still maintained for 99 discovering new sources. In addition LHR would now have to maintain 100 a prune state with to RP for not getting that particular stream over 101 the shared tree and source tree. 103 This behavior could be optimized if the LHR could have a means to 104 know about the sources active for a multicast group. Then it could 105 directly do an SPT join without having to wait for the ASM shared- 106 tree to be established. 108 2. LHR Source Discovery Overview 110 Reliable PIM register Reliable PIM Registers 111 [I-D.anish-reliable-pim-registers] extends PIM PORT [RFC6559] to 112 have PIM register states to be send over a reliable transport. 114 Independent of reliable register support as specified in Reliable PIM 115 Registers [I-D.anish-reliable-pim-registers] this document introduces 116 a reliable communication between LHR and RP, so that LHR would now 117 learn all the source informations directly from RP with out the need 118 for a shared tree. 120 For achieving this on a LHR in a source discovery enabled network, 121 targeted neighborhood is established between LHR and RP, with the LHR 122 expressing its capability in the targeted hello. This leads to a 123 reliable connection setup as stated in Reliable PIM Registers 124 [I-D.anish-reliable-pim-registers] . Subsequent to this LHR would 125 send receiver-interest messages to RP stating the groups for which it 126 wishes to receive. This "Receiver-Interest" could be for, 128 1: Single group address, when the prefix-len would be equal to the 129 prefix-length of a host address. 131 2: Group address range, when the prefix-len indicated a address mask 132 for the groups of interest 134 3: Wild-card, which would indicate all the asm addresses that RP is 135 aware of 137 RP would respond back to LHR with the list of multicast streams 138 active with it that matches this Receiver-Interest in a reliable 139 register message. Unless a 'One-time' flag is set RP would retain 140 this Receiver-Interest with it for notifying the LHR about the 141 incremental changes happening to the groups falling in this Receiver- 142 Interest. 144 When the interest in LHR ceases for a Receiver-Interest it had set 145 with the RP, it could send the same Receiver-Interest message, but 146 with the withdraw bit set. 148 3. Targeted Hellos 150 Reliable PIM Registers [I-D.anish-reliable-pim-registers] defined 151 targeted hellos for PIM. This specification extends them to apply it 152 for the RP-LHR segment. The only change it introduces is that it 153 uses one bit among the reserved bits for the purpose of a router 154 identifying itself as a LHR in the targeted hello optional TLV in 155 targeted hello message 157 3.1. New Hello Optional TLV's 159 Option Type: Targeted hello 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type = H1 (for alloc) | Length = 4 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |F|R|L| Reserved | Exp | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: PIM Hello Optional TLV 171 Assigned Hello Type values can be found in IANA PIM registry. 173 Type: As defined in Reliable PIM Registers 174 [I-D.anish-reliable-pim-registers] 176 Length: As defined in Reliable PIM Registers 177 [I-D.anish-reliable-pim-registers] 179 F: As defined in Reliable PIM Registers 180 [I-D.anish-reliable-pim-registers] 182 R: As defined in Reliable PIM Registers 183 [I-D.anish-reliable-pim-registers] 185 L: Identifies the PIM hellos senders capability of being a LHR 187 Reserved: Set to zero on transmission and ignored on receipt. 189 Exp: As defined in Reliable PIM Registers 190 [I-D.anish-reliable-pim-registers] 192 4. Reliable Connection setup 194 A reliable connection has to be setup between the LHR and RP for 195 reliable messaging to happen. 197 4.1. Active LHR 199 Once LHR and RP discovery each other with targeted hello 200 neighborhood, LHR takes the active role. LHR would listen for RP to 201 connect once it forms targeted neighbor-ship with RP. The RP would 202 be expected to use its primary address, which it would have used as 203 the source address in its pim hellos. 205 5. Anycast RP's 207 PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy. 208 Reliable PIM Registers [I-D.anish-reliable-pim-registers]introduced 209 procedures to support anycast-RP with reliable connection. This 210 section describes how anycast-RP would work with this specification. 212 5.1. Anycast-RP change 214 In the event of nearest anycast-RP changing over to a different 215 router, LHR would detect that when it starts receiving PIM hellos 216 with a different primary address for the same anycast address. Upon 217 detecting this scenario, the LHR may wait for an interval before 218 setting up connection with the newly found primary address of the RP. 220 Upon detecting this scenario, the LHR would establish connection and 221 transmit its states to the new peer. Subsequently older connection 222 would get terminated due to neighbor timeout. 224 Once the old connection is terminated, LHR should clear off the 225 states for the multicast streams that were advertised in the old 226 connection and not by the new connection. In order to accommodate 227 for delays in a new RP discovering and advertising a stream, this 228 state cleanup should be done only after a suitable delay. 230 5.1.1. Anycast-RP state mirroring 232 The Receiver Interest message from the LHR should not be mirrored to 233 the other anycast RP peers as its sufficient for it to rest with the 234 nearest RP. 236 6. Multicast Stream Liveness 238 Traditionally with PIM-SM [RFC4601] the LHR had the responsibility of 239 checking the stream liveness, so that it could prune of the traffic 240 that are not active any more in the SPT. This is besides that same 241 stream getting traced for liveness at the First-Hop-Router (FHR) and 242 RP. 244 With the extension in this document, this liveness motoring could be 245 avoided on LHR. LHR can now prune of a SPT path based on the 246 withdraw of the stream. 248 When deployed along with Reliable PIM Registers 249 [I-D.anish-reliable-pim-registers]this liveness check could be 250 restricted to FHR alone 252 7. PORT message 254 This document defines new PORT multicast stream Receiver-Interest 255 messages and PORT multicast stream reports messages, to the existing 256 messages in PORT specification. 258 The records in the message could be defined as the use case be. In 259 the context of this draft this use case is only for multicast group 260 joins. 262 7.1. PORT stream Receiver-Interest message TLV 264 This message format defines the receiver interest message. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type = P3 (for alloc) | Message Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |W|O| Reserved | Exp. | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |A| Reserved-1 | Aux-len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 z Record-1 z 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 z Auxiliary-data-1 z 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 z 2, 3, . . . z 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |A| Reserved-n | Aux-len | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 z Record-n z 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 z Auxiliary-data-n z 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: PORT Stream Receiver-Interest Message for 290 Type: This is subject to IANA allocation. It would be next 291 unallocated value, which is referred until allocation as P3. 293 Length: Length in bytes for the value part of the Type/Length/Value 295 W: This flag when set signifies if the record is to be Added or 296 Withdrawn. When set, it indicates that the record is withdrawn by 297 the LHR. 299 O: This flag when set identifies the Receiver-Interest as a One-time. 301 A: This bit indicate the presence of an auxiliary data applicable to 302 the record immediately following it. 304 When A bit is cleared, reserved bits for the next record follows 305 record. Else it would be auxiliary data TLV. 307 Reserved: Set to zero on transmission and ignored on receipt. This 308 reserved bits are for properties that apply to the entire message. 310 Reserved-n: Set to zero on transmission and ignored on receipt. This 311 reserved bits are for properties that apply to any particular stream. 313 Exp: : For experimental use. 315 7.1.1. Group prefix record 317 This record type as stated before could be used for 319 1: Single group, when prefix len is 32 321 2: Group prefix, when 4 < prefix len > 32 323 3: Any group (Wildcard), when prefix len is 4 325 Record type 0x1 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type = 1 (suggested) | Message Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | grp addr | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 3: Record for Receiver-Interest 336 Type: This is a new IANA registry, suggested value 1 338 Length: Length in bytes for the value part of the Type/Length/Value 339 In this case it would be 12bytes. 341 grp addr: Group address for which there is Receiver-Interest. This 342 this group address should be of "Encoded-Group-Address Format as 343 specified in [RFC4601] 345 8. Management Considerations 347 LHR multicast stream discovery is capable of configuration free 348 operations. But its recommended to have it as configuration 349 controlled. 351 Implementation should provide knobs needed to stop supporting *g 352 join/prune states created by a neighboring router. 354 9. IANA Considerations 356 This specification introduces new TLV in PORT messages. Hence the 357 tlv ids for these needs IANA allocation 359 It also introduces a registry for PORT Receiver-Interest record type. 361 9.1. PIM PORT Message Type 363 The following PIM PORT message TLV types need IANA allocation. Place 364 holder are kept to differentiate the different types. 366 +---------------------+------------------------+---------------+ 367 | Value | Name | Reference | 368 +---------------------+------------------------+---------------+ 369 | P3 (Next available) | PORT Receiver-Interest | This document | 370 +---------------------+------------------------+---------------+ 372 Table 1: Place holder values for PIM PORT TLV type for IANA 373 allocation 375 9.2. PIM PORT Receiver-Interest message type 377 +-------------------------+-------------------------+---------------+ 378 | Value | Name | Reference | 379 +-------------------------+-------------------------+---------------+ 380 | 1 (suggested) | Group Receiver-Interest | This document | 381 | 0, 2 - 65000 | Unassigned - Reserved | This document | 382 | (suggested) | | | 383 | 65001 - 65535 | For experimental use | This document | 384 | (suggested) | | | 385 +-------------------------+-------------------------+---------------+ 387 Table 2: Suggested values for PIM PORT Message types for Receiver- 388 Interest TLV for IANA allocation 390 10. Security Considerations 392 10.1. Targeted Hello Threats 394 The state reduction introduced by this specification has 395 possibilities for improving the vulnerabilities in a multicast 396 network. 398 Reliable PIM Registers [I-D.anish-reliable-pim-registers] document 399 introduces targeted hellos. This could be a seen as a new security 400 threat. Targeted hellos are part of other IETF protocol 401 implementations which are widely deployed. In future introduction of 402 a mechanism similar to those stated in RFC 7349 [RFC7349] could be 403 used in PIM. 405 10.2. TCP or SCTP security threats 407 The security perception for this is stated in [RFC6559]. 409 11. References 411 11.1. Normative References 413 [I-D.anish-reliable-pim-registers] 414 Peter, A., Kebler, R., and V. Nagarajan, "Reliable 415 Transport For PIM Register States", draft-anish-reliable- 416 pim-registers-00 (work in progress), March 2015. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 422 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 423 Protocol Specification (Revised)", RFC 4601, August 2006. 425 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 426 Independent Multicast (PIM)", RFC 4610, August 2006. 428 [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. 429 Napierala, "A Reliable Transport Mechanism for PIM", RFC 430 6559, March 2012. 432 11.2. Informative References 434 [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 435 Cryptographic Authentication", RFC 7349, August 2014. 437 Authors' Addresses 439 Anish Peter (editor) 440 Juniper Networks, Inc. 441 Electra, Exora Business Park 442 Bangalore, KA 560103 443 India 445 Email: anishp@juniper.net 446 Robert Kebler 447 Juniper Networks, Inc. 448 1194 N. Mathilda Ave. 449 Sunnyvale, CA 94089 450 US 452 Email: rkebler@juniper.net 454 Vikram Nagarajan 455 Juniper Networks, Inc. 456 Electra, Exora Business Park 457 Bangalore, KA 560103 458 India 460 Email: vikramna@juniper.net