PIM Working Group B. Joshi Internet-Draft Infosys Technologies Ltd. Expires: August 17, 2008 A. Patel Cisco Systems, Inc. J. Kulkarni Citrix systems February 14, 2008 PIM Protocol States Diagnostics draft-joshi-pim-protocol-state-diag-00.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 BCP 79. 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. This Internet-Draft will expire on August 17, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract Multicast networks are being deployed in large numbers. It becomes very important that, proper mechanisms are in place for troubleshooting error conditions and diagnosing other failure situations. Since multicasting has little support from IP in this matter (since ICMP does not support multicasting and broadcasting) it Joshi, et al. Expires August 17, 2008 [Page 1] Internet-Draft PIM Protocol States Diagnostics February 2008 behooves that, multicast routing protocols, embed these features in themselves. There are various debugging tools available to debug Multicast connectivity [ssmping][3] and to trace multicast routes [mtrace][4] but there is none to diagnose, troubleshoot routing protocol states. Since PIM protocol family is probably the most widely used multicast routing protocol, this draft suggests an extension to PIM protocol to diagnose and troubleshoot various PIM states in PIM routers. Joshi, et al. Expires August 17, 2008 [Page 2] Internet-Draft PIM Protocol States Diagnostics February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. TLV options . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Upstream Neighbor Address option . . . . . . . . . . . 8 4.1.2. Multicast Group Address option . . . . . . . . . . . . 9 4.1.3. RP Address option . . . . . . . . . . . . . . . . . . 9 4.1.4. Source Address option . . . . . . . . . . . . . . . . 9 4.1.5. BSR Address option . . . . . . . . . . . . . . . . . . 10 4.1.6. Router Address option . . . . . . . . . . . . . . . . 10 4.1.7. Timestamp option . . . . . . . . . . . . . . . . . . . 10 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Request Message . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. The request types . . . . . . . . . . . . . . . . . . 12 5.2. The response types . . . . . . . . . . . . . . . . . . . . 12 5.2.1. Response Message . . . . . . . . . . . . . . . . . . . 13 5.3. Reference topology . . . . . . . . . . . . . . . . . . . . 14 5.4. New PIM Hello option . . . . . . . . . . . . . . . . . . . 15 5.5. A dry-run for Join state . . . . . . . . . . . . . . . . . 15 5.5.1. ASM Join test . . . . . . . . . . . . . . . . . . . . 15 5.5.2. SSM Join test . . . . . . . . . . . . . . . . . . . . 16 5.6. Testing RP consistency state . . . . . . . . . . . . . . . 17 5.6.1. Sending the request message . . . . . . . . . . . . . 17 5.6.2. Processing of these messages at the intermediate routers . . . . . . . . . . . . . . . . . . . . . . . 17 5.6.3. Processing of these messages at border routers . . . . 17 5.7. Testing E-BSR consistency state . . . . . . . . . . . . . 18 5.7.1. Sending the request message . . . . . . . . . . . . . 18 5.7.2. Processing of these messages at the intermediate routers . . . . . . . . . . . . . . . . . . . . . . . 18 5.7.3. Processing of these messages at border routers . . . . 18 5.8. Processing the response message at originator . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Normative References . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Joshi, et al. Expires August 17, 2008 [Page 3] Internet-Draft PIM Protocol States Diagnostics February 2008 1. Introduction Multicast technology has been around for quite some time now. But widespread deployment of multicasting has just begun. Multicast routing protocols of PIM protocol family have established themselves as principal multicast routing protocols. As of this writing, there are various tools available to debug Multicast connectivity [ssmping] and tracing multicast routes [mtrace] but there is none to diagnose, troubleshoot routing protocol states. We believe that capability to diagnose routing protocol states should be embedded in the routing protocol itself. It also becomes necessary to extend the routing protocol to provide diagnosing capabilities when a user would want to diagnose the multicast domain even before the protocol states are created. For example: An administrator may want to test whether joining a particular SSM channel will be successful or not even before source starts sending data traffic or receivers start joining the channel. This draft describes simple extensions to PIM protocol suite to diagnose various PIM states in the PIM domain. Following tests can be carried out based on the functionality described in this document: o To carry a dry-run to join a Multicast Group [ASM/SSM] o To calculate approximately the time needed to construct a SPT or RPT. [Yet to be discussed] o To test the RP consistency for a Multicast Group in the PIM domain. o To carry a dry-run to check E-BSR consistency in the PIM domain. o To trace the route through which multicast data will traverse, within a pim domain. o To carry a dry-run for asserting for a (*,G)/(S,G) state. [TBD] Joshi, et al. Expires August 17, 2008 [Page 4] Internet-Draft PIM Protocol States Diagnostics February 2008 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119. This document also uses following terms: o RPF Interface RPF stands for "Reverse Path Forwarding". The RPF Interface of a router with respect to an address is the interface that the unicast- routing table indicates should be used to reach that address. o RPF Neighbor The RPF Neighbor of a router with respect to an address is the neighbor that the Unicast Routing Table indicates should be used to reach that address. o PIM Neighbor Any neighbor router with which pim hello adjacency is established. o Rendezvous Point (RP) RP is a router that has been configured to be used as the root of the non-source-specific distribution tree for a multicast group. Join messages from receivers for a group are sent towards the RP, and data from senders is sent to the RP so that receivers can discover who the senders are, and start to receive traffic destined for the group. Joshi, et al. Expires August 17, 2008 [Page 5] Internet-Draft PIM Protocol States Diagnostics February 2008 3. Protocol Overview This document assumes some familiarity with working of PIM protocol suite. This document introduces a new PIM Message type 'x'. This document also introduces a new PIM hello option 'xx' which is used to negotiate the capability of handling the new PIM message type. Processing of the new message does not lead to creation of any state in a router. This document suggest different methods to diagnose different PIM states. These methods are either similar to the way SPT/RPT is built in PIM or similar to how Group-RP mappings are flooded in the PIM domain. For carrying out a dry-run for a PIM Join state, a router generates a request message which is propagated hop by hop either towards the RP (for ASM requests) or towards the DR of a source( for SSM requests). Each hop forwards the request to upstream neighbor if it can successfully join the group. When the request reaches the RP or DR of the source, it generates a response message back to the originator. For carrying out a dry-run for RP consistency, a router generates a request message which is flooded to all PIM enabled interfaces. PIM neighbors receiving this message process it similar to the way they process BSR messages. When the message reaches to the PIM border router, it generates a response message back to the originator. A dry-run for PIM Assert message can be done similar to PIM Join state. A dry-run for E-BSR consistency can be done similar to RP consistency. An administrator can use dry-run test for PIM Join state to calculate the time in constructing a RPT or SPT. Routers also append their IPv4/IPV6 addresses in the request message, if originator has asked for it. This list of router addresses could be used to trace the path towards multicast data source or a RP. Joshi, et al. Expires August 17, 2008 [Page 6] Internet-Draft PIM Protocol States Diagnostics February 2008 4. Message Format PIM Diagnostic message has a constant header and options in TLV format. One or multiple options can be present in a message. Refer to section [] for more details on which message should include which options. Common message header is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message type | Rqst/Response | Transaction Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originator Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV Option #1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV Option #2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | | : | | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV Option #n | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM Version number is 2. Type Type for the message is x [Is IANA registry required for this?] Reserved Set to zero on transmission. Ignored upon receipt. Checksum The checksum is a standard IP checksum, i.e.,the 16-bit one's complement of the one's complement sum of the entire PIM message. For computing the checksum, the checksum Joshi, et al. Expires August 17, 2008 [Page 7] Internet-Draft PIM Protocol States Diagnostics February 2008 field is zeroed. If the message's length is not an integral number of 16-bit words, the message is padded with a trailing byte of zero before performing the checksum. For IPv6, the checksum also includes the IPv6 "pseudo-header",as specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" is perpended to the PIM header for the purposes of calculating the checksum. The "Upper-Layer Packet Length" in the pseudo-header is set to the length of the PIM message. The Next Header value used in the pseudo-header SHOULD BE 103. Message Type As of now, it supports only two type of Diagnostic messages. One is request message and another is response message. Request/Response Type In request message, this is populated with the diagnostic test that needs to run. In response message, it contains the response code. Request Types are mentioned in Section 5.1 and response types are mentioned in section 5.2 Transaction Number Randomly generated number to identify the request message. An originator use this to identify whether it has been expecting a response message. Originator Address This field contains the Originators address in Encoded Unicast address format. This is used as the destination address when a router generates a response message. 4.1. TLV options Request and Response message MAY contain one or multiple TLV options. Some TLV options are mandatory for specific request/response message types. 4.1.1. Upstream Neighbor Address option This TLV option is used when a message needs to be forwarded hop-by- hop towards the RP/Source i.e. similar to the PIM Join message. This option contains the Upstream Neighbor's address in encoded unicast address format. Unicast Encoding Format used is same as mentioned in Section 4.9.1, RFC 4601[1]. Joshi, et al. Expires August 17, 2008 [Page 8] Internet-Draft PIM Protocol States Diagnostics February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Neighbor Address | | (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2. Multicast Group Address option This TLV option is used to identify the Multicast Group address for which a test is being conducted. This option contains the Multicast Group address in encoded multicast address format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group address | | (Encoded Multicast format ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.3. RP Address option This TLV option is used to identify the RP address when a RP consistency test is conducted. This option contains the RP address in encoded source address format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RP address | | (Encoded Source format ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.4. Source Address option This TLV option is used to identify the source address when either an SSM PIM join state or convexity of the PIM domain is tested. This option contains the source address in encoded source address format. Joshi, et al. Expires August 17, 2008 [Page 9] Internet-Draft PIM Protocol States Diagnostics February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source address | | (Encoded Source format ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.5. BSR Address option This TLV option is used to identify the BSR address. This is used while running a E-BSR consistency test. This option contains the unicast address in encoded unicast address format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSR address | | (Encoded Unicast format ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.6. Router Address option This TLV option is used when a user wants intermediate routers to append their IP addresses in the message. This option contains the router address in encoded unicast address format. Number of routers is calculated based on the length in TLV option. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router's address | | (Encoded Source format ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.7. Timestamp option This TLV option MAY be used when an administrator is doing a ASM/SSM join to test the time taken in building a shared/source specific tree. The Length of this option is 8. Joshi, et al. Expires August 17, 2008 [Page 10] Internet-Draft PIM Protocol States Diagnostics February 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time stamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Joshi, et al. Expires August 17, 2008 [Page 11] Internet-Draft PIM Protocol States Diagnostics February 2008 5. Protocol Details 5.1. Request Message All diagnostic request messages uses IP protocol number 103 [Same as PIM Control message]. The request message is multicast with TTL 1 to the `ALL-PIM-ROUTERS' Group. 5.1.1. The request types This draft describes following request types: o ASM_JOIN_TEST This request type is used when an administrator wants to test the ASM Join state for a given Group Address. This request message MUST contain 'Group Address option' and 'Upstream Neighbor address option' TLVs. This request MAY contain the 'Timestamp' option if administrator wants to check the time taken in building a Shared/ Source Specific Tree. The value for this option is 1. o SSM_JOIN_TEST This request type is used when an administrator wants to test the SSM Join state for a given Group Address and source address. This request message MUST contain 'Group Address option', 'Source address option' and 'Upstream Neighbor address option' TLVs. This request MAY contain the 'Timestamp' option if administrator wants to check the time taken in building a Shared/Source Specific Tree. The value for this option is 2. o EBSR_CONSISTENCY_TEST This request type is used when an administrator wants to test the Elected-BSR consistency in a PIM domain. This request message MUST contain 'BSR Address option', TLV. The value for this option is 3. o RP_CONSISTENCY_TEST This request type is used when an administrator wants to test the RP consistency in a PIM domain. This request message MUST contain 'Group Address option' and 'RP Address option', TLVs. The value for this option is 4. 5.2. The response types Joshi, et al. Expires August 17, 2008 [Page 12] Internet-Draft PIM Protocol States Diagnostics February 2008 5.2.1. Response Message All response messages also uses IP protocol number 103 [Same as PIM Control message]. The response message is unicast to the originator's unicast address available in the received request message. TTL in the response message is set to the same value which the router would use when generating a unicast message. A response message MAY have zero, one or multiple TLV options. 'Originator address' in the message header is set to the router's unicast address which is generating the response message. The following are the response types and the values for them, as described in this draft: o JOIN_STATE_SUCCESS This response type is used by either a RP for ASM_JOIN_TEST request or by the DR of a source for SSM_JOIN_TEST request when the join state test succeeded. This need not contain any TLV option. The value for this response type is 1. o RP_MATCH This response type is used by PIM Border router when they receive a RP_CONSISTENCY_TEST request message. This need not contain any TLV option. The value for this response type is 2. o EBSR_MATCH This response type is used by PIM Border router when they receive a EBSR_CONSISTENCY_TEST request message. This need not contain any TLV option. The value for this response type is 3. o NO_PIM_NEIGHBOR This response type is used by PIM routers when they receive a request message but does not have a upstream PIM Neighbor. This need not contain any TLV option. The value for this response type is 4. o NO_UNICAST_ROUTE This response type is used by PIM routers when they receive a request message but does not have a unicast route to find out the next destination. This need not contain any TLV option. The value for this response type is 5. o NO_PIM_CONFIGURATION Joshi, et al. Expires August 17, 2008 [Page 13] Internet-Draft PIM Protocol States Diagnostics February 2008 This response is generated by intermediate routers. Due to configuration related problems, the request message could not be forwarded. The value for this response type is 6. o RP_MISMATCH This response is generated by the router, when the RP address used for the multicast group does not match the RP address available in the request message. This response message MAY contain the 'RP address option' containing the RP address used by the router generating the response message. The value for this response type is 7. o EBSR_MISMATCH This response is generated by the router, when the Elected-BSR address used by the router does not match with what is available in the request message. This message MAY contain the 'BSR address option' containing the E-BSR address used by the router generating the response message. The value for this response type is 8. o UPSTREAM_NBR_NOT_CAPABLE This response type is used by a router when it finds that the upstream neighbor it has selected, is not capable of handling PIM diagnostic messages. The value for this response type is 9. o MSG_VERIFICATION_ERROR This response type is used by a router in which verification of a request message fails. This need not contain any TLV option. The value for this response type is 10. 5.3. Reference topology Following topology is used as reference to explain various test cases that can be carried out using PIM diagnostic functionality: | +------R6 | | R1----+------R2----+------R3-+ | [RP] | | | +------R7 | | | | +------R4----+-----R5 | Joshi, et al. Expires August 17, 2008 [Page 14] Internet-Draft PIM Protocol States Diagnostics February 2008 5.4. New PIM Hello option A new PIM hello option is introduced to establish a router's capability of handling PIM diagnostic messages. A router would always add this option if it can handle these diagnostic messages. Before sending a PIM diagnostic message to an upstream PIM neighbor, a router first checks if that neighbor is capable of handling these messages. If the upstream neighbor router is not capable of handling these messages, it generates a response message with response type set to UPSTREAM_NBR_NOT_CAPABLE. Hello option will look as follows: o OptionType X: PIM Diagnostic Capable 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 = X | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.5. A dry-run for Join state 5.5.1. ASM Join test 5.5.1.1. Sending the request message Suppose at R5, an administrator wants to test an ASM join for a multicast group 'G'. It would generate a diagnostic request message with request type as 'ASM_JOIN_TEST' and sends it towards the 'RP' [Router 'R2'] as a normal PIM join for group address 'G' would have been sent. In the message header, originator's address will be set to its own address. Following TLV option MUST be added to the message: o 'Multicast Group Address option' containing the Group Address that needs to be joined. o 'Upstream Neighbor's address option' which should process this message. In this case, Upstream Neighbor's address option would contain the address of 'R4'. Following TLV options MAY optionally be added to the message: o 'Router Address option' could be used if originator wants every router to append its unicast address in the list. Joshi, et al. Expires August 17, 2008 [Page 15] Internet-Draft PIM Protocol States Diagnostics February 2008 o 'Timestamp option' could be used if originator wants to measure the time in constructing SPT or RPT. The message is sent to ALL-PIM-ROUTERs address. 5.5.1.2. Processing of these messages at the intermediate routers When 'R4' receives the message, it first verifies the PIM version, type, checksum of the message. For a ASM_JOIN_TEST, router MUST also verify that the message contains 'Group Address option' and 'Upstream neighbor option' TLVs. If the verification of a message fails, a response message is sent back to the originator. After verifying the message, it does all the operations it would have done when it would have received a normal PIM join request for this 'group'. It generates an error response back if it would have failed to create the Join state. Otherwise it would forward it towards the 'RP' [i.e. router 'R2']. An intermediate router could generate an error response if an upstream PIM neighbor is not capable of handling the PIM diagnostic messages. If 'Router address option' is present, a router processing this request, would also update its unicast address in the 'Router address option' TLV. 5.5.1.3. Processing of these request messages at the RP When router 'R2' receives this request, it process it similar to other routers. During processing, it finds out that it is the 'RP' for this request and so generates a response with response type 'JOIN_STATE_SUCCESS' back to the originator. If the request message contains 'Router option', it SHOULD append its own address in the 'Router option'. It MUST append this 'Router option' in the response message. If the request message contains a "Timestamp option", RP adds the received "Timestamp option" as it is and also appends a new "Timestamp option" to the response message. 5.5.2. SSM Join test When an administrator wants to test the SSM join state, it would generate a diagnostic message with request type 'SSM_JOIN_TEST'. In this case, the request MUST also include 'Source address option' TLV and instead of sending it towards the RP, this message is sent Joshi, et al. Expires August 17, 2008 [Page 16] Internet-Draft PIM Protocol States Diagnostics February 2008 towards the source. Intermediate routers must verify that the message also contains the 'Source address option' TLV. This message is forwarded and processed similar to how an ASM_JOIN_TEST message is forwarded and processed. When the request reaches the DR of the source, it generates a response message back to the originator. 5.6. Testing RP consistency state 5.6.1. Sending the request message When an administrator wants to check the RP consistency in a PIM domain, it generates a diagnostic message with type 'RP_CONSISTENCY_TEST'. Let us assume that administrator start this test on router 'R4'. 'R4' would send this message to all PIM enable interfaces i.e. towards 'R5' and 'R1'/'R2'. This message is sent to ALL-PIM-ROUTERS address. 5.6.2. Processing of these messages at the intermediate routers When 'R1'/'R2' or 'R5' receives this message, it first verifies the PIM message type, version and checksum. Routers silently discards a message if the RPF check for the originator address fails. It also expect the message to have 'RP address option' TLV option. If the verification of a message fails, a response message is sent back to the originator. After verifying the message, they do the consistency check for 'RP' for the multicast group address available in the request message with the 'RP' address available in the request message. If the check fails, they generate a response message with message type 'RP_MISMATCH' back to the originating router but forward the request message to all PIM enabled interface. If the consistency check passes, it does not generate any response and forward this message on all the PIM enabled interface except on which the request message was received. [NOTE: We can also make a router discard the message if the RP consistency check fails but in that case an administrator may need to start the test again after fixing this router] 5.6.3. Processing of these messages at border routers When this message reaches the PIM Border router, PIM Border router generates a response message. An originating router could receive as much response message as the number of border routers in the PIM domain. An originating router MAY wait for some time to make sure that it has received responses from all border routers in the PIM domain. Joshi, et al. Expires August 17, 2008 [Page 17] Internet-Draft PIM Protocol States Diagnostics February 2008 5.7. Testing E-BSR consistency state 5.7.1. Sending the request message Let us assume that an administrator wants to test the E-BSR consistency in its PIM domain starting at Router 'R2'. When the test starts, Router 'R2' would generate diagnostic message with message type 'EBSR_CONSISTENCY_TEST' and send it out on all the PIM enabled interfaces. 5.7.2. Processing of these messages at the intermediate routers Router 'R1', 'R4' and 'R3' would receive this message. They will process it similar to how they process BSMs [Bootstrap Messages]. These intermediate router first verifies that the message is received on an RPF interface towards the 'Originator address' available in request message header. A message is silently dropped if RPF check fails. These intermediate routers than verifies PIM version and checksum. They also expect the message to have 'BSR address option' TLV option. If the verification of a message fails, a response message is sent back to the originator. After verifying the message, they check the E-BSR they are using against the one available in the message. If there is a mismatch, they generate a response message with message type EBSR_MISMATCH. The request message is forwarded to all the PIM interfaces except on which the request message was received. 5.7.3. Processing of these messages at border routers When these messages reaches the border routers of the PIM domain, after processing the message as mentioned in the previous section, they generate a response message with message type EBSR_MATCH and send it to the originator. 5.8. Processing the response message at originator When the originating router receives a response message, it verifies the PIM version, type and checksum. It also checks the transaction number and the destination IP/IPv6 address to verify that the response message is for one of the request it had sent. It silently discards the response message if it is not expecting a response. Joshi, et al. Expires August 17, 2008 [Page 18] Internet-Draft PIM Protocol States Diagnostics February 2008 6. Security Considerations This document suggest a mechanism which is similar to the mechanism already described in PIM-SM[1], PIM-SM-BSR[2]. As mechanism suggested in this document does not create any states in routers except the originating router, it can not be used to affect functionality of a router. An implementation SHOULD provide means to rate-limit the number of diagnostic messages it generates, accepts and processes. Joshi, et al. Expires August 17, 2008 [Page 19] Internet-Draft PIM Protocol States Diagnostics February 2008 7. IANA Considerations This document needs IANA to assign a unique value for the new PIM Hello option type {X} as described in section 5.4. Joshi, et al. Expires August 17, 2008 [Page 20] Internet-Draft PIM Protocol States Diagnostics February 2008 8. Acknowledgments Pavan Kurapati provided useful review comments on this document. 9. Normative References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [2] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. [3] Venaas, S. and H. Santos, "ssmping Protocol", draft-ietf-mboned-ssmping-02 (work in progress), November 2007. [4] Asaeda, H., Jinmei, T., Fenner, B., and S. Casner, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace-v2-00 (work in progress), November 2007. Joshi, et al. Expires August 17, 2008 [Page 21] Internet-Draft PIM Protocol States Diagnostics February 2008 Authors' Addresses Bharat Joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: bharat_joshi@infosys.com URI: http://www.infosys.com/ Archana Patel Cisco Systems, Inc. Bangalore India Email: archanap@cisco.com URI: http://www.cisco.com/ Janardhan Kulkarni Citrix systems Bangalore India Email: janardhan.kulkarni@citrix.com URI: http://www.citrix.com/ Joshi, et al. Expires August 17, 2008 [Page 22] Internet-Draft PIM Protocol States Diagnostics February 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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, THE IETF TRUST 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Joshi, et al. Expires August 17, 2008 [Page 23]