From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5015.txt | 2411 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2411 insertions(+) create mode 100644 doc/rfc/rfc5015.txt (limited to 'doc/rfc/rfc5015.txt') diff --git a/doc/rfc/rfc5015.txt b/doc/rfc/rfc5015.txt new file mode 100644 index 0000000..b148f60 --- /dev/null +++ b/doc/rfc/rfc5015.txt @@ -0,0 +1,2411 @@ + + + + + + +Network Working Group M. Handley +Request for Comments: 5015 UCL +Category: Standards Track I. Kouvelas + T. Speakman + Cisco + L. Vicisano + Digital Fountain + October 2007 + + + Bidirectional Protocol Independent Multicast (BIDIR-PIM) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document discusses Bidirectional PIM (BIDIR-PIM), a variant of + PIM Sparse-Mode that builds bidirectional shared trees connecting + multicast sources and receivers. Bidirectional trees are built using + a fail-safe Designated Forwarder (DF) election mechanism operating on + each link of a multicast topology. With the assistance of the DF, + multicast data is natively forwarded from sources to the Rendezvous- + Point (RP) and hence along the shared tree to receivers without + requiring source-specific state. The DF election takes place at RP + discovery time and provides the route to the RP, thus eliminating the + requirement for data-driven protocol events. + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 1] + +RFC 5015 Bidirectional PIM October 2007 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 2.1. Definitions ................................................4 + 2.2. Pseudocode Notation ........................................6 + 3. Protocol Specification ..........................................6 + 3.1. BIDIR-PIM Protocol State ...................................7 + 3.1.1. General Purpose State ...............................8 + 3.1.2. RPA State ...........................................8 + 3.1.3. Group State .........................................9 + 3.1.4. State Summarization Macros .........................10 + 3.2. PIM Neighbor Discovery ....................................11 + 3.3. Data Packet Forwarding Rules ..............................11 + 3.3.1. Upstream Forwarding at RP ..........................12 + 3.3.2. Source-Only Branches ...............................12 + 3.3.3. Directly Connected Sources .........................13 + 3.4. PIM Join/Prune Messages ...................................13 + 3.4.1. Receiving (*,G) Join/Prune Messages ................13 + 3.4.2. Sending Join/Prune Messages ........................16 + 3.5. Designated Forwarder (DF) Election ........................18 + 3.5.1. DF Requirements ....................................18 + 3.5.2. DF Election Description ............................19 + 3.5.2.1. Bootstrap Election ........................20 + 3.5.2.2. Loser Metric Changes ......................20 + 3.5.2.3. Winner Metric Changes .....................21 + 3.5.2.4. Winner Loses Path .........................22 + 3.5.2.5. Late Router Starting Up ...................22 + 3.5.2.6. Winner Dies ...............................22 + 3.5.3. Election Protocol Specification ....................22 + 3.5.3.1. Election State ............................22 + 3.5.3.2. Election Messages .........................23 + 3.5.3.3. Election Events ...........................24 + 3.5.3.4. Election Actions ..........................25 + 3.5.3.5. Election State Transitions ................26 + 3.5.4. Election Reliability Enhancements ..................30 + 3.5.5. Missing Pass .......................................30 + 3.5.6. Periodic Winner Announcement .......................30 + 3.6. Timers, Counters, and Constants ...........................31 + 3.7. BIDIR-PIM Packet Formats ..................................34 + 3.7.1. DF Election Packet Formats .........................34 + 3.7.2. Backoff Message ....................................36 + 3.7.3. Pass Message .......................................36 + 3.7.4. Bidirectional Capable PIM-Hello Option .............37 + 4. RP Discovery ...................................................37 + 5. Security Considerations ........................................38 + 5.1. Attacks Based on Forged Messages ..........................38 + 5.1.1. Election of an Incorrect DF ........................38 + + + +Handley, et al. Standards Track [Page 2] + +RFC 5015 Bidirectional PIM October 2007 + + + 5.1.2. Preventing Election Convergence ....................39 + 5.2. Non-Cryptographic Authentication Mechanisms ...............39 + 5.2.1. Basic Access Control ...............................39 + 5.3. Authentication Using IPsec ................................40 + 5.4. Denial-of-Service Attacks .................................40 + 6. IANA Considerations ............................................40 + 7. Acknowledgments ................................................40 + 8. Normative References ...........................................40 + 9. Informative References .........................................41 +List of Figures + Figure 1. Downstream group per-interface state machine ............15 + Figure 2. Upstream group state machine ............................17 + Figure 3. Designated Forwarder election state machine .............27 + +1. Introduction + + This document specifies Bidirectional PIM (BIDIR-PIM), a variant of + PIM Sparse-Mode (PIM-SM) [4] that builds bidirectional shared trees + connecting multicast sources and receivers. + + PIM-SM constructs unidirectional shared trees that are used to + forward data from senders to receivers of a multicast group. PIM-SM + also allows the construction of source-specific trees, but this + capability is not related to the protocol described in this document. + + The shared tree for each multicast group is rooted at a multicast + router called the Rendezvous Point (RP). Different multicast groups + can use separate RPs within a PIM domain. + + In unidirectional PIM-SM, there are two possible methods for + distributing data packets on the shared tree. These differ in the + way packets are forwarded from a source to the RP: + + o Initially, when a source starts transmitting, its first hop router + encapsulates data packets in special control messages (Registers) + that are unicast to the RP. After reaching the RP, the packets are + decapsulated and distributed on the shared tree. + + o A transition from the above distribution mode can be made at a + later stage. This is achieved by building source-specific state on + all routers along the path between the source and the RP. This + state is then used to natively forward packets from that source. + + Both of these mechanisms suffer from problems. Encapsulation results + in significant processing, bandwidth, and delay overheads. + Forwarding using source-specific state has additional protocol and + memory requirements. + + + + +Handley, et al. Standards Track [Page 3] + +RFC 5015 Bidirectional PIM October 2007 + + + Bidirectional PIM dispenses with both encapsulation and source state + by allowing packets to be natively forwarded from a source to the RP + using shared tree state. In contrast to PIM-SM, this mode of + forwarding does not require any data-driven events. + + The protocol specification in this document assumes familiarity with + the PIM-SM specification in [4]. Portions of the BIDIR-PIM protocol + operation that are identical to that of PIM-SM are only defined by + reference. + +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 BIDIR-PIM implementations. + +2.1. Definitions + + This specification uses a number of terms to refer to the roles of + routers participating in BIDIR-PIM. The following terms have special + significance for BIDIR-PIM: + + Multicast Routing Information Base (MRIB) + The multicast topology table, which is typically derived from the + unicast routing table, or routing protocols such as Multiprotocol + BGP (MBGP) [8] that carry multicast-specific topology information. + It is used by PIM for establishing the RPF interface (used in the + forwarding rules). In PIM-SM, the MRIB is also used to make + decisions regarding where to forward Join/Prune messages, whereas + in BIDIR-PIM, it is used as a source for routing metrics for the + DF election process. + + Rendezvous Point Address (RPA) + An RPA is an address that is used as the root of the distribution + tree for a range of multicast groups. The RPA must be routable + from all routers in the PIM domain. The RPA does not need to + correspond to an address for an interface of a real router. In + this respect, BIDIR-PIM differs from PIM-SM, which requires an + actual router to be configured as the Rendezvous Point (RP). Join + messages from receivers for a BIDIR-PIM group propagate hop-by-hop + towards the RPA. + + Rendezvous Point Link (RPL) + An RPL for a particular RPA is the physical link to which the RPA + belongs. In BIDIR-PIM, all multicast traffic to groups mapping to + a specific RPA is forwarded on the RPL of that RPA. The RPL is + special within a BIDIR-PIM domain as it is the only link on which + + + +Handley, et al. Standards Track [Page 4] + +RFC 5015 Bidirectional PIM October 2007 + + + a Designated Forwarder election does not take place (see DF + definition below). + + Upstream + Towards the root (RPA) of the tree. The direction used by packets + traveling from sources to the RPL. + + Downstream + Away from the root of the tree. The direction on which packets + travel from the RPL to receivers. + + Designated Forwarder (DF) + The protocol presented in this document is largely based on the + concept of a Designated Forwarder (DF). A single DF exists for + each RPA on every link within a BIDIR-PIM domain (this includes + both multi-access and point-to-point links). The only exception + is the RPL on which no DF exists. The DF is the router on the + link with the best route to the RPA (determined by comparing MRIB + provided metrics). A DF for a given RPA is in charge of + forwarding downstream traffic onto its link, and forwarding + upstream traffic from its link towards the RPL. It does this for + all the bidirectional groups that map to the RPA. The DF on a + link is also responsible for processing Join messages from + downstream routers on the link as well as ensuring that packets + are forwarded to local receivers (discovered through a local + membership mechanism such as MLD [3] or IGMP [2]). + + RPF Interface + RPF stands for "Reverse Path Forwarding". The RPF Interface of a + router with respect to an address is the interface that the MRIB + indicates should be used to reach that address. In the case of a + BIDIR-PIM multicast group, the RPF interface is determined by + looking up the RPA in the MRIB. The RPF information determines + the interface of the router that would be used to send packets + towards the RPL for the group. + + RPF Neighbor + The RPF Neighbor of a router with respect to an address is the + neighbor that the MRIB indicates should be used to reach that + address. Note that in BIDIR-PIM, the RPF neighbor for a group is + not necessarily the router on the RPF interface that Join messages + for that group would be directed to (Join messages are only + directed to the DF on the RPF interface for the group). + + Tree Information Base (TIB) + This is the collection of state at a PIM router that has been + created by receiving PIM Join/Prune messages, PIM DF election + messages, and IGMP or MLD information from local hosts. It + + + +Handley, et al. Standards Track [Page 5] + +RFC 5015 Bidirectional PIM October 2007 + + + essentially stores the state of all multicast distribution trees + at that router. + + Multicast Forwarding Information Base (MFIB) + The TIB holds all the state that is necessary to forward multicast + packets at a router. However, although this specification defines + forwarding in terms of the TIB, to actually forward packets using + the TIB is very inefficient. Instead, a real router + implementation will normally build an efficient MFIB from the TIB + state to perform forwarding. How this is done is implementation- + specific, and is not discussed in this document. + +2.2. Pseudocode Notation + + We use set notation in several places in this specification. + + A (+) B + is the union of two sets, A and B. + + A (-) B is the elements of set A that are not in set B. + + NULL + is the empty set or list. + + In addition, we use C-like syntax: + + = denotes assignment of a variable. + + == denotes a comparison for equality. + + != denotes a comparison for inequality. + + Braces { and } are used for grouping. + +3. Protocol Specification + + The specification of BIDIR-PIM is broken into several parts: + + o Section 3.1 details the protocol state stored. + + o Section 3.2 defines the BIDIR-PIM extensions to the PIM-SM [4] + neighbor discovery mechanism. + + o Section 3.3 specifies the data packet forwarding rules. + + o Section 3.4 specifies the BIDIR-PIM Join/Prune generation and + processing rules. + + + + +Handley, et al. Standards Track [Page 6] + +RFC 5015 Bidirectional PIM October 2007 + + + o Section 3.5 specifies the Designated Forwarder (DF) election. + + o Section 3.7 specifies the PIM packet formats. + + o Section 3.6 summarizes BIDIR-PIM timers and gives their default + values. + +3.1. BIDIR-PIM Protocol State + + This section specifies all the protocol state that a BIDIR-PIM + implementation should maintain in order to function correctly. We + term this state the Tree Information Base or TIB, as it holds the + state of all the multicast distribution trees at this router. In + this specification, we define PIM mechanisms in terms of the TIB. + However, only a very simple implementation would actually implement + packet forwarding operations in terms of this state. Most + implementations will use this state to build a multicast forwarding + table, which would then be updated when the relevant state in the TIB + changes. + + Although we specify precisely the state to be kept, this does not + mean that an implementation of BIDIR-PIM needs to hold the state in + this form. This is actually an abstract state definition, which is + needed in order to specify the router's behavior. A BIDIR-PIM + implementation is free to hold whatever internal state it requires, + and will still be conformant with this specification so long as it + results in the same externally visible protocol behavior as an + abstract router that holds the following state. + + We divide TIB state into two sections: + + RPA state + State that maintains the DF election information for each RPA. + + Group state + State that maintains a group-specific tree for groups that map to + a given RPA. + + The state that should be kept is described below. Of course, + implementations will only maintain state when it is relevant to + forwarding operations - for example, the "NoInfo" state might be + assumed from the lack of other state information, rather than being + held explicitly. + + + + + + + + +Handley, et al. Standards Track [Page 7] + +RFC 5015 Bidirectional PIM October 2007 + + +3.1.1. General Purpose State + + A router holds the following state that is not specific to an RPA or + group: + + Neighbor State: + + For each neighbor: + + o Neighbor's Gen ID + + o Neighbor liveness timer (NLT) + + o Other information from neighbor's Hello + + For more information on Hello information, look at Section 3.2 as + well as the PIM-SM specification in [4]. + +3.1.2. RPA State + + A router maintains a multicast-group to RPA mapping, which is built + through static configuration or by using an automatic RP discovery + mechanism like BSR or AUTO-RP (see Section 4). For each BIDIR-PIM + RPA, a router holds the following state: + + o RPA (actual address) + + Designated Forwarder (DF) State: + + For each router interface: + + Acting DF information: + + o DF IP Address + + o DF metric + + Election information: + + o Election State + + o DF election-Timer (DFT) + + o Message-Count (MC) + + Current best offer: + + o IP address of best offering router + + + +Handley, et al. Standards Track [Page 8] + +RFC 5015 Bidirectional PIM October 2007 + + + o Best offering router metric + + Designated Forwarder state is described in Section 3.5. + +3.1.3. Group State + + For every group G, a router keeps the following state: + + Group state: + + For each interface: + + Local Membership: + + o State: One of {"NoInfo", "Include"} + + PIM Join/Prune State: + + o State: One of {"NoInfo" (NI), "Join" (J), + "PrunePending" (PP)} + + o PrunePendingTimer (PPT) + + o Join/Prune Expiry Timer (ET) + + Not interface specific: + + o Upstream Join/Prune Timer (JT) + + o Last RPA Used + + Local membership is the result of the local membership mechanism + (such as IGMP [2]) running on that interface. This information is + used by the pim_include(*,G) macro described in Section 3.1.4. + + PIM Join/Prune state is the result of receiving PIM (*,G) Join/Prune + messages on this interface, and is specified in Section 3.4.1. The + state is used by the macros that calculate the outgoing interface + list in Section 3.1.4, and in the JoinDesired(G) macro (defined in + Section 3.4.2) that is used in deciding whether a Join(*,G) should be + sent upstream. + + The upstream Join/Prune timer is used to send out periodic Join(*,G) + messages, and to override Prune(*,G) messages from peers on an + upstream LAN interface. + + + + + + +Handley, et al. Standards Track [Page 9] + +RFC 5015 Bidirectional PIM October 2007 + + + The last RPA used must be stored because if the group to RPA mapping + changes (see RP Set changes in [4]), then state must be torn down and + rebuilt for groups whose RPA changes. + +3.1.4. State Summarization Macros + + Using this state, we define the following "macro" definitions that we + will use in the descriptions of the state machines and pseudocode in + the following sections. + + olist(G) = + RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G) + + RPF_interface(RPA) is the interface the MRIB indicates would be used + to route packets to RPA. The olist(G) is the list of interfaces on + which packets to group G must be forwarded. + + The macro pim_include(G) indicates the interfaces to which traffic + might be forwarded because of hosts that are local members on that + interface. + + pim_include(G) = + { all interfaces I such that: + I_am_DF(RPA(G),I) AND local_receiver_include(G,I) } + + The clause "I_am_DF(RPA,I)" is TRUE if the router is in the Win or + Backoff states in the DF election state machine (described in Section + 3.5) for the given RPA on interface I. Otherwise, it is FALSE. + + The clause "local_receiver_include(G,I)" is true if the IGMP module, + MLD module, or other local membership mechanism has determined that + there are local members on interface I that desire to receive traffic + sent to group G. + + The set "joins(G)" is the set of all interfaces on which the router + has received (*,G) Joins: + + joins(G) = + { all interfaces I such that + I_am_DF(RPA(G),I) AND + DownstreamJPState(G,I) is either Joined or PrunePending } + + DownstreamJPState(G,I) is the state of the finite state machine in + Section 3.4.1. + + RPF_DF(RPA) is the neighbor that Join messages must be sent to in + order to build the group shared tree rooted at the RPL for the given + RPA. This is the Designated-Forwarder on the RPF_interface(RPA). + + + +Handley, et al. Standards Track [Page 10] + +RFC 5015 Bidirectional PIM October 2007 + + +3.2. PIM Neighbor Discovery + + PIM routers exchange PIM-Hello messages with their neighboring PIM + routers. These messages are used to update the Neighbor State + described in Section 3.1. The procedures for generating and + processing Hello messages as well as maintaining Neighbor State are + specified in the PIM-SM [4] documentation. + + BIDIR-PIM introduces the Bidirectional Capable PIM-Hello option that + MUST be included in all Hello messages from a BIDIR-PIM capable + router. The Bidirectional Capable option advertises the router's + ability to participate in the BIDIR-PIM protocol. The format of the + Bidirectional Capable option is described in Section 3.7. + + If a BIDIR-PIM router receives a PIM-Hello message that does not + contain the Bidirectional Capable option from one of its neighbors, + the error must be logged to the router administrator in a rate- + limited manner. + +3.3. Data Packet Forwarding Rules + + For groups mapping to a given RPA, the following responsibilities are + uniquely assigned to the DF for that RPA on each link: + + o The DF is the only router that forwards packets traveling + downstream onto the link. + + o The DF is the only router that picks-up upstream traveling packets + off the link to forward towards the RPL. + + Non-DF routers on a link, which use that link as their RPF interface + to reach the RPA, may perform the following forwarding actions for + bidirectional groups: + + o Forward packets from the link towards downstream receivers. + + o Forward packets from downstream sources onto the link (provided + they are the DF for the downstream link from which the packet was + picked-up). + + The BIDIR-PIM packet forwarding rules are defined below in + pseudocode. + + iif is the incoming interface of the packet. + G is the destination address of the packet (group address). + RPA is the Rendezvous Point Address for this group. + + + + + +Handley, et al. Standards Track [Page 11] + +RFC 5015 Bidirectional PIM October 2007 + + + First we check to see whether the packet should be accepted based on + TIB state and the interface that the packet arrived on. A packet is + accepted if it arrives on the RPF interface to reach the RPA + (downstream traveling packet) or if the router is the DF on the + interface the packet arrives (upstream traveling packet). + + If the packet should be forwarded, we build an outgoing interface + list for the packet. + + Finally, we remove the incoming interface from the outgoing interface + list we've created, and if the resulting outgoing interface list is + not empty, we forward the packet out of those interfaces. + + On receipt of data to G on interface iif: + if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) { + oiflist = olist(G) (-) iif + forward packet on all interfaces in oiflist + } + +3.3.1. Upstream Forwarding at RP + + When configuring a BIDIR-PIM domain, it is possible to assign the + Rendezvous Point Address (RPA) such that it does not belong to a + physical box but instead is simply a routable address. Routers that + have interfaces on the RPL that the RPA belongs to will upstream + forward traffic onto the link. Joins from receivers in the domain + will propagate hop-by-hop till they reach one of the routers + connected to the RPL where they will terminate (as there will be no + DF elected on the RPL). + + If instead the administrator chooses to configure the RPA to be the + address of a physical interface of a specific router, then nothing + changes. That router must still upstream forward traffic on to the + RPL and behave no differently than any other router with an interface + on the RPL. + + To configure a BIDIR-PIM network to operate in a mode similar to that + of PIM-SM where a single router (the RP) is acting as the root of the + distribution tree, the RPA can be configured to be the loopback + interface of a router. + +3.3.2. Source-Only Branches + + Source-only branches of the distribution tree for a group G are + branches that do not lead to any receivers, but that are used to + forward packets traveling upstream from sources towards the RPL. + Routers along source-only branches only have the RPF interface to the + RPA in their olist for G, and hence do not need to maintain any group + + + +Handley, et al. Standards Track [Page 12] + +RFC 5015 Bidirectional PIM October 2007 + + + specific state. Upstream forwarding can be performed using only RPA + specific state. An implementation may decide to maintain group state + for source-only branches for accounting or performance reasons. + However, doing so requires data-driven events (to discover the groups + with active sources), thus sacrificing one of the main benefits of + BIDIR-PIM. + +3.3.3. Directly Connected Sources + + A major advantage of using a Designated Forwarder in BIDIR-PIM + compared to PIM-SM is that special treatment is no longer required + for sources that are directly connected to a router. Data from such + sources does not need to be differentiated from other multicast + traffic and will automatically be picked up by the DF and forwarded + upstream. This removes the need for performing a directly- + connected-source check for data to groups that do not have existing + state. + +3.4. PIM Join/Prune Messages + + BIDIR-PIM Join/Prune messages are used to construct group-specific + distribution trees between receivers and the RPL. Joins are + originated by last-hop routers that are elected as the DF on an + interface with directly connected receivers. The Joins propagate + hop-by-hop towards the RPA until they reach a router connected to the + RPL. + + A BIDIR-PIM Join/Prune message consists of a list of Joined and + Pruned Groups. When processing a received Join/Prune message, each + Joined or Pruned Group is effectively considered individually by + applying the following state machines. When considering a Join/Prune + message whose PIM Destination field addresses this router, (*,G) + Joins and Prunes can affect the downstream state machine. When + considering a Join/Prune message whose PIM Destination field + addresses another router, most Join or Prune entries could affect the + upstream state machine. + +3.4.1. Receiving (*,G) Join/Prune Messages + + When a router receives a Join(*,G) or Prune(*,G), it MUST first check + to see whether the RP address in the message matches RPA(G) (the + router's idea of what the Rendezvous Point Address is). If the RP + address in the message does not match RPA(G), the Join or Prune MUST + be silently dropped. + + If a router has no RPA information for the group (e.g., has not + recently received a BSR message), then it MAY choose to accept + Join(*,G) or Prune(*,G) and treat the RP address in the message as + + + +Handley, et al. Standards Track [Page 13] + +RFC 5015 Bidirectional PIM October 2007 + + + RPA(G). If the newly discovered RPA did not previously exist for any + other group, a DF election has to be initiated. + + Note that a router will process a Join(*,G) targeted to itself even + if it is not the DF for RP(G) on the interface on which the message + was received. This is an optimisation to eliminate the Join delay of + one Join period (t_periodic) in the case where a new DF processes the + received Pass and Join messages in reverse order. The BIDIR-PIM + forwarding logic will ensure that data packets are not forwarded on + such an interface while the router is not the DF (unless it is the + RPF interface towards the RPA). + + The per-interface state machine for receiving (*,G) Join/Prune + Messages is given below. There are three states: + + NoInfo (NI) + The interface has no (*,G) Join state and no timers running. + + Join (J) + The interface has (*,G) Join state. If the router is the DF on + this interface (I_am_DF(RPA(G),I) is TRUE), the Join state will + cause us to forward packets destined for G on this interface. + + PrunePending (PP) + The router has received a Prune(*,G) on this interface from a + downstream neighbor and is waiting to see whether the Prune + will be overridden by another downstream router. For + forwarding purposes, the PrunePending state functions exactly + like the Join state. + + In addition, the state machine uses two timers: + + ExpiryTimer (ET) + This timer is restarted when a valid Join(*,G) is received. + Expiry of the ExpiryTimer causes the interface state to revert + to NoInfo for this group. + + PrunePendingTimer (PPT) + This timer is set when a valid Prune(*,G) is received. Expiry + of the PrunePendingTimer causes the interface state to revert + to NoInfo for this group. + + + + + + + + + + +Handley, et al. Standards Track [Page 14] + +RFC 5015 Bidirectional PIM October 2007 + + + Figure 1: Downstream group per-interface state machine in tabular + form + + +---------------++---------------------------------------------------+ + | || Prev State | + |Event ++---------------+-----------------+-----------------+ + | || NoInfo (NI) | Join (J) | PrunePending | + | || | | (PP) | + +---------------++---------------+-----------------+-----------------+ + | || -> J state | -> J state | -> J state | + |Receive || start Expiry | restart Expiry | restart Expiry | + |Join(*,G) || Timer | Timer | Timer; stop | + | || | | PrunePending- | + | || | | Timer | + +---------------++---------------+-----------------+-----------------+ + |Receive || - | -> PP state | -> PP state | + |Prune(*,G) || | start Prune- | | + | || | PendingTimer | | + +---------------++---------------+-----------------+-----------------+ + |PrunePending- || - | - | -> NI state | + |Timer Expires || | | Send Prune- | + | || | | Echo(*,G) | + +---------------++---------------+-----------------+-----------------+ + |Expiry Timer || - | -> NI state | -> NI state | + |Expires || | | | + +---------------++---------------+-----------------+-----------------+ + |Stop Being DF || - | -> NI state | -> NI state | + |on I || | | | + +---------------++---------------+-----------------+-----------------+ + + The transition events "Receive Join(*,G)" and "Receive Prune(*,G)" + imply receiving a Join or Prune targeted to this router's address on + the received interface. If the destination address is not correct, + these state transitions in this state machine must not occur, + although seeing such a packet may cause state transitions in other + state machines. + + On unnumbered interfaces on point-to-point links, the router's + address should be the same as the source address it chose for the + Hello packet it sent over that interface. However, on point-to-point + links, we also RECOMMEND that PIM messages with a destination address + of all zeros also be accepted. + + The transition event "Stop Being DF" implies a DF re-election taking + place on this router interface for RPA(G) and the router changing + status from being the active DF to being a non-DF router (the value + of the I_am_DF macro changing to FALSE). + + + + +Handley, et al. Standards Track [Page 15] + +RFC 5015 Bidirectional PIM October 2007 + + + When ExpiryTimer is started or restarted, it is set to the HoldTime + from the Join/Prune message that triggered the timer. + + When PrunePendingTimer is started, it is set to the + J/P_Override_Interval if the router has more than one neighbor on + that interface; otherwise, it is set to zero causing it to expire + immediately. + + The action "Send PruneEcho(*,G)" is triggered when the router stops + forwarding on an interface as a result of a Prune. A PruneEcho(*,G) + is simply a Prune(*,G) message sent by the upstream router to itself + on a LAN. Its purpose is to add additional reliability so that if a + Prune that should have been overridden by another router is lost + locally on the LAN, then the PruneEcho may be received and cause the + override to happen. A PruneEcho(*,G) need not be sent when the + router has only one neighbor on the link. + +3.4.2. Sending Join/Prune Messages + + The downstream per-interface state machines described above hold Join + state from downstream PIM routers. This state then determines + whether a router needs to propagate a Join(*,G) upstream towards the + RPA. Such Join(*,G) messages are sent on the RPF interface towards + the RPA and are targeted at the DF on that interface. + + If a router wishes to propagate a Join(*,G) upstream, it must also + watch for messages on its upstream interface from other routers on + that subnet, and these may modify its behavior. If it sees a + Join(*,G) to the correct upstream neighbor, it should suppress its + own Join(*,G). If it sees a Prune(*,G) to the correct upstream + neighbor, it should be prepared to override that Prune by sending a + Join(*,G) almost immediately. Finally, if it sees the Generation ID + (see PIM-SM specification [4]) of the correct upstream neighbor + change, it knows that the upstream neighbor has lost state, and it + should be prepared to refresh the state by sending a Join(*,G) almost + immediately. + + In addition, changes in the next hop towards the RPA trigger a Prune + off from the old next hop and join towards the new next hop. Such a + change can be caused by the following two events: + + o The MRIB indicates that the RPF Interface towards the RPA has + changed. In this case the DF on the new RPF interface becomes + the new RPF Neighbor. + + o There is a DF re-election on the RPF interface and a new router + emerges as the DF. + + + + +Handley, et al. Standards Track [Page 16] + +RFC 5015 Bidirectional PIM October 2007 + + + The upstream (*,G) state machine only contains two states: + + Not Joined + The downstream state machines indicate that the router does not + need to join the RPA tree for this group. + + Joined + The downstream state machines indicate that the router would + like to join the RPA tree for this group. + + In addition, one timer JT(G) is kept, which is used to trigger the + sending of a Join(*,G) to the upstream next hop towards the RPA (the + DF on the RPF interface for RPA(G)). + + Figure 2: Upstream group state machine in tabular form + + +---------------------+----------------------------------------------+ + | | Event | + | Prev State +-----------------------+----------------------+ + | | JoinDesired(G) | JoinDesired(G) | + | | ->True | ->False | + +---------------------+-----------------------+----------------------+ + | | -> J state | - | + | NotJoined (NJ) | Send Join(*,G); | | + | | Set Timer to | | + | | t_periodic | | + +---------------------+-----------------------+----------------------+ + | Joined (J) | - | -> NJ state | + | | | Send Prune(*,G) | + +---------------------+-----------------------+----------------------+ + + In addition, we have the following transitions that occur within the + Joined state: + + +--------------------------------------------------------------------+ + | In Joined (J) State | + +----------------+----------------+-----------------+----------------+ + |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) | + | | to | to | GenID changes | + | | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | | + +----------------+----------------+-----------------+----------------+ + |Send | Increase Timer | Decrease Timer | Decrease Timer | + |Join(*,G); Set | to | to t_override | to t_override | + |Timer to | t_suppressed | | | + |t_periodic | | | | + +----------------+----------------+-----------------+----------------+ + + + + + +Handley, et al. Standards Track [Page 17] + +RFC 5015 Bidirectional PIM October 2007 + + + +--------------------------------------------------------------------+ + | In Joined (J) State | + +-----------------------------------+--------------------------------+ + | Change of RPF_DF(RPA(G)) | RPF_DF(RPA(G)) GenID | + | | changes | + +-----------------------------------+--------------------------------+ + | Send Join(*,G) to new | Decrease Timer to | + | DF; Send Prune(*,G) to | t_override | + | old DF; set Timer to | | + | t_periodic | | + +-----------------------------------+--------------------------------+ + + This state machine uses the following macro: + + bool JoinDesired(G) { + if (olist(G) (-) RPF_interface(RPA(G))) != NULL + return TRUE + else + return FALSE + } + +3.5. Designated Forwarder (DF) Election + + This section presents a fail-safe mechanism for electing a per-RPA + designated router on each link in a BIDIR-PIM domain. We call this + router the Designated Forwarder (DF). The DF election does not take + place on the RPL for an RPA. + +3.5.1. DF Requirements + + The DF election chooses the best router on a link to assume + responsibility for forwarding traffic between the RPL and the link + for the range of multicast groups served by the RPA. Different + multicast groups that share a common RPA share the same upstream + direction. Hence, the election of an upstream forwarder on each link + does not have to be a group-specific decision but instead can be + RPA-specific. As the number of RPAs is typically small, the number + of elections that have to be performed is significantly reduced by + this observation. + + To optimise tree creation, it is desirable that the winner of the + election process should be the router on the link with the "best" + unicast routing metric (as reported by the MRIB) to reach the RPA. + When comparing metrics from different unicast routing protocols, we + use the same comparison rules used by the PIM-SM assert process [4]. + + The election process needs to take place when information on a new + RPA initially becomes available. The result can be re-used as new + + + +Handley, et al. Standards Track [Page 18] + +RFC 5015 Bidirectional PIM October 2007 + + + bidir groups that map to the same RPA are encountered. However, + there are some conditions under which an update to the election is + required: + + o There is a change in unicast metric to reach the RPA for any of + the routers on the link. + + o The interface on which the RPA is reachable (RPF Interface) + changes to an interface for which the router was previously the + DF. + + o A new PIM neighbor starts up on a link that must participate in + the elections and be informed of the current outcome. + + o The elected DF fails (detected through neighbor information + timeout or MRIB RPF change at downstream router). + + The election process has to be robust enough to ensure with very high + probability that all routers on the link have a consistent view of + the DF. Given the forwarding rules described in Section 3.3, loops + may result if multiple routers end-up thinking that they should be + responsible for forwarding. To minimize the possibility of this + occurrence, the election algorithm has been biased towards discarding + DF information and suspending forwarding during periods of ambiguity. + +3.5.2. DF Election Description + + This section gives an outline of the DF election process. It does + not provide the definitive specification for the DF election. If any + discrepancy exists between Section 3.5.3 and this section, the + specification in Section 3.5.3 is to be assumed correct. + + To perform the election of the DF for a particular RPA, routers on a + link need to exchange their unicast routing metric information for + reaching the RPA. Routers advertise their own metrics in Offer, + Winner, Backoff, and Pass messages. The advertised metric is + calculated using the RPF Interface and metric to reach the RPA + available through the MRIB. When a router is participating in a DF + election for an RPA on the interface that its MRIB indicates as the + RPF Interface, then that router MUST always advertise an infinite + metric in its election messages. When a router is participating in a + DF election on an interface other than the MRIB-indicated RPF + Interface then it MUST advertise the MRIB-provided metrics in its + election messages. + + In the election protocol described below, many message exchanges are + repeated Election_Robustness times for reliability. In all those + cases, the message retransmissions are spaced in time by a small + + + +Handley, et al. Standards Track [Page 19] + +RFC 5015 Bidirectional PIM October 2007 + + + random interval. All of the following description is specific to the + election on a single link for a single RPA. + +3.5.2.1. Bootstrap Election + + Initially, when no DF has been elected, routers finding out about a + new RPA start participating in the election by sending Offer + messages. Offer messages include the router's metric to reach the + RPA. Offers are periodically retransmitted with a period of + Offer_Interval. + + If a router hears a better offer than its own from a neighbor, it + stops participating in the election for a period of + Election_Robustness * Offer_Interval, thus giving a chance to the + neighbor with the better metric to be elected DF. If during this + period no winner is elected, the router restarts the election from + the beginning. If at any point during the initial election a router + receives an out of order offer with worse metrics than its own, then + it restarts the election from the beginning. + + The result should be that all routers except the best candidate stop + advertising their offers. + + A router assumes the role of the DF after having advertised its + metrics Election_Robustness times without receiving any offer from + any other neighbor. At that point, it transmits a Winner message + that declares to every other router on the link the identity of the + winner and the metrics it is using. + + Routers receiving a Winner message stop participating in the election + and record the identity and metrics of the winner. If the local + metrics are better than those of the winner, then the router records + the identity of the winner (accepting it as the acting DF) but re- + initiates the election to try and take over. + +3.5.2.2. Loser Metric Changes + + Whenever the unicast metric to an RPA changes at a non-DF router to a + value that is better than that previously advertised by the acting + DF, the router with the new better metric should take action to + eventually assume forwarding responsibility. When the metric change + is detected, the non-DF router with the now better metric restarts + the DF election process by sending Offer messages with this new + metric. Note that at any point during an election if no response is + received after Election_Robustness retransmissions of an offer, a + router assumes the role of the DF following the usual Winner + announcement procedure. + + + + +Handley, et al. Standards Track [Page 20] + +RFC 5015 Bidirectional PIM October 2007 + + + Upon receipt of an offer that is worse than its current metric, the + DF will respond with a Winner message declaring its status and + advertising its better metric. Upon receiving the Winner message, + the originator of the Offer records the identity of the DF and aborts + the election. + + Upon receipt of an offer that is better than its current metric, the + DF records the identity and metrics of the offering router and + responds with a Backoff message. This instructs the offering router + to hold off for a short period of time while the unicast routing + stabilizes and other routers get a chance to put in their offers. + The Backoff message includes the offering router's new metric and + address. All routers on the link that have pending offers with + metrics worse than those in the Backoff message (including the + original offering router) will hold further offers for a period of + time defined in the Backoff message. + + If a third router sends a better offer during the Backoff_Period, the + Backoff message is repeated for the new offer and the Backoff_Period + is restarted. + + Before the Backoff_Period expires, the acting DF nominates the router + having made the best offer as the new DF using a Pass message. This + message includes the IDs and metrics of both the old and new DFs. + The old DF stops performing its tasks at the time the Pass message + transmission is made. The new DF assumes the role of the DF as soon + as it receives the Pass message. All other routers on the link take + note of the new DF and its metric. Note that this event constitutes + an RPF Neighbor change, which may trigger Join messages to the new DF + (see Section 3.4). + +3.5.2.3. Winner Metric Changes + + If the DF's routing metric to reach the RPA changes to a worse value, + it sends a set of Election_Robustness randomly spaced Winner messages + on the link, advertising the new metric. Routers that receive this + announcement but have a better metric may respond with an Offer + message that results in the same handoff procedure described above. + All routers assume the DF has not changed until they see a Pass or + Winner message indicating the change. + + There is no pressure to make this handoff quickly if the acting DF + still has a path to the RPL. The old path may now be suboptimal, but + it will still work while the re-election is in progress. + + + + + + + +Handley, et al. Standards Track [Page 21] + +RFC 5015 Bidirectional PIM October 2007 + + +3.5.2.4. Winner Loses Path + + If a router's RPF Interface to the RPA switches to be on a link for + which it is acting as the DF, then it can no longer provide + forwarding services for that link. It therefore immediately stops + being the DF and restarts the election. As its path to the RPA is + through the link, an infinite metric is used in the Offer message it + sends. + +3.5.2.5. Late Router Starting Up + + A late router starting up after the DF election process has completed + will have no immediate knowledge of the election outcome. As a + result, it will start advertising its metric in Offer messages. As + soon as this happens, the currently elected DF will respond with a + Winner message if its metric is better than the metric in the Offer + message, or with a Backoff message if its metric is worse than the + metric in the Offer message. + +3.5.2.6. Winner Dies + + Whenever the DF dies, a new DF has to be elected. The speed at which + this can be achieved depends on whether there are any downstream + routers on the link. + + If there are downstream routers, typically their MRIB reported next- + hop before the DF dies will be the DF itself. They will therefore + notice either a change in the metric for the route to the RPA or a + change in next-hop away from the DF and can restart the election by + transmitting Offer messages. If according to the MRIB the RPA is now + reachable through the same link via another upstream router, an + infinite metric will be used in the Offer. + + If no downstream routers are present, the only way for other upstream + routers to detect a DF failure is by the timeout of the PIM neighbor + information, which will take significantly longer. + +3.5.3. Election Protocol Specification + + This section provides the definitive specification for the DF + election process. If any discrepancy exists between Section 3.5.2 + and this section, the specification in this section is to be assumed + correct. + +3.5.3.1. Election State + + The DF election state is maintained per RPA for each multicast + enabled interface I on the router as introduced in Section 3.1. + + + +Handley, et al. Standards Track [Page 22] + +RFC 5015 Bidirectional PIM October 2007 + + + The state machine has the following four states: + + Offer + Initial election state. When in the Offer state, a router + thinks it can eventually become the winner and periodically + generates Offer messages. + + Lose + In this state, the router knows that there either is a + different election winner or that no router on the link has a + path to the RPA. + + Win + The router is the acting DF without any contest. + + Backoff + The router is the acting DF but another router has made a bid + to take over. + + In the state machine, a router is considered to be an acting DF if it + is in the Win or Backoff states. + + The operation of the election protocol makes use of the variables and + timers described below: + + Acting DF information + Used to store the identity and advertised metrics of the + election winner that is the currently acting DF. + + DF election-Timer (DFT) + Used to schedule transmission of Offer, Winner, and Pass + messages. + + Message-Count (MC) + Used to maintain the number of times an Offer or Winner message + has been transmitted. + + Best-Offer + Used by the DF to record the identity and advertised metrics of + the router that has made the last offer, for use when sending + the Path message. + +3.5.3.2. Election Messages + + The election process uses the following PIM control messages. The + packet format is described in Section 3.7: + + + + + +Handley, et al. Standards Track [Page 23] + +RFC 5015 Bidirectional PIM October 2007 + + + Offer (OfferingID, Metric) + Sent by routers that believe they have a better metric to the + RPA than the metric that has been on offer so far. + + Winner (DF-ID, DF-Metric) + Sent by a router when assuming the role of the DF or when re- + asserting in response to worse offers. + + Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric, + BackoffInterval) + Used by the DF to acknowledge better offers. It instructs + other routers with equal or worse offers to wait until the DF + passes responsibility to the sender of the offer. + + Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric) + Used by the old DF to pass forwarding responsibility to a + router that has previously made an offer. The Old-DF-Metric is + the current metric of the DF at the time the pass is sent. + + Note that when a router is participating in a DF election for an RPA + on the interface that its MRIB indicates as the RPF Interface, then + that router MUST always advertise an infinite metric in its election + messages. When a router is participating in a DF election on an + interface other than the MRIB-indicated RPF Interface, then it MUST + advertise the MRIB-provided metrics in its election messages. + +3.5.3.3. Election Events + + During protocol operation, the following events can take place: + + Control message reception + Reception of one of the four control DF election messages + (Offer, Winner, Backoff, and Pass). When a control message is + received and actions are specified on a condition that metrics + are Better or Worse, the comparison must be performed as + follows: + + o On receipt of an Offer or Winner message, compare the current + metrics for the RPA with the metrics advertised for the + sender of the message. + + o On receipt of a Backoff or Pass message, compare the current + metrics for the RPA with the metrics advertised for the + target of the message. + + + + + + + +Handley, et al. Standards Track [Page 24] + +RFC 5015 Bidirectional PIM October 2007 + + + Path to RPA lost + Losing the path to the RPA can happen in two ways. The first + happens when the route learned through the MRIB is withdrawn + and the MRIB no longer reports an available route to reach the + RPA. The second case happens when the next-hop information + reported by the MRIB changes to indicate a next-hop that is + reachable through the router interface under consideration. + Clearly, as the router is using the interface as its RPF + Interface, it cannot offer forwarding services towards the RPL + to other routers on that link. + + Metric reported by the MRIB to reach the RPA changes + This event is triggered when the MRIB supplied information for + the RPA changes and the new information provides a path to the + RPA. If the new MRIB information either reports no route or + reports a next-hop interface through the interface for which + the DF election is taking place, then the "Path to RPA lost" + event triggers instead. In specific states, the event may be + further filtered by specifying whether it is expected of the + metric to become better or worse and which of the stored + metrics the new MRIB information must be compared against. The + new information must be compared with either the router's old + metric, the stored DF metric, or the stored Best Offer metric. + + Election-Timer (DFT) expiration + Expiration of the DFT election timer can cause message + transmission and state transitions. The event might be further + qualified by specifying the value of the Message Count (MC) as + well as the current existence of a path to the RPA (as defined + above). + + Detection of DF failure + Detection of DF failure can occur through the timeout of PIM + neighbor state. + +3.5.3.4. Election Actions + + The DF election state machine action descriptions use the following + notation in addition to the pseudocode notation described earlier in + this specification: + + ?= denotes the operation of lowering a timer to a new value. If + the timer is not running, then it is started using the new + value. If the timer is running with an expiration lower than + the new value, then the timer is not altered. + + + + + + +Handley, et al. Standards Track [Page 25] + +RFC 5015 Bidirectional PIM October 2007 + + + When an action of "set DF to Sender or Target" is encountered during + receipt of a Winner, Pass, or Backoff message, it means the + following: + + o On receipt of a Winner message, set the DF to be the originator + of the message and record its metrics. + + o On receipt of a Pass message, set the DF to be the target of the + message and record its metrics. + + o On receipt of a Backoff message, set the DF to be the originator + of the message and record its metrics. + +3.5.3.5. Election State Transitions + + When a Designated Forwarder election is initiated, the starting state + is the Offer state, the message counter (MC) is set to zero, and the + DF election Timer (DFT) is set to OPlow (see Section 3.6 for a + definition of timer values). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 26] + +RFC 5015 Bidirectional PIM October 2007 + + + Figure 3: Designated Forwarder election state machine in tabular form + + +-------------+------------------------------------------------------+ + | | Event | + | Prev State +-----------------+------------------+-----------------+ + | | Recv better | Recv better | Recv better | + | | Pass / Win | Backoff | Offer | + +-------------+-----------------+------------------+-----------------+ + | | -> Lose | - | - | + | Offer | DF = Sender or | DFT = BOperiod | DFT = OPhigh; | + | | Target; Stop | + OPlow; MC = | MC = 0 | + | | DFT | 0 | | + +-------------+-----------------+------------------+-----------------+ + | | - | - | -> Offer | + | Lose | DF = Sender or | DF = Sender | DFT = OPhigh; | + | | Target | | MC = 0 | + +-------------+-----------------+------------------+-----------------+ + | | -> Lose | -> Lose | -> Backoff | + | | DF = Sender or | DF = Sender; | Set Best to | + | Win | Target; Stop | Stop DFT | Sender; Send | + | | DFT | | Backoff; DFT = | + | | | | BOperiod | + +-------------+-----------------+------------------+-----------------+ + | | -> Lose | -> Lose | - | + | | DF = Sender or | DF = Sender; | Set Best to | + | Backoff | Target; Stop | Stop DFT | Sender; Send | + | | DFT | | Backoff; DFT = | + | | | | BOperiod | + +-------------+-----------------+------------------+-----------------+ + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 27] + +RFC 5015 Bidirectional PIM October 2007 + + + +-----------+-------------------------------------------------------+ + | | Event | + | +-------------+-------------+--------------+------------+ + |Prev State |Recv Backoff |Recv Pass |Recv Worse |Recv worse | + | |for us |for us |Pass / Win / |Offer | + | | | |Backoff | | + +-----------+-------------+-------------+--------------+------------+ + | |- |-> Win |- |- | + | |DFT = |Stop DFT |Set DF to |DFT ?= | + |Offer |BOperiod + | |Sender or |OPlow; MC = | + | |OPlow; MC = | |Target; DFT |0 | + | |0 | |?= OPlow; MC | | + | | | |= 0 | | + +-----------+-------------+-------------+--------------+------------+ + | |-> Offer |-> Offer |-> Offer |-> Offer | + | |DF = Sender; |DF = Sender; |DF = Sender |DFT = OPlow;| + |Lose |DFT = OPlow; |DFT = OPlow; |or Target; |MC = 0 | + | |MC = 0 |MC = 0 |DFT = OPlow; | | + | | | |MC = 0 | | + +-----------+-------------+-------------+--------------+------------+ + | |-> Offer |-> Offer |-> Offer |- | + | |DF = Sender; |DF = Sender; |DF = Sender |Send Winner | + |Win |DFT = OPlow; |DFT = OPlow; |or Target; | | + | |MC = 0 |MC = 0 |DFT = OPlow; | | + | | | |MC = 0 | | + +-----------+-------------+-------------+--------------+------------+ + | |-> Offer |-> Offer |-> Offer |-> Win | + | |DF = Sender; |DF = Sender; |DF = Sender |Send Winner;| + |Backoff |DFT = OPlow; |DFT = OPlow; |or Target; |Stop DFT | + | |MC = 0 |MC = 0 |DFT = OPlow; | | + | | | |MC = 0 | | + +-----------+-------------+-------------+--------------+------------+ + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 28] + +RFC 5015 Bidirectional PIM October 2007 + + + +--------------------------------------------------------------------+ + | In Offer State | + +----------------------+----------------------+----------------------+ + | DFT Expires and MC | DFT Expires and MC | DFT Expires and MC | + | is less than | is equal to | is equal to | + | Robustness | Robustness and we | Robustness and | + | | have path to RPA | there is no path | + | | | to RPA | + +----------------------+----------------------+----------------------+ + | - | -> Win | -> Lose | + | Send Offer; DFT = | Send Winner | Set DF to None | + | OPlow; MC = MC + 1 | | | + +----------------------+----------------------+----------------------+ + +--------------------------------------------------------------------+ + | In Offer State | + +--------------------------------------------------------------------+ + | Metric changes and is now worse | + +--------------------------------------------------------------------+ + | DFT ?= OPlow | + | MC = 0 | + +--------------------------------------------------------------------+ + + +--------------------------------------------------------------------+ + | In Lose State | + +------------------------------+-------------------------------------+ + | Detect DF Failure | Metric changes and now | + | | is better than DF | + +------------------------------+-------------------------------------+ + | -> Offer | -> Offer | + | DF = None; DFT = | DFT = OPlow_int; MC = 0 | + | OPlow_int; MC = 0 | | + +------------------------------+-------------------------------------+ + + +--------------------------------------------------------------------+ + | In Win State | + +----------------------+-----------------------+---------------------+ + | Metric changes and | Timer Expires and | Path to RPA lost | + | is now worse | MC is less than | | + | | Robustness | | + +----------------------+-----------------------+---------------------+ + | - | - | -> Offer | + | DFT = OPlow; MC = | Send Winner; DFT = | Set DF to None; | + | 0 | OPlow; MC = MC + 1 | DFT = OPlow; MC = | + | | | 0 | + +----------------------+-----------------------+---------------------+ + + + + + + +Handley, et al. Standards Track [Page 29] + +RFC 5015 Bidirectional PIM October 2007 + + + +--------------------------------------------------------------------+ + | In Backoff State | + +----------------------+-----------------------+---------------------+ + | Metric changes and | Timer Expires | Path to RPA lost | + | is now better than | | | + | Best | | | + +----------------------+-----------------------+---------------------+ + | -> Win | -> Lose | -> Offer | + | Stop Timer | Send Pass; Set DF | Set DF to None; | + | | to stored Best | DFT = OPlow; MC = | + | | | 0 | + +----------------------+-----------------------+---------------------+ + +3.5.4. Election Reliability Enhancements + + For the correct operation of BIDIR-PIM, it is very important to avoid + situations where two routers consider themselves to be Designated + Forwarders for the same link. The two precautions below are not + required for correct operation but can help diagnose and correct + anomalies. + +3.5.5. Missing Pass + + After a DF has been elected, a router whose metrics change to become + better than the DF will attempt to take over. If during the re- + election the acting DF has a condition that causes it to lose all of + the election messages (like a CPU overload), the new candidate will + transmit three offers and assume the role of the forwarder resulting + in two DFs on the link. This situation is pathological and should be + corrected by fixing the overloaded router. It is desirable that such + an event can be detected by a network administrator. + + When a router becomes the DF for a link without receiving a Pass + message from the known old DF, the PIM neighbor information for the + old DF can be marked to this effect. Upon receiving the next PIM + Hello message from the old DF, the router can retransmit Winner + messages for all the RPAs for which it is acting as the DF. The + anomaly may also be logged by the router in a rate-limited manner to + alert the operator. + +3.5.6. Periodic Winner Announcement + + An additional degree of safety can be achieved by having the DF for + each RPA periodically announce its status in a Winner message. + Transmission of the periodic Winner message can be restricted to + occur only for RPAs that have active groups, thus avoiding the + periodic control traffic in areas of the network without senders or + receivers for a particular RPA. + + + +Handley, et al. Standards Track [Page 30] + +RFC 5015 Bidirectional PIM October 2007 + + +3.6. Timers, Counters, and Constants + + BIDIR-PIM maintains the following timers, as discussed in Section + 3.1. All timers are countdown timers - they are set to a value and + count down to zero, at which point they typically trigger an action. + Of course they can just as easily be implemented as count-up timers, + where the absolute expiry time is stored and compared against a real- + time clock, but the language in this specification assumes that they + count downwards to zero. + + Per Rendezvous-Point Address (RPA): + + Per interface (I): + + DF Election Timer: DFT(RPA,I) + + Per Group (G): + + Upstream Join Timer: JT(G) + + Per interface (I): + + Join Expiry Timer: ET(G,I) + + PrunePendingTimer: PPT(G,I) + + When timers are started or restarted, they are set to default values. + This section summarizes those default values. + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 31] + +RFC 5015 Bidirectional PIM October 2007 + + + Timer Name: DF Election Timer (DFT) + + +-------------------+------------------------+-----------------------+ + | Value Name | Value | Explanation | + +-------------------+------------------------+-----------------------+ + | Offer_Period | 100 ms | Interval to wait | + | | | between repeated | + | | | Offer and Winner | + | | | messages. | + +-------------------+------------------------+-----------------------+ + | Backoff_Period | 1 sec | Period that acting | + | | | DF waits between | + | | | receiving a better | + | | | Offer and sending | + | | | the Pass message | + | | | to transfer DF | + | | | responsibility. | + +-------------------+------------------------+-----------------------+ + | OPlow | rand(0.5, 1) * | Range of actual | + | | Offer_Period | randomised value | + | | | used between | + | | | repeated messages. | + +-------------------+------------------------+-----------------------+ + | OPhigh | Election_Robustness | Interval to wait | + | | * Offer_Period | in order to give a | + | | | chance to a router | + | | | with a better | + | | | Offer to become | + | | | the DF. | + +-------------------+------------------------+-----------------------+ + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 32] + +RFC 5015 Bidirectional PIM October 2007 + + + Timer Names: Join Expiry Timer (ET(G,I)) + + +---------------+---------------+------------------------------------+ + |Value Name | Value | Explanation | + +---------------+---------------+------------------------------------+ + |J/P HoldTime | from message | Hold Time from Join/Prune Message | + +---------------+---------------+------------------------------------+ + + Timer Names: PrunePendingTimer (PPT(G,I)) + + +-------------------------+-------------------+----------------------+ + | Value Name | Value | Explanation | + +-------------------------+-------------------+----------------------+ + | J/P Override Interval | Default: 3 secs | Short period after | + | | | a Join or Prune to | + | | | allow other | + | | | routers on the LAN | + | | | to override the | + | | | Join or Prune | + +-------------------------+-------------------+----------------------+ + + Note that the value of the J/P Override Interval is interface specific + and depends on both the Propagation_Delay and the Override_Interval + values that may change when Hello messages are received [4]. + + Timer Names: Upstream Join Timer (JT(G)) + + +------------+-------------------+-----------------------------------+ + Value Name |Value Explanation | + +------------+-------------------+-----------------------------------+ + t_periodic |Default: 60 secs Period between Join/Prune Messages | + +------------+-------------------+-----------------------------------+ + t_suppressed |rand(1.1 * Suppression period when someone | + | |t_periodic, 1.4 * else sends a J/P message so we | + | |t_periodic) don't need to do so. | + +------------+-------------------+-----------------------------------+ + t_override |rand(0, 0.9 * J/P Randomized delay to prevent | + | |Override Interval) response implosion when sending a | + | | Join message to override someone | + | | else's Prune message. | + +------------+-------------------+-----------------------------------+ + + For more information about these values, refer to the PIM-SM [4] + documentation. + + + + + + + +Handley, et al. Standards Track [Page 33] + +RFC 5015 Bidirectional PIM October 2007 + + + Constant Name: DF Election Robustness + + +-------------------------+------------------+-----------------------+ + | Constant Name | Value | Explanation | + +-------------------------+------------------+-----------------------+ + | Election_Robustness | Default: 3 | Minimum number of | + | | | election messages | + | | | that must be lost | + | | | in order for | + | | | election to fail. | + +-------------------------+------------------+-----------------------+ + +3.7. BIDIR-PIM Packet Formats + + This section describes the details of the packet formats for BIDIR- + PIM control messages. BIDIR-PIM shares a number of control messages + in common with PIM-SM [4]. These include the Hello and Join/Prune + messages as well as the format for the Encoded-Unicast address. For + details on the format of these packets, please refer to the PIM-SM + documentation. Here we will only define the additional packets that + are introduced by BIDIR-PIM. These are the packets used in the DF + election process as well as the Bidirectional Capable PIM-Hello + option. + +3.7.1. DF Election Packet Formats + + All PIM control messages have IP protocol number 103. + + BIDIR-PIM messages are 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'. + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 34] + +RFC 5015 Bidirectional PIM October 2007 + + + All DF election BIDIR-PIM control messages share the common header + below: + + 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 |Subtype| Rsvd | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RP Address (Encoded-Unicast format) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Metric Preference | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sender Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PIM Ver + PIM Version number is 2. + + Type + All DF-Election PIM control messages share the PIM message Type of + 10. + + Subtype + Subtypes for DF election messages are: + + 1 = Offer + 2 = Winner + 3 = Backoff + 4 = Pass + + Rsvd + Set to zero on transmission. Ignored on receipt. + + Checksum + A standard checksum IP checksum is used, 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. + + RP Address + The bidirectional RPA for which the election is taking place. The + format is described in [4], Section 4.9.1. + + Sender Metric Preference + Preference value assigned to the unicast routing protocol that the + message sender used to obtain the route to the RPA. + + + + + + +Handley, et al. Standards Track [Page 35] + +RFC 5015 Bidirectional PIM October 2007 + + + Sender Metric + The unicast routing table metric used by the message sender to + reach the RPA. The metric is in units applicable to the unicast + routing protocol used. + + In addition to the fields defined above, the Backoff and Pass + messages have the extra fields described below. + +3.7.2. Backoff Message + + The Backoff message uses the following fields in addition to the + common election message format described above. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Offering Address (Encoded-Unicast format) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Offering Metric Preference | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Offering Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Offering Address + The address of the router that made the last (best) Offer. The + format is described in [4], Section 4.9.1. + + Offering Metric Preference + Preference value assigned to the unicast routing protocol that the + offering router used to obtain the route to the RPA. + + Offering Metric + The unicast routing table metric used by the offering router to + reach the RPA. The metric is in units applicable to the unicast + routing protocol used. + + Interval + The backoff interval in milliseconds to be used by routers with + worse metrics than the offering router. + +3.7.3. Pass Message + + The Pass message uses the following fields in addition to the common + election fields described above. + + + + + +Handley, et al. Standards Track [Page 36] + +RFC 5015 Bidirectional PIM October 2007 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Winner Address (Encoded-Unicast format) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Winner Metric Preference | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Winner Metric | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + New Winner Address + The address of the router that made the last (best) Offer. The + format is described in [4], Section 4.9.1. + + New Winner Metric Preference + Preference value assigned to the unicast routing protocol that the + offering router used to obtain the route to the RPA. + + New Winner Metric + The unicast routing table metric used by the offering router to + reach the RPA. The metric is in units applicable to the unicast + routing protocol used. + +3.7.4. Bidirectional Capable PIM-Hello Option + + BIDIR-PIM introduces one new PIM-Hello option. + + o OptionType 22: Bidirectional 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 = 22 | Length = 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4. RP Discovery + + Routers discover that a range of multicast group addresses operates + in bidirectional mode, and that the address of the Rendezvous-Point + address (RPA) is serving the group range either through static + configuration or using an automatic RP discovery mechanism like the + PIM Bootstrap mechanism (BSR) [7] or Auto-RP. + + + + + + + + + +Handley, et al. Standards Track [Page 37] + +RFC 5015 Bidirectional PIM October 2007 + + +5. Security Considerations + + The IPsec [5] authentication header MAY be used to provide data + integrity protection and group-wise data origin authentication of + BIDIR-PIM protocol messages. Authentication of BIDIR-PIM messages + can protect against unwanted behaviour caused by unauthorized or + altered BIDIR-PIM messages. + +5.1. Attacks Based on Forged Messages + + As in PIM Sparse-Mode, the extent of possible damage depends on the + type of counterfeit messages accepted. BIDIR-PIM only uses link- + local multicast messages sent to the ALL_PIM_ROUTERS address, hence + attacks can only be carried out by directly connected nodes, or with + the complicity of directly connected routers. + + Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are + identical, both in format and functionality, to the respective + messages used in PIM-SM. Security considerations for these messages + are to be found in [4]. Other messages (DF-election messages) are + specific to BIDIR-PIM and will be discussed in the following + paragraphs. + + By forging DF-election messages, an attacker can disrupt the election + of the Designated Forwarder on a link in two different ways: + +5.1.1. Election of an Incorrect DF + + An attacker can force its election as DF by participating in a + regular election and advertising the best metric to reach the RPA. + An attacker can also try to force the election of another router as + DF by sending an Offer, Winner, or Pass message and impersonating + another router. In some cases (e.g., the Offer), multiple messages + might be needed to carry out an attack. + + In the case of Offer or Winner messages, the attacker will have to + impersonate the node that it wants to have become the DF. In the + case of the Pass, it will have to impersonate the current DF. This + type of attack causes the wrong DF to be recorded in all nodes apart + from the one that is being impersonated. This node typically will be + able to detect the anomaly and, possibly, restart a new election. + + A more sophisticated attacker might carry out a concurrent DoS attack + on the node being impersonated, so that it will not be able to detect + the forged packets and/or take countermeasures. + + + + + + +Handley, et al. Standards Track [Page 38] + +RFC 5015 Bidirectional PIM October 2007 + + + All attacks based on impersonation can be detected by all routers and + avoided if the source of DF-election messages can be authenticated. + When authentication is available, spoofed messages MUST be discarded + and a rate-limited warning message SHOULD be logged. + + A more subtle attacker could use MAC-level addresses to partition the + set of recipients of DF-election messages and create an inconsistent + DF view on the link. For example, the attacker could use unicast MAC + addresses for its forged DF-election messages. To prevent this type + of attack, BIDIR-PIM routers SHOULD check the destination MAC address + of received DF-election messages. This however is ineffective on + links that do not support layer-2 multicast delivery. + + Source authentication is also sufficient to prevent this kind of + attack. + +5.1.2. Preventing Election Convergence + + By forging DF election messages, an attacker can prevent the election + from converging, thus disrupting the establishment of multicast + forwarding trees. There are many ways to achieve this. The simplest + is by sending an infinite sequence of Offer messages (the metric used + in the messages is not important). + +5.2. Non-Cryptographic Authentication Mechanisms + + A BIDIR-PIM router SHOULD provide an option to limit the set of + neighbors from which it will accept Join/Prune, Assert, and DF- + election messages. Either static configuration of IP addresses or an + IPsec security association may be used. Furthermore, a PIM router + SHOULD NOT accept protocol messages from a router from which it has + not yet received a valid Hello message. + +5.2.1. Basic Access Control + + In a PIM-SM domain, when all routers are trusted, it is possible to + implement a basic form of access control for both sources and + receivers: Receivers can be validated by the last-hop DR and sources + can be validated by the first-hop DR and/or the RP. + + In BIDIR-PIM, this is generally feasible only for receivers, as + sources can send to the multicast group without the need for routers + to detect their activity and create source-specific state. However, + it is possible to modify the standard BIDIR-PIM behaviour, in a + backward compatible way, to allow per-source access control. The + tradeoff would be protocol simplicity, memory, and processing + requirements. + + + + +Handley, et al. Standards Track [Page 39] + +RFC 5015 Bidirectional PIM October 2007 + + +5.3. Authentication Using IPsec + + Just as with PIM-SM, the IPsec [5] transport mode using the + Authentication Header (AH) is the recommended method to prevent the + above attacks against BIDIR-PIM. + + It is recommended that IPsec authentication be applied to all BIDIR- + PIM protocol messages. The specification on how this is done is + found in [4]. Specifically, the authentication of PIM-SM link-local + messages, described in [4], applies to all BIDIR-PIM messages as + well. + +5.4. Denial-of-Service Attacks + + The denial-of-service attack based on forged Join messages, described + in [4], also applies to BIDIR-PIM. + +6. IANA Considerations + + IANA has assigned OptionType 22 to the "Bidirectional Capable" + option. + +7. Acknowledgments + + The bidirectional proposal in this document is heavily based on the + ideas and text presented by Estrin and Farinacci in [6]. The main + difference between the two proposals is in the method chosen for + upstream forwarding. + + We would also like to thank John Zwiebel at Cisco, Deborah Estrin at + ISI/USC, Bill Fenner at AT&T Research, as well as Nidhi Bhaskar, + Yiqun Cai, Toerless Eckert, Apoorva Karan, Rajitha Sumanasekera, and + Beau Williamson at Cisco for their contributions and comments to this + document. + +8. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version 3", RFC + 3376, October 2002. + + [3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener + Discovery (MLD) for IPv6", RFC 2710, October 1999. + + + + + +Handley, et al. Standards Track [Page 40] + +RFC 5015 Bidirectional PIM October 2007 + + + [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol + Independent Multicast - Sparse Mode (PIM-SM): Protocol + Specification (Revised)", RFC 4601, August 2006. + + [5] Kent, S. and R. Atkinson, "Security Architecture for the Internet + Protocol", RFC 2401, November 1998. + +9. Informative References + + [6] Estrin, D. and D. Farinacci, "Bi-directional Shared Trees in + PIM-SM", Work in Progress, May 1999. + + [7] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap + Router (BSR) Mechanism for PIM", Work in Progress, February 2007. + + [8] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol + Extensions for BGP-4", RFC 4760, January 2007. + +Index + + DF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5,18 + Downstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + DownstreamJPState(G,I). . . . . . . . . . . . . . . . . . . . . . 10 + ET(G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33 + ET(RPA,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + I_am_DF(RPA,I). . . . . . . . . . . . . . . . . . . . . . . .10,12,14 + J/P_HoldTime. . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + J/P_Override_Interval . . . . . . . . . . . . . . . . . . . . . 16,33 + JoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . . . . 18 + joins(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + JT(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,33 + local_receiver_include(G,I) . . . . . . . . . . . . . . . . . . . 10 + MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Offer_Period. . . . . . . . . . . . . . . . . . . . . . . . . . . 32 + olist(G). . . . . . . . . . . . . . . . . . . . . . . . . . .10,12,18 + Bidirectional Capable OptionType . . . . . . . . . . . . . . . . 37 + pim_include(G). . . . . . . . . . . . . . . . . . . . . . . . . . 10 + PPT(G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33 + RPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + RPF_interface(RPA). . . . . . . . . . . . . . . . . . . . . . . 10,12 + RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + t_override. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33 + t_periodic. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33 + t_suppressed. . . . . . . . . . . . . . . . . . . . . . . . . . 17,33 + Upstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + + + +Handley, et al. Standards Track [Page 41] + +RFC 5015 Bidirectional PIM October 2007 + + +Authors' Addresses + + Mark Handley + Computer Science Department + University College London + EMail: M.Handley@cs.ucl.ac.uk + + Isidor Kouvelas + Cisco Systems + EMail: kouvelas@cisco.com + + Tony Speakman + Cisco Systems + EMail: speakman@cisco.com + + Lorenzo Vicisano + Digital Fountain + EMail: lorenzo@digitalfountain.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Handley, et al. Standards Track [Page 42] + +RFC 5015 Bidirectional PIM October 2007 + + +Full Copyright Statement + + 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. + + + + + + + + + + + + +Handley, et al. Standards Track [Page 43] + -- cgit v1.2.3