draft-ietf-pim-port-00.txt   draft-ietf-pim-port-01.txt 
Network Working Group Dino Farinacci Network Working Group D. Farinacci
Internet-Draft IJsbrand Wijnands Internet-Draft IJ. Wijnands
Intended status: Experimental Apoorva Karan Intended status: Experimental S. Venaas
Expires: February 23, 2009 Arjen Boers Expires: January 9, 2010 cisco Systems
cisco Systems M. Napierala
Maria Napierala
AT&T Labs AT&T Labs
August 22, 2008 July 8, 2009
A Reliable Transport Mechanism for PIM A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-00.txt draft-ietf-pim-port-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 February 23, 2009. This Internet-Draft will expire on January 9, 2010.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This draft describes how a reliable transport mechanism can be used This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission. utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol. or SCTP transport protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3. New PIM Hello Options . . . . . . . . . . . . . . . . . . . . 8 3. New PIM Hello Options . . . . . . . . . . . . . . . . . . . . 7
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 7
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 8
4. Establishing Transport Connections . . . . . . . . . . . . . . 11 4. Establishing Transport Connections . . . . . . . . . . . . . . 10
4.1. TCP Connection Maintenance . . . . . . . . . . . . . . . . 12 4.1. TCP Connection Maintenance . . . . . . . . . . . . . . . . 11
4.2. Transitional Periods . . . . . . . . . . . . . . . . . . . 13 4.2. Moving from PORT to Datagram Mode . . . . . . . . . . . . 12
4.3. On-demand versus Pre-configured Connections . . . . . . . 13 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 . . . . . 14 4.5. Avoiding a Pair of Connections between Neighbors . . . . . 13
5. Common Header Definition . . . . . . . . . . . . . . . . . . . 15 5. Common Header Definition . . . . . . . . . . . . . . . . . . . 15
6. Join/Prune Processing . . . . . . . . . . . . . . . . . . . . 19 6. Outgoing Interface List Explicit Tracking . . . . . . . . . . 19
7. Outgoing Interface List Explicit Tracking . . . . . . . . . . 20 7. Multiple Instances and Address-Family Support . . . . . . . . 20
8. Multiple Instances and Address-Family Support . . . . . . . . 21 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 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
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
The goals of this specification are: The goals of this specification are:
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.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
deletion events. Also known as a triggered message. deletion events. Also known as a triggered message.
Native JP: A JP message which is carried with an IP protocol type Native JP: A JP message which is carried with an IP protocol type
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.
Transport Mode: Procedures used by PIM defined in this PORT Mode: Procedures used by PIM defined in this specification for
specification for sending JP messages over the TCP or SCTP sending JP messages over the TCP or SCTP transport layer.
transport layer.
MDT/PMSI: Used interchangeably in this document. An MDT tunnel is MDT/PMSI: Used interchangeably in this document. An MDT tunnel is
one used between PE router to provide support for a Multicast VPN. one used between PE router to provide support for a Multicast VPN.
The new standards term for an MDT tunnel is a Provider-Network The new standards term for an MDT tunnel is a Provider-Network
Multicast Service Interface or PMSI. Multicast Service Interface or PMSI.
Segmented Multi-Access LAN: A segmented (or partitioned) LAN is Segmented Multi-Access LAN: A segmented (or partitioned) LAN is
like a virtual overlay network using the physical LAN to realize like a virtual overlay network using the physical LAN to realize
control and data packets. Multiple overlay networks may be control and data packets. Multiple overlay networks may be
created using the physical LAN, much like how VLANs or PMSI created using the physical LAN, much like how VLANs or PMSI
overlays are configured over a multi-access phsyical LAN. The overlays are configured over a multi-access phsyical LAN. The
interface associated with the partitioned LAN is like an NBMA interface associated with the partitioned LAN is like an NBMA
interface type so explicit tracking can be accomplished. Each interface type so explicit tracking can be accomplished. Each
partitioned or segmented LAN has it's own data-link encapsulation partitioned or segmented LAN has its own data-link encapsulation
and link-layer multicast is still used to avoid head-end and link-layer multicast is still used to avoid head-end
replication. This concept also applies to MDTs/PMSIs and is replication. This concept also applies to MDTs/PMSIs and is
called "Segmented MDTs/PMSIs". A Segmented MDT/PMSI is a MDT/PMSI 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 that has a single forwarder (i.e. a single ingress PE) for any
multicast stream. 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.
PORT can be incrementally used on an interface between PORT capable This document only specifies PORT for the following physical or
logical link types: point-to-point, segmented multi-access LAN,
segmented MDT, PMSI [MCAST-VPN], and point-to-point or point-to-
multipoint GRE tunnel. For all other link types, such as multi-
access LANs, Datagram Mode is used.
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 a new PORT PIM in Datagram Mode. PORT capability is detected using new PORT
Capable PIM Hello Option. Capable PIM Hello Options.
Once PORT is enabled on an interface and a PIM neighbor also
announces that it is PORT enabled, only Reliable JP messages will be
used. That is, only Reliable JP messages are accepted from, and sent
to, that particular neighbor. Native JP messages may still be used
for other neighbors.
Reliable JP messages are sent using a TCP/SCTP connection. When two
PIM neighbors are PORT enabled, both for TCP or both for SCTP, they
will immediately, or on-demand, establish a connection. If the
connection goes down, they will again immediately, or on-demand, try
to reestablish the connection. No JP messages (neither Native nor
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 explicitly tracks downstream routers
which have expressed interest. An interface is deleted from the which have expressed interest. An interface is deleted from the
outgoing interface list only when all downstream routers on the outgoing interface list only when all downstream routers on the
interface, no longer wish to receive traffic. interface, no longer wish to receive traffic.
Because incremental JPs are sent over a TCP/SCTP connection, no Join
suppression or Prune-Override of incremental JPs is possible on
multi-access LANs. As a result, upstream routers, which receive an
incremental Join or Prune that creates state, explicitly track all
downstream nodes. Note, for point-to-point links there is no need
for explicitly tracking downstream nodes.
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
Option Type: PIM-over-TCP Capable Option Type: PIM-over-TCP Capable
0 1 2 3 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 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 = 65006 | Length = X + 4 | | Type = 27 | Length = X + 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID AFI | Reserved | | TCP Connection ID AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP Connection ID | | TCP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 PORT Capable hello option in its Hello messages it MUST include the PIM-over-TCP Capable hello option in its Hello
for that interface. If a router is explicitly disabled from using JP messages for that interface. If a router is explicitly disabled from
over TCP it MUST NOT include the PORT Capable hello option in its using JP over TCP it MUST NOT include the PIM-over-TCP Capable hello
Hello messages. When the router cannot setup a TCP connection, it option in its Hello messages. When the router cannot setup a TCP
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 This option is only used when a physical or logical interface is a
point-to-point, segmented multi-access LAN, a PMSI [MCAST-VPN], a point-to-point, a segmented multi-access LAN, a segmented MDT, a PMSI
point-to-point or point-to-multipoint GRE tunnel. In all other [MCAST-VPN], a point-to-point or point-to-multipoint GRE tunnel. In
cases, such as multi-access LANs, Datagram Mode is used. all other cases, such as multi-access LANs, Datagram Mode is used.
Implementation 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 IP AFI of value 1 is used and 16 encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and
bytes when IPv6 AFI of 2 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.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
TCP Connection ID: An IP or IPv6 address used to establish the TCP TCP Connection ID: An IPv4 or IPv6 address used to establish the
connection. When this field is 0, a mechanism outside the scope TCP connection. When this field is 0, a mechanism outside the
of this spec is used to obtain the addresses used to establish the scope of this spec is used to obtain the addresses used to
TCP connection. 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 thie Hello TLV, it must send the same the Interface ID in the Hello TLV, it must send the same Interface
Interface ID value in all JP messages it is sending to the PIM ID value in all JP messages it is sending to the PIM neighbor.
neighbor.
3.2. PIM over the SCTP Transport Protocol 3.2. PIM over the SCTP Transport Protocol
Option Type: PIM-over-SCTP Capable Option Type: PIM-over-SCTP Capable
0 1 2 3 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 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 = 65007 | Length = X + 4 | | Type = 28 | Length = X + 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID AFI | Reserved | | SCTP Connection ID AFI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Connection ID | | SCTP Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 PORT Capable hello option in its Hello interface, it MUST include the PIM-over-SCTP Capable hello option in
messages for that interface. If a router is explicitly disabled from its Hello messages for that interface. If a router is explicitly
using JP over SCTP it MUST NOT include the PORT Capable hello option disabled from using JP over SCTP it MUST NOT include the PIM-over-
in its Hello messages. When the router cannot setup a SCTP SCTP Capable hello option in its Hello messages. When the router
connection, it will refrain from including this option. cannot setup a SCTP connection, it will refrain from including this
option.
This option is only used when an interface is point-to-point or when This option is only used when a physical or logical interface is a
a multi-access LAN or MDT is segmented (also known as "Partitioned point-to-point, a segmented multi-access LAN, a segmented MDT, a PMSI
MDTs" in a non-broadcast multi-access (NBMA) mode. In all other [MCAST-VPN], a point-to-point or point-to-multipoint GRE tunnel. In
cases, such as general purpose multi-access LANs, Datagram Mode is all other cases, such as multi-access LANs, Datagram Mode is used.
used.
Implementation 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 IP AFI of value 1 is used and 16 encoding. Where X is 4 bytes if AFI of value 1 (IPv4) is used and
bytes when IPv6 AFI of 2 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.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
SCTP Connection ID: An IP 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. When this field is 0, a mechanism outside the
scope of this spec is used to obtain the addresses used to scope of this spec is used to obtain the addresses used to
establish the SCTP connection. 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 thie Hello TLV, it must send the same the Interface ID in the Hello TLV, it must send the same Interface
Interface ID value in all JP messages it is sending to the PIM ID value in all JP messages it is sending to the PIM neighbor.
neighbor.
4. Establishing Transport Connections 4. Establishing Transport Connections
Since this specification describes using Transport on point-to- point While a router interface is PORT enabled, a PIM-over-TCP or a PIM-
links or NBMA configured MDTs, a router knows when a Transport is over-SCTP option is included in the PIM Hello messages sent on that
established with the neighbor. When the Transport connection is not interface. When a router on a PORT-enabled interface receives a
established, Datagram Mode is used. When the Transport connection Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a
becomes established Transport Mode is in effect where the router can new neighbor, or an existing neighbor that did not previously include
suppress sending periodic JPs. the option, it switches to PORT mode for that particular neighbor.
When a router receives a Hello from a neighbor it has not previously When a router switches to PORT mode for a neighbor, it stops sending
heard from, or the PORT-Capable Option is included in a Hello that and accepting Native JP messages for that neighbor. Any state from
was not previously included by an existing neighbor, the router will previous Native JP messages is left to expire as normal. It will
attempt to establish a Transport connection with the neighbor. When also attempt to establish a Transport connection (TCP or SCTP) with
the router is using TCP it will compare the IP address it uses to the neighbor.
send Hellos on the interface with the IP address the neighbor is
using to send Hellos. The router with the lower IP address will do When the router is using TCP it will compare the TCP Connection ID it
an active Transport open to the neighbor address. The higher IP announced in the PIM-over-TCP Capable Option with the TCP Connection
addressed neighbor will do a passive Transport open. When the router ID in the Hello received from the neighbor. The router with the
is using SCTP, the IP address comparison not be done since the SCTP lower Connection ID will do an active Transport open to the neighbor
protocol can handle call collision. Connection ID. The router with the higher Connection ID will do a
passive Transport open. An implementation may open connections only
on-demand, in that case it may be that the neighbor with the higher
Connection ID does the active open, see Section 4.3. Note that the
source address of the active open must be the announced Connection
ID.
When the router is using SCTP, the IP address comparison need not be
done since the SCTP protocol can handle call collision.
If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello
messages are sent, both containing PORT Hello options. If two
neighbors announce the same transport (TCP or SCTP) and the same
Connection ID in the IPv4 and IPv6 Hello messages, then only one
connection is established and is shared. Otherwise, two connections
are established and are used separately.
The PIM router that performs the active open initiates the connection The PIM router that performs the active open initiates the connection
with a locally generated source transport port number and a well- with a locally generated source transport port number and a well-
known destination transport port number. The PIM router that known destination transport port number. The PIM router that
performs the passive open listens on the well-known local transport performs the passive open listens on the well-known local transport
port number and does not qualify the remote transport port number. port number and does not qualify the remote transport port number.
See Section 5 for well-known port number assignment for PORT. See Section 5 for well-known port number assignment for PORT.
When a Transport connection is established (or reestablished), the
two routers MUST both send a full set of JP messages for which the
other router is the upstream neighbor. This is needed to ensure that
the upstream neighbor has the correct state. When moving from
Datagram mode, or when the connection has gone down, the router
cannot be sure that all the previous JP data was received by the
neighbor. Any state received while in Datagram mode that is not
refreshed, will be left to expire.
When a Transport connection goes down, Join or Prune state that was When a Transport connection goes down, Join or Prune state that was
sent over the Transport connection is still retained. The neighbor sent over the Transport connection is still retained. The neighbor
should not be considered down until the neighbor timer has expired. should not be considered down until the neighbor timer has expired.
This allows routers to do a control-plane switchover without This allows routers to do a control-plane switchover without
disrupting the network. If a Transport connection is reestablished disrupting the network. If a Transport connection is reestablished
before the neighbor timer expires, the previous state is intact and before the neighbor timer expires, the previous state is intact and
any new JP messages sent cause state to be created or removed any new JP messages sent cause state to be created or removed
(depending on if it was a Join or Prune). If the neighbor timer does (depending on if it was a Join or Prune). If the neighbor timer does
expire, only the upstream router, that has oif-list state, to the expire, only the upstream router, that has oif-list state, to the
expired downstream neighbor will need to clear state. A downstream expired downstream neighbor will need to clear state. A downstream
router, when an upstream neighboring router has expired, will simply router, when an upstream neighboring router has expired, will simply
RPF to a new neighbor where it would trigger JP messages like it RPF to a new neighbor where it would trigger JP messages like it
would in [RFC4601]. It is required of a PIM router to clear it's would in [RFC4601]. It is required of a PIM router to clear its
neighbor table for a neighbor who has timed out due to neighbor neighbor table for a neighbor who has timed out due to neighbor
holdtime expiration. holdtime expiration.
When a router is in Datagram Mode with a neighbor and has been Note, since JP messages are sent over a Transport connection, no
sending periodic JP messages to it and then the Transport connection Prune Override or Join Suppression are possible for these messages.
has been established to the neighbor, there is no requirement for the
downstream router to send JP messages to the upstream neighbor. The
upstream router can keep the state maintained from the Datagram Mode
creation. However when a router is in Transport Mode with a neighbor
and moves to Datagram Mode because the transport connection went down
(and several attempts to reestablish the transport connection fail),
the router cannot be sure that all the JP data was received by the
neighbor. Therefore, it is required to send a full set of JP
messages to refresh or re-create state in the upstream neighbor.
An upstream neighbor does have the responsibility of removing the
timer-activated timeout of an oif-list entry. When a Transport
connection is established, the timer-activated timeout is disabled.
When a Transport connection goes down, the timer-activated timeout
for an oif-list is enabled. Both the upstream and downstream routers
stay in sync based on the state of the Transport connection. If the
upstream router has timer-activated timeout on oif-lists, the
downstream router will be sending periodic JPs. Otherwise, the
downstream router suppresses sending periodic JPs because it assumes
the upstream router has disabled the timer-activated timeout of oif-
list entries the downstream router has previously joined.
4.1. TCP Connection Maintenance 4.1. TCP Connection Maintenance
TCP is designed to keep connections up indefinitely during a period TCP is designed to keep connections up indefinitely during a period
of network disconnection. If a PIM-over-TCP router fails, the TCP of network disconnection. If a PIM-over-TCP router fails, the TCP
connection may stay up until the neighbor actually reboots, and even connection may stay up until the neighbor actually reboots, and even
then it may continue to stay up until you actually try to send the then it may continue to stay up until you actually try to send the
neighbor some information. This is particularly relevant to PIM, neighbor some information. This is particularly relevant to PIM,
since the flow of JPs might be in only one direction, and the since the flow of JPs might be in only one direction, and the
downstream neighbor might never get any indication via TCP that the downstream neighbor might never get any indication via TCP that the
skipping to change at page 12, line 44 skipping to change at page 11, line 47
Most applications using TCP want to detect when a neighbor is no Most applications using TCP want to detect when a neighbor is no
longer there, so that the associated application state can be longer there, so that the associated application state can be
released. Also, one wants to clean up the TCP state, and not keep released. Also, one wants to clean up the TCP state, and not keep
half-open connections around indefinitely. This is accomplished by half-open connections around indefinitely. This is accomplished by
using PIM Hellos and by not introducing an application-specific or using PIM Hellos and by not introducing an application-specific or
new PIM keep-alive message. Therefore, when a GENID changes from a new PIM keep-alive message. Therefore, when a GENID changes from a
received PIM Hello message, and a TCP connection is established or received PIM Hello message, and a TCP connection is established or
attempting to be established, the local side will tear down the attempting to be established, the local side will tear down the
connection and attempt to reopen a new one for the new instance of connection and attempt to reopen a new one for the new instance of
the neighbor coming up. the neighbor coming up. However, if the connection is shared by
multiple interfaces and the GENID changes only for one of them, then
there was not a full reboot and the connection is likely to still
work. In that case, the router should just resend all JP state for
that particular neighbor. This is similar to how state is refreshed
when GENID changes for PIM in datagram mode.
When PORT capable routers come up and try to establish transport There may be situations where a router ignores some joins or prunes.
connections with their neighbors, but cannot for some reason, after 3 E.g. due to wrong RP information or receiving joins on an RPF
attempts to do so, the router should go into datagram mode and not interface. A router may try to cache such messages and apply them
advertise the PORT Hello option anymore. Operator intervention is later if only a temporary error. It may however also ignore the
required to restart the process after the problem is found. message, and later change its GENID for that interface to make the
neighbor resend all state, including any that may have been
previously ignored. It is possible that one receives JP messages for
an interface/link that is down. As long as the neighbor has not
expired, we recommend processing those messages as usual. If they
are ignored, then the router should change the GENID for that
interface when it comes back up, in order to get a full update.
4.2. Transitional Periods 4.2. Moving from PORT to Datagram Mode
There may be transitional periods when a router receives, from a There may be situations where an administrator decides to stop using
given neighbor, both datagram JP messages and JP messages sent over a PORT. If PORT is disabled on a router interface, we start expiry
transport connection. When this happens, a transport connection to a timers with the respective neighbor holdtimes as the initial values.
particular neighbor is established, and as long as it remains Similarly if we receive a Hello message without a PORT Capable option
established, the router MUST ignore PIM messages sent in Datagram from a neighbor, we start expiry timers for all JP state we have for
Mode from that neighbor. Otherwise, the datagram messages could get that particular neighbor. The Transport connection should be shut
out of order with respect to the transport messages, and the router down as soon as there are no more PIM neighborships using it. That
could end up in an erroneous state of pruning joined state or joining is, for the connection we have associated local and remote Connection
pruned state which it is unable to recover from as long as the IDs. When there is no PIM neighbor with that particular remote
transport connection stays up. connection ID on any interface where we announce the local connection
ID, the connection should be shut down.
4.3. On-demand versus Pre-configured Connections 4.3. On-demand versus Pre-configured Connections
Transport connections could be established when they are needed or Transport connections could be established when they are needed or
when a router interface to other PIM neighbors has come up. The when a router interface to other PIM neighbors has come up. The
advantages of on-demand Transport connection establishment are the advantage of on-demand Transport connection establishment is the
reduction of router resources. Especially in the case where there is reduction of router resources. Especially in the case where there is
no need for n^2 connections on a network interface or MDT tunnel. no need for n^2 connections on a network interface or MDT tunnel.
The disadvantages are deciding what to do when a JP message needs to The disadvantage is additional delay and queueing when a JP message
be sent and a Transport connection is not established yet. An needs to be sent and a Transport connection is not established yet.
implementation can either send a Datagram Mode JP or queue the JP to
be sent as a Transport Mode JP after the Transport connection is
established.
If a router interface has become operational and PIM neighbors are If a router interface has become operational and PIM neighbors are
learned from Hello messages, at that time, Transport connections may learned from Hello messages, at that time, Transport connections may
be established. The advantage is that a connection is ready to be established. The advantage is that a connection is ready to
transport data by the time a JP messages needs to be sent. The transport data by the time a JP messages needs to be sent. The
disadvantage is there can be more connections established than disadvantage is there can be more connections established than
needed. This can occur when there is a small set of RPF neighbors needed. This can occur when there is a small set of RPF neighbors
for the active distribution trees compared to the total number of for the active distribution trees compared to the total number of
neighbors. Even when Transport connections are pre-established neighbors. Even when Transport connections are pre-established
before they are needed, a connection can go down and an before they are needed, a connection can go down and an
implementation will have to deal with an on-demand situation. implementation will have to deal with an on-demand situation.
Note that for TCP, it is the router with the lower Connection ID that
decides whether to open a connection immediately, or on-demand. The
router with the higher Connection ID should only initiate a
connection on-demand. That is, if it needs to send a JP message and
there is no currently established connection.
Therefore, this specification recommends but does not mandate the use Therefore, this specification recommends but does not mandate the use
of on-demand Transport connection establishment. of on-demand Transport connection establishment.
4.4. Possible Hello Suppression Considerations 4.4. Possible Hello Suppression Considerations
This specification indicates that a Transport connection cannot be This specification indicates that a Transport connection cannot be
established until a Hello message is received. One reason for this established until a Hello message is received. One reason for this
is to determine if the PIM neighbor supports this specification and is to determine if the PIM neighbor supports this specification and
the other is to determine the remote address to use to establish the the other is to determine the remote address to use to establish the
Transport connection. Transport connection.
skipping to change at page 14, line 16 skipping to change at page 13, line 33
transmission of Hello messages. In this case, it is outside the transmission of Hello messages. In this case, it is outside the
scope of this document on how to determine if the PIM neighbor scope of this document on how to determine if the PIM neighbor
supports this specification as well as an out-of-band (outside of the supports this specification as well as an out-of-band (outside of the
PIM protocol) method to determine the remote address to establish the PIM protocol) method to determine the remote address to establish the
Transport connection. Transport connection.
4.5. Avoiding a Pair of Connections between Neighbors 4.5. Avoiding a Pair of Connections between Neighbors
To ensure there are not two connections between a pair of PIM To ensure there are not two connections between a pair of PIM
neighbors, the following set of rules must be followed. Let A and B neighbors, the following set of rules must be followed. Let A and B
be two PIM neighbors where A's IP address is numerically smaller than be two PIM neighbors where A's Connection ID is numerically smaller
B's IP address, and each is known to the other as having a potential than B's Connection ID, and each is known to the other as having a
PIM adjacency relationship. potential PIM adjacency relationship.
At node A: At node A:
o If there is already an established TCP connection to B, on the o If there is already an established TCP connection to B, on the
PIM-over-TCP port, then A MUST NOT attempt to establish a new PIM-over-TCP port, then A MUST NOT attempt to establish a new
connection to B. Rather it uses the established connection to send connection to B. Rather it uses the established connection to send
JPs to B. (This is independent of which node initiated the JPs to B. (This is independent of which node initiated the
connection.) connection.)
o If A has initiated a connection to B, but the connection is still o If A has initiated a connection to B, but the connection is still
skipping to change at page 14, line 46 skipping to change at page 14, line 15
At node B: At node B:
o If there is already an established TCP connection to A, on the o If there is already an established TCP connection to A, on the
PIM-over-TCP port, then B MUST NOT attempt to establish a new PIM-over-TCP port, then B MUST NOT attempt to establish a new
connection to A. Rather it uses the established connection to send connection to A. Rather it uses the established connection to send
JPs to A. (This is independent of which node initiated the JPs to A. (This is independent of which node initiated the
connection.) connection.)
o If B has initiated a connection to A, but the connection is still o If B has initiated a connection to A, but the connection is still
in the process of being established, then if A initiates a in the process of being established, then if A initiates a
connection to, B MUST accept the connection initiated by A and connection too, B MUST accept the connection initiated by A and
must release the connection which it (B) initiated. must release the connection which it (B) initiated.
5. Common Header Definition 5. Common Header Definition
It may be desirable for scaling purposes to include JP messages from It may be desirable for scaling purposes to allow JP messages from
different PIM protocol instances to be sent over the same Transport different PIM protocol instances to be sent over the same Transport
connection. Also, it may be desirable to have a set of JP messages connection. Also, it may be desirable to have a set of JP messages
for one address-family sent over a Transport connection that is for one address-family sent over a Transport connection that is
established over a different address-family network layer. established over a different address-family network layer.
To be able to do this we need a common header that is inserted and To be able to do this we need a common header that is inserted and
parsed for each PIM JP message that is sent on a Transport parsed for each PIM JP message that is sent on a Transport
connection. This common header will provide both record boundary and connection. This common header will provide both record boundary and
demux points when sending over a stream protocol like Transport. demux points when sending over a stream protocol like Transport.
Each JP message will have in front of it the following common header Each JP message will have in front of it the following common header
in Type/Length/Value format. And multiple different TLV types can be in Type/Length/Value format. And multiple different TLV types can be
sent over the same Transport connection. sent over the same Transport connection.
To make sure PIM JP messages are delivered as soon as the TCP To make sure PIM JP messages are delivered as soon as the TCP
transport layer receives the JP buffer, the TCP Push flag will be set transport layer receives the JP buffer, the TCP Push flag will be set
in all outgoing JP messages sent over a TCP transport connection. in all outgoing JP messages sent over a TCP transport connection.
PIM messages will be sent using destination TCP port number 8471. PIM messages will be sent using destination TCP port number 8471.
When using SCTP as the reliable transport, destination port number When using SCTP as the reliable transport, destination port number
8471 will be used. See Section 11 for IANA considerations. 8471 will be used. See Section 10 for IANA considerations.
If the buffer length of the received TLV message is less than what is
encoded in the TLV Length field, the entire TLV encoded message is
ignored and a error message is logged. Likewise, if the received
buffer length left to process at each record parsing level, is less
than the JP Message Length, the rest of the message is malformed and
not processed.
Each JP message that has passed the length checks above, contained in JP messages are error checked. This includes a bad PIM checksum,
the TLV encoding, will be error checked individually. This includes illegal type fields, illegal addresses or a truncated message. If
a bad PIM checksum, illegal type fields, or illegal addresses. If any parsing errors occur in a JP message, it is skipped, and we
any parsing errors occur in a single JP message, it is skipped over proceed processing any following TLVs.
and not processed but other JP message records in the TLV are still
parsed and processed.
The current list of defined TLVs are: The current list of defined TLVs are:
IPv4 JP Message IPv4 JP Message
0 1 2 3 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 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 = 1 | Length = (12 * X) + Y | | Type = 1 | Length = X + 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JP Message Length | Reserved |I-Type| | Reserved |I-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . | | Instance ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID | | . . . Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 JP Message | | PIMv2 JP Message |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JP Message Length | Reserved |I-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 JP Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 JP common header is used when a JP message is sent that has The IPv4 JP common header is used when a JP message is sent that has
all IPv4 encoded addresses in the PIM payload. all IPv4 encoded addresses in the PIM payload.
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 there are 12 bytes per JP message (where X above encoding. Where X is the number of bytes that make up the PIMv2
is the number of JP messages contained) enclosed in one JP message.
transmission plus Y which is the sum of each "JP Message Length"
field that appears in the transmission.
I-Type: Defines the encoding and semantics of the Instance ID I-Type: Defines the encoding and semantics of the Instance ID
field. This is not specified in this specification. field. Instance Type 0 means Instance ID is not used. Other
values are not defined in this specification.
Interface ID: This is the Interface ID from the Hello TLV, defined Interface ID: This is the Interface ID from the Hello TLV, defined
in this specification, the PIM router is sending to the PIM in this specification, the PIM router is sending to the PIM
neighbor. It indicates to the PIM neighbor what interface to neighbor. It indicates to the PIM neighbor what interface to
associate the JP Join or Prune with. associate the JP Join or Prune with.
Instance ID: This can be a VPN-ID. This field could also be a BGP Instance ID: This can be a VPN-ID. This field could also be a BGP
Route Target (RT) or BGP Route Distinguisher (RD) as defined in Route Target (RT) or BGP Route Distinguisher (RD) as defined in
[RFC4364]. Not specified in this specification. [RFC4364]. This document only defines this for Instance Type 0.
For type 0 the field should be set to zero on 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.
JP Message Length: The number of bytes that follow which make up
the PIMv2 JP message.
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 Instance IDs. the same or different Interface and Instance IDs.
IPv6 JP Message IPv6 JP Message
0 1 2 3 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 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 = 2 | Length = (12 * X) + Y | | Type = 2 | Length = X + 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JP Message Length | Reserved |I-Type| | Reserved |I-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . | | Instance ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID | | . . . Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 JP Message | | PIMv2 JP Message |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| JP Message Length | Reserved |I-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 JP Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 JP common header is used when a JP message is sent that has The IPv6 JP common header is used when a JP message is sent that has
all IPv6 encoded addresses in the PIM payload. all IPv6 encoded addresses in the PIM payload.
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 there are 12 bytes per JP message (where X above encoding. Where X is the number of bytes that make up the PIMv2
is the number of JP messages contained) enclosed in one JP message.
transmission plus Y which is the sum of each "JP Message Length"
field that appears in the transmission.
I-Type: Defines the encoding and semantics of the Instance ID I-Type: Defines the encoding and semantics of the Instance ID
field. This is not specified in this specification. field. Instance Type 0 means Instance ID is not used. Other
values are not defined in this specification.
Interface ID: This is the Interface ID from the Hello TLV, defined Interface ID: This is the Interface ID from the Hello TLV, defined
in this specification, the PIM router is sending to the PIM in this specification, the PIM router is sending to the PIM
neighbor. It indicates to the PIM neighbor what interface to neighbor. It indicates to the PIM neighbor what interface to
associate the JP Join or Prune with. associate the JP Join or Prune with.
Instance ID: This can be a VPN-ID, BGP Route Target (RT) or BGP Instance ID: This can be a VPN-ID, BGP Route Target (RT) or BGP
Route Distinguisher (RD). Not specified in this specification. Route Distinguisher (RD). This document only defines this for
Instance Type 0. For type 0 the field should be set to zero on
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.
JP Message Length: The number of bytes that follow which make up
the PIMv2 JP message.
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 Instance IDs. the same or different Interface and Instance IDs.
6. Join/Prune Processing
When a PORT neighbor transitions to using Transport Mode, the
downstream router sends JP messages for existing routes that RPF to
the neighbor over the Transport connection. In addition, periodic JP
messages are stopped and only incremental JPs are sent thereafter.
A router which has a Transport connection established MUST send and
receive JP messages over the Transport session to that given peer as
well as accept and process native JP messages as described in
[RFC4601].
When a Transport connection is established for a newly discovered
neighbor, the downstream router triggers JP messages for its existing
state. This is to allow the upstream router to build state it may
previously not had. If state had existed due to a Native JP, the
expiration timer would have been started. Now it can be stopped
because the state is being sent incrementally over the Transport
connection.
When a Transport connection goes down to a given neighbor, the
downstream router does not have to trigger native JP messages. It
can wait for its next periodic interval to send a native JP messages.
When the upstream router receives the native JP message, it will
start the expiration timer for the oif associated with the state from
the JP message.
Note, since JP messages are sent over a Transport connection, no
Prune Override or Join Suppression are possible for these messages.
7. Outgoing Interface List Explicit Tracking 6. Outgoing Interface List Explicit Tracking
Since this specification indicates the use of TCP/SCTP for PIM JP Since this specification indicates the use of TCP/SCTP for PIM JP
messages over point-to-point or NBMA type links, explicit tracking messages only over point-to-point or NBMA type links, explicit
can be achieved by tracking only oif-list state and not per-neighbor tracking can be achieved by tracking only oif-list state and not per-
per oif-list state. This is true for segmented LANs and in segmented neighbor per oif-list state. This is true for segmented LANs and in
MDT/PMSI environments. segmented MDT/PMSI environments.
By using explicit tracking of oifs, the router tracks all downstream By using explicit tracking of oifs, the router tracks all downstream
neighbors which have expressed interest in a route on a given neighbors which have expressed interest in a route on a given
interface. The list of tracked routers is one of the checks used to interface. The list of tracked routers is one of the checks used to
determine whether traffic needs to be forwarded on a given interface determine whether traffic needs to be forwarded on a given interface
or not. or not.
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. This is tracking the oif to the neighbor. When the
skipping to change at page 21, line 5 skipping to change at page 20, line 5
list based explicit tracking will occur just like in the (*,G) and list based explicit tracking will occur just like in the (*,G) and
(S,G) route case above. (S,G) route case above.
The only difference in the (S,G,R) route case, is that when the The only difference in the (S,G,R) route case, is that when the
outgoing interface is pruned, the entry must stay in the route table outgoing interface is pruned, the entry must stay in the route table
or else forwarding will occur on the interfaces for the (*,G) entry. or else forwarding will occur on the interfaces for the (*,G) entry.
Therefore, explicit tracking for Prunes must be provided. Only when Therefore, explicit tracking for Prunes must be provided. Only when
the (S,G,R) oif-list interfaces match the interfaces in the (*,G) can the (S,G,R) oif-list interfaces match the interfaces in the (*,G) can
the (S,G,R) route be removed. the (S,G,R) route be removed.
8. 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.
There are two ways this can be accomplished, one using a common There are two ways this can be accomplished, one using a common
header format over a TCP connection and the other using multiple header format over a TCP connection and the other using multiple
skipping to change at page 22, line 5 skipping to change at page 21, line 5
within a TLV, multiple occurrences of JP messages can occur and are within a TLV, multiple occurrences of JP messages can occur and are
tagged with an instance-ID so multiple JP messages for different VPNs tagged with an instance-ID so multiple JP messages for different VPNs
can use a single Transport connection. can use a single Transport connection.
When using SCTP multi-streaming, the common header is still used to When using SCTP multi-streaming, the common header is still used to
convey instance information but an SCTP association is used, on a convey instance information but an SCTP association is used, on a
per-VPN basis, to send data concurrently for multiple instances. per-VPN basis, to send data concurrently for multiple instances.
When data is sent concurrently, head of line blocking, which can When data is sent concurrently, head of line blocking, which can
occur when using TCP, is avoided. occur when using TCP, is avoided.
9. Miscellany 8. Miscellany
No changes expected in processing of other PIM messages like PIM No changes expected in processing of other PIM messages like PIM
Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This
goes for BSR and Auto-RP type messages as well. goes for BSR and Auto-RP type messages as well.
This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM. This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM.
It does not take requirements for PIM-DM into consideration. It does not take requirements for PIM-DM into consideration.
10. Security Considerations 9. Security Considerations
Transport connections can be authenticated using HMACs MD5 and SHA-1 Transport connections can be authenticated using HMACs MD5 and SHA-1
similar to use in BGP [RFC4271] and MSDP [RFC3618]. similar to use in BGP [RFC4271] and MSDP [RFC3618].
When using SCTP as the transport protocol, [RFC4895] can be used, on When using SCTP as the transport protocol, [RFC4895] can be used, on
a per SCTP association basis to authenticate PIM data. a per SCTP association basis to authenticate PIM data.
11. IANA Considerations 10. IANA Considerations
This specification requests IANA to allocate a TCP port number and a This specification makes use of a TCP port number and a SCTP port
SCTP port number for the use of PIM-Over-Reliable-Transport. number for the use of PIM-Over-Reliable-Transport that has been
allocated by IANA. It also makes use of IANA PIM Hello Options
allocations that should be made permanent. In addition, a registry
for PORT message types is requested. This document defines two PORT
message types. Type 1, IPv4 JP Message; and Type 2, IPv6 JP Message.
11. Contributors
In addition to the persons listed as authors, significant
contributions were provided by Apoorva Karan and Arjen Boers.
12. Acknowledgments 12. Acknowledgments
The authors would like to give a special thank you and appreciation The authors would like to give a special thank you and appreciation
to Nidhi Bhaskar for her initial design and early prototype of this to Nidhi Bhaskar for her initial design and early prototype of this
idea. idea.
Appreciation goes to Randall Stewart for his authoritative review and Appreciation goes to Randall Stewart for his authoritative review and
recommendation for using SCTP. recommendation for using SCTP.
Thanks also goes to the following for their ideas and commentary Thanks also goes to the following for their ideas and commentary
review of this specification, Mike McBride, Toerless Eckert, Yiqun review of this specification, Mike McBride, Toerless Eckert, Yiqun
Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John
Zwiebel, Yakov Rekhter, and Lenny Giuliano. Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst and Sameer
Gulrajani.
A special thank you goes to Eric Rosen for his very detailed review A special thank you goes to Eric Rosen for his very detailed review
and commentary. Many of his comments are reflected as text in this and commentary. Many of his comments are reflected as text in this
specification. specification.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC0761] Postel, J., "DoD standard Transmission Control Protocol", [RFC0761] Postel, J., "DoD standard Transmission Control Protocol",
skipping to change at page 27, line 23 skipping to change at page 27, line 23
Email: dino@cisco.com Email: dino@cisco.com
IJsbrand Wijnands IJsbrand Wijnands
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: ice@cisco.com Email: ice@cisco.com
Apoorva Karan Stig Venaas
cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: apoorva@cisco.com
Arjen Boers
cisco Systems cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: aboers@cisco.com Email: stig@cisco.com
Maria Napierala Maria Napierala
AT&T Labs AT&T Labs
200 Laurel Drive 200 Laurel Drive
Middletown, New Jersey 07748> Middletown, New Jersey 07748>
USA USA
Email: mnapierala@att.com Email: mnapierala@att.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 73 change blocks. 
262 lines changed or deleted 229 lines changed or added

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