INTERNET DRAFT Venu Hemige Internet Engineering Task Force Suresh Boddapati Document: Alcatel draft-hemige-pim-improved-assert-00.txt Yetik Serbest November 2005 SBC Category: Informational Expires: May 2006 Improved Assert in PIM-SM Status of this memo 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. IPR Disclosure Acknowledgement 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. Abstract In [PIM-SM], assert procedures are triggered by data-plane interaction with the control-plane when traffic arrives on an outgoing interface. There are several disadvantages with this in that duplicate traffic is forwarded downstream until an assert winner is elected and seen by all routers on the LAN; such dependence on the data-plane to build control-plane state does not scale well. When [PIM-SM] is used to setup P2MP LSP trees as in [SURESH-P2MP], it is [Page 1] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 not always possible to determine if traffic arrived on an outbound interface . This draft proposes mechanisms to trigger assert completely in the control plane by reacting to Joins sent to another router on a LAN. These procedures are essential when it is not possible to determine if traffic arrived on an outbound interface. It also helps completely remove the dependency on data-plane to trigger asserts and eliminates duplicate traffic resulting from assert scenarios. Conventions used in this document 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 RFC 2119. Table of Contents 1. Introduction....................................................2 2. Control Plane Assert Mechanism..................................3 2.1. Definition of event "See Join"................................3 2.2. Changes to the Per-Interface (S,G) Assert State Machine.......4 2.2.1. Changes to CouldAssert(S,G,I)...............................4 2.2.2. Changes to (S,G) Assert Action A1...........................5 2.3. Changes to the Per-Interface (*,G) Assert State Machine.......5 2.3.1. Changes to (*,G) Assert Action A1...........................6 2.4. Assert Message Refreshes......................................6 3. Compatibility with PIM-SM v2 Routers............................6 4. Security Considerations.........................................7 5. IANA Considerations.............................................7 6. Normative References............................................7 7. Informative References..........................................7 1. Introduction In [PIM-SM], assert procedures on a LAN are triggered by data-plane interaction with the control-plane when traffic arrives on an outgoing interface. There are several disadvantages with this: - Duplicate traffic is forwarded downstream until an assert winner is elected and seen by all routers on the LAN - Such dependence on the data-plane to build control-plane state does not scale well. - It is not always deterministic who wins an (S,G) assert election due to possible race conditions. Since CouldAssert(S,G,I) depends on the SPT bit, a router on which the SPT bit is set first may become the assert winner even though its assert metric is worse than another router on the LAN. [Page 2] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 - When [PIM-SM] is used to setup P2MP LSP trees as in [SURESH- P2MP], it is not always possible to determine if traffic arrived on an outbound interface. It is desirable to trigger assert procedures completely in the control-plane and remove the data-plane dependency to address the above issues. It is also desirable to elect an assert winner even before traffic starts flowing on the LAN so that no duplicate traffic is forwarded to the LAN. This is particularly important for some applications like IPTV, duplicate traffic is as bad as lost traffic. Another important benefit of these procedures is that these procedures can be used in scenarios, e.g. [SURESH-P2MP], where assert procedures cannot always be triggered by looking at the packet that arrives on an outgoing interface. By implementing the simple changes defined in this document - There will be no duplicate traffic forwarded on a LAN due to multiple forwarders on the LAN. - There will not be any control-plane dependence on the data- plane to trigger assert states, so the design becomes a lot simpler and scales much better. - It can be used in scenarios where it is not possible to determine if traffic for a flow is received on an outbound interface. Regular assert mechanisms are ineffective in such cases. - A PIM-SM router adopting improved-assert mechanisms is fully compatible with PIM-SM v2 routers. 2. Control Plane Assert Mechanism The downstream join/prune state machine in [PIM-SM] defines procedures for "receive" join/prunes. i.e. if join/prune messages are sent to other routers on the same LAN, they are silently ignored. 2.1. Definition of event "See Join" A "See Join(S,G) on interface I" is an event that occurs when a Join(S,G) is received on interface I and the router is not the Upstream Neighbor for that Join. If a router sees a Join(S,G) and CouldAssert(S,G,I) is TRUE on that router, then it means there will be two routers forwarding traffic to the LAN. Hence we need to assert as a result of the "See Join(S,G) on interface I" event. Similarly, we define "See Join(*,G) on interface I" as the event that occurs when a Join(*,G) is received on interface I and the router is not the Upstream Neighbor for that Join. [Page 3] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 "See Join(*,*,RP) on interface I" is the event that occurs when a Join(*,*,RP) is received on interface I and the router is not the Upstream Neighbor for that Join. We also define "see pim_include(S,G) on interface I" as an event that occurs when local_receiver_include(S,G,I) becomes TRUE, but I is not in pim_include(S,G). This event implies that there is a local receiver on the LAN interface I, but the router is not the PIM-DR on that interface. So another router which is the PIM-DR is a forwarder for the (S,G). If CouldAssert(S,G,I) is also TRUE, then it means this router is also going to be a forwarder. Similarly "see pim_include(*,G) on interface I" is the event that occurs when local_receiver_include(*,G,I) becomes TRUE, but I is not in pim_include(*,G). 2.2. Changes to the Per-Interface (S,G) Assert State Machine Following changes are required to the (S,G) Assert State Machine defined in section 4.6.1 of [PIM-SM]. If the current Assert State is "No Info" and we see a "Join(S,G) or Join(*,G) or Join(*,*,RP) or pim_include(S,G) or pim_include(*,G)" addressed to another router on the interface I and CouldAssert(S,G,I) is TRUE, then the Assert state machine MUST trigger Action A1 specified in section 4.6.1 of [PIM-SM] and the Assert State MUST change to "I am Assert Winner" state. This rule replaces the rule "Data arrives from S to G on I and CouldAssert(S,G,I)". If the current Assert State is "I Am Assert Winner (W)" and we see a "Join(S,G) or Join(*,G) or Join(*,*,RP) or pim_include(S,G) or pim_include(*,G)" addressed to another router on interface I AND CouldAssert(S,G,I) is TRUE, then the Assert state machine MUST trigger Action A1 specified in section 4.6.1 of [PIM-SM] and the Assert State MUST remain "I Am Assert Winner". This rule is added to handle the case where a router (R1) is already the Assert Winner for the LAN and subsequently JoinDesired(S,G) or RPTJoinDesired(G) on another router (R2) becomes TRUE causing it to send a Join(S,G) or Join(*,G) or Join(*,*,RP) to a third router R3 or causes pim_include(S,G) or pim_include(*,G) to become TRUE on the third router R3. 2.2.1. Changes to CouldAssert(S,G,I) [Page 4] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 Since the idea is to trigger Assert by simply "seeing Joins" prior to the flow of data traffic, CouldAssert(S,G,I) MUST NOT depend on the SPT bit. Instead CouldAssert(S,G,I) MUST be changed to the following: CouldAssert(S,G,I) = JoinDesired(S,G) == TRUE AND (RPF_interface(S) != I) AND (I in ( ( joins(*,*,RP(G)) (+) joins(*,G) (-) prunes(S,G,rpt) ) (+) ( pim_include(*,G) (-) pim_exclude(S,G) ) (-) lost_assert(*,G) (+) joins(S,G) (+) pim_include(S,G) ) ) This change causes Assert election to be possible by "see joins" and it also makes determining who on a LAN becomes the assert winner deterministic. 2.2.2. Changes to (S,G) Assert Action A1 For better reliability of Assert messages when improved-assert is employed, we SHOULD set Assert Timer to Assert_Period in Action A1 of section 4.6.1 in [PIM-SM]. 2.3. Changes to the Per-Interface (*,G) Assert State Machine Following changes are required to the (*,G) Assert State Machine defined in section 4.6.2 of [PIM-SM]. If the current Assert State is "No Info" and we see a "Join(*,G) or Join(*,*,RP) or pim_include(*,G)" addressed to another router on the interface I and CouldAssert(*,G,I) is TRUE, then the Assert state machine MUST trigger Action A1 specified in section 4.6.2 of [PIM-SM] and the Assert State MUST change to "I am Assert Winner" state. This rule replaces the rule "Data arrives for G on I and CouldAssert(*,G,I)". If the current Assert State is "I Am Assert Winner (W)" and we see a "Join(*,G) or Join(*,*,RP) or pim_include(*,G)" addressed to another router on interface I AND CouldAssert(*,G,I) is TRUE, then the Assert state machine MUST trigger Action A1 specified in section 4.6.2 of [PIM-SM] and the Assert State MUST remain "I Am Assert Winner". This rule is added to handle the case where a router (R1) is already the Assert Winner for the LAN and subsequently RPTJoinDesired(G) on another router (R2) becomes TRUE causing it to send a Join(*,G) or Join(*,*,RP) to a third router R3 or causes pim_include(*,G) to become TRUE on a third router R3. [Page 5] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 2.3.1. Changes to (*,G) Assert Action A1 For better reliability of Assert messages when improved-assert is employed, we SHOULD set Assert Timer to Assert_Period in Action A1 of section 4.6.2 in [PIM-SM]. 2.4. Assert Message Refreshes Since the current Assert mechanism defined in [PIM-SM] relies on the data-plane, Assert messages are refreshed by the Assert Winner a few seconds before the Assert Timer expires on the other routers. But with the changes proposed above, it becomes important to protect against the possibility of Assert refreshes getting lost. The following changes are proposed to the Assert timer values defined in section 4.11 of [PIM-SM]. We define a new "Assert Period" value as the time when periodic Assert messages MUST be sent by the Assert Winner implementing this improved-assert mechanism. Assert_Override_Interval is deprecated. "Assert_Time" SHOULD be the same as is currently defined. Timer Names: Assert Timer (AT(*,G,I), AT(S,G,I)) +---------------------+----------------------+----------------------+ | Value Name | Value | Explanation | +---------------------+----------------------+----------------------+ | Assert_Period | Default: 50 secs | Period between periodic | | | | assert messages from | | | | the assert winner. | +---------------------+-------------------+-------------------------+ | Assert_Time | Default: 180 secs | Period after last assert| | | | before assert state is | | | | timed out. | +---------------------+-------------------+-------------------------+ Note that for historical reasons, the Assert message lacks a Holdtime field. Thus changing the Assert Time from the default value is not recommended. 3. Compatibility with PIM-SM v2 Routers A PIM-SM Router adopting the improved-assert mechanism is fully compatible with PIM-SM v2 Router. It is not required for all routers on a LAN to support improved-assert for it to work. When only some routers on a LAN implement improved-assert, it does tilt the choice of (S,G) assert winner to the improved-assert router(s). But that is a good thing because it helps eliminate duplicate traffic due to assert when the improved-assert router is the assert-winner. While [Page 6] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 the benefits of improved-assert can be fully realized only when all routers on the LAN support it, it does help those routers supporting improved-assert by removing the dependence on the data-plane to trigger assert election and eliminating duplicate traffic due to assert when the improved-assert router is the assert winner. For assert procedures to work properly in scenarios where PIM-SM is used to setup P2MP LSP trees, all routers on the LAN MUST support improved-assert. 4. Security Considerations Security considerations provided in [PIM-SM] apply to this document as well. 5. IANA Considerations This document does not require any IANA assignments or action. 6. Normative References 7. Informative References [PIM-SM] Fenner, W, et al., "Protocol Independent Multicast- Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11.txt, April 2005. [SURESH-P2MP] Boddapati, S, et al., "P2MP LSP Setup using PIM and LDP", draft-boddapati-mpls-ldp-p2mp-00.txt, November 2005. Authors' Addresses Venu Hemige Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Venu.hemige@alcatel.com Suresh Boddapati Alcatel North America 701 East Middlefield Rd. Mountain View, CA 94043 Suresh.Boddapati@alcatel.com Yetik Serbest SBC Labs 9505 Arboretum Blvd. Austin, TX 78759 Yetik_serbest@labs.sbc.com Acknowledgements The authors would like to thank Jozef Raets, Devendra Raut and Jayant Kotalwar of Alcatel for their ideas and support. [Page 7] Internet Draft draft-hemige-pim-improved-assert-00.txt Nov, 2005 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. 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. 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. [Page 8]