Internet DRAFT - draft-hemige-pim-improved-assert

draft-hemige-pim-improved-assert






  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]