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]