Network Working Group Tom Pusateri
Internet-Draft Juniper Networks
Expires: August 21, 2005 February 2005
PIM Sparse-Mode IETF Proposed Standard Requirements Analysis
draft-ietf-pim-proposed-req-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
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/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
1. Introduction
This analysis provides supporting documentation to advance the
Protocol Independent Multicast (PIM) Sparse-Mode routing protocol
from the IETF Experimental status to Proposed Standard. PIM Sparse-
Mode was first published as RFC 2117 in 1997 and then again as RFC
2362 in 1998. The protocol was classified as Experimental in both of
these documents. The PIM Sparse-Mode protocol specification was then
rewritten in whole in order to more fully specify the protocol. It
is this new specification that is to be advanced to Proposed
Standard.
Pusateri [Page 1]
Internet-Draft PIM Sparse-Mode Proposed Standard February 2005
2. RFC 1264 Requirements
Section 4.0 of RFC 1264 [ROUTESTD] describes the requirements for
routing protocols to advance to Proposed Standard. Each requirement
is listed below along with an explanation of how the requirement has
been satisfied.
2.1. Documents specifying the Protocol and its Usage
The authors of the new PIM Sparse-Mode specification have taken
considerable care to fully specify the protocol operation. It removes
all known ambiguities and tries to normalize corner cases that
existed in the previous specification. It has been used to provide
several interoperable implementations by developers that were not
authors of the specification. These implementations will be
described below.
2.2. Management Information Base
A Management Information Base for PIM is currently specified in RFC
2934 [PIMMIB]. This MIB has many implementations and has been used
by network management applications for several years. Updates to this
MIB to support IPv6 and other improvements based on operation
experience are in progress in the PIM Working Group of the IETF.
2.3. Explicit Security Architecture
The new PIM Sparse-Mode protocol specification contains an extensive
security section explaining its security features and limitations.
Data integrity protection and groupwise data origin authentication is
provided for PIM protocol messages.
2.4. Implementation Existence
There are at least 4 known independent implementations of the new
protocol specification and there are over 6 independent
implementations of a previous version (RFC 2362) of the
specification. The new specification was carefully written to be
backward compatible with the old specification allowing
implementations compliant with RFC 2362 to also be compliant with the
new specification.
The 4 implementations of the new version are described below:
Pusateri [Page 2]
Internet-Draft PIM Sparse-Mode Proposed Standard February 2005
XORP
The XORP project [XORP] has an open-source implementation of PIM-
SMv2 as specified in the draft-ietf-pim-sm-v2-new-11.txt. It was
written by Pavlin Radoslavov <pavlin@icir.org> and has been
available to the public since December 2002. Pavlin is not an
author of the protocol specification. It does not use any other
existing code as a base.
Cisco IOS/IOX
Cisco Systems, Inc. has written an implementation of the new
protocol specification which has been deployed in production
routers. There exists an IOS implementation for IPv6 only. There
exists an IOX implementation for both IPv4 and IPv6. This code was
initially written by Isidor Kouvelas <kouvelas@cisco.com>. It does
not depend on any existing code base. Isidor is a co-author of
the protocol specification.
Infosys Technologies, Ltd.
Infosys Technologies, Ltd. (www.infosys.com) have developed a
limited shared tree implementation of the new Sparse-Mode
specification including PIM Hello messages, DR election, PIM
join/prune messages, join suppression, and prune override. It was
written by Bharat Joshi <<bharat_joshi@infosys.com> and is used in
commercial products. Bharat is not an author of the protocol
specification.
Procket Networks
An implementation was written from scratch at Procket Networks by
Dino Farinacci <dino@cisco.com>. This implementation is now owned
by Cisco Systems, Inc. Dino is not an author of the new protocol
speicfication.
2.5. Evidence of Testing
Cisco
The Cisco implementation has undergone extensive laboratory
testing as well as testing in production deployments. It is found
to interoperate with implementations of earlier versions of the
PIM Sparse-Mode protocol specification.
XORP
The XORP PIM-SM implementation has been thoughtfully tested
internally by the XORP project. The emphasis during testing has
been on correctness. In a typical setup, a PIM-SM router's
behavior is tested by connecting it to external packet generators
Pusateri [Page 3]
Internet-Draft PIM Sparse-Mode Proposed Standard February 2005
and observers. The packet generators are used to generate messages
such as IGMP and PIM-SM control packets, and multicast data
packets. The packet observers are used to observe the PIM-SM
control packets generated by the PIM-SM router under test, and to
observe the data packets that may be forwarded by that router. In
addition, the router's command-line interface has been used to
observe its internal state during some of the tests.
The test scenarios have been designed to closely follow the
protocol specification (e.g., a separate test has been created for
each event in the various protocol state machines, etc). All test
scenarios are described in detail in [XORP-Test].
The major tested features are:
1. Multicast data forwarding.
2. PIM Hello messages exchange, PIM router neighbor discovery,
option exchange, and DR election.
3. PIM Register messages transmission and reception, PIM Register
state machine, multicast data packets encapsulation and
decapsulation.
4. Transmission and reception of PIM Join/Prune messages, upstream
and downstream protocol state machines. The tests consider the
following state: (*,*,RP), (*,G), (S,G) and (S,G,rpt).
5. Transmission and reception of PIM Assert messages and the per-
interface (*,G) and (S,G) Assert state machines.
6. PIM Bootstrap mechanism: transmission, reception and forwarding
of PIM Bootstrap messages, transmission and reception of PIM
Cand-RP-Adv messages, candidate and non-candidate BSR state
machines, creating the RP-Set at the BSR, receiving and using
the RP-Set, semantic fragmentation of BSMs.
In the final tests, the tested router behaved as specified in the
PIM-SM protocol specification. All issues found in the protocol
specification itself have been corrected in earlier versions of
the Internet Draft.
Procket Networks
The Procket Networks implementation was deployed in many research
and service provider networks and showed interoperability with new
and old Cisco Systems implementations as well as Juniper Networks
implementations.
Pusateri [Page 4]
Internet-Draft PIM Sparse-Mode Proposed Standard February 2005
2.6. Suitability
PIM Sparse-Mode is a protocol for efficiently routing multicast
groups that may span wide-area (and inter-domain) Internets. PIM
uses the underlying unicast routing to provide reverse-path
information for multicast tree building but it is not dependent on
any particular unicast routing protocol.
2.7. Authentication Mechanisms
PIM specifies the use of the IP security authentication header to
provide data integrity protection and groupwise data origin
authentication of protocol messages. The specific AH authentication
algorithm and parameters, including the choice of authentication
algorithm and the choice of key, are configured by the network
administrator. The threats associated with receiving forged PIM
messages are outlined in the security considerations section of the
protocol specification.
3. Acknowledgments
Pavlin Radoslavov provided text for the section on XORP testing.
Dino Farinacci provided text for the Procket Networks testing.
4. Normative References
[PIMMIB] McCloghrie, K., Farinacci, D., Thaler, D., Fenner, B.,
"Protocol Independent Multicast MIB for IPv4", RFC 2934,
October 2000.
5. Informative References
[ROUTESTD] Hinden, R., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[XORP] XORP Project, http://www.xorp.org/
[XORP-Test] XORP PIM-SM Test Suite,
http://www.xorp.org/releases/current/docs/pim_test-
suite/pim_testsuite.pdf
Pusateri [Page 5]
Internet-Draft PIM Sparse-Mode Proposed Standard February 2005
6. Author's Address
Tom Pusateri
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Phone: (408) 745-2000
EMail: pusateri@juniper.net
7. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
8. Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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."
Pusateri [Page 6]
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. RFC 1264 Requirements . . . . . . . . . . . . . . . . . . . . 2
2.1. Documents specifying the Protocol and its Usage . . . . . . 2
2.2. Management Information Base . . . . . . . . . . . . . . . . 2
2.3. Explicit Security Architecture . . . . . . . . . . . . . . . 2
2.4. Implementation Existence . . . . . . . . . . . . . . . . . . 2
2.5. Evidence of Testing . . . . . . . . . . . . . . . . . . . . 3
2.6. Suitability . . . . . . . . . . . . . . . . . . . . . . . . 5
2.7. Authentication Mechanisms . . . . . . . . . . . . . . . . . 5
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
4. Normative References . . . . . . . . . . . . . . . . . . . . . 5
5. Informative References . . . . . . . . . . . . . . . . . . . . 5
6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6
8. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Pusateri [Page i]
