RFC 7767

Application-Initiated Check-Pointing via the Port Control Protocol (PCP)

📅 published February 2016, from ietf

RFC 7767: Application-Initiated Check-Pointing via the Port Control Protocol (PCP) ✨

okay bestie, this one is giving PCP glow-up 🦋 It's from February 2016 and it's an Informational doc that came in as an Independent Submission (ISSN 2070-1721). The authors are S. Vinapamula (Juniper Networks), S. Sivakumar (Cisco Systems), M. Boucadair (Orange), and T. Reddy (Cisco) 🫶 Its title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract 💜

okay so this doc explains how a host can tell the network, through PCP, which connections are important enough to protect when something breaks 🛡️ Those connections then get high-availability stuff turned on by the network side. The core idea is that apps and users know way more about their sensitive connections than any heuristic the network could ever guess 🔥

Status of This Memo 🌈

tl;dr this is not an Internet Standards Track spec 🙅‍♀️ It's just published for information. It's a contribution to the RFC Series, and the RFC Editor picked it for publication but isn't saying it's good for implementing or deploying. Docs the RFC Editor approves aren't candidates for any level of Internet Standard, and you can see Section 2 of RFC 5741 for that. For the current status, errata, and feedback info, check http://www.rfc-editor.org/info/rfc7767 🍓

Copyright Notice 🫶

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved ✨ This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc 📜

Table of Contents 📚

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Note  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Issues with the Existing Implementations  . . . . . . . . . .   4
   3.  CHECKPOINT_REQUIRED PCP Option  . . . . . . . . . . . . . . .   4
     3.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Operation . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Sample Use Cases  . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Additional Considerations  . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

Losing Internet service is a huge deal for service providers and enterprise networks 😭 Teams usually cut that risk by setting up active/backup systems. Those setups don't just minimize the risk of service disruption, they also make maintenance easier, like hitless hardware or software upgrades (e.g., hitless hardware or software upgrades).

Also, some connections set up and keep connection-specific states inside some of the network functions that get invoked when the connection is established. During active/backup failover caused by a network failure, those states need to be check-pointed by the backup system. More issues are covered in Section 2 🧚

Heuristics based on the protocol, mapping lifetime, etc., are used in the network to pick which connections need to be check-pointed (e.g., by means of high-availability (HA) techniques). This doc pushes for an application-initiated approach, so apps and/or users can signal to the network which of their connections are critical 💖

In this document, "check-pointing" means a process of state replication and synchronization between active and backup PCP-controlled devices. When the active PCP-controlled device fails, the backup PCP-controlled device takes over all the existing established sessions that were check-pointed. This process is transparent to internal hosts 🦋

This doc specifies how PCP [RFC6887] can be extended to indicate which connection should be check-pointed for high availability (Section 3). A set of use cases is provided for illustrative purposes in Section 4. This doc doesn't make any assumptions about the PCP-controlled device that processes the PCP-formatted signaling information from PCP clients. These devices are likely to be flow aware 👀

The approach here lines up with networking trends pushing for open network APIs to interact with applications/services (e.g., [RFC7149]). For instance, the decision-making process about policy on the network side gets enriched with information that applications provide using PCP 🌸

1.1. Note 🎀

The CHECKPOINT_REQUIRED PCP option (Section 3) is defined in the "Specification Required" range (see Section 6). To get a code point in that range, a permanent publication is required as per Section 4.1 of [RFC5226]. Publishing an RFC is the ideal way to meet this and also ease interoperability 💅

Note, this work was presented to the Port Control Protocol (PCP) WG, but there was no consensus to define this option in the "Standards Action" range, even though the working group gave positive feedback. Technical comments from PCP meetings and the mailing list were addressed 🙌

1.2. Requirements Language 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🤓

2. Issues with the Existing Implementations 💅

Whatever the tech or design (HA-based designs included), reliably securing connections is expensive in terms of memory, CPU usage, and other resources 💸 Also, check-pointing may not be required for every connection, since not all connections are critical. But that leaves a challenge: figuring out which connections to check-point 🤔

Typically, this gets solved by spotting long-lived connections and check-pointing only the state of those that lived long enough, to the backup for service continuity 🫶

But check-pointing long-lived connections raises these issues:

It's hard for a network to identify (or guess) which connection is (business) critical. This is often customer-specific: a flow can be sensitive for User #1 while it isn't for User #2. And it can change over time, too: a flow can be sensitive during hour X but not during other times ⏰
Heuristics are not deterministic 🎲
A potentially long-lived connection may experience disruption upon failure of the active system, but before it is check-pointed 😬
A connection may not be long-lived but still be critical, e.g., for Voice over IP (VoIP) conversations 📞
Likewise, not all long-lived connections are critical. For example, connections for free Internet services are usually considered not critical compared to the equivalent connections for paid services. Only the latter need to be check-pointed 💜

3. CHECKPOINT_REQUIRED PCP Option 🧚

3.1. Format 🍓

The solution is built on the assumption that an application or user is the best judge of which of its connections are critical 👑

