INTERNET-DRAFT PIM-PING Archana Patel Expires 28 December 2007 Cisco Janardhan Kulkarni Citrix 28 June 2007 PIM-PING 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. Abstract As multicast networks start to get deployed in large number, it becomes very important that, proper mechanisms are in place for trouble shooting error conditions and informing other failure situations. Since multicasting has little support from IP in this matter (since ICMP does not support multicasting and broadcasting) it behooves that, multicast routing protocols, embed these features in themselves. This draft presents some ideas about how this can be done using PIM protocol suite as example, since PIMSSM and PIMSM are probably most widely used multicast routing protocols. Archana/Janardhan PIM-PING [Page 1] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 Table of Contents 1. Introduction 3 2. Terminology 4 2.1 Definitions 4 3. PIM-PING Overview 5 4. PIM-PING message formats 6 4.1 Request Message format 6 4.2 Response Message format 9 5. Specification of PIM-Ping 10 5.1. Checking Convexity in PIM-Domain 10 5.1.1. Sending the PIM-PING Request message 10 5.1.2. Processing of the PIM-PING packets at the intermediate Routers 10 5.1.3 Processing of the PIM-PING request packet at the firsthop router towards destination or at destination. 10 5.2. Checking for the RP consistency along a path 10 5.2.1 Sending the PIM-PING message to verify RP consistency 11 5.2.2 Processing of the PIM-PING RP consistency messages at the intermediate routers. 11 5.2.3 Processing of the PIM-PING RP consistency messages at destination. 11 5.3. Request Types 12 5.4. Response Types 12 6. Processing the received response message 13 7. Message Verifications 13 8. References 14 9. Author’s Address 14 10. Copyright (C) The IETF Trust (2007) 15 Archana/Janardhan PIM-PING [Page 2] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 Justification Multicast technology has been around for quite some time now. But widespread deployment of multicasting has just begun. All these days, multicasting technology was revolving around developing efficient, scalable routing protocols. Now that, multicast routing protocols are matured, PIMSSM and PIMSM have established themselves as principal multicast routing protocols, since many applications are using multicasting as their base technology, it is the time to address other aspects like debugging, trouble shooting and error reporting. Most of the work that has been done so far in these areas, either depend on multicast tree being set up or support from IP, and MIBS. But it is our opinion that, multicast routing protocols should in themselves embed necessary mechanisms to address these issues, even if it means protocol implementations needs to be tweaked. Also, we should note that, most of multicast routing protocols which use PULL model like PIMSM, PIMSSM will create a multicast tree only if there are some receivers join the tree. So, to get information about the reachability or to trace the path of multicast data, even before creating the tree it is necessary to extend the protocols. In this draft we want to present some extensions to PIM, which help in trouble shooting PIM related issues. 1. Introduction This draft describes simple extensions to PIM protocol suite to test the convexity of pim domain and RP consistency for a multicast group along a path.A convex pim domain implies that data from a multicast source can be received if the source lies within the domain. Hence this feature can also be used to test whether a multicast source can be reached within a pim domain and to test whether source is sending multicast data. For PIMSM to function properly, it is required that, group to RP mapping is consistent across the pim domain. Since, group to RP mapping is done using various mechanisms like static configurations, BSR-RP and in case of IPV6 embedded RP, it is cumbersome to track the consistency of the mapping across all the routers. Hence these extensions to pim protocol suite can be handy to debug these scenarios.We call these extensions as PIM-PING, since it does the same function for multicast as PING does for unicast routing. PIM-PING as described in this draft can be used to solve following problems: o To test the convexity of pim domain, and to test whether a multicast data source is active. o To test whether RP mapping for a particular group is consistent, at all the routers. Archana/Janardhan PIM-PING [Page 3] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 o To trace the route through which multicast data will traverse, within a pim domain. o To calculate approximately the time needed to construct a SPT or RPT. 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 [1] and indicate requirement levels for compliant PIM-PING implementations. 2.1. Definitions The following terms have special significance for PIM-PING: 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. 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. PIM Neighbor Any adjacent router from which pim hello messages are received. 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. Archana/Janardhan PIM-PING [Page 4] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 3. PIM-PING Overview This document assumes some familiarity with working of PIM protocol suite, specially PIMSM or PIMSSM. PIM-PING uses a 2 new PIM Message types, request and response message which are very similar to PIM Join/prune messages.These messages do not create any state at the intermediate routers, but it does involve processing of these messages by all the routers. PIM-PING uses a method very similar to building a SPT or RPT in PIMSM (or PIMSSM), to test the convexity of PIM domain, or to do the RP consistency. A router generates request message which will be propagated hop by hop towards the destination router. If the any of the intermediate routers fail to propagate the message, they will generate response message back to router which originated the request. If the request message reaches the destination successfully, a response message indicating the success will be generated and sent to the originator of request. Although this feature can be used for both IPV4 and IPV6 versions of PIM protocols, here IPV4 is used to demonstrate the working of PIM-PING. Consider the following topology: 10.0.0.0 20.0.0.0 30.0.0.0 40.0.0.0 [S]-----R1------------R2-------------R3----------R4----------[R5] .1 .2 .1 .2 .1 .2 .1 .2 Suppose at R5, user wants to test the reachability of multicast source S, which is sending multicast data for group G. So, router R5 generates request message, with type as PIMPING_CONVEXITY_TEST, (request message types are explained in detail later) and sends it to the RPF neighbor of S, which in this example is R4. R4 on reception of this packet, in turn sends this packet to R3, Which is RPF neighbor of S at R3. This process continues till either message reaches R1 or one of the router fails to propagate the message.In the former case, R1 being the last hop router and since it recognizes that S is a directly connected multicast data source, it sends back a unicast reply to R5, indicating the success. In case of failure, where message cannot be propagated by a router,an appropriate response message will be generated by the router and will be sent back to R5. Archana/Janardhan PIM-PING [Page 5] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 A similar idea is used to check the RP consistency along a path. Taking the above example, suppose user wants to test whether all the routers from R5 to R2 use same RP for a particular multicast group G. To verify this, R5 will originate a request message with type as PIMPING_RPCONSISTENCY_TEST. It puts the group address and RP it is using for that group in the packet and sends it to the RPF neighbor of destination (which is R2 now). When the packet reaches router R4, it verifies whether RP for group G it is using is same as one in the packet it has got. If the RP being used mismatch, a response message is unicasted back to R5. If RP addresses match then it propagates’ the packet to RPF neighbor of destination. This continues till the packet reaches R2. Here R2 being the destination will send a response message back to R5, informing the consistency of RP addresses along the path. If, any router fails to propagate the packet, either due to RP inconsistency or, due to other problems like having no PIM neighbors, an appropriate response message will be generated back to R5. Routers also append their IPv4/IPV6 addresses in the request message, when they propagate the message towards destination. This list of router addresses is used to trace the path towards multicast data source. 4. PIM-PING Packet Format PIM-Ping uses 2 types of messages o Request Message : This message is generated by the router which wants to use PIM-PING functionality mentioned above. Request packet format and fields are described in the section 4.1. o Response Message : This message is generated by the firsthop router for destination or destination Router or intermediate routers in case of failure, for a particular request. The message format is described in detail in the section 4.2. 4.1 Request Message: All PIM control messages have IP protocol number 103. PIM-PING request message is multicast with TTL 1 to the `ALL-PIM-ROUTERS' Group. The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6 `ALL-PIM-ROUTERS' group is `ff02::d'. In case of IPV6, the source address used for request Message is the link-local address of the interface on which the message is being sent. Archana/Janardhan PIM-PING [Page 6] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 Following is the PIM-Ping Request messages format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upstream Neighbor Address (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |request/response| NA | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination address. (EUF) | | (Normally a Multicast data source) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Group address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | The RP address Used (ESF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Routers | NA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address 1 (Originator of request)(ESF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address 2 (Encoded-Unicast format) (EUF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address n (Encoded-Unicast format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PIM Ver PIM Version number is 2. Type Type for PIM-Ping packet is 14 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 field is zeroed. If the packet's length is not an integral number of 16-bit words, the packet is padded with a trailing byte of zero before performing the checksum. Archana/Janardhan PIM-PING [Page 7] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 For IPv6, the checksum also includes the IPv6 "pseudo-header",as specified in RFC 2460, Section 8.1 [5]. This "pseudo-header" is prepended 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 is 103. Upstream Neighbor Address The upstream neighbor address is the RPF neighbor address for the destination as indicated by the unicast RIB. Unicast Encoding Format used is same as mentioned in Section 4.9.1, RFC 4601. Request Type Request Types are mentioned in Section 5.3. NA Field will be set as zero. Sequence Number Randomly generated number to identify the request message. Destination address Destination address is the address of the router, or multicast source, the path of which is being tested for convexity or RP consistency. Group Address This field contains the multicast group address in encoded group format, for which RP consistency check is being carried out. If the request type is PIMPING_CONVEXITY_TEST,this field will be set to 0, and should be ignored by the routers. RP Address This field contains the RP being used for a multicast group address at a router. If the request type is PIMPING_CONVEXITY_TEST, this field will be set to 0, and should be ignored by the routers. Number of routers This field gives the number of router addresses appended in the router address list. Archana/Janardhan PIM-PING [Page 8] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 Router Address Every router when it propagates the request message will also append its own address to the request message. The first address in this list is that of the router which initiated this request, is used as destination address to generate the response message. The list of router addresses helps in tracing the multicast path towards a particular destination. The address appended is always global routable unicast address, present on the RPF interface on which message will be propagated. 4.2 The Response Message Format: The response message is same as the request message, except the following 2 differences. o Request type field becomes Response type. o When the response is for RP consistency, the “The RP address field”, will indicate, in failure cases, the RP address used for a particular group, at the router where RP’s used for a particular multicast group address mismatch. PIM-PING response message has IP protocol number 103. The response message is unicasted to originator of the request. Address of the originator of request, is got from first address of the routers list from request message. The source address used for response message is a domain-wide reachable unicast routable address. TTL value for response message is same as TTL value used by unicast packet on that router. Upstream Neighbor Address Upstream Neighbor address is set to 0 by sender and is ignored by receiver. Response Type Response type values are mentioned in Section 5.7. All other fields of the response message shall remain same as received request packet for which response is generated. Archana/Janardhan PIM-PING [Page 9] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 5. Specification of PIM-PING functionality. 5.1 Checking the convexity of PIM-Domain. 5.1.1 Sending the PIM-PING request message. When a router wants to verify the reachability of a multicast source, or wants to verify the convexity of PIM domain, it generates a request message and sets the request type as PIMPING_CONVEXITY_TEST. Destination address and upstream neighbor address fields are filled. It also includes a sequence number, which is a randomly generated number to identify the request message. Number of routers field is set as 1, IP address present on the RPF interface towards destination is appended and packet is sent to PIM-ALLROUTERS. An optional implementation may start a timer and repeat the whole process for certain number of times, to make it robust against possible loss of packets. 5.1.2 Processing of the PIM-PING packets at the intermediate routers. When an intermediate router receives a PIM-PING request message, it does message verification as described in section 7. Request message is dropped, if any of the verification checks fail. Router then looks up RPF neighbor for destination address present in the message. If RPF neighbor is found, it fills this address in upstream neighbor field and adds its own IP address present on the RPF interface to the list of router’s addresses. Number of routers count is incremented and packet is sent to PIM-ALLROUTERS. If the router fails to propagate request message it generates a reply message as described in the section 5.4. 5.1.3 Processing of the PIM-PING request packet at the firsthop router towards destination or at destination. When the first hop router towards destination or destination router receives the PIM-PING message, it does the message verification as described in Section. A unicast reply message is sent back to towards the router which issued the request. Details about the various responses are given in section 5.4. 5.2. Checking for the RP consistency along a path. Archana/Janardhan PIM-PING [Page 10] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 5.2.1 Sending the PIM-PING message to verify RP consistency. When a router wants to verify the RP consistency for group, it generates a request message and sets the request type as PIMPING_RPCONSISTENCY_TEST. Destination address and upstream neighbor address fields are filled. The multicast group address for which RP consistency needs to be verified and RP being used for that group are set. It also includes a sequence number, which is a randomly generated number to identify the request message. Number of routers field is set to 1, IP address present on the RPF interface towards destination is appended and message is sent to PIM-ALLROUTERS. An optional implementation may start a timer and repeat the whole process for certain number of times, to make it robust against possible loss of packets. 5.2.2 Processing of the PIM-PING RP consistency messages at the intermediate routers. When an intermediate router receives a PIM-PING request message, it does message the verification as described in section 7. Request message is silently dropped, if any of the verification checks fail. Router then verifies whether RP addresses being used for multicast group are consistent .If they match, router then looks up RPF neighbor for destination address present in the message. If RPF neighbor is found, it fills this address in upstream neighbor field and adds its own IP address present on the RPF interface to the list of router’s addresses. Number of routers count is incremented and packet is sent to PIM-ALLROUTERS. If the RP addresses mismatch or router fails to propagate request message it generates a reply message as described in the section 5.4. 5.2.3 Processing of the PIM-PING RP consistency messages at destination. When the destination router receives the PIM-PING message, it does the message verification as described in Section 7. A unicast reply message is sent back to towards the router which issued the request. Details about the various responses is described in detail in section 5.4. Archana/Janardhan PIM-PING [Page 11] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 5. 3 The request types: This draft describes following two request types 1. To verify convexity of PIM domain (PIMPING_CONVEXITY_TEST): This request type is used to check the convexity of pim domain or reachability of multicast data source through a pim domain. The value for this is 1. 2. To verify RP consistency (PIMPING_RPCONSISTENCY_TEST): This request type is used to check the RP consistency. The value for this is 2. 5.4 The response types: The following are the response types and the values for them, as described in this draft. 1. Source is active [PIMPING_DESTINATION_ACT]: This will be the response type, when a response message is generated by the first hop router in the subnet of destination or destination router itself. Value is 3. 2. Source is not active but is reachable [PIMPING_ DESTINATION _REACHABLE]: This is the response type, when a response message is generated by the first hop router in the subnet of destination or destination router itself. Destination is reachable but is not sending the multicast data. Value is 4. 3. Destination is not present in the subnet of firsthop router. [PIMPING_ DESTINATION _NOTPRESENT]: This will be the response type, when a reply message is generated the first hop router in the subnet of destination. This response will be generated only when first hop router in the subnet of destination has the knowledge that destination address being pinged is not present. Value is 5. 4. Destination is not reachable since unicast route is not present: [PIMPING_DESTINATION_NOUNICASTROUTE]: This response is generated by intermediate routers. Since unicast route is not there, (or no static multicast RPF interface is not configured) join cannot be propagated further. Value is 6. Archana/Janardhan PIM-PING [Page 12] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 5. Destination is not reachable since there there is no pim neighbor on the RPF interface [PIMPING_DESTINATION_NOPIMNBR]: This response is generated by intermediate routers. Since pim neighbor is not present, the request message cannot be propagated further. Value is 7. 6. Destination is not reachable due to configuration issues [PIMPING_DESTINATION_NOPIMCFG]: This response is generated by intermediate routers. Due to configuration related problems, the request message cannot be forwarded. Value is 8. 7. RP addresses used at for a particular group mismatch [RP_MISMATCH]: This response is generated by the router, when the RP address used for a particular group mismatch. The value is 9. 8. RP addresses used for a particular group are consistent [RP_CONSISTANT]: This will be generated by the last hop router or router to which request is issued. This means that, all the routers are using the same RP address for a particular multicast group address, along this path. The value is 10. 6. Processing the recieved response message. The router which recieves the response message should do the packet verification as desribed in the section 9. It should check the source address and sequence number fields to verify that response message is for the request it sent. If the response is intended to it, response type indicates result of its query. 7. Message Verification The following fields of the request and response messages should be verified for the validity before message is processed by the routers. If any of the checks fail, message should be dropped. 1. PIM Ver and Type must have value mentioned in Section 4.1. 2. Upstream address must be valid unicast ip address for ipv4 and valid link-local address for IPv6. This field shall be ignored in response message. 3. Destination address must be valid unicast global ip-address. 4. Routers’ List must contain valid unicast global ip-addresses. Archana/Janardhan PIM-PING [Page 13] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 For RP Consistency messages : 5. RP address must be valid unicast global ip-address. 6. Group address must be valid multicast address. Above fields must be set to zero in the request and response messages for domain convexity tests. 8. References [1] RFC 4601 – Protocol Independent Multicast – Sparse Mode: Protocol Specification [2] RFC 3973 – Protocol Independent Multicast – Dense Mode [3] draft-ietf-pim-bsr-10.txt – Bootstrap Router (BSR) Mechanism for PIM   [4] draft-ietf-pim-ipv6-03.txt - Protocol Independent Multicast Routing in IPv6 9. Author's address Janardhan Kulkarni, Citrix systems, Bangalore. email: janardhan.kulkarni@citrix.com Archana Patel, Cisco Systems, Inc., Bangalore. email: archanap@cisco.com Archana/Janardhan PIM-PING [Page 14] INTERNET-DRAFT Exp: Dec 2007 28 June 2007 10. Copyright (C) The IETF Trust (2007) 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. 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. Intellectual Property 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. Archana/Janardhan PIM-PING [Page 15] INTERNET-DRAFT Exp: Dec 2007 28 June 2007