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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Option Code=TBA|  Reserved     |        Option Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Option Name: CHECKPOINT_REQUIRED
         Number: <TBA>
         Purpose:  Indicate if an entry needs to be check pointed.
         Valid for Opcodes: MAP, PEER
         Length: 0.
         May appear in: request, response.
         Maximum occurrences: 1.
        

Figure 1: CHECKPOINT_REQUIRED PCP Option

The description of the fields is as follows:

• Option Code: To be assigned by IANA.
• Reserved: This field is initialized as specified in Section 7.3 of [RFC6887].
• Option Length: 0. This means no data is included in the option.

It was tempting to include additional fields in the option but this would lead to a more complex design that is not justified, e.g.,:

• Define a dedicated field to indicate a priority level. This priority is intended to be used by the PCP server as a hint when processing a request with a CHECKPOINT_REQUIRED option. Nevertheless, an applications may systematically choose to set the priority level to the highest value so that it increases its chance to be serviced!
• Return a more granular failure error code to the requesting PCP client. Nevertheless this would require extra processing at both the PCP client and server sides for handling the various error codes without any guarantee for the PCP client to have its mappings check-pointed.

An application or user can use this option to indicate that one or more of its connections are critical and disruption is not desired. Doing so will trigger check-pointing of state to the backup.

Communication between application/user and PCP client is implementation-specific.

3.2. Behavior

Support for the CHECKPOINT_REQUIRED option by PCP servers and PCP clients is optional. This option (Code TBA; see Figure 1) MAY be included in a PCP MAP/PEER request to indicate a connection is to be protected against network failures.

The PCP client includes a CHECKPOINT_REQUIRED option in a MAP or PEER request to signal that the corresponding mapping is to be protected.

A PCP server MAY ignore the CHECKPOINT_REQUIRED option sent to it by a PCP client (e.g., if it does not support the option or if it is configured to ignore it). To signal that it has not accepted the option, a PCP server simply does not include the CHECKPOINT_REQUIRED option in the response. If the PCP client does not receive a CHECKPOINT_REQUIRED option in a response to a request enclosing a CHECKPOINT_REQUIRED option, this means the PCP server does not support the option or it is configured to ignore it.

If the CHECKPOINT_REQUIRED option is not included in the PCP client request, the PCP server does not include the CHECKPOINT_REQUIRED option in the associated response. This is mainly because there are not valid motivation that would justify a PCP server notify a PCP client about it reliability decision.

When the PCP server receives a CHECKPOINT_REQUIRED option, the PCP server checks if it can honor this request depending on whether resources are available for check-pointing. If there are no resources available for check-pointing, but there are resources available to honor the MAP/PEER request, a response is sent back to the PCP client without including the CHECKPOINT_REQUIRED option (i.e., the request is processed as any MAP/PEER request that does not convey a CHECKPOINT_REQUIRED option). If check-pointing resources are still available and the quota for this PCP client is not reached, the PCP server tags the corresponding entry as eligible to HA mechanism and sends back the CHECKPOINT_REQUIRED option in the positive answer to the PCP client.

To update the check-pointing behavior of a mapping maintained by the PCP server, the PCP client generates a PCP MAP/PEER renewal request that includes a CHECKPOINT_REQUIRED option to indicate this mapping has to be check-pointed or without including a CHECKPOINT_REQUIRED option to indicate this mapping need not be check-pointed anymore. Upon receipt of the PCP request, the PCP server proceeds to the same operations to validate a MAP/PEER request refreshing an existing mapping. If validation checks are successfully passed, the PCP server updates the check-point flag associated with that mapping accordingly (i.e., it is set if a CHECKPOINT_REQUIRED option was included in the refresh request or it is cleared if no CHECKPOINT_REQUIRED option was included) , and the PCP server returns the response to the PCP client accordingly.

What information to checkpoint and how to checkpoint is out of scope of this document, and is left for implementations. Also, interest to indicate check-pointing by users/applications in a PCP request, may be automatic, semi-automatic, or human intervened. This behavior is also left for application implementations.

It is RECOMMENDED to checkpoint state on backup for honored requests before a response is sent to the PCP client.

4. Typical Usage Examples

Below are provided some examples for illustration purposes:

1. Disruption in a VoIP connection is not desired: Application that is initiating a VoIP connection can include CHECKPOINT_REQUIRED option in its associated MAP/PEER message(s) to indicate to the server that the corresponding entry must be protected against failure.
2. Similarly disruption in media streaming is not desired: A user hosting a media service, uses CHECKPOINT_REQUIRED option while initiating a mapping request, and may mark connection associated with that mapping, depending on whether the connection is from a paid subscriber or from a free subscriber through a PEER request. So check-pointing mapping doesn't result in auto check-pointing of connections, as it gives flexibility to the end user to pick specific connections only to checkpoint.

5. Signaling HA for other Network Functions

In conjunction with NAT, other network functions that may maintain state for each connection such as stateful firewall may register to PCP server, and may be triggered for check-pointing respective state of that connection.

6. Security Considerations

PCP-related security considerations are discussed in [RFC6887].

CHECKPOINT_REQUIRED option can be used by an attacker to identify critical flows. This issue is mitigated if the network on which the PCP messages are to be sent is fully trusted. Means to defend against attackers who can intercept packets between the PCP server and the PCP client should be enabled. In some deployments, access control lists (ACLs) can be installed on the PCP client, PCP server, and the network between them, so those ACLs allow only communications between trusted PCP elements. If the networking environment between the PCP client and PCP server is not secure, means to protect exposing the content of PCP messages (e.g., DTLS [RFC6347]) are recommended.

A network device can always override the end-user signalling, i.e., what is signaled by the PCP client, if the instructions are conflicting with the network policies.

There is a risk that every PCP client may wish to checkpoint every connection, which can potentially load the system. Administration SHOULD restrict the number of connections that can be elected to be backuped and the rate of check-pointing on per PCP client.

7. IANA Considerations

The following PCP Option Code is to be allocated in the optional-to- process range (the registry is maintained in http://www.iana.org/ assignments/pcp-parameters):

• CHECKPOINT_REQUIRED set to TBA (see Section 3.1)

8. Acknowledgements

Thanks to Reinaldo Penno, Stuart Shechire, and Dave Thaler for their comments.

9. References

9.1. Normative references

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6887]	Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.

9.2. Informative References

[RFC6347]

Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.

Authors' Addresses