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

Document Type RFC - Informational (February 2016; No errata)
Was draft-vinapamula-flow-ha (individual)
Last updated 2016-02-08
Stream ISE
Formats plain text pdf html bibtex
IETF conflict review conflict-review-vinapamula-flow-ha
Stream ISE state Published RFC
Consensus Boilerplate Unknown
Document shepherd Nevil Brownlee
Shepherd write-up Show (last changed 2015-10-18)
IESG IESG state RFC 7767 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack
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
Show full document text