Internet DRAFT - draft-holmberg-sipcore-rkeep

draft-holmberg-sipcore-rkeep






SIPCORE Working Group                                        C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                              O. Gallego
Expires: June 19, 2015                                          Vodafone
                                                       December 16, 2014


              Indication of support for reverse keep-alive
                  draft-holmberg-sipcore-rkeep-05.txt

Abstract

   This specification defines a new Session Initiation Protocol (SIP)
   Via header field parameter, "rkeep".  The "rkeep" parameter allows a
   SIP entity to indicate willingness to receive keep-alives from its
   adjacent downstream SIP entity, the adjacent downstream SIP entity to
   indicate willingness to send keep-alives, and for SIP entities
   willing to send keep-alives to inform the receiver about the keep-
   alive interval.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 19, 2015.

Copyright Notice

   Copyright (c) 2014 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.  Code Components extracted from this document must



Holmberg & Gallego        Expires June 19, 2015                 [Page 1]

Internet-Draft             reverse keep-alive              December 2014


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Use-case: UA not able to send keep-alives due to sleep
           mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  User Agent and Proxy behavior . . . . . . . . . . . . . . . .   4
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Lifetime of keep-alives . . . . . . . . . . . . . . . . .   4
     5.3.  Behavior of a SIP entity willing to receive keep-alives .   4
     5.4.  Behavior of a SIP entity willing to send keep-alives  . .   5
   6.  Keep-alive interval . . . . . . . . . . . . . . . . . . . . .   7
   7.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  'rkeep' Via header field parameter  . . . . . . . . . . .   9
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   12. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     13.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   RFC 6223 [RFC6223] defines a mechanism, which allows adjacent SIP
   entities to explicitly negotiate usage of the NAT keep-alive
   mechanisms defined in SIP Outbound [RFC5626].  The "keep" parameter
   [RFC6223] allows SIP entities, when sending a request, to indicate
   willingness to send keep-alives, and it allows SIP entities, when
   sending a response, indicate willingness to receive keep-alives.

   In some cases a SIP device, located behind a NAT, is not able to send
   keep-alives.  One reason can be that the scheduling policy of the
   operating system used by the SIP device does not meet the requirement
   for sending keep-alives using a proper interval, meaning that NAT
   bindings might not be kept.  In such cases, the device needs to
   request another device to send keep-alives towards the itself.  Then,




Holmberg & Gallego        Expires June 19, 2015                 [Page 2]

Internet-Draft             reverse keep-alive              December 2014


   the keep-alive response message sent from the SIP device will ensure
   that the NAT binding is kept open.

   This specification defines a new Session Initiation Protocol (SIP)
   Via header field parameter [RFC3261], "rkeep".  The "rkeep" parameter
   allows a SIP entity to indicate willingness to receive keep-alives
   from its adjacent downstream SIP entity, the adjacent downstream SIP
   entity to indicate willingness to send keep-alives, and for SIP
   entities willing to send keep-alives to inform the receiver about the
   keep-alive interval.

   The following sections describe use-cases where a mechanism to
   explicitly negotiate usage of keep-alives is needed.

1.1.  Use-case: UA not able to send keep-alives due to sleep mode

2.  Applicability

   The mechanism defined in this specification MUST only be used by SIP
   entities that are not able, e.g. because the scheduling policy of the
   operating system used by the SIP device does not meet the requirement
   for sending keep-alives using a proper interval.

3.  Conventions

   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 BCP 14, RFC 2119
   [RFC2119].

4.  Definitions

   Keep-alives: The keep-alive messages defined in RFC 5626.

   "rkeep" parameter: A SIP Via header field parameter that a SIP entity
   can insert in the topmost Via header field that it adds to the
   request, to explicitly indicate willingness to receive keep-alives
   from its adjacent downstream SIP entity.  A SIP entity can add a
   parameter value to the "rkeep" parameter, or remove an existing
   parameter value, in a response to explicitly indicate willingness to
   send keep-alives to its adjacent upstream SIP entity.

   SIP entity: SIP User Agent (UA), or proxy, as defined in RFC 3261.

   Adjacent downstream SIP entity: The adjacent SIP entity in the
   direction towards which a SIP request is sent.





