Internet DRAFT - draft-venaas-pim-port-pfm
draft-venaas-pim-port-pfm
Network Working Group S. Venaas
Internet-Draft B. Ganesh
Intended status: Experimental K. Thiruvenkatasamy
Expires: September 12, 2019 R. Chokkanathapuram
Cisco Systems, Inc.
March 11, 2019
PIM Flooding Protocol over Reliable Transport
draft-venaas-pim-port-pfm-00
Abstract
The PIM Flooding Protocol (PFM) defined in RFC8364 relies on sending
periodic updates as it does not provide for any reliability. If a
message is lost, the information will be provided in the next
periodic update.
This document extends the Reliable Transport Mechanism for PIM in
RFC6559 to allow for sending PFM messages. This significantly
reduces the PFM signaling by not requiring frequent periodic updates,
and it provides for retransmission, allowing for quick recovery when
an IP packet is dropped.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019.
Copyright Notice
Copyright (c) 2019 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
Venaas, et al. Expires September 12, 2019 [Page 1]
Internet-Draft PIM PORT PFM March 2019
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Protocol specification . . . . . . . . . . . . . . . . . . . 3
4. PFM over PORT message definitions . . . . . . . . . . . . . . 5
4.1. PORT PFM Update . . . . . . . . . . . . . . . . . . . . . 5
4.2. PORT PFM Request . . . . . . . . . . . . . . . . . . . . 7
4.3. PORT PFM Update Option . . . . . . . . . . . . . . . . . 8
4.4. PORT PFM Request Option . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The PIM Flooding Protocol (PFM) defined in [RFC8364] relies on
sending periodic updates as it does not provide for any reliability.
If a message is lost, the information will be provided in the next
periodic update. With PFM, a router will typically originate a full
update every 60 seconds. This ensures that in case of packet drops,
one usually will recover in 60 seconds. There is a trade-off between
the number of updates and the recovery time.
This document extends the Reliable Transport Mechanism for PIM in
[RFC6559] to allow for sending PFM messages. We will refer to it as
PORT (PIM Over Reliable Transport). The use of PORT significantly
reduces the PFM signaling by not requiring frequent periodic updates,
and it provides for retransmission, allowing for quick recovery when
an IP packet is dropped. There will still be some full updates, but
they can be sent much more rarely. If there is a packet drop, the
reliable transport (TCP/SCTP) will ensure retransmission.
The PORT sessions are established as specified in [RFC6559] between
PIM neighbors. The sessions may be used to send other PORT messages,
or they can be used only for PFM. Unless all the neighbors support
PFM over PORT, regular PFM is used. How to signal support and how a
router relays a PFM over PORT message as regular PFM and vice versa
will be discussed in a later revision.
Venaas, et al. Expires September 12, 2019 [Page 2]
Internet-Draft PIM PORT PFM March 2019
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol specification
PFM messages are sent over PORT by sending PORT PFM Update messages.
They contain a PFM message as defined in [RFC8364]. They also
contain a Full ID and a Delta ID that together specifies an ID for
the update. Some updates are full updates, they contain all the
information an originator is announcing. This would be similar to
the periodic updates in regular PFM. Full updates over PORT are sent
after some a configurable number of deltas have been sent, or
whenever information needs to be withdrawn. Delta updates are used
for triggered updates, similar to triggered updates in regular PFM.
Each time there is some change a delta update can be triggered.
The Full ID is an unsigned 48 bit value and it is assumed that it is
always increasing. That is, any Full Update MUST always have a Full
ID larger than any previous updates ever sent using the same
Originator address. This MUST also be preserved if the router is
reloaded. For the protocol to work, it may also be necessary to
ensure this if an address used as an originator address is moved to a
different router. It is RECOMMENDED that implementations use the
number of seconds since 0h UTC on 1 January 1900 as the ID value.
This allows for this protocol to be used for about four million years
from the time of publication of this document. If for any reason the
clock on a router is adjusted to a value back in time, an
implementation would have to ensure that values are still increasing.
Since Full Updates do not need to be sent every second, one should in
this case be able to catch up.
The first time a router originates a PFM message, it sends a Full
update, even though it likely is triggered by some event. Full
updates always have the Delta ID set to zero. After that it may send
several Delta updates. For each Delta update, the Delta ID is
incremented, while the Full ID remains the same. After some time it
may decide to send a new full update. The Full ID in the full update
MUST be larger than the Full ID in the previous update, and Delta ID
is reset to zero. A Full update always has Delta ID zero, and a
Delta update always has a non-zero Delta ID.
When a router receives an update it performs RPF check as in regular
PFM, boundary processing as in regular PFM. For each interface where
Venaas, et al. Expires September 12, 2019 [Page 3]
Internet-Draft PIM PORT PFM March 2019
the update would have been forwarded in regular PFM, it will be sent
over PORT to all PFM PORT neighbors on the interface. If there are
any neighbors on the interface not supporting PFM PORT it MAY revert
to sending unreliable PFM messages.
When a router receives a Full update it will remove any stored
information from the originator and store the information in the new
update. When it receives a Delta update it stores the update and
keeps all previous information.
Due to routers being restarted, PORT connections going down etc.,
some routers MAY have missed some updates, potentially not having
received any updates when restarting. In order to receive the most
recent data from a neighbor it sends a PORT PFM Request message. For
each originator the router has stored information from, it will
include an option indicating the Full and Delta IDs of the last
message received from that originator. A router receiving the
Request compares the IDs of the specified originators with the latest
data it has for these originators. If it has a more recent full
update, it will first send it to the neighbor. Next, if it has more
recent delta updates, it will send all the delta updates in the order
they were received. This means that the requesting router receives
the messages in order. It will first get a full update if a more
recent version exists. The ID of this update may be much larger than
the previously seen ID. The first Delta update received, if any,
will have ID one if a Full update was received, or one larger than
the Delta ID in the request, if not. If multiple Delta updates are
received, the Delta ID will increment by one for each update. If the
router has stored information for any originators not included in the
request message, it will also send this information. It will first
send the stored Full update, and then the Delta updates. As
discussed above, the Delta updates MUST be sent in the order they
were received, first sending update one, then update two, and so
forth.
The Delta ID is an unsigned 16 bits value. It never wraps around. A
router MUST send a new full update if the Delta ID value is reaching
its maximum value. It is RECOMMENDED having a configurable limit for
how many Delta updates can be sent before sending a new Full update.
Sending Full updates often is in some ways wasteful, but it limits
how many deltas routers need to store, and they are also used to
remove information that no longer is needed.
When a router starts up, it is RECOMMENDED that before it originates
any messages, it sends a PORT PFM Request message to receive any
updates that neighbors may have stored for the originator address it
would use. It could simply not include an option with the originator
address it would use, and receive any information neighbors may have,
Venaas, et al. Expires September 12, 2019 [Page 4]
Internet-Draft PIM PORT PFM March 2019
or it could could include an option, but with the Full ID set to a
value smaller than the Full ID it would use for the next Full Update.
E.g., if the ID is based on the number of seconds since the epoch, it
could send a request based on the current time. It would then
normally get no updates from the neighbors with its own ID. If it
does, it is RECOMMENDED to log an error, and ensure that the Full IDs
of the next future Full Updates are larger than what was received.
In order to handle extra ordinary cases where a router has originated
messages with an erroneously large Full ID, it is RECOMMENDED that
implementations provides a way for an administrator to clear the
stored PFM state on a router, as well as a way to trigger sending of
a Full Update on an originator. This means that as a last resort, an
administrator could clear the state for an originator on all the
routers, and optionally afterwards trigger a full update by the
originator.
4. PFM over PORT message definitions
We define a new PORT message for sending a PFM message. This
consists of an update version and a new PORT option containing a PFM
message as defined in [RFC8364]. We also define a new PORT message
for requesting a PFM update from a neighbor. This contains the
latest update version that the router has from each originator and
requests the neighbor to transmit any information that it is missing.
4.1. PORT PFM Update
Venaas, et al. Expires September 12, 2019 [Page 5]
Internet-Draft PIM PORT PFM March 2019
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD1 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface |
| ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Full-update |
| +-------------------------------|
| ID | Delta-update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type is TBD.
Message Length: Length in bytes for the value part of the Type/
Length/Value encoding. If no PORT Options are included, the
length is 12. If n PORT Options with Option Value lengths L1, L2,
..., Ln are included, the message length is 12 + 4*n + L1 + L2 +
... + Ln.
Reserved: Set to zero on transmission and ignored on receipt.
Interface ID: This MUST be the Interface ID of the Interface ID
Hello Option contained in the PIM Hello messages that the PIM
router is sending to the PIM neighbor. It indicates to the PIM
neighbor what interface to associate the update with. This is
similar to how the Interface ID is used in [RFC6559]. The
Venaas, et al. Expires September 12, 2019 [Page 6]
Internet-Draft PIM PORT PFM March 2019
Interface ID allows us to do connection sharing while still
allowing the regular PFM RPF neighbor validation.
Full-update ID: If this is a full update, it is the ID of this
update. If this is a delta, then this is the ID of the last full
update. This is a 48 bit value.
Delta-update ID: If this is a delta update, this is the ID of the
delta. Note that the Full-update ID is also used for a delta. If
this is a full update, delta-update is set to 0. This is a 16 bit
value.
PORT Options: The general format is defined in [RFC6559] section
5.3. This message MUST contain exactly one PFM Update PORT
option. The PFM Update PORT option is defined below. It MAY
contain other options that are defined for use in a PORT PFM
Update message.
4.2. PORT PFM Request
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD2 | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ . \
/ . /
\ . \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type is TBD.
Venaas, et al. Expires September 12, 2019 [Page 7]
Internet-Draft PIM PORT PFM March 2019
Message Length: Length in bytes for the value part of the Type/
Length/Value encoding. If no PORT Options are included, the
length is 12. If n PORT Options with Option Value lengths L1, L2,
..., Ln are included, the message length is 12 + 4*n + L1 + L2 +
... + Ln.
Reserved: Set to zero on transmission and ignored on receipt.
PORT Options: The general format is defined in [RFC6559] section
5.3. This message MAY contain zero, one or multiple PFM Request
PORT options. The options indicate which versions the requesting
router has from which originators; one option per originator. No
options, means that the requesting router wants a full update for
all known originators. The PFM Request PORT option is defined
below. It MAY contain other options that are defined for use in a
PORT PFM Request message.
4.3. PORT PFM Update Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = TBD3 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PFM Message |
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type is TBD.
Option Value Length: The number of octets that make up the PFM
Message.
PFM Message: A PFM Message as defined in [RFC8364].
4.4. PORT PFM Request Option
Venaas, et al. Expires September 12, 2019 [Page 8]
Internet-Draft PIM PORT PFM March 2019
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT Option Type = TBD4 | Option Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Full-update |
| +-------------------------------|
| ID | Delta-update ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type is TBD.
Option Value Length: The length in octets of the originator address
plus 6.
Originator Address: The address of an originator as defined in
[RFC8364].
Full-update ID: The ID of the last full update that the router has
stored. It is requesting getting the most recent newer full
update, if any exists. Plus, any deltas after the last full
update.
Delta-update ID: The ID of the last delta update that the router
has stored. It is requesting getting the most recent newer full
update, using the Full-update ID, if it exists plus any deltas
after that. If there are no more recent full updates, then it is
requesting any delta updates more recent than this ID.
5. Security Considerations
To be completed. Largely similar to the considerations for PIM PORT.
One may use TCP/SCTP authentication mechanisms.
6. IANA considerations
To be completed. IANA would need to assign types for the messages
and options defined.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Venaas, et al. Expires September 12, 2019 [Page 9]
Internet-Draft PIM PORT PFM March 2019
[RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M.
Napierala, "A Reliable Transport Mechanism for PIM",
RFC 6559, DOI 10.17487/RFC6559, March 2012,
<https://www.rfc-editor.org/info/rfc6559>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM
Flooding Mechanism (PFM) and Source Discovery (SD)",
RFC 8364, DOI 10.17487/RFC8364, March 2018,
<https://www.rfc-editor.org/info/rfc8364>.
Authors' Addresses
Stig Venaas
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: stig@cisco.com
Balaji Ganesh
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: balagane@cisco.com
Kesavan Thiruvenkatasamy
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: kethiruv@cisco.com
Venaas, et al. Expires September 12, 2019 [Page 10]
Internet-Draft PIM PORT PFM March 2019
Ramakrishnan Chokkanathapuram
Cisco Systems, Inc.
Tasman Drive
San Jose CA 95134
USA
Email: ramaksun@cisco.com
Venaas, et al. Expires September 12, 2019 [Page 11]
