draft-ietf-pim-port-05.txt   draft-ietf-pim-port-06.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: August 19, 2011 cisco Systems Expires: September 5, 2011 cisco Systems
M. Napierala M. Napierala
AT&T Labs AT&T Labs
February 15, 2011 March 4, 2011
A Reliable Transport Mechanism for PIM A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-05.txt draft-ietf-pim-port-06.txt
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.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 19, 2011. This Internet-Draft will expire on September 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 8 3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 8
3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8
3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9
3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 10
4. Establishing Transport Connections . . . . . . . . . . . . . . 11 4. Establishing Transport Connections . . . . . . . . . . . . . . 11
4.1. Connection Security . . . . . . . . . . . . . . . . . . . 12 4.1. Connection Security . . . . . . . . . . . . . . . . . . . 13
4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13 4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13
4.3. Actions When a Connection Goes Down . . . . . . . . . . . 14 4.3. Actions When a Connection Goes Down . . . . . . . . . . . 14
4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15 4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15
4.5. On-demand versus Pre-configured Connections . . . . . . . 15 4.5. On-demand versus Pre-configured Connections . . . . . . . 15
4.6. Possible Hello Suppression Considerations . . . . . . . . 16 4.6. Possible Hello Suppression Considerations . . . . . . . . 16
4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 16 4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 16
5. PORT Message Definition . . . . . . . . . . . . . . . . . . . 18 5. PORT Message Definition . . . . . . . . . . . . . . . . . . . 18
5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19 5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19
5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20 5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20
5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21
6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 23 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 23
7. Multiple Address-Family Support . . . . . . . . . . . . . . . 24 7. Multiple Address-Family Support . . . . . . . . . . . . . . . 24
8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. PORT Message Type Registry . . . . . . . . . . . . . . . . 27 10.1. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 27
10.2. PORT Option Type Registry . . . . . . . . . . . . . . . . 27 10.2. PORT Message Type Registry . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.3. PORT Option Type Registry . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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 for use with PIM Sparse-Mode message delivery in PIM version 2 for use with PIM Sparse-Mode
[RFC4601] (including Source-Specific Multicast) and Bidirectional [RFC4601] (including Source-Specific Multicast) and Bidirectional
PIM [RFC5015]. PIM [RFC5015].
skipping to change at page 3, line 29 skipping to change at page 3, line 29
negotiation on a per neighbor 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 message formats as defined in [RFC4601]. o Changes to the PIM message formats as defined in [RFC4601].
o Provide support for automatic switching between the reliable o Provide support for automatic switching between the reliable
transport mechanism and the regular PIM mechanism defined in transport mechanism and the regular PIM mechanism defined in
[RFC4601]. Two routers that are PIM neighbors on a link will [RFC4601]. Two routers that are PIM neighbors on a link will
always use the reliable transport mechanism if and only if both always use the reliable transport mechanism if and only if both
have reliable transport enabled. have enabled support for the reliable transport mechanism.
This document will specify how periodic Join/Prune message This document will specify how periodic Join/Prune message
transmission can be eliminated by using TCP [RFC0793] or SCTP transmission can be eliminated by using TCP [RFC0793] or SCTP
[RFC4960] as the reliable transport mechanism for Join/Prune [RFC4960] as the reliable transport mechanism for Join/Prune
messages. messages.
This specification enables greater scalability in terms of control This specification enables greater scalability in terms of control
traffic overhead. However, for routers connected to multi-access traffic overhead. However, for routers connected to multi-access
links that comes at the price of increased control plane state links that comes at the price of increased control plane state
overhead and the control plane overhead required to maintain this overhead and the control plane overhead required to maintain this
skipping to change at page 8, line 30 skipping to change at page 8, line 30
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 PIM over TCP, it MUST NOT include the PIM-over-TCP Capable using PIM over TCP, it MUST NOT include the PIM-over-TCP Capable
hello option in its Hello messages. hello option in its Hello messages.
All Hello messages containing the PIM-over-TCP Capable hello option, All Hello messages containing the PIM-over-TCP Capable hello option,
MUST also contain the Interface ID hello option, see section . MUST also contain the Interface ID hello option, see section
Section 3.3.
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. It is RECOMMENDED that this capability
disabled by default. be disabled by default.
Length: Length in bytes for the value part of the Type/Length/Value Length: Length in bytes for the value part of the Type/Length/Value
encoding; where X is the number of bytes that make up the encoding; where X is the number of bytes that make up the
Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, Connection ID field. X is 4 when AFI of value 1 (IPv4) is used,
16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is
used [AFI]. 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. When this field is of the address of the TCP Connection ID field. When this field is
0, a mechanism outside the scope of this document is used to 0, a mechanism outside the scope of this document is used to
skipping to change at page 9, line 34 skipping to change at page 9, line 36
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 PIM over SCTP, it MUST NOT include the PIM-over- disabled from using PIM over SCTP, it MUST NOT include the PIM-over-
SCTP Capable hello option in its Hello messages. SCTP Capable hello option in its Hello messages.
All Hello messages containing the PIM-over-SCTP Capable hello option, All Hello messages containing the PIM-over-SCTP Capable hello option,
MUST also contain the Interface ID hello option, see section . MUST also contain the Interface ID hello option, see section
Section 3.3.
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. It is RECOMMENDED that this capability
disabled by default. be disabled by default.
Length: Length in bytes for the value part of the Type/Length/Value Length: Length in bytes for the value part of the Type/Length/Value
encoding; where X is the number of bytes that make up the encoding; where X is the number of bytes that make up the
Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, Connection ID field. X is 4 when AFI of value 1 (IPv4) is used,
16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is
used [AFI]. 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. When this family of the address of the SCTP Connection ID field. When this
field is 0, a mechanism outside the scope of this document is used field is 0, a mechanism outside the scope of this document is used
skipping to change at page 12, line 7 skipping to change at page 12, line 7
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 When a Transport connection is established (or reestablished), the
two routers MUST both send a full set of Join/Prune messages for two routers MUST both send a full set of Join/Prune messages for
state for which the other router is the upstream neighbor. This is state for which the other router is the upstream neighbor. This is
needed to ensure that the upstream neighbor has the correct state. needed to ensure that the upstream neighbor has the correct state.
When moving from Datagram mode, or when the connection has gone down, When moving from Datagram mode, or when the connection has gone down,
the router cannot be sure that all the previous Join/Prune state was the router cannot be sure that all the previous Join/Prune state was
received by the neighbor. Any state received while in Datagram mode received by the neighbor. Any state created before the connection
that is not refreshed, will be left to expire. was established (or reestablished) that is not refreshed, MUST be
left to expire and be deleted. When the non-refreshed state has
expired and been deleted, the two neighbors will be in sync.
It is possible that a router starts sending Hello messages with a new It is possible that a router starts sending Hello messages with a new
Connection ID, e.g. due to configuration changes. One MUST always Connection ID, e.g. due to configuration changes. One MUST always
use the last announced and last seen Connection IDs. When a use the last announced and last seen Connection IDs. A connection is
Connection ID changes, if the previously used connection is not identified by the local Connection ID (the one we are announcing on a
needed (there are no other PIM neighborships using the same pair of particular interface), and the remote Connection ID (the one we are
Connection IDs), both peers MUST attempt a graceful shutdown of the receiving from a neighbor on the same interface). When either the
connection. Next (even if the old connection is still needed), they local or remote ID changes, the Connection ID pair we need a
MUST, unless a connection already exists with the new Connection IDs, connection for changes. There may be an existing connection with the
immediately or on-demand attempt to establish a new connection with same pair, in which case we will share that connection. Or a new
the new Connection IDs. connection may need to be established. Note that for link-local
addresses, the interface should be regarded as part of the ID, so
that connection sharing is not attempted when the same link-local
addresses are seen on different interfaces.
When a Connection ID changes, if the previously used connection is
not needed (there are no other PIM neighborships using the same
Connection ID pair), both peers MUST attempt a graceful shutdown of
the connection. Next (even if the old connection is still needed),
they MUST, unless a connection already exists with the new Connection
ID pair, immediately or on-demand attempt to establish a new
connection with the new Connection ID pair.
Normally the Interface ID would not change while a connection is up. Normally the Interface ID would not change while a connection is up.
However, if it does, it should not affect the connection. It just However, if it does, it should not affect the connection. It just
means that when subsequent PORT join/prune messages are received, means that when subsequent PORT join/prune messages are received,
they should be matched against the last seen Interface ID. they should be matched against the last seen Interface ID.
Note that, a Join sent over a Transport connection will only be seen Note that, a Join sent over a Transport connection will only be seen
by the upstream router, and thus will not cause routers on the link by the upstream router, and thus will not cause routers on the link
that do not use PIM PORT with the upstream router to possibly delay that do not use PIM PORT with the upstream router to possibly delay
the refresh of Join state for the same state. Similarly, a Prune the refresh of Join state for the same state. Similarly, a Prune
skipping to change at page 13, line 22 skipping to change at page 13, line 35
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 Join/Prune messages might be in only one direction, since the flow of Join/Prune messages might be in only one direction,
and the downstream neighbor might never get any indication via TCP and the downstream neighbor might never get any indication via TCP
that the other end of the connection is not really there. that the other end of the connection is not really there.
One can quicker detect that a PORT connection is not working by One can detect that a PORT connection is not working by regularly
regularly sending PORT messages. PORT in itself does not require any sending PORT messages. E.g., for TCP the connection will be reset if
periodic signaling. PORT Join/Prune messages are only sent when no TCP ACKs are received after a few retries. PORT in itself does
there is a state change. If the state changes are not frequent not require any periodic signaling. PORT Join/Prune messages are
enough, a PORT Keep-Alive message can be sent instead. E.g. if an only sent when there is a state change. If the state changes are not
implementation wants to send a PORT message, to check that the frequent enough, a PORT Keep-Alive message can be sent instead. E.g.
if an implementation wants to send a PORT message, to check that the
connection is working, at least every 60 seconds, then whenever there connection is working, at least every 60 seconds, then whenever there
is 60 seconds since the the previous message, a Keep-Alive message is 60 seconds since the previous message, a Keep-Alive message could
could be sent. If there were less than 60 seconds between each Join/ be sent. If there were less than 60 seconds between each Join/Prune,
Prune, no Keep-Alive messages would be needed. Implementations no Keep-Alive messages would be needed. Implementations SHOULD
SHOULD support the use of PORT Keep-Alive messages. We RECOMMEND support the use of PORT Keep-Alive messages. It is RECOMMENDED that
this to be optional, allowing network administrators to use it as a configuration option is available to network administrators to
needed. Note that Keep-Alives can be used by a peer, independently enable it when needed. Note that Keep-Alives can be used by a peer,
of whether the other peer supports it. independently of whether the other peer supports it.
As described in the previous paragraph, an implementation can make The mechanism above relies on the connection eventually going down
use of Keep-Alives to regularly send messages and detect when a when we don't get any ACKs for the data we send. A quicker and more
connection is not working. For TCP the connection will be reset if reliable way of detecting that a connection is not working, is to
no TCP ACKs are received. A quicker and more reliable way of send regular PORT messages, and have our peer take down the
detecting that a connection is not working, is to send regular PORT connection if it doesn't receive them. This can be done by sending
messages, and have our peer take down the connection if it doesn't Keep-alive messages with a non-zero holdtime value. If the last
receive them. This can be done by sending Keep-alive messages with a received Keep-alive message had a non-zero holdtime, one tears down
non-zero holdtime value. If the last received Keep-alive message had the connection if the time measured in seconds since the last
a non-zero holdtime, one tears down the connection if the time processed PORT message exceeds the specified holdtime.
measured in seconds since the last processed PORT message exceeds the
specified holdtime.
Implementations SHOULD support Keep-Alive messages. An Implementations SHOULD support Keep-Alive messages. An
implementation that supports Keep-Alive messages acts as follows when implementation that supports Keep-Alive messages acts as follows when
processing a received PORT message. When processing a Keep-Alive processing a received PORT message. When processing a Keep-Alive
message with a non-zero Holdtime value, it MUST set a timer to the message with a non-zero Holdtime value, it MUST set a timer to the
value. We call this timer Connection Expiry Timer (CET). If the CET value. We call this timer Connection Expiry Timer (CET). If the CET
is already running, it MUST be reset to the new value. When is already running, it MUST be reset to the new value. When
processing a Keep-Alive message with a zero Holdtime value, the CET processing a Keep-Alive message with a zero Holdtime value, the CET
MUST be stopped if running. When processing a PORT message other MUST be stopped if running. When processing a PORT message other
than Keep-Alive, the CET MUST be reset to the last received Holdtime than Keep-Alive, the CET MUST be reset to the last received Holdtime
value if running. If the CET is not running, no action is taken. If value if running. If the CET is not running, no action is taken. If
the CET expires, the connection SHOULD be shut down. the CET expires, the connection SHOULD be shut down.
It is possible that a router receives Join/Prune messages for an It is possible that a router receives Join/Prune messages for an
interface/link that is down. As long as the neighbor has not interface/link that is down. As long as the neighbor has not
expired, we RECOMMEND processing those messages as usual. If they expired, it is RECOMMENDED processing those messages as usual. If
are ignored, then the router SHOULD ensure it gets a full update for they are ignored, then the router SHOULD ensure it gets a full update
that interface when it comes back up. This can be done by changing for that interface when it comes back up. This can be done by
the GenID, or by terminating and reestablishing the connection. changing the GenID (Generation Identifier, see [RFC4601]), or by
terminating and reestablishing the connection.
If a PORT neighbor changes its GenID and a connection is established If a PORT neighbor changes its GenID and a connection is established
or attempting to be established, the local side should generally tear or attempting to be established, the local side should generally tear
down the connection and do as described in Section 4.3. However, if down the connection and do as described in Section 4.3. However, if
the connection is shared by multiple interfaces and the GenID changes the connection is shared by multiple interfaces and the GenID changes
only for one of them, then there was not a full restart, and one may only for one of them, the local side SHOULD simply send a full
simply send a full update similar to other cases when a GenID changes update, similar to other cases when a GenID changes for an upstream
for an upstream neighbor. neighbor.
4.3. Actions When a Connection Goes Down 4.3. Actions When a Connection Goes Down
A connection may go down for a variety of reasons. It may be due to A connection may go down for a variety of reasons. It may be due to
an error condition, or a configuration change. A connection SHOULD an error condition, or a configuration change. A connection SHOULD
be shut down as soon as there are no more PIM neighborships using it. be shut down as soon as there are no more PIM neighbors using it.
That is, for the connection we have associated local and remote That is, for the connection we have associated local and remote
Connection IDs. When there is no PIM neighbor with that particular Connection IDs. When there is no PIM neighbor with that particular
remote connection ID on any interface where we announce the local remote connection ID on any interface where we announce the local
connection ID, the connection SHOULD be shut down. This may happen connection ID, the connection SHOULD be shut down. This may happen
when a new connection ID is configured, PORT is disabled, or a PIM when a new connection ID is configured, PORT is disabled, or a PIM
neighbor expires. neighbor expires.
If a PIM neighbor expires, one should free connection state and If a PIM neighbor expires, one should free connection state and
downstream oif-list state for the neighbor. A downstream router, downstream oif-list state for the neighbor. A downstream router,
when an upstream neighboring router has expired, will simply update when an upstream neighboring router has expired, will simply update
the RPF for the corresponding state to a new neighbor where it would the RPF neighbor for the corresponding state to a new neighbor where
trigger Join/Prune messages like it would in [RFC4601]. It is it would trigger Join/Prune messages. This behavior is according to
[RFC4601] where also the term RPF neighbor is defined. It is
required of a PIM router to clear its neighbor table for a neighbor required of a PIM router to clear its neighbor table for a neighbor
who has timed out due to neighbor holdtime expiration. who has timed out due to neighbor holdtime expiration.
When a connection is no longer available between two PORT enabled PIM When a connection is no longer available between two PORT enabled PIM
neighbors, they MUST immediately, or on-demand, try to reestablish neighbors, they MUST immediately, or on-demand, try to reestablish
the connection following the normal rules for connestion the connection following the normal rules for connection
establishment. The neighbors MUST also start expiry timers so that establishment. The neighbors MUST also start expiry timers so that
all oif-list state for the neighbor using the connection, gets all oif-list state for the neighbor using the connection, gets
expired after JP_HOLDTIME, unless it later gets refreshed by expired after JP_HOLDTIME, unless it later gets refreshed by
receiving new Join/Prunes. receiving new Join/Prunes.
The value of JP_HOLDTIME is 215 seconds. This value is based on The value of JP_HOLDTIME is 215 seconds. This value is based on
section 4.11 of [RFC4601] which says that J/P_HoldTime should be 3.5 section 4.11 of [RFC4601] which says that JP_HoldTime should be 3.5 *
* t_periodic where the default for t_periodic is 60 seconds. t_periodic where the default for t_periodic is 60 seconds.
4.4. Moving from PORT to Datagram Mode 4.4. Moving from PORT to Datagram Mode
There may be situations where an administrator decides to stop using There may be situations where an administrator decides to stop using
PORT. If PORT is disabled on a router interface, or a previously PORT. If PORT is disabled on a router interface, or a previously
PORT enabled neighbor no longer announces any of the PORT Hello PORT enabled neighbor no longer announces any of the PORT Hello
options, one follows the rules in Section 4.3 for taking down options, one follows the rules in Section 4.3 for taking down
connections and starting timers. Next, one should trigger a full connections and starting timers. Next, one should trigger a full
state update similar to what would be done if the GenID changed in state update similar to what would be done if the GenID changed in
Datagram Mode. This means sending joins for any state where we Datagram Mode. This means sending joins for any state where we
skipping to change at page 18, line 14 skipping to change at page 18, line 14
5. PORT Message Definition 5. PORT Message Definition
It may be desirable for scaling purposes to allow Join/Prune messages It may be desirable for scaling purposes to allow Join/Prune messages
from different PIM protocol families to be sent over the same from different PIM protocol families to be sent over the same
Transport connection. Also, it may be desirable to have a set of Transport connection. Also, it may be desirable to have a set of
Join/Prune messages for one address-family sent over a Transport Join/Prune messages for one address-family sent over a Transport
connection that is established over a different address-family connection that is established over a different address-family
network layer. network layer.
To be able to do this we need a common PORT message message format. To be able to do this we need a common PORT message format. This
This will provide both record boundary and demux points when sending will provide both record boundary and demux points when sending over
over a stream protocol like TCP/SCTP. a stream protocol like TCP/SCTP.
A PORT message may contain PORT options, see Section 5.3. We will A PORT message may contain PORT options, see Section 5.3. We will
define two PORT options for carrying PIM Join/Prune messages. One define two PORT options for carrying PIM Join/Prune messages. One
for IPv4 and one for IPv6. For each PIM Join/Prune message to be for IPv4 and one for IPv6. For each PIM Join/Prune message to be
sent over the Transport connection, we send a PORT Join/Prune message sent over the Transport connection, we send a PORT Join/Prune message
containing exactly one such option. containing exactly one such option.
Each PORT message will have the below Type/Length/Value format. Each PORT message will have the Type/Length/Value format. Multiple
Multiple different TLV types can be sent over the same Transport different TLV types can be sent over the same Transport connection.
connection.
To make sure PIM Join/Prune messages are delivered as soon as the TCP To make sure PIM Join/Prune messages are delivered as soon as the TCP
transport layer receives the Join/Prune buffer, the TCP Push flag transport layer receives the Join/Prune buffer, the TCP Push flag
will be set in all outgoing Join/Prune messages sent over a TCP will be set in all outgoing Join/Prune messages sent over a TCP
transport connection. transport connection.
PORT messages will be sent using destination TCP port number 8471. PORT 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 10 for IANA considerations. 8471 will be used. See Section 10 for IANA considerations.
PORT messages are error checked. This includes a bad PIM checksum, PORT messages are error checked. This includes a bad PIM checksum,
illegal type fields, illegal addresses or a truncated message. If illegal type fields, illegal addresses or a truncated message. If
any parsing errors occur in a Join/Prune message, it is skipped, and any parsing errors occur in a PORT message, it is skipped, and we
we proceed processing any following PORT messages. proceed to any following PORT messages.
The TLV type field is 16 bits. The range 61440 - 65535 is for The TLV type field is 16 bits. The range 61440 - 65535 is for
experimental use [RFC3692]. experimental use [RFC3692].
This document defines two message types. This document defines two message types.
5.1. PORT Join/Prune Message 5.1. PORT Join/Prune Message
PORT Join/Prune Message PORT Join/Prune Message
skipping to change at page 20, line 8 skipping to change at page 20, line 8
L1, L2, ..., Ln are included, the message length will be 12 + 4*n L1, L2, ..., Ln are included, the message length will be 12 + 4*n
+ L1 + L2 + ... + Ln. + L1 + L2 + ... + Ln.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
Interface ID: This is the Interface ID of the Interface ID Hello Interface ID: This is the Interface ID of the Interface ID Hello
option contained in the PIM Hello messages the PIM router is option contained in the PIM Hello messages the PIM router is
sending to the PIM neighbor. It indicates to the PIM neighbor sending to the PIM neighbor. It indicates to the PIM neighbor
what interface to associate the Join/Prune with. what interface to associate the Join/Prune with. The Interface ID
allows us to do connection sharing.
PORT Options: The message MUST contain exactly one PIM Join/Prune PORT Options: The message MUST contain exactly one PIM Join/Prune
Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/
Prune. It MUST NOT contain both. It MAY contain additional Prune. It MUST NOT contain both. It MAY contain additional
options not defined in this document. A router receiving a PORT options not defined in this document. A router receiving a PORT
Join/Prune message containing unknown options MUST ignore the Join/Prune message containing unknown options MUST ignore the
entire PORT message. See Section 5.3 for option definitions. entire PORT message. See Section 5.3 for option definitions.
As can be seen from the packet format diagram, multiple Join/Prune
messages can go into one TCP/SCTP stream from the same or different
Interface IDs.
5.2. PORT Keep-alive Message 5.2. PORT Keep-alive Message
PORT Keep-alive Message PORT Keep-alive 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 | Message Length | | Type = 2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Exp | | Reserved | Exp |
skipping to change at page 21, line 4 skipping to change at page 20, line 50
| PORT Option Type | Option Value Length | | PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
| . | | . |
| . | | . |
| . | | . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PORT Keep-alive Message is used to regularly send PORT messages The PORT Keep-alive Message is used to regularly send PORT messages
to verify that a connection is alive. They are used when other PORT to verify that a connection is alive. They are used when other PORT
messages are not sent of the desired frequency. messages are not sent at the desired frequency.
Message Length: Length in bytes for the value part of the Type/ Message Length: Length in bytes for the value part of the Type/
Length/Value encoding. If no PORT Options were included, the Length/Value encoding. If no PORT Options were included, the
length would be 6. If n PORT Options with Option Value lengths length would be 6. If n PORT Options with Option Value lengths
L1, L2, ..., Ln are included, the message length will be 6 + 4*n + L1, L2, ..., Ln are included, the message length will be 6 + 4*n +
L1 + L2 + ... + Ln. L1 + L2 + ... + Ln.
Reserved: Set to zero on transmission and ignored on receipt. Reserved: Set to zero on transmission and ignored on receipt.
Exp: For experimental use [RFC3692]. Exp: For experimental use [RFC3692].
skipping to change at page 21, line 27 skipping to change at page 21, line 26
A non-zero value means that the connection SHOULD be gracefully A non-zero value means that the connection SHOULD be gracefully
shut down if no further PORT messages are received within the shut down if no further PORT messages are received within the
specified time. This is measured on the receiving side by specified time. This is measured on the receiving side by
measuring the time from one PORT message has been processed until measuring the time from one PORT message has been processed until
the next has been processed. Note that this is done for any PORT the next has been processed. Note that this is done for any PORT
message, not just keep-alive messages. A hold time of 0 disables message, not just keep-alive messages. A hold time of 0 disables
the keep-alive mechanism. the keep-alive mechanism.
PORT Options: A keep-alive message MUST NOT contain any of the PORT Options: A keep-alive message MUST NOT contain any of the
options defined in this document. It MAY contain other options options defined in this document. It MAY contain other options
not defined in this document. See Section 5.3 for option not defined in this document. Unknown options MUST be ignored.
definitions. See Section 5.3 for option definitions.
5.3. PORT Options 5.3. PORT Options
Each PORT Option is a TLV. The type is 16 bits. PORT Option types Each PORT Option is a TLV. The type is 16 bits. PORT Option types
are assigned by IANA, except the range 61440 - 65535 which is for are assigned by IANA, except the range 61440 - 65535 which is for
experimental use [RFC3692]. The length specifies the length of the experimental use [RFC3692]. The length specifies the length of the
value in bytes. Below are the two options defined in this document. value in bytes. Below are the two options defined in this document.
PIM IPv4 Join/Prune Option PIM IPv4 Join/Prune Option
PIM IPv4 Join/Prune Option Format PIM IPv4 Join/Prune Option Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = 1 | Option Value Length | | PORT Option Type = 1 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIMv2 Join/Prune Message | | PIMv2 Join/Prune Message |
| . | | . |
| . | | . |
skipping to change at page 27, line 12 skipping to change at page 27, line 12
association basis. Also GTSM [RFC5082] can be used to help prevent association basis. Also GTSM [RFC5082] can be used to help prevent
spoofing. spoofing.
10. IANA Considerations 10. IANA Considerations
This specification makes use of a TCP port number and a SCTP port This specification makes use of a TCP port number and a SCTP port
number for the use of PIM-Over-Reliable-Transport that has been number for the use of PIM-Over-Reliable-Transport that has been
allocated by IANA. It also makes use of IANA PIM Hello Options allocated by IANA. It also makes use of IANA PIM Hello Options
allocations that should be made permanent. allocations that should be made permanent.
10.1. PORT Message Type Registry 10.1. PORT Hello Options
In the Protocol Independent Multicast (PIM) Hello Options registry,
the following options are needed for PORT.
Value Length Name Reference
------- ---------- ----------------------- ---------------
27 Variable PIM-over-TCP Capable this document
28 Variable PIM-over-SCTP Capable this document
10.2. PORT Message Type Registry
A registry for PORT message types is requested. The message type is A registry for PORT message types is requested. The message type is
a 16-bit integer, with values from 0 to 65535. An RFC is required a 16-bit integer, with values from 0 to 65535. An RFC is required
for assignments in the range 0 - 61439. This document defines one for assignments in the range 0 - 61439. This document defines one
PORT message type. Type 1, PORT Join/Prune Message. The type range PORT message type. Type 1, PORT Join/Prune Message. The type range
61440 - 65535 is for experimental use [RFC3692]. 61440 - 65535 is for experimental use [RFC3692].
The initial content of the registry should be as follows: The initial content of the registry should be as follows:
Type Name Reference Type Name Reference
------------- ------------------------------- --------------- ------------- ------------------------------- ---------------
0 Reserved this document 0 Reserved this document
1 Join/Prune this document 1 Join/Prune this document
2 Keep-alive Message this document 2 Keep-alive Message this document
3-61439 Unassigned 3-61439 Unassigned
61440-65535 Experimental this document 61440-65535 Experimental this document
10.2. PORT Option Type Registry 10.3. PORT Option Type Registry
A registry for PORT option types is requested. The option type is a A registry for PORT option types is requested. The option type is a
16-bit integer, with values from 0 to 65535. An RFC is required for 16-bit integer, with values from 0 to 65535. An RFC is required for
assignments in the range 0 - 61439. This document defines two PORT assignments in the range 0 - 61439. This document defines two PORT
option types. Type 1, PIM IPv4 Join/Prune Message; and Type 2, PIM option types. Type 1, PIM IPv4 Join/Prune Message; and Type 2, PIM
IPv6 Join/Prune Message. The type range 61440 - 65535 is for IPv6 Join/Prune Message. The type range 61440 - 65535 is for
experimental use [RFC3692]. experimental use [RFC3692].
The initial content of the registry should be as follows: The initial content of the registry should be as follows:
 End of changes. 32 change blocks. 
85 lines changed or deleted 109 lines changed or added

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