Holmberg & Gallego        Expires June 19, 2015                 [Page 3]

Internet-Draft             reverse keep-alive              December 2014


   Adjacent upstream SIP entity: The adjacent SIP entity in the
   direction from which a SIP request is received.

5.  User Agent and Proxy behavior

5.1.  General

   This section describes how SIP UAs and proxies negotiate usage of
   keep-alives associated with a registration, or a dialog, which types
   of SIP requests can be used in order to negotiate the usage, and the
   lifetime of the negotiated keep-alives.

   SIP entities indicate willingness to receive keep-alives from the
   adjacent downstream SIP entity using SIP requests.  The associated
   responses are used by SIP entities to indicate willingness to send
   keep-alives.  Both SIP entities can indicate a recommended keep-alive
   interval.

   The procedures to negotiate usage of keep-alives are identical for
   SIP UAs and proxies.

   NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
   entity has indicated willingness to receive keep-alives from an
   adjacent SIP entity, sending of keep-alives towards that adjacent SIP
   entity needs to be separately negotiated.

5.2.  Lifetime of keep-alives

   The lifetime of negotiated keep-alives depends on whether the keep-
   alives are associated with a registration or a dialog.  The rules
   defined in RFC 6223 [RFC6223] also apply when keep-alives are
   negotiated using the 'rkeep' Via header field parameter.

5.3.  Behavior of a SIP entity willing to receive keep-alives

   As defined in RFC 5626, a SIP entity that supports receiving of keep-
   alives must act as a STUN server [RFC5389].  The SIP entity must
   support those aspects of STUN that are required in order to apply the
   STUN keep-alive mechanism defined in RFC 5626, and it must support
   the CRLF keep-alive mechanism defined in RFC 5626.

   When a SIP entity sends or forwards a request, if it wants to
   negotiate the receiving of keep-alives associated with a
   registration, or a dialog, it MUST insert a "rkeep" parameter in the
   topmost Via header field that it adds to the request, to indicate
   willingness to receive keep-alives.  The SIP entity MAY add a
   parameter value to the "rkeep" parameter before sending or forwarding
   the request.  The parameter value, if present and with a value other



Holmberg & Gallego        Expires June 19, 2015                 [Page 4]

Internet-Draft             reverse keep-alive              December 2014


   than zero, represents a recommended keep-alive interval, given in
   seconds.

   When the SIP entity receives the associated response, if the "rkeep"
   parameter in the topmost Via header field of the response contains a
   "rkeep" parameter value with a non-zero value, or a value which is
   different from the value sent in the request (counting a "rkeep"
   parameter without a value) it MUST be prepared to start receiving
   keep-alives from the same destination from where it received the
   response which was used to negotiate the receiving of keep-alives.
   If the "rkeep" parameter does not contain a value, the SIP entity
   MUST assume that keep-alives will be sent using the recommended keep-
   alive interval, if any, that the SIP entity added to the associated
   request.

   If the associated response contains the same "rkeep" parameter value
   as the request (counting a "rkeep" parameter without a value), the
   SIP entity MUST assume that keep-alives will not be sent.

   Once a SIP entity has negotiated receiving of keep-alives associated
   with a dialog towards an adjacent SIP entity, it MUST NOT insert a
   "rkeep" parameter in any subsequent SIP requests, associated with the
   dialog, towards that adjacent SIP entity.  Such "rkeep" parameter
   MUST be ignored, if received.

   Since an ACK request does not have an associated response, it can not
   be used to negotiate usage of keep-alives.  Therefore, a SIP entity
   MUST NOT insert a "rkeep" parameter in the topmost Via header field
   of an ACK request.  Such "rkeep" parameter MUST be ignored, if
   received.

   A SIP entity MUST NOT indicates willingness to receive keep-alives
   associated with a dialog, unless it has also inserted itself in the
   dialog route set [RFC3261].

   If an INVITE request is used to indicate willingness to receive keep-
   alives, as long as at least one response (provisional or final) to
   the INVITE request contains a "rkeep" parameter with a parameter
   value which is different from the value in the request (counting a
   "rkeep" parameter without a value) it is seen as an indication that
   the adjacent downstream SIP entity is willing to send keep-alives
   associated with the dialog on which the response is received.