An application or user can explicitly identify the connections that need to be check-pointed by means of a PCP client, using the CHECKPOINT_REQUIRED option shown in Figure 1 ✨

The entry to be backed up is indicated by the content of a MAP or PEER message.

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

            Option Name: CHECKPOINT_REQUIRED
            Number: 192
            Purpose:  Indicate if an entry needs to be check-pointed.
            Valid for Opcodes: MAP, PEER
            Length: 0.
            May appear in: Request and response.
            Maximum occurrences: 1.

                 Figure 1: CHECKPOINT_REQUIRED PCP Option

Here's the field breakdown 🎀

Option Code: 192 (see Section 6).
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.

An application or user can use this PCP option to explicitly flag which connections need to be check-pointed and should not be disrupted 🛟 Once the PCP server processes this option, it yields the check-pointing of the corresponding states by the relevant devices or functions that the PCP server dynamically controls 🔥

Communication between the application/user and the PCP client is implementation specific 🦋

3.2. Operation ✨

okay so supporting the CHECKPOINT_REQUIRED option is optional for both PCP servers and PCP clients 🎀. This option (Code 192; see Figure 1) can be tossed into a MAP or PEER request to say "hey, protect this connection from network failures" 🛡️.

ngl, there's a real risk here. Every PCP client could decide it wants every single connection checkpointed, and that could seriously overload the system 😭. So admins SHOULD restrict how many connections can be picked for backup, and how fast checkpointing happens, per network attachment point (like a Customer Premises Equipment (CPE) or a host) 💅. To make that work, the PCP server needs to clearly identify which network attachment point a PCP client belongs to. The server might use the PCP identity [RFC7652], the prefix assigned to a CPE or host, the subscriber-mask [PREFIX-BINDING], or some other identification method 🔍.

The PCP client adds a CHECKPOINT_REQUIRED option to a MAP or PEER request to signal that the mapping needs to be protected 🫶.

Now here's the tricky part 🙈. If the PCP client sends a CHECKPOINT_REQUIRED option but gets no CHECKPOINT_REQUIRED option back, that could mean one of three things. Either the PCP server doesn't support the option, or the PCP server is configured to ignore it, or the PCP server simply can't do it (for example, it's out of resources) 🤷‍♀️.

If the CHECKPOINT_REQUIRED option is not in the PCP client's request, the PCP server MUST NOT include the CHECKPOINT_REQUIRED option in the associated response. No sneaking it in, bestie 🚫.

When the PCP server gets a CHECKPOINT_REQUIRED option, it checks whether it can actually honor the request, based on whether there are resources available for checkpointing 🧐. If there are no checkpointing resources left, but there are still resources to handle the MAP or PEER request itself, the server sends a response without the CHECKPOINT_REQUIRED option. The request just gets processed like any normal MAP or PEER request that doesn't carry that option 🌸. If checkpointing resources are still free and this PCP client hasn't hit its quota yet, the PCP server tags the entry as eligible for the HA mechanism and sends back the CHECKPOINT_REQUIRED option in the positive answer 🎉.

Want to change the checkpointing status of a mapping that already exists? The PCP client sends a PCP MAP or PEER renewal request. If it includes a CHECKPOINT_REQUIRED option, the mapping should be checkpointed. If it leaves the option out, the mapping doesn't need to be checkpointed anymore 🔄. The PCP server handles this renewal the same way it validates any MAP or PEER request that updates an existing mapping. If the validation checks pass, the server updates the checkpoint flag for that mapping to match the request. The flag is set if the update included a CHECKPOINT_REQUIRED option, and cleared if it didn't. Then the server sends the response back to the PCP client accordingly 💖.

What information gets checkpointed, and how it gets done, is outside the scope of this document and left up to implementations 🧠. Same goes for how users or applications ask for checkpointing in a PCP request. That could be automatic, semiautomatic, or need a human to click something, and it's also left up to application implementations 💅. For managed CPEs, a service provider may influence which connections get checkpointed 👑.

For honored requests, it is RECOMMENDED to checkpoint state on backup before a response is sent to the PCP client ✨. Very responsible of us 🥹.

4. Sample Use Cases 🌈

Here are some examples, just for illustration purposes 🍓:

Example 1: Picture a streaming service like live TV broadcasting, or any other media streaming, that supports checkpoint signaling 📺. Say this app is installed on three hosts: A, B, and C. For A, the app is critical and should not be interrupted. For B, it's not. For C, only some programs are of interest. When the app is installed, the matching preferences can be set up 🎀. Then, when the application starts streaming:

All the flows associated with the streaming application are critical for A. Limiting the number of flows to be backed up will make sure that host doesn't go over the user's limit 🙅‍♀️.
For B, none of these flows are critical for checkpointing. The CHECKPOINT_REQUIRED option is not included in the PCP requests 💤.
For C, the user gets invited to interact with the app through a configuration option. It lets them dynamically pick which streams get checkpointed, based on what they're into 🦋.

