Internet DRAFT - draft-anish-pim-stream-discovery
draft-anish-pim-stream-discovery
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]