5.4.  Behavior of a SIP entity willing to send keep-alives

   As defined in RFC 5626, a SIP entity that supports sending of keep-
   alives must act as a Session Traversal Utilities for NAT (STUN)
   client [RFC5389].  The SIP entity must support those aspects of STUN



Holmberg & Gallego        Expires June 19, 2015                 [Page 5]

Internet-Draft             reverse keep-alive              December 2014


   that are required in order to apply the STUN keep-alive mechanism
   defined in RFC 5626, and it must support the CRLF keep-alive
   mechanism defined in RFC 5626.  RFC 5626 defines when to use STUN,
   respectively double-CRLF, for keep-alives.

   When a SIP entity sends or forwards a response, and the adjacent
   upstream SIP entity indicated willingness to receive keep-alives
   without a recommended keep-alive interval, if the SIP entity is
   willing to send keep-alives associated with the registration, or the
   dialog, to the adjacent upstream SIP entity it MUST add a parameter
   value to the "rkeep" parameter, before sending or forwarding the
   response.  The parameter value, represents the keep-alive interval,
   given in seconds, that the sender of the keep-alives will use.

   If the adjacent upstream SIP entity provided a recommended keep-alive
   interval, and if the SIP entity is willing to send keep-alives using
   that interval, it MUST remove the "rkeep" parameter value which
   indicates the recommended keep-alive interval, before sending or
   forwarding the response.

   NOTE: The reason for removing the "rkeep" parameter value is to
   indicate that the SIP entity supports the mechanism, and simply does
   not forward an unknown parameter.

   If the adjacent upstream SIP entity provided a recommended keep-alive
   interval, and if the SIP entity is willing to send keep-alives using
   a different interval, it MUST modify the "rkeep" parameter value
   which indicates the recommended keep-alive interval, before sending
   or forwarding the response.

   There might be multiple responses to an INVITE request.  When a SIP
   entity indicates willingness to send keep-alives in a response to an
   INVITE request, it MUST add a parameter value to the "rkeep"
   parameter in at least one reliable response to the request.  The SIP
   entity MAY add identical parameter values to the "rkeep" parameters
   in other responses to the same request.  The SIP entity MUST NOT add
   different parameter value to the "rkeep" parameters in responses to
   the same request.  The SIP entity SHOULD indicate the willingness to
   send keep-alives as soon as possible.

   In case an INVITE request is forked [RFC3261], there might be
   responses associated with multiple early dialogs [RFC5389].  When a
   SIP entity indicates willingness to send keep-alives, it MUST add a
   parameter in at least one reliable response per early dialog.  Once
   an early dialog is terminated (e.g. when a 200 OK final response
   associated with anohter early dialog is received) the SIP entity MUST
   cease sending keep-alives negotiated for the terminated early dialog.




Holmberg & Gallego        Expires June 19, 2015                 [Page 6]

Internet-Draft             reverse keep-alive              December 2014


   A SIP entity MUST NOT indicates willingness to send keep-alives
   associated with a dialog, unless it has also inserted itself in the
   dialog route set [RFC3261].

   When the SIP entity has indicated willingness to send keep-alives, it
   MUST start sending keep-alives towards the same destination where it
   sent the response used to indicate willingness to send keep-alives.

6.  Keep-alive interval

   If a SIP entity sends a SIP response, where the topmost Via header
   field contains a "rkeep" parameter with a non-zero value that
   indicates the keep-alive interval, given in seconds, it MUST use the
   procedures defined for the Flow-Timer header field [RFC5626].
   According to the procedures, the SIP entity must send keep-alives at
   least as often as the indicated keep-alive interval, and if the SIP
   entity uses the indicated keep-alive interval then it should send its
   keep-alives so that the interval between each keep-alive is randomly
   distributed between 80% and 100% of the indicated keep-alive
   interval.

   This specification does not define any semantic for a "rkeep" Via
   header parameter value with a zero value.  A SIP entity MUST NOT
   insert a zero value to a "rkeep" parameter.  A SIP entity that
   receives a "rkeep" parameter with a zero value SHOULD NOT assume that
   the sender of the response will send keep-alives towards the SIP
   entity.

   This specification does not specify actions to take if negotiated
   keep-alives are not received.  As defined in RFC 5626, the receiving
   SIP entity may consider a connection to be dead in such situations.

   NOTE: The Flow-Timer header field [RFC5626] has no impact on keep-
   alives negotiated using the "rkeep" Via header field parameter.

