diff options
Diffstat (limited to 'doc/rfc/rfc7767.txt')
| -rw-r--r-- | doc/rfc/rfc7767.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7767.txt b/doc/rfc/rfc7767.txt new file mode 100644 index 0000000..97330f1 --- /dev/null +++ b/doc/rfc/rfc7767.txt @@ -0,0 +1,675 @@ + + + + + + +Independent Submission S. Vinapamula +Request for Comments: 7767 Juniper Networks +Category: Informational S. Sivakumar +ISSN: 2070-1721 Cisco Systems + M. Boucadair + Orange + T. Reddy + Cisco + February 2016 + + +Application-Initiated Check-Pointing via the Port Control Protocol (PCP) + +Abstract + + This document specifies a mechanism for a host to indicate via the + Port Control Protocol (PCP) which connections should be protected + against network failures. These connections will then be subject to + high-availability mechanisms enabled on the network side. + + This approach assumes that applications and/or users have more + visibility about sensitive connections than any heuristic that can be + enabled on the network side to guess which connections should be + check-pointed. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7767. + + + + + + + + + + + +Vinapamula, et al. Informational [Page 1] + +RFC 7767 HA through PCP February 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + (http://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. + +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 + + The risk of Internet service disruption is critical in service + providers and enterprise networking environments. Such a risk is + often mitigated with the introduction of active/backup systems. Such + designs not only contribute to minimize the risk of service + disruption, but also facilitate maintenance operations (e.g., hitless + hardware or software upgrades). + + In addition, the nature of some connections leads to the + establishment and the maintenance of connection-specific states by + some of the network functions invoked when the connection is + established. During active/backup failover in case of a network + failure, the said states need to be check-pointed by the backup + system. Additional issues are discussed in Section 2. + + + + + +Vinapamula, et al. Informational [Page 2] + +RFC 7767 HA through PCP February 2016 + + + Heuristics based on the protocol, mapping lifetime, etc., are used in + the network to elect which connections need to be check-pointed + (e.g., by means of high-availability (HA) techniques). This document + advocates for an application-initiated approach that would allow + applications and/or users to signal to the network which of their + connections are critical. + + Within this document, "check-pointing" refers to 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 will take over all the existing + established sessions that were check-pointed. This process is + transparent to internal hosts. + + This document 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 are provided for illustrative + purposes in Section 4. This document does not make any assumptions + about the PCP-controlled device that will process the PCP-formatted + signaling information from PCP clients. These devices are likely to + be flow aware. + + The approach in this document is aligned with the networking trends + advocating for open network APIs to interact with applications/ + services (e.g., [RFC7149]). For instance, the decision-making + process about policy on the network side will be enriched with + information provided by applications using PCP. + +1.1. Note + + The CHECKPOINT_REQUIRED PCP option (Section 3) is defined in the + "Specification Required" range (see Section 6). In order to be + assigned a code point in that range, a permanent publication is + required as per Section 4.1 of [RFC5226]. Publication of an RFC is + an ideal means of achieving this requirement and also to 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 despite positive feedback that was received from the + working group. Technical comments that were received during PCP + meetings and those received on 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]. + + + +Vinapamula, et al. Informational [Page 3] + +RFC 7767 HA through PCP February 2016 + + +2. Issues with the Existing Implementations + + Regardless of the selected technology or design like HA-based + designs, reliably securing connections is expensive in terms of + memory, CPU usage, and other resources. Also, check-pointing may not + be required for all connections, as all connections may not be + critical. But, this leaves a challenge to identify what connections + to check-point. + + Typically, this is addressed by identifying long-lived connections + and check-pointing the state of only those connections that lived + long enough, to the backup for service continuity. + + However, check-pointing long-lived connections raises the following + issues: + + 1. It is hard for a network to identify (or guess) which connection + is (business) critical. This characterization is often customer- + specific: a flow can be sensitive for a User #1, while it is not + for another User #2. Furthermore, this characterization can vary + over time: a flow can be sensitive during hour X, while it is not + during other times. + + 2. Heuristics are not deterministic. + + 3. A potentially long-lived connection may experience disruption + upon failure of the active system, but before it is check- + pointed. + + 4. A connection may not be long-lived but it may be critical, e.g., + for Voice over IP (VoIP) conversations. + + 5. Likewise, not all long-lived connections are deemed critical: for + example, connections that pertain to 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 based on the assumption that an application or user + is the best judge of which of its connections are critical. + + An application or user may explicitly identify the connections that + need to be check-pointed by means of a PCP client, using the + CHECKPOINT_REQUIRED option as described in Figure 1. + + + +Vinapamula, et al. Informational [Page 4] + +RFC 7767 HA through PCP February 2016 + + + 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 + + The description of the fields is as follows: + + o Option Code: 192 (see Section 6). + + o Reserved: This field is initialized as specified in Section 7.3 of + [RFC6887]. + + o Option Length: 0. This means no data is included in the option. + + An application or user can take advantage of this PCP option to + explicitly indicate which of the connections need to be check-pointed + and should not be disrupted. The processing of this option by the + PCP server will then yield the check-pointing of the corresponding + states by the relevant devices or functions dynamically controlled by + the PCP server. + + Communication between application/user and PCP client is + implementation specific. + +3.2. Operation + + Support of the CHECKPOINT_REQUIRED option by PCP servers and PCP + clients is optional. This option (Code 192; see Figure 1) may be + included in a PCP MAP or PEER request to indicate a connection is to + be protected against network failures. + + There is a risk that every PCP client may wish to check-point every + connection; this can potentially load the system. Administration + SHOULD restrict the number of connections that can be elected to be + + + +Vinapamula, et al. Informational [Page 5] + +RFC 7767 HA through PCP February 2016 + + + backed up and the rate of check-pointing per network attachment point + (e.g., Customer Premises Equipment (CPE), host). To that aim, the + PCP server should unambiguously identify the network attachment point + a PCP client belongs to. For example, the PCP server may rely on the + PCP identity [RFC7652], the assigned prefix to a CPE or host, the + subscriber-mask [PREFIX-BINDING], or other identification means. + + The PCP client includes a CHECKPOINT_REQUIRED option in a MAP or PEER + request to signal that the corresponding mapping is to be protected. + + If the PCP client does not receive a CHECKPOINT_REQUIRED option in + response to a PCP request that enclosed the CHECKPOINT_REQUIRED + option, this means that either the PCP server does not support the + option, or the PCP server is configured to ignore the option, or the + PCP server cannot satisfy the request expressed in this option (e.g., + because of a lack of resources). + + If the CHECKPOINT_REQUIRED option is not included in the PCP client + request, the PCP server MUST NOT include the CHECKPOINT_REQUIRED + option in the associated response. + + 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 or 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 or PEER request that does + not convey a CHECKPOINT_REQUIRED option). If check-pointing + resources are still available and the quota for this PCP client has + not been reached, the PCP server tags the corresponding entry as + eligible to the 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 or PEER renewal + request that includes a CHECKPOINT_REQUIRED option to indicate this + mapping has to be check-pointed or that doesn't include a + CHECKPOINT_REQUIRED option to indicate this mapping does not need be + check-pointed anymore. Upon receipt of the PCP request, the PCP + server proceeds with the same operations to validate a MAP or PEER + request to update an existing mapping. If validation checks are + 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 update request or it is cleared if no + CHECKPOINT_REQUIRED option was included), and the PCP server returns + the response to the PCP client accordingly. + + + + +Vinapamula, et al. Informational [Page 6] + +RFC 7767 HA through PCP February 2016 + + + What information to check-point and how to check-point are outside + the scope of this document and are left for implementations. Also, + the mechanism for users or applications to indicate check-pointing in + a PCP request may be automatic, semiautomatic, or require human + intervention. This behavior is also left for application + implementations. For managed CPEs, a service provider may influence + what connections are to be check-pointed. + + For honored requests, it is RECOMMENDED to check-point state on + backup before a response is sent to the PCP client. + +4. Sample Use Cases + + Below are provided some examples for illustrative purposes: + + Example 1: Consider a streaming service such as live TV + broadcasting, or any other media streaming, that supports check- + pointing signaling functionality. Suppose this application is + installed in three hosts A, B and C. For A, the application is + critical and should not be interrupted, while for B it is not. + While for C, only some programs are of interest. At the time of + installing this application's software, corresponding preferences + can be provisioned. 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 ensure that host doesn't exceed the user's limit. + + * For B, none of these flows are critical for check-pointing. + The CHECKPOINT_REQUIRED option is not included in the PCP + requests. + + * For C, the user is invited to interact with the application by + means of a configuration option that is provided to dynamically + select which streaming to check-point, based on the user's + interest. + + Example 2: Consider a streaming service offered by a provider. + Suppose three levels of subscriptions are offered by that + provider, e.g., gold, silver, and bronze. To guarantee a certain + level of quality of service for each subscription, policies are + configured such that: + + * All flows associated with a gold subscription should be check- + pointed. + + * Only some flows associated with a silver subscription are + check-pointed. + + + +Vinapamula, et al. Informational [Page 7] + +RFC 7767 HA through PCP February 2016 + + + * None of the flows associated with a bronze subscription are + check-pointed. + + When a user invokes the streaming service, he/she may fall into + one of those buckets, and according to the configured policy, his/ + her associated streaming flows are automatically check-pointed. + Login credentials can be used as a trigger to determine the + subscription level (and therefore the associated check-pointing + behavior). + + Example 3: Consider a VoIP application that is able to request that + its flows be check-pointed. No matter what is configured by the + user, some calls such as emergency calls should be check-pointed. + The application has to identify such calls. + + Example 4: In the context of an enterprise network, applications are + customized by the administrator. Instructions about whether a + CHECKPOINT_REQUIRED option is to be included are determined by the + administrator. Only the subset of applications identified by the + administrator will make use of this option in conformance with the + enterprise network's management policies. Any misbehavior can be + considered as abuse. + + In order to prevent every application from including a + CHECKPOINT_REQUIRED option in its PCP requests, the following items + are assumed: + + o Applications may be delivered with some default settings for + check-pointing, and these settings should be programmable by end + user. + + o Exposing and enforcing these settings is application specific. + + o The end user may customize these settings based on the + requirements. + +5. Security Considerations + + PCP-related security considerations are discussed in [RFC6887]. + + The CHECKPOINT_REQUIRED option can be used by an attacker to identify + critical flows; this is sensitive from a privacy standpoint. Also, + an attacker can cause critical flows to not be check-pointed by + stripping the CHECKPOINT_REQUIRED option or by consuming the quota by + adding the option to other flows. + + + + + + +Vinapamula, et al. Informational [Page 8] + +RFC 7767 HA through PCP February 2016 + + + These two issues can be 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 the PCP server is not secure, PCP authentication [RFC7652] + MUST be enabled. + + A network device can always override the end-user signaling, i.e., + what is signaled by the PCP client, if the instructions conflict with + the network policies. + +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. + + + +Vinapamula, et al. Informational [Page 9] + +RFC 7767 HA through PCP February 2016 + + + [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>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vinapamula, et al. Informational [Page 10] + +RFC 7767 HA through PCP February 2016 + + +Appendix A. Additional Considerations + + It was tempting to include additional fields in the option but this + would lead to a more complex design that is not justified. For + example, we considered the following. + + o 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 application may systematically choose to set the + priority level to the highest value so that it increases its + chance to be serviced! + + o Return a more granular failure error code to the requesting PCP + client. However, this would require extra processing at both the + PCP client and server sides for handling the various error codes + without any guarantee that the PCP client would have its mappings + check-pointed. + +Acknowledgments + + Thanks to Reinaldo Penno, Stuart Cheshire, Dave Thaler, Prashanth + Patil, and Christian Jacquenet for their comments. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Vinapamula, et al. Informational [Page 11] + +RFC 7767 HA through PCP February 2016 + + +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 + + + + + + + + + + + + + +Vinapamula, et al. Informational [Page 12] + |