doc: Add RFC documents

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]
+