Protocol Independent Multicast (pim) A. Peter, Ed. Internet-Draft R. Kebler Intended status: Standards Track V. Nagarajan Expires: January 7, 2016 Juniper Networks, Inc. July 6, 2015 PIM source discovery in Last-Hop-Router draft-anish-pim-stream-discovery-01 Abstract This specification introduces a mechanism in PIM-SM [RFC4601] for the Last-Hop-Router (LHR) router to discover the stream information. Once this mechanism is available the complications of the shared tree procedures can be avoided. The document introduces a hard-state, reliable transport for the information about multicast streams active in the network. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559]. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 7, 2016. Peter, et al. Expires January 7, 2016 [Page 1] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. LHR Source Discovery Overview . . . . . . . . . . . . . . . . 3 3. Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. New Hello Optional TLV's . . . . . . . . . . . . . . . . 4 4. Reliable Connection setup . . . . . . . . . . . . . . . . . . 5 4.1. Active LHR . . . . . . . . . . . . . . . . . . . . . . . 5 5. Anycast RP's . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Anycast-RP change . . . . . . . . . . . . . . . . . . . . 5 5.1.1. Anycast-RP state mirroring . . . . . . . . . . . . . 5 6. Multicast Stream Liveness . . . . . . . . . . . . . . . . . . 6 7. PORT message . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. PORT stream Receiver-Interest message TLV . . . . . . . . 6 7.1.1. Group prefix record . . . . . . . . . . . . . . . . . 8 8. Management Considerations . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. PIM PORT Message Type . . . . . . . . . . . . . . . . . . 9 9.2. PIM PORT Receiver-Interest message type . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10.1. Targeted Hello Threats . . . . . . . . . . . . . . . . . 9 10.2. TCP or SCTP security threats . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The existing specification for PIM-SM [RFC4601], requires a shared tree (*,G) tree to be setup for each multicast group as the LHR does not have the information about the sources active for the given group. Once the LHR starts receiving traffic on this shared tree, it Peter, et al. Expires January 7, 2016 [Page 2] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 would discover the source and may switch to source path. Once source path is established the RP shared tree is still maintained for discovering new sources. In addition LHR would now have to maintain a prune state with to RP for not getting that particular stream over the shared tree and source tree. This behavior could be optimized if the LHR could have a means to know about the sources active for a multicast group. Then it could directly do an SPT join without having to wait for the ASM shared- tree to be established. 2. LHR Source Discovery Overview Reliable PIM register Reliable PIM Registers [I-D.anish-reliable-pim-registers] extends PIM PORT [RFC6559] to have PIM register states to be send over a reliable transport. Independent of reliable register support as specified in Reliable PIM Registers [I-D.anish-reliable-pim-registers] this document introduces a reliable communication between LHR and RP, so that LHR would now learn all the source informations directly from RP with out the need for a shared tree. For achieving this on a LHR in a source discovery enabled network, targeted neighborhood is established between LHR and RP, with the LHR expressing its capability in the targeted hello. This leads to a reliable connection setup as stated in Reliable PIM Registers [I-D.anish-reliable-pim-registers] . Subsequent to this LHR would send receiver-interest messages to RP stating the groups for which it wishes to receive. This "Receiver-Interest" could be for, 1: Single group address, when the prefix-len would be equal to the prefix-length of a host address. 2: Group address range, when the prefix-len indicated a address mask for the groups of interest 3: Wild-card, which would indicate all the asm addresses that RP is aware of RP would respond back to LHR with the list of multicast streams active with it that matches this Receiver-Interest in a reliable register message. Unless a 'One-time' flag is set RP would retain this Receiver-Interest with it for notifying the LHR about the incremental changes happening to the groups falling in this Receiver- Interest. Peter, et al. Expires January 7, 2016 [Page 3] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 When the interest in LHR ceases for a Receiver-Interest it had set with the RP, it could send the same Receiver-Interest message, but with the withdraw bit set. 3. Targeted Hellos Reliable PIM Registers [I-D.anish-reliable-pim-registers] defined targeted hellos for PIM. This specification extends them to apply it for the RP-LHR segment. The only change it introduces is that it uses one bit among the reserved bits for the purpose of a router identifying itself as a LHR in the targeted hello optional TLV in targeted hello message 3.1. New Hello Optional TLV's Option Type: Targeted hello 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 = H1 (for alloc) | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R|L| Reserved | Exp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PIM Hello Optional TLV Assigned Hello Type values can be found in IANA PIM registry. Type: As defined in Reliable PIM Registers [I-D.anish-reliable-pim-registers] Length: As defined in Reliable PIM Registers [I-D.anish-reliable-pim-registers] F: As defined in Reliable PIM Registers [I-D.anish-reliable-pim-registers] R: As defined in Reliable PIM Registers [I-D.anish-reliable-pim-registers] L: Identifies the PIM hellos senders capability of being a LHR Reserved: Set to zero on transmission and ignored on receipt. Exp: As defined in Reliable PIM Registers [I-D.anish-reliable-pim-registers] Peter, et al. Expires January 7, 2016 [Page 4] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 4. Reliable Connection setup A reliable connection has to be setup between the LHR and RP for reliable messaging to happen. 4.1. Active LHR Once LHR and RP discovery each other with targeted hello neighborhood, LHR takes the active role. LHR would listen for RP to connect once it forms targeted neighbor-ship with RP. The RP would be expected to use its primary address, which it would have used as the source address in its pim hellos. 5. Anycast RP's PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy. Reliable PIM Registers [I-D.anish-reliable-pim-registers]introduced procedures to support anycast-RP with reliable connection. This section describes how anycast-RP would work with this specification. 5.1. Anycast-RP change In the event of nearest anycast-RP changing over to a different router, LHR would detect that when it starts receiving PIM hellos with a different primary address for the same anycast address. Upon detecting this scenario, the LHR may wait for an interval before setting up connection with the newly found primary address of the RP. Upon detecting this scenario, the LHR would establish connection and transmit its states to the new peer. Subsequently older connection would get terminated due to neighbor timeout. Once the old connection is terminated, LHR should clear off the states for the multicast streams that were advertised in the old connection and not by the new connection. In order to accommodate for delays in a new RP discovering and advertising a stream, this state cleanup should be done only after a suitable delay. 5.1.1. Anycast-RP state mirroring The Receiver Interest message from the LHR should not be mirrored to the other anycast RP peers as its sufficient for it to rest with the nearest RP. Peter, et al. Expires January 7, 2016 [Page 5] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 6. Multicast Stream Liveness Traditionally with PIM-SM [RFC4601] the LHR had the responsibility of checking the stream liveness, so that it could prune of the traffic that are not active any more in the SPT. This is besides that same stream getting traced for liveness at the First-Hop-Router (FHR) and RP. With the extension in this document, this liveness motoring could be avoided on LHR. LHR can now prune of a SPT path based on the withdraw of the stream. When deployed along with Reliable PIM Registers [I-D.anish-reliable-pim-registers]this liveness check could be restricted to FHR alone 7. PORT message This document defines new PORT multicast stream Receiver-Interest messages and PORT multicast stream reports messages, to the existing messages in PORT specification. The records in the message could be defined as the use case be. In the context of this draft this use case is only for multicast group joins. 7.1. PORT stream Receiver-Interest message TLV This message format defines the receiver interest message. Peter, et al. Expires January 7, 2016 [Page 6] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 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 = P3 (for alloc) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |W|O| Reserved | Exp. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved-1 | Aux-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ z Record-1 z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ z Auxiliary-data-1 z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ z 2, 3, . . . z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A| Reserved-n | Aux-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ z Record-n z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ z Auxiliary-data-n z +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PORT Stream Receiver-Interest Message for Type: This is subject to IANA allocation. It would be next unallocated value, which is referred until allocation as P3. Length: Length in bytes for the value part of the Type/Length/Value W: This flag when set signifies if the record is to be Added or Withdrawn. When set, it indicates that the record is withdrawn by the LHR. O: This flag when set identifies the Receiver-Interest as a One-time. A: This bit indicate the presence of an auxiliary data applicable to the record immediately following it. When A bit is cleared, reserved bits for the next record follows record. Else it would be auxiliary data TLV. Reserved: Set to zero on transmission and ignored on receipt. This reserved bits are for properties that apply to the entire message. Reserved-n: Set to zero on transmission and ignored on receipt. This reserved bits are for properties that apply to any particular stream. Exp: : For experimental use. Peter, et al. Expires January 7, 2016 [Page 7] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 7.1.1. Group prefix record This record type as stated before could be used for 1: Single group, when prefix len is 32 2: Group prefix, when 4 < prefix len > 32 3: Any group (Wildcard), when prefix len is 4 Record type 0x1 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 (suggested) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | grp addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Record for Receiver-Interest Type: This is a new IANA registry, suggested value 1 Length: Length in bytes for the value part of the Type/Length/Value In this case it would be 12bytes. grp addr: Group address for which there is Receiver-Interest. This this group address should be of "Encoded-Group-Address Format as specified in [RFC4601] 8. Management Considerations LHR multicast stream discovery is capable of configuration free operations. But its recommended to have it as configuration controlled. Implementation should provide knobs needed to stop supporting *g join/prune states created by a neighboring router. 9. IANA Considerations This specification introduces new TLV in PORT messages. Hence the tlv ids for these needs IANA allocation It also introduces a registry for PORT Receiver-Interest record type. Peter, et al. Expires January 7, 2016 [Page 8] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 9.1. PIM PORT Message Type The following PIM PORT message TLV types need IANA allocation. Place holder are kept to differentiate the different types. +---------------------+------------------------+---------------+ | Value | Name | Reference | +---------------------+------------------------+---------------+ | P3 (Next available) | PORT Receiver-Interest | This document | +---------------------+------------------------+---------------+ Table 1: Place holder values for PIM PORT TLV type for IANA allocation 9.2. PIM PORT Receiver-Interest message type +-------------------------+-------------------------+---------------+ | Value | Name | Reference | +-------------------------+-------------------------+---------------+ | 1 (suggested) | Group Receiver-Interest | This document | | 0, 2 - 65000 | Unassigned - Reserved | This document | | (suggested) | | | | 65001 - 65535 | For experimental use | This document | | (suggested) | | | +-------------------------+-------------------------+---------------+ Table 2: Suggested values for PIM PORT Message types for Receiver- Interest TLV for IANA allocation 10. Security Considerations 10.1. Targeted Hello Threats The state reduction introduced by this specification has possibilities for improving the vulnerabilities in a multicast network. Reliable PIM Registers [I-D.anish-reliable-pim-registers] document introduces targeted hellos. This could be a seen as a new security threat. Targeted hellos are part of other IETF protocol implementations which are widely deployed. In future introduction of a mechanism similar to those stated in RFC 7349 [RFC7349] could be used in PIM. Peter, et al. Expires January 7, 2016 [Page 9] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 10.2. TCP or SCTP security threats The security perception for this is stated in [RFC6559]. 11. References 11.1. Normative References [I-D.anish-reliable-pim-registers] Peter, A., Kebler, R., and V. Nagarajan, "Reliable Transport For PIM Register States", draft-anish-reliable- pim-registers-00 (work in progress), March 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006. [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. Napierala, "A Reliable Transport Mechanism for PIM", RFC 6559, March 2012. 11.2. Informative References [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello Cryptographic Authentication", RFC 7349, August 2014. Authors' Addresses Anish Peter (editor) Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India Email: anishp@juniper.net Peter, et al. Expires January 7, 2016 [Page 10] Internet-Draft PIM source discovery in Last-Hop-Router July 2015 Robert Kebler Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US Email: rkebler@juniper.net Vikram Nagarajan Juniper Networks, Inc. Electra, Exora Business Park Bangalore, KA 560103 India Email: vikramna@juniper.net Peter, et al. Expires January 7, 2016 [Page 11]