7.  Example















Holmberg & Gallego        Expires June 19, 2015                 [Page 7]

Internet-Draft             reverse keep-alive              December 2014


     Alice                        P1                      REGISTRAR
       |                          |                           |
       |--- REGISTER------------->|                           |
       |    Via: Alice;rkeep      |                           |
       |                          |--- REGISTER-------------->|
       |                          |    Via: P1                |
       |                          |    Via: Alice;rkeep       |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: P1                |
       |                          |    Via: Alice;rkeep       |
       |<-- 200 OK ---------------|                           |
       |    Via: Alice;rkeep=30   |                           |
       |                          |                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |<=== STUN request ========|                           |
       |=== STUN response =======>|                           |
       |                          |                           |
       |                   *** Timeout ***                    |
       |                          |                           |
       |<=== STUN request ========|                           |
       |=== STUN response =======>|                           |
       |                          |                           |


                        Figure 1: Example call flow

8.  Grammar

8.1.  General

   This section describes the syntax extensions to the ABNF syntax
   defined in RFC 3261, by defining a new Via header field parameter,
   "rkeep".  The ABNF defined in this specification is conformant to RFC
   5234 [RFC5234].

8.2.  ABNF

   via-params =/ rkeep

   rkeep      = "rkeep" [ EQUAL 1*(DIGIT) ]








Holmberg & Gallego        Expires June 19, 2015                 [Page 8]

Internet-Draft             reverse keep-alive              December 2014


9.  IANA Considerations

9.1.  'rkeep' Via header field parameter

   This specification defines a new Via header field parameter, called
   "rkeep", in the "Header Field Parameters and Parameter Values" sub-
   registry as per the registry created by [RFC3968].  The syntax is
   defined in Section 8.  The required information is:

                                                  Predefined
   Header Field            Parameter Name         Values      Reference
   ----------------------  ---------------------  ----------  ---------
   Via                     rkeep                  No          [RFCXXXX]


10.  Security Considerations

   The Security Considerations in RFC 6223 apply.

11.  Acknowledgements

   The following persons provided comments and feedback on the document:
   Paul Kyzivat, Dan Wing, Gethin Liddell and Venkata Ramesh
   Balabhadruni.

12.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-holmberg-sipcore-rkeep-04

   o  New version submitted due to expiration of previous version.

   Changes from draft-holmberg-sipcore-rkeep-03

   o  New version submitted due to expiration of previous version.

   Changes from draft-holmberg-sipcore-rkeep-02

   o  New version submitted due to expiration of previous version.

   Changes from draft-holmberg-sipcore-rkeep-01

   o  New version submitted due to expiration of previous version.

   Changes from draft-holmberg-sipcore-rkeep-00

   o  Forking text added.



Holmberg & Gallego        Expires June 19, 2015                 [Page 9]

Internet-Draft             reverse keep-alive              December 2014


   o  Editorial corrections.

   o  - s/6263/6223.

   o  - s/frequency/interval.

   o  Example added.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

   [RFC6223]  Holmberg, C., "Indication of Support for Keep-Alive", RFC
              6223, April 2011.

13.2.  Informative References

   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Header Field Parameter Registry for the Session
              Initiation Protocol (SIP)", BCP 98, RFC 3968, December
              2004.

Authors' Addresses









Holmberg & Gallego        Expires June 19, 2015                [Page 10]

Internet-Draft             reverse keep-alive              December 2014


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com


   Oscar Gallego
   Vodafone
   One Kingdom Street, Paddington Central
   London  W2 6BY
   UK

   Email: oscar.gallego@vodafone.com



































Holmberg & Gallego        Expires June 19, 2015                [Page 11]