draft-ietf-pim-port-01.txt   draft-ietf-pim-port-02.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft IJ. Wijnands Internet-Draft IJ. Wijnands
Intended status: Experimental S. Venaas Intended status: Experimental S. Venaas
Expires: January 9, 2010 cisco Systems Expires: April 29, 2010 cisco Systems
M. Napierala M. Napierala
AT&T Labs AT&T Labs
July 8, 2009 October 26, 2009
A Reliable Transport Mechanism for PIM A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-01.txt draft-ietf-pim-port-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. New PIM Hello Options . . . . . . . . . . . . . . . . . . . . 7 3. New PIM Hello Options . . . . . . . . . . . . . . . . . . . . 7
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 7 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 7
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 8 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 8
4. Establishing Transport Connections . . . . . . . . . . . . . . 10 4. Establishing Transport Connections . . . . . . . . . . . . . . 10
4.1. TCP Connection Maintenance . . . . . . . . . . . . . . . . 11 4.1. TCP Connection Maintenance . . . . . . . . . . . . . . . . 11
4.2. Moving from PORT to Datagram Mode . . . . . . . . . . . . 12 4.2. Moving from PORT to Datagram Mode . . . . . . . . . . . . 12
4.3. On-demand versus Pre-configured Connections . . . . . . . 12 4.3. On-demand versus Pre-configured Connections . . . . . . . 12
4.4. Possible Hello Suppression Considerations . . . . . . . . 13 4.4. Possible Hello Suppression Considerations . . . . . . . . 13
4.5. Avoiding a Pair of Connections between Neighbors . . . . . 13 4.5. Avoiding a Pair of Connections between Neighbors . . . . . 13
5. Common Header Definition . . . . . . . . . . . . . . . . . . . 15 5. Common Header Definition . . . . . . . . . . . . . . . . . . . 15
6. Outgoing Interface List Explicit Tracking . . . . . . . . . . 19 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 19
7. Multiple Instances and Address-Family Support . . . . . . . . 20 7. Multiple Instances and Address-Family Support . . . . . . . . 20
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 26 13.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 19 skipping to change at page 3, line 19
o To create a simple incremental mechanism to provide reliable PIM o To create a simple incremental mechanism to provide reliable PIM
message delivery in PIM version 2. message delivery in PIM version 2.
o The reliable transport mechanism will be used for Join-Prune o The reliable transport mechanism will be used for Join-Prune
message transmission only. message transmission only.
o Can be used for link-local transmission of Join-Prune messages or o Can be used for link-local transmission of Join-Prune messages or
multi-hop for use in a multicast VPN environments. multi-hop for use in a multicast VPN environments.
o When a router supports this specification, it need not use the o When a router supports this specification, it need not use the
reliable transport mechanism on every interface. That is, reliable transport mechanism with every neighbor. That is,
negotiation on per interface basis (or MDT basis) will occur. negotiation on a per neighbor basis will occur.
The explicit non-goals of this specification are: The explicit non-goals of this specification are:
o Changes to the PIM protocol machinery as defined in [RFC4601]. o Changes to the PIM protocol machinery as defined in [RFC4601].
The reliable transport mechanism will be used as a plugin layer so The reliable transport mechanism will be used as a plugin layer so
the PIM component does not know it is really there. the PIM component does not know it is really there.
o Provide support for both Datagram mode and Transport mode (see o Provide support for automatic switching between Datagram mode and
Section 1.2 for definitions) on the same physical interface or Transport mode. Two routers that are PIM neighbors on a link will
MDT. always use Transport mode if and only if both have Transport mode
enabled.
This document will specify how periodic JP message transmission can This document will specify how periodic JP message transmission can
be eliminated by using TCP [RFC0761] or SCTP [RFC4960] as the be eliminated by using TCP [RFC0761] or SCTP [RFC4960] as the
reliable transport mechanism for JP messages. reliable transport mechanism for JP messages.
This specification enables greater scalability in multicast This specification enables greater scalability in multicast
deployment since the processing required for protocol state deployment since the processing required for protocol state
maintenance can be reduced. These enhancements to PIMv2 are maintenance can be reduced. In addition to reduced processing on PIM
applicable to IP multicast over routed services and VPNs [MCAST-VPN]. enabled routers, another important feature is the reduced join and
In addition to reduced processing on PIM enabled routers, another leave latency provided through a reliable transport.
important feature is the reduced join and leave latency provided
through a reliable transport.
In many existing and emerging networks, particularly wireless and In many existing and emerging networks, particularly wireless and
mobile satellite systems, link degradation due to weather, mobile satellite systems, link degradation due to weather,
interference, and other impairments can result in temporary spikes in interference, and other impairments can result in temporary spikes in
the packet loss. In these environments, periodic PIM joining can the packet loss. In these environments, periodic PIM joining can
cause join latency when messages are lost causing a retransmission cause join latency when messages are lost causing a retransmission
only 60 seconds later. By applying a reliable transport, a lost join only 60 seconds later. By applying a reliable transport, a lost join
is retransmitted rapidly. Furthermore, when the last user leaves a is retransmitted rapidly. Furthermore, when the last user leaves a
multicast group, any lost prune is similarly repaired and the multicast group, any lost prune is similarly repaired and the
multicast stream is quickly removed from the wireless/satellite link. multicast stream is quickly removed from the wireless/satellite link.
skipping to change at page 5, line 35 skipping to change at page 6, line 5
of PIM. of PIM.
Reliable JP: A JP message using TCP or SCTP for transport. Reliable JP: A JP message using TCP or SCTP for transport.
Datagram Mode: The current procedures PIM uses by encapsulating JP Datagram Mode: The current procedures PIM uses by encapsulating JP
messages in IP packets sent either triggered or periodically. messages in IP packets sent either triggered or periodically.
PORT Mode: Procedures used by PIM defined in this specification for PORT Mode: Procedures used by PIM defined in this specification for
sending JP messages over the TCP or SCTP transport layer. sending JP messages over the TCP or SCTP transport layer.
MDT/PMSI: Used interchangeably in this document. An MDT tunnel is
one used between PE router to provide support for a Multicast VPN.
The new standards term for an MDT tunnel is a Provider-Network
Multicast Service Interface or PMSI.
Segmented Multi-Access LAN: A segmented (or partitioned) LAN is
like a virtual overlay network using the physical LAN to realize
control and data packets. Multiple overlay networks may be
created using the physical LAN, much like how VLANs or PMSI
overlays are configured over a multi-access phsyical LAN. The
interface associated with the partitioned LAN is like an NBMA
interface type so explicit tracking can be accomplished. Each
partitioned or segmented LAN has its own data-link encapsulation
and link-layer multicast is still used to avoid head-end
replication. This concept also applies to MDTs/PMSIs and is
called "Segmented MDTs/PMSIs". A Segmented MDT/PMSI is a MDT/PMSI
that has a single forwarder (i.e. a single ingress PE) for any
multicast stream.
2. Protocol Overview 2. Protocol Overview
PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for
refresh reduction of PIM JP messages. It involves sending refresh reduction of PIM JP messages. It involves sending
incremental rather than periodic JPs over a TCP/SCTP connection incremental rather than periodic JPs over a TCP/SCTP connection
between PIM neighbors. between PIM neighbors.
This document only specifies PORT for the following physical or This document does not restrict PORT to any specific link types. It
logical link types: point-to-point, segmented multi-access LAN, is however not recommended to use PORT on e.g. multi-access LANs with
segmented MDT, PMSI [MCAST-VPN], and point-to-point or point-to- many PIM neighbors. This due to the fact that there may be a full
multipoint GRE tunnel. For all other link types, such as multi- mesh of PORT connections, and that there is no join suppression.
access LANs, Datagram Mode is used.
PORT can be incrementally used on a link between PORT capable PORT can be incrementally used on a link between PORT capable
neighbors. Routers which are not PORT capable can continue to use neighbors. Routers which are not PORT capable can continue to use
PIM in Datagram Mode. PORT capability is detected using new PORT PIM in Datagram Mode. PORT capability is detected using new PORT
Capable PIM Hello Options. Capable PIM Hello Options.
Once PORT is enabled on an interface and a PIM neighbor also Once PORT is enabled on an interface and a PIM neighbor also
announces that it is PORT enabled, only Reliable JP messages will be announces that it is PORT enabled, only Reliable JP messages will be
used. That is, only Reliable JP messages are accepted from, and sent used. That is, only Reliable JP messages are accepted from, and sent
to, that particular neighbor. Native JP messages may still be used to, that particular neighbor. Native JP messages may still be used
skipping to change at page 6, line 43 skipping to change at page 6, line 42
to reestablish the connection. No JP messages (neither Native nor to reestablish the connection. No JP messages (neither Native nor
Reliable) are sent while there is no connection. Reliable) are sent while there is no connection.
When PORT is used, only incremental JPs are sent from downstream When PORT is used, only incremental JPs are sent from downstream
routers to upstream routers. As such, downstream routers do not routers to upstream routers. As such, downstream routers do not
generate periodic JPs for routes which RPF to a PORT-capable generate periodic JPs for routes which RPF to a PORT-capable
neighbor. neighbor.
For Joins and Prunes, which are received over a TCP/SCTP connection, For Joins and Prunes, which are received over a TCP/SCTP connection,
the upstream router does not start or maintain timers on the outgoing the upstream router does not start or maintain timers on the outgoing
interface entry. Instead, it explicitly tracks downstream routers interface entry. Instead, it keeps track of which downstream routers
which have expressed interest. An interface is deleted from the have expressed interest. An interface is deleted from the outgoing
outgoing interface list only when all downstream routers on the interface list only when all downstream routers on the interface, no
interface, no longer wish to receive traffic. longer wish to receive traffic.
There is no change proposed for the PIM JP packet format. However, There is no change proposed for the PIM JP packet format. However,
for JPs sent over TCP/SCTP connections, no IP Header is included. for JPs sent over TCP/SCTP connections, no IP Header is included.
The message begins with the PIM common header, followed by the JP The message begins with the PIM common header, followed by the JP
message. See section Section 5 for details on the common header. message. See section Section 5 for details on the common header.
3. New PIM Hello Options 3. New PIM Hello Options
3.1. PIM over the TCP Transport Protocol 3.1. PIM over the TCP Transport Protocol
skipping to change at page 7, line 32 skipping to change at page 7, line 32
Allocated Hello Type values can be found in [HELLO-OPT]. Allocated Hello Type values can be found in [HELLO-OPT].
When a router is configured to use PIM over TCP on a given interface, When a router is configured to use PIM over TCP on a given interface,
it MUST include the PIM-over-TCP Capable hello option in its Hello it MUST include the PIM-over-TCP Capable hello option in its Hello
messages for that interface. If a router is explicitly disabled from messages for that interface. If a router is explicitly disabled from
using JP over TCP it MUST NOT include the PIM-over-TCP Capable hello using JP over TCP it MUST NOT include the PIM-over-TCP Capable hello
option in its Hello messages. When the router cannot setup a TCP option in its Hello messages. When the router cannot setup a TCP
connection, it will refrain from including this option. connection, it will refrain from including this option.
This option is only used when a physical or logical interface is a
point-to-point, a segmented multi-access LAN, a segmented MDT, a PMSI
[MCAST-VPN], a point-to-point or point-to-multipoint GRE tunnel. In
all other cases, such as multi-access LANs, Datagram Mode is used.
Implementations may provide a configuration option to enable or Implementations may provide a configuration option to enable or
disable PORT functionality. We recommend that this capability be disable PORT functionality. We recommend that this capability be
disabled by default. disabled by default.
Length: In bytes for the value part of the Type/Length/Value Length: In bytes for the value part of the Type/Length/Value
encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and
16 bytes when AFI of value 2 (IPv6) is used [AFI]. 16 bytes when AFI of value 2 (IPv6) is used [AFI].
TCP Connection ID AFI: The AFI value to describe the address-family TCP Connection ID AFI: The AFI value to describe the address-family
of the address of the TCP Connection ID field. of the address of the TCP Connection ID field. When this field is
0, a mechanism outside the scope of this spec is used to obtain
the addresses used to establish the TCP connection.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
TCP Connection ID: An IPv4 or IPv6 address used to establish the TCP Connection ID: An IPv4 or IPv6 address used to establish the
TCP connection. When this field is 0, a mechanism outside the TCP connection. This field is omitted (length 0) for the
scope of this spec is used to obtain the addresses used to Connection ID AFI 0.
establish the TCP connection.
Interface ID: An Interface ID is used to associate the connection a Interface ID: An Interface ID is used to associate the connection a
JP message is received over with an interface which is added or JP message is received over with an interface which is added or
removed from an oif-list. When unnumbered interfaces are used or removed from an oif-list. When unnumbered interfaces are used or
when a single Transport connection is used for sending and when a single Transport connection is used for sending and
receiving JP messages over multiple interfaces, the Interface ID receiving JP messages over multiple interfaces, the Interface ID
is used convey the interface from JP message sender to JP message is used convey the interface from JP message sender to JP message
receiver. When a PIM router sets a locally generated value for receiver. When a PIM router sets a locally generated value for
the Interface ID in the Hello TLV, it must send the same Interface the Interface ID in the Hello TLV, it must send the same Interface
ID value in all JP messages it is sending to the PIM neighbor. ID value in all JP messages it is sending to the PIM neighbor.
skipping to change at page 8, line 48 skipping to change at page 8, line 41
Allocated Hello Type values can be found in [HELLO-OPT]. Allocated Hello Type values can be found in [HELLO-OPT].
When a router is configured to use PIM over SCTP on a given When a router is configured to use PIM over SCTP on a given
interface, it MUST include the PIM-over-SCTP Capable hello option in interface, it MUST include the PIM-over-SCTP Capable hello option in
its Hello messages for that interface. If a router is explicitly its Hello messages for that interface. If a router is explicitly
disabled from using JP over SCTP it MUST NOT include the PIM-over- disabled from using JP over SCTP it MUST NOT include the PIM-over-
SCTP Capable hello option in its Hello messages. When the router SCTP Capable hello option in its Hello messages. When the router
cannot setup a SCTP connection, it will refrain from including this cannot setup a SCTP connection, it will refrain from including this
option. option.
This option is only used when a physical or logical interface is a
point-to-point, a segmented multi-access LAN, a segmented MDT, a PMSI
[MCAST-VPN], a point-to-point or point-to-multipoint GRE tunnel. In
all other cases, such as multi-access LANs, Datagram Mode is used.
Implementations may provide a configuration option to enable or Implementations may provide a configuration option to enable or
disable PORT functionality. We recommend that this capability be disable PORT functionality. We recommend that this capability be
disabled by default. disabled by default.
Length: In bytes for the value part of the Type/Length/Value Length: In bytes for the value part of the Type/Length/Value
encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and
16 bytes when AFI of value 2 (IPv6) is used [AFI]. 16 bytes when AFI of value 2 (IPv6) is used [AFI].
SCTP Connection ID AFI: The AFI value to describe the address- SCTP Connection ID AFI: The AFI value to describe the address-
family of the address of the SCTP Connection ID field. family of the address of the SCTP Connection ID field. When this
field is 0, a mechanism outside the scope of this spec is used to
obtain the addresses used to establish the SCTP connection.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
SCTP Connection ID: An IPv4 or IPv6 address used to establish the SCTP Connection ID: An IPv4 or IPv6 address used to establish the
SCTP connection. When this field is 0, a mechanism outside the SCTP connection. This field is omitted (length 0) for the
scope of this spec is used to obtain the addresses used to Connection ID AFI 0.
establish the SCTP connection.
Interface ID: An Interface ID is used to associate the connection a Interface ID: An Interface ID is used to associate the connection a
JP message is received over with an interface which is added or JP message is received over with an interface which is added or
removed from an oif-list. When unnumbered interfaces are used or removed from an oif-list. When unnumbered interfaces are used or
when a single Transport connection is used for sending and when a single Transport connection is used for sending and
receiving JP messages over multiple interfaces, the Interface ID receiving JP messages over multiple interfaces, the Interface ID
is used convey the interface from JP message sender to JP message is used convey the interface from JP message sender to JP message
receiver. When a PIM router sets a locally generated value for receiver. When a PIM router sets a locally generated value for
the Interface ID in the Hello TLV, it must send the same Interface the Interface ID in the Hello TLV, it must send the same Interface
ID value in all JP messages it is sending to the PIM neighbor. ID value in all JP messages it is sending to the PIM neighbor.
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Instance Type 0. For type 0 the field should be set to zero on Instance Type 0. For type 0 the field should be set to zero on
transmission and ignored on receipt. transmission and ignored on receipt.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
PIMv2 JP Message: PIMv2 Join/Prune message and payload with no IP PIMv2 JP Message: PIMv2 Join/Prune message and payload with no IP
header in front of it. As you can see from the packet format header in front of it. As you can see from the packet format
diagram, multiple JP messages can go into one TCP/SCTP stream from diagram, multiple JP messages can go into one TCP/SCTP stream from
the same or different Interface and Instance IDs. the same or different Interface and Instance IDs.
6. Outgoing Interface List Explicit Tracking 6. Explicit Tracking
Since this specification indicates the use of TCP/SCTP for PIM JP
messages only over point-to-point or NBMA type links, explicit
tracking can be achieved by tracking only oif-list state and not per-
neighbor per oif-list state. This is true for segmented LANs and in
segmented MDT/PMSI environments.
By using explicit tracking of oifs, the router tracks all downstream A router needs to keep track of which PORT neighbors express interest
neighbors which have expressed interest in a route on a given in a route on a given interface. For non-PORT neighbors, there is no
interface. The list of tracked routers is one of the checks used to change, one would usually just need to know if at least one non-PORT
determine whether traffic needs to be forwarded on a given interface neighbor is interested. For some link-types, e.g. point-to-point,
or not. tracking neighbors is no different than tracking interfaces. It may
also be possible for an implementation to treat different downstream
neighbors as being on different logical interfaces, even if they are
on the same physical link. Exactly how this is implemented and for
which link types, is left to the implementer.
For (*,G) and (S,G) routes, the router starts forwarding traffic on For (*,G) and (S,G) routes, the router starts forwarding traffic on
an interface when a Join is received from a neighbor on such an an interface when a Join is received from a neighbor on such an
interface. This is tracking the oif to the neighbor. When the interface. When a non-PORT neighbor sends a Prune, there is
neighbor sends a Prune, the interface is removed and forwarding of generally a small delay to see if another non-PORT neighbor sends a
traffic stops on the interface. Prune Override. If there is no override, one should note that no
non-PORT neighbor is interested. If no PORT neighbors are
When all interfaces are removed from the oif-list, the route entry interested, the interface can be removed from the oif-list. When a
can be removed. PORT neighbor sends a Prune, one removes the join state for that
neighbor. If no other PORT or non-PORT neighbors are interested, the
For (S,G,R) routes, typically is tracking Prune state on the shared interface can be removed from the oif-list. In this case there is no
tree. One at least one downstream neighbor sends a Prune over a Prune Override, since the Prune was not visible to other neighbors.
Transport connection, the (S,G,R) state is create with a empty
outgoing interface list. If a subsequent JP is received over a
Transport connection which has (*,G) in the join-list and does not
have (S,G,R) in the prune-list, the upstream router will add the
interface the JP message was received on to the oif-list. And oif-
list based explicit tracking will occur just like in the (*,G) and
(S,G) route case above.
The only difference in the (S,G,R) route case, is that when the For (S,G,R) routes, the router needs to track Prune state on the
outgoing interface is pruned, the entry must stay in the route table shared tree. It needs to know which PORT neighbors have sent prunes,
or else forwarding will occur on the interfaces for the (*,G) entry. and whether any non-PORT neighbors have sent prunes. The latter is
Therefore, explicit tracking for Prunes must be provided. Only when exactly like when not using PORT. Normally one would forward a
the (S,G,R) oif-list interfaces match the interfaces in the (*,G) can packet from a source S to a group G out on an interface if a
the (S,G,R) route be removed. (*,G)-join is received, but no (S,G,R)-prune. With PORT one needs to
do this check per PORT neighbor. That is, the packet should be
forwarded unless all PORT neighbors that have sent (*,G)-joins have
also sent (S,G,R)-prunes and if a non-PORT neighbor has sent a
(*,G)-join, whether there also is non-PORT (S,G,R)-prune state.
7. Multiple Instances and Address-Family Support 7. Multiple Instances and Address-Family Support
Multiple instances of the PIM protocol may be used to support Multiple instances of the PIM protocol may be used to support
multiple VPNs or within a VPN to support multiple address families. multiple VPNs or within a VPN to support multiple address families.
Multiple instances can cause a multiplier effect on the number of Multiple instances can cause a multiplier effect on the number of
router resources consumed. To be able to have an option to use router resources consumed. To be able to have an option to use
router resources more efficiently, muxing JP messages over fewer router resources more efficiently, muxing JP messages over fewer
Transport connections can be performed. Transport connections can be performed.
skipping to change at page 26, line 45 skipping to change at page 27, line 5
13.2. Informative References 13.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/numbers.html, February 2007. NUMBERS http://www.iana.org/numbers.html, February 2007.
[HELLO-OPT] [HELLO-OPT]
IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per
RFC4601 http://www.iana.org/assignments/pim-hello-options, RFC4601 http://www.iana.org/assignments/pim-hello-options,
March 2007. March 2007.
[MCAST-VPN]
Rosen and Aggarwal, "Multicast in MPLS/BGP VPNs", Internet
Draft draft-ietf-l3vpn-2547bis-mcast-05.txt, July 2007.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dino@cisco.com Email: dino@cisco.com
 End of changes. 22 change blocks. 
99 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/