Example 2: Now picture a provider offering a streaming service with three subscription levels: gold, silver, and bronze 🥇🥈🥉. To guarantee a certain quality of service for each tier, policies are set up like this:

All flows associated with a gold subscription should be checkpointed 👑.
Only some flows associated with a silver subscription are checkpointed ✨.
None of the flows associated with a bronze subscription are checkpointed 🫠.

When a user opens the streaming service, they land in one of these buckets. Under the configured policy, their streaming flows get checkpointed automatically, based on their tier 💅. Login credentials can act as the trigger that figures out the subscription level, and therefore the checkpointing behavior 🔑.

Example 3: Consider a VoIP app that can ask for its flows to be checkpointed 📞. No matter what the user has configured, some calls, like emergency calls, should be checkpointed 🚨. The app has to be able to identify those calls 🫶.

Example 4: In an enterprise network, applications are customized by the administrator 🏢. The administrator decides whether a CHECKPOINT_REQUIRED option gets included. Only the subset of applications the administrator identifies will use this option, following the enterprise network's management policies 📋. Any misbehavior here can be considered abuse 🙈.

To keep every application from slapping a CHECKPOINT_REQUIRED option on all its PCP requests, the following items are assumed:

Applications may come with some default checkpointing settings, and end users should be able to program those settings 🛠️.
Exposing and enforcing these settings is application specific 🧩.
The end user may customize these settings based on their requirements 💜.

5. Security Considerations 🔐

PCP-related security considerations are discussed in [RFC6887]. Go read that one too 📖.

Okay, the big deal here: the CHECKPOINT_REQUIRED option can be used by an attacker to identify critical flows, and that's a serious privacy problem 😱. An attacker can also make critical flows not get checkpointed in two ways. They can strip the CHECKPOINT_REQUIRED option, or they can use up the quota by adding the option to other flows 💀.

Both of these issues can be mitigated if the network carrying the PCP messages is fully trusted 🛡️. Defenses against attackers who can intercept packets between the PCP server and the PCP client should be enabled too 🚧. In some deployments, access control lists (ACLs) can be installed on the PCP client, the PCP server, and the network between them, so they only allow communication between trusted PCP elements 🔒. If the networking environment between the PCP client and the PCP server is not secure, PCP authentication [RFC7652] MUST be enabled. No exceptions, periodt 🚨.

A network device can always override the end-user signaling, meaning whatever the PCP client signaled, if the instructions conflict with the network policies. The network wins, bestie 👑.

6. IANA Considerations 📚

The following PCP Option Code has been allocated in the "Specification Required" range of the "PCP Options" registry (http://www.iana.org/assignments/pcp-parameters) 🎟️:

192 CHECKPOINT_REQUIRED (see Section 3.1)

7. References 📖

7.1. 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,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
           P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
           DOI 10.17487/RFC6887, April 2013,
           <http://www.rfc-editor.org/info/rfc6887>.

[RFC7652]  Cullen, M., Hartman, S., Zhang, D., and T. Reddy, "Port
           Control Protocol (PCP) Authentication Mechanism",
           RFC 7652, DOI 10.17487/RFC7652, September 2015,
           <http://www.rfc-editor.org/info/rfc7652>.

7.2. Informative References 🌷

[PREFIX-BINDING]
           Vinapamula, S. and M. Boucadair, "Recommendations for
           Prefix Binding in the Softwire DS-Lite Context", Work in
           Progress, draft-vinapamula-softwire-dslite-prefix-
           binding-12, October 2015.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           DOI 10.17487/RFC5226, May 2008,
           <http://www.rfc-editor.org/info/rfc5226>.

[RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
           Networking: A Perspective from within a Service Provider
           Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014,
           <http://www.rfc-editor.org/info/rfc7149>.

Appendix A. Additional Considerations 🧁

It was tempting to add more fields to the option, but that would make the design more complex without enough justification 🤏. For example, these were considered:

Defining a dedicated field to indicate a priority level. The PCP server would use this priority as a hint when processing a request with a CHECKPOINT_REQUIRED option. But an application could systematically set the priority to the highest value so it boosts its chances of being serviced. Sneaky 😏!
Returning a more granular failure error code to the requesting PCP client. However, this would need extra processing on both the PCP client and server sides to handle the various error codes, with no guarantee that the PCP client would get its mappings checkpointed 😩.

Acknowledgments 🫶

Thanks to Reinaldo Penno, Stuart Cheshire, Dave Thaler, Prashanth Patil, and Christian Jacquenet for their comments 💜.

Authors' Addresses 🎀

Suresh Vinapamula
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
United States

Phone: +1 408 936 5441
Email: sureshk@juniper.net

Senthil Sivakumar
Cisco Systems
7100-8 Kit Creek Road
Research Triangle Park, NC  27760
United States

Phone: +1 919 392 5158
Email: ssenthil@cisco.com

Mohamed Boucadair
Orange
Rennes  35000
France

Email: mohamed.boucadair@orange.com

Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: tireddy@cisco.com

📦 where this page comes from

ietf: rfc7767 2016-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms