Internet DRAFT - draft-yuan-hiprg-failure-detection-recovery

draft-yuan-hiprg-failure-detection-recovery



HIPRG                                                        Tao Yuan
Internet Draft                                                  Bo Hu
Intended status: Experimental                             Shanzhi Chen
Expires: July 2, 2012                                      Qinqin Chu
                                                          Zhangfeng Hu
                                                               Wenjun Li
                                                          BUPT, China
                                                       January 2, 2012


          HIP-based Failure Detection and Recovery for Multihoming
             draft-yuan-hiprg-failure-detection-recovery-03.txt


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 2, 2012.

Copyright Notice

   Copyright (c) 2011 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.




Yuan, et al.           Expires January 5, 2012                [Page 1]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012




Abstract

   Fault tolerance is one of greatest feature of multihomed host. This
   document proposes a failure detection and communication recovery
   mechanism for Host Identity Protocol. It can be applied to HIP by
   using new defined HIP parameters. A HIP-enabled multihomed host can
   switch to alternative locator if current link breaks down by adopting
   this mechanism.






































Yuan, et al.           Expires January 5, 2012                [Page 2]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012




Table of Contents

   1. Introduction................................................4
   2. Alternative Proposals........................................4
      2.1. Reap4hip...............................................4
   3. HIP locator management.......................................5
      3.1. Locator States.........................................5
      3.2. Locators of Multihomed Host.............................6
   4. Failure Detection and Communication Recovery for HIP..........7
      4.1. Initialization Module...................................7
      4.2. Link-Monitor Module.....................................8
      4.3. Link-Keep Module........................................9
      4.4. Recovery Module.........................................9
   5. Packet Formats.............................................12
      5.1. New HIP Parameter......................................12
         5.1.1. KEEPALIVE_TIMEOUT.................................12
      5.2. NOTIFICATION Parameter.................................12
         5.2.1. KEEPALIVE........................................12
         5.2.2. INVALD_LOCATOR....................................13
   6. Security Considerations.....................................13
   7. IANA Considerations........................................13
   8. References.................................................13
      8.1. Normative References...................................13
      8.2. Informative References.................................13
   Authors' Addresses............................................14





















Yuan, et al.           Expires January 5, 2012                [Page 3]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012




1. Introduction

   Multihomed host has multiple locators available for fault tolerance.
   This means it can use an alternative locator if current link breaks
   down without re-establishing connection with correspondent peers. To
   achieve such failure tolerance capability, host needs a failure
   detection mechanism to decide when to process such a locator
   switching, and how to recover communication.

   RFC5206 describes HIP support for multihoming. It mainly focused on
   how to set up multiple connections between multihomed host and
   correspondent peers, but left multihoming support in advanced
   scenarios for further study. We propose a failure detection and
   recovery extension for HIP in this document. It can be implemented
   easily without too many modifications to HIP protocol.

2. Alternative Proposals

2.1. Reap4hip

   Reap4hip is a solution which considers fault tolerance capability in
   multihomed HIP hosts. In order to support such configurations,
   reap4hip introduced REAP protocol which described in RFC5534 for HIP,
   and thus updated the behavior for HIP multihomed hosts currently
   defined.

   The REAP protocol provides failure detection and locator pair
   exploration for the Shim6 protocol. Reap4hip applied REAP's features
   to HIP. It created a REAP instance to communicate with the ESP and
   HIP layers.  For the on-going source/destination locator pair,
   rep4hip sets up two timers to detect communicating condition. Besides,
   a new message named Keepalive message is introduced to maintain the
   reachability of a locator. Once the path breaks down, hosts try all
   possible locator pairs constantly until a new available locator pair
   is found.

   To implement reap4hip, a new message named Probe message is defined
   for HIP. It is used to probe new locator pair for two communicating
   hosts after currently used locator pair become invalid. The probe
   process would try possible locator pairs by sending Probe message
   constantly until at least one working locator pair is found. Since
   the Probe message format is huge, the probe process may negatively
   impact the performance of both host and network. Besides, Probe
   message and Keepalive message is not a HIP parameter, it may not be
   applied to existing HIP code easily.


Yuan, et al.           Expires January 5, 2012                [Page 4]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012




3. HIP locator management

3.1. Locator States

   A HIP locator can have three kinds of status. The status is used to
   track the reachability of a locator. They are: UNVERIFIED, ACTIVE and
   DEPRECATED. UNVERYFIED locator can not be used unless the
   reachability of it has been verified. ACTIVE indicates that the
   reachability of the locator has been verified and the locator has not
   been deprecated. DEPRECATED indicates an expired locator. As
   described in RFC5206, the following state changes are allowed:

   If current status of a locator is UNVERIFIED, the status can be
   changed to ACTIVE if the reachability procedure completes
   successfully, or can be changed to DEPRECATED if the lifetime expires.

   If current status of a locator is ACTIVE, the status can be changed
   to UNVERIFIED if there has been no traffic on the address for some
   time, or can be changed to DEPRECATED if the lifetime expires.

   If current status of a locator is DEPRECATED, the status can be
   changed to UNVERIFIED if the host receives a new lifetime for the
   locator.

   A host may receive a LOCATOR parameter in R1, I2, UPDATE and NOTIFY
   packets. For each locator listed in the LOCATOR parameter, the host
   should check whether it is already bound to the SPI indicated. If the
   locator is already bound, its lifetime is updated. If the status of
   it is DEPRECATED, the status is changed to UNVERIFIED. If the locator
   is not already bound, the locator is added, and its status is set to
   UNVERIFIED.  Mark all locators that were not listed in the LOCATOR
   parameter as DEPRECATED. Furthermore, if the LOCATOR parameter
   contains a new Preferred locator, the host should initiate a change
   of the Preferred locator.

   A host must verify the reachability of an UNVERIFIED locator. The
   status of a newly learned locator MUST initially be set to UNVERIFIED
   unless the new locator is advertised in a R1 packet as a new
   Preferred locator.  A host may also want to verify the reachability
   of an ACTIVE locator again after some time, in which case it would
   set the status of the locator to UNVERIFIED and reinitiate address
   verification.





Yuan, et al.           Expires January 5, 2012                [Page 5]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


3.2. Locators of Multihomed Host



   Before failure detection operates, the two communicating hosts must
   be aware of the set of locators which can be used. As described in
   RFC5206, HIP multihomed hosts can convey multiple locators by sending
   UPDATE message, and also by exchanging locators in R1 and I2 during
   the HIP base exchange.

   This locator set contains at least one pair of locators (the
   currently used locators) in status of ACTIVE, and may contain several
   UNVERIFIED or DEPRECATED locators. Along with the normal
   communication, host must verify the reachability of all UNVERIFIED
   locators. After the address verification procedure, additional ACTIVE
   locators are available. Due to such a locator management mechanism in
   HIP, in most case, the locator set of two communicating hosts
   contains more than one pair of ACTIVE locators in multihoming
   scenario

   Furthermore, multihomed host must declare one locator from locator
   set as Preferred locator on which it prefers to receive data. By
   default, the locators used in the HIP base exchange are the Preferred
   locators. A host can change the Preferred outgoing locator for
   different reasons, e.g., because receiving a LOCATOR parameter that
   has the "P" bit set.

   This document considers a HIP multihoming scenario in which the two
   communicating hosts have exchanged locator information, and indicated
   Preferred locators. As shown in Figure 1, the function of failure
   detection and communication recovery is added at the MH block. Once
   currently used preferred locators become unreachable, hosts should
   choose another locator as Preferred locator to maintain communication.















Yuan, et al.           Expires January 5, 2012                [Page 6]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


                   +-------+
                   |  TCP  |  (sockets bound to HITs)
                   +-------+
                       |
                   +-------+
        ---------->|  ESP  |  {HIT_s, HIT_d} <-> SPI
       |           +-------+
       |               |
   +-------+       +-------+
   |  MH   |------>|  HIP  |  {HIT_s, HIT_d, SPI} <-> {IP_s, IP_d, SPI}
   +-------+       +-------+
                       |
                   +-------+
                   |  IP   |
                   +-------+
      Figure 1: Architecture for HIP Mobility and Multi-homing (MH)

4. Failure Detection and Communication Recovery for HIP

   The failure detection and communication recovery mechanism divides
   HIP multihomed host into two kinds: D (Detection) host and K
   (Keepalive) host. D host is responsible for monitoring current used
   link, and maintains a Send Timer. When D host sends a payload packet,
   it turns on the Send Timer. When receiving a payload packet, D host
   turns off the Send Timer. K host is the corresponding host of D host.
   Its main task is to keep the reachability of current used locator. If
   no other packet has been sent since the payload packet has been
   received, K host transmits a HIP NOTIFY message with KEEPALIVE
   parameter to D host. K host maintains a Keepalive Timer to control
   when to send the NOTIFY message. In addition, another procedure of
   failure detection and communication recovery can be added in the
   reverse direction when needed.

   The failure detection and communication recovery mechanism consists
   of four functional modules, which are: initialization module, link-
   monitor module, link-keep module, and recovery module. These modules
   are added at the MH block. The details of each module are described
   as follows.


4.1. Initialization Module

   Both D host and K host runs initialization module firstly when D host
   triggers failure detection and communication recovery scheme. The
   initialization module makes D host communicate the timeout value of



Yuan, et al.           Expires January 5, 2012                [Page 7]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


   its Send Timer to the K host as a KEEPALIVE_TIMEOUT parameter in the
   I2, R1, or UPDATE messages.

   For K host, upon receive packet that contains KEEPALIVE_TIMEOUT
   parameter, initialization module will made it set its Keepalive Timer.
   The timeout value of Keepalive Timer is set to the value of
   KEEPALIVE_TIMEOUT parameter.

   The initialization module is responsible for the initial work of
   failure detection and communication recovery. After the work of
   initialization module, D host and K host have reached an agreement on
   how quickly NOTIFY message will be send and how rapidly detection of
   failure will take place. The time value of Send Timer can be modified
   in real time in order to adapt to unusual situations. The
   communication of the two hosts is capable of fault tolerance by
   initialization module's work.

4.2. Link-Monitor Module

   In HIP, monitor currently used link aims at providing a mechanism to
   detect the path between one pair of Preferred locators. If failure
   takes place, a new pair of locators should be chosen as Preferred
   locators. D host runs link-monitor module to detect the potential
   failure. D host has four states under the control of link-monitor
   module. The behavior of D host is described as follows:

   Wait state. After the work of initialization module or having
   received packet from K host, D host is in Wait state. It is the
   initial state of D host. D host is waiting for the arrival of upper
   packet. Whenever outgoing payload packets are generated, D host enter
   Send Packet state.

   Send Packet state. D host in Send Packet state is prepared for
   sending packet to K host. It will turn on Send Timer, and then send
   out the packet. After that, D host enter Detect state. Detect state.
   While in Detect state, D host is monitoring current used link, and
   the Send Timer is on. If D host received packet from K host in Detect
   state, it will turn off Send Timer, and back to Wait state. Otherwise,
   after Send Timer expires, if no return traffic from K host, D host
   will assume current used link has broken down, and enter Failure
   state to explore a new pair of locators.

   Failure state. After the expiration of Send Timer, D host enter
   Failure state. It will turn off Send Timer, and get ready for
   communication recovery. Then, the recovery module will take in charge
   of D host.



Yuan, et al.           Expires January 5, 2012                [Page 8]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


4.3. Link-Keep Module

   K host runs Link-Keep Module to keep the reachability of current used
   locator. K host has five states under the control of Link-Keep Module.
   The behavior of K host is described as follows:

   Wait state. After the work of initialization module, having sent out
   packet to D host or the expiration of Keepalive Timer, K host is in
   Wait state. It is the initial state of K host. K host is waiting for
   the arrival of packet from upper layer protocol or D host. Whenever
   outgoing payload packets are generated, D host enter Send Packet
   state to send out the packet. Whenever incoming payload packets are
   received, K host enter Receive Packet state to bring incoming packets
   into the proper process.

   Send Packet state. K host in Send Packet state is prepared for
   sending packet to D host. At this time, if Keepalive Timer is on, K
   host will turn it off, and then send out the packet, back to Wait
   state.

   Receive Packet state. While incoming payload packets are received, K
   host is in Receive Packet state. If the received packet is a HIP
   NOTIFY packet with INVALD_LOCATOR parameter, K host will enter
   Failure state. If it is a payload packet, K host will enter Keep
   state.

   Keep state. K host maintains the reachability of current used locator
   pair in Keep state. If K host in Keep state is going to send packet,
   it will turn off Keepalive Timer, and enter Send Packet state.
   Otherwise, K host should turn on Keepalive Timer, and send HIP NOTIFY
   packet with KEEPALIVE parameter to keep the reachability of current
   used locator pair. This process is under the control of Keepalive
   Timer. Usually, K host sends out HIP NOTIFY packet with KEEPALIVE
   parameter at the frequency of every one-third to one-half of the time
   value of Keepalive Timer until timer expires. After Keepalive Timer
   expires, K host back to Wait state.

   Failure state. K host is in Failure state for having received a HIP
   NOTIFY packet with INVALD_LOCATOR parameter. It will turn off Send
   Timer, and get ready for communication recovery. Then, the recovery
   module will take in charge of K host.

4.4. Recovery Module

   After the failure is detected, D host runs recovery module to start a
   process to choose new Preferred locator pair to recover communication.



Yuan, et al.           Expires January 5, 2012                [Page 9]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


   There are two work modes that D host can choose to recovery, which
   are Active mode and Passive mode.


   A.    Active mode


   If D host is in active mode, it sends a LOCATOR parameter to K host
   in an UPDATE packet as described in RFC5206. In this packet, a new
   Preferred locator is set. If no responses are obtained during a
   period of time, D host will assume the testing locator does not work.
   Then, it may enter passive mode or choose another locator as
   Preferred locator, and re-send UPDATE packet. The locator selection
   order could be a local policy. This process may continue for a period
   of time until available locator pair is found. If D host have tried
   all its locators, and could not find any available locator, it must
   enter passive mode. The behavior of D host in active mode while under
   the control of Recovery Module is described as follows:

   Choose Address state. It is the initial state of Active mode. D host
   will choose a new address as Preferred locator to send UPDATE packet
   to K host. Then it enters Wait Response state. D host can switch to
   Passive mode on this state.

   Wait Response state. After sending out the first UPDATE packet, D
   host is in Wait Response state. If no response received from K host,
   D host will back to Choose Address state. Otherwise, once receiving
   the replied UPDATE packet from K host, it will enter HIP Update state.

   HIP Update state. In this state, D host will finish the address
   change with K host as defined in HIP protocol. Then, the
   communication can be recovered.

   For K host under the control of Recovery Module, after receiving the
   UPDATE packet, it will send back an UPDATE packet as described in
   RFC5206 to D host. Then, the two hosts continue their communication
   using the new Preferred locator pair.

   B. Passive mode

   If D host is in passive mode, it selects one ACTIVE locator from the
   locator set which has been exchanged with K host before. If there is
   no ACTIVE locator can be used, D host must enter active mode. D host
   sends a NOTIFY packet to K host by using the selected ACTIVE locator.
   In this NOTIFY packet, the Notify Message Type is set to
   INVALID_LOCATOR, which notifies errors in the communication path. The
   NOTIFY packet may fail to reach K host. In such a case, D host may


Yuan, et al.           Expires January 5, 2012               [Page 10]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


   enter active mode or try another ACTIVE locator if no responses are
   obtained during a period of time. After trying all ACTIVE locators,
   if no available locator is found, D host must enter active mode. The
   behavior of D host in passive mode while under the control of
   Recovery Module is described as follows:

   Choose K host's Address state It is the initial state of passive mode.
   D host will choose a new address of K host to send HIP NOTIFY packet
   with INVALD_LOCATOR parameter. Then it enters Wait Response state. D
   host can switch to Passive mode when in this state.

   Wait Response state. After sending out the HIP NOTIFY packet with
   INVALD_LOCATOR parameter, D host is in Wait Response state. If no
   response received from K host, D host will back to Choose K host's
   Address state. Otherwise, once receiving the replied UPDATE packet
   from K host, it will enter HIP Update state.

   HIP Update: D host and K host will finish the address change as
   defined in HIP protocol. Then, the communication can be recovered.
   For K host under the control of Recovery Module, after receiving the
   NOTIFY packet, it is aware of the failure of previously used path,
   and then it enters active mode. By default, K host may use the
   source/destination locator pair of the NOTIFY packet as new Preferred
   locator to initiate the active mode. Additionally, K host is also
   allowed to choose Preferred locator according to local policy.  D
   host firstly enters active mode or passive mode is a local policy.
   The main difference in the two modes is the selection of preferential
   changing side of two communicating hosts. No matter which combination
   is chosen, the communication can always be recovered.

   This mechanism is also suitable for multi-point network: When a D
   host detects link failures and then finish recovery, it can send a
   broadcast message about the status of the locators of both two ends
   (if we run active mode link recovery, the D host will send a
   broadcast message about the status of the D host's own locators to
   the network; if we run passive mode link recovery, the D host will
   send a broadcast message about the status of the K host's locators to
   the network;), The connections of the network determine the
   specific scope of broadcast. With this mechanism, the other hosts of
   the network can select the right locator to set up a link without
   having to wait for the timer to send out, and reducing
   the signaling overhead.







Yuan, et al.           Expires January 5, 2012               [Page 11]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


5. Packet Formats

5.1. New HIP Parameter

5.1.1. KEEPALIVE_TIMEOUT

   This parameter is used to indicate how quickly KEEPALIVE NOTIFY
   message will be send. The value of KEEPALIVE_TIMEOUT is set to the
   value of Send Timeout of the host. KEEPALIVE_TIMEOUT can be sent in
   the I2, R1, or UPDATE messages. After receiving a packet with
   KEEPALIVE_TIMEOUT, the peer maps this value to set its Keepalive
   Timer.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Type = 10           |        Length  = 4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |      Keepalive Timeout        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 2: KEEPALIVE_TIMEOUT Parameter Format

   The fields are exactly the same as defined in RFC5534.

   Type: This field identifies the parameter and MUST be set to 10
   (Keepalive Timeout).

   Length: 4.

   Reserved: 16-bit field reserved for future use. Set to zero upon
   transmit and MUST be ignored upon receipt.

   Keepalive Timeout: Value in seconds corresponding to suggested
   Keepalive Timeout value for the peer.

5.2. NOTIFICATION Parameter

5.2.1. KEEPALIVE

   This document defines a new kind of NOTIFICATION parameter named
   KEEPALIVE. It is sent if there is no outgoing packet to inform
   corresponding peer that current path is OK. Types of NOTIFY message
   in the range 0-16383 are intended for reporting errors and in the
   range 16384-65535 for other status information.  Thus, the type value
   of KEEPALIVE should range among 16384-65535.




Yuan, et al.           Expires January 5, 2012               [Page 12]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


5.2.2. INVALD_LOCATOR

   This document defines a new kind of NOTIFICATION parameter named
   INVALD_LOCATOR. Host in passive mode sends it to corresponding peer
   to indicate an error in the path. The type value of INVALD_LOCATOR
   should range among 0-16383.

6. Security Considerations

   To be done.

7. IANA Considerations

   This document defines a KEEPALIVE Notify Message Type and a
   INVALD_LOCATOR Notify Message Type for HIP.

8. References

8.1. Normative References

   [RFC5206] P. Nikander, T. Henderson, C. Vogt, J.Arkko, "End-Host
             Mobility and Multihoming with the Host Identity Protocol",
             RFC 5206, April 2008.

   [RFC5201] R.Moskowitz, P. Nikander, P. Jokela, T. Henderson, "Host
             Identity Protocol", RFC 5201, April 2008.

8.2. Informative References

   [REAP4HIP] A. de la Oliva, M. Bagnulo, "Fault tolerance
              configurations for HIP multihoming", <draft-oliva-hiprg
              reap4hip-00>, July, 2007.

   [RFC5534] J. Arkko, I. van Beijnum, "Failure Detection and Locator
             Exploration Protocol for IPv6 Multihoming", RFC 5534, June,
             2009

   [RFC5533] E. Nordmark. and M. Bagnulo, "Shim6: Level 3 Multihoming
             Shim Protocol for IPv6", RFC 5533, June 2009

   [BFD]     D. Katz, D. Ward, "Bidirectional Forwarding Detection",
             <draftietf-bfd-base-11(work in progress)>, January, 2010







Yuan, et al.           Expires January 5, 2012               [Page 13]

    Internet-Draft   HIP Failure Detection and Recovery      January, 2012


Authors' Addresses

   Tao Yuan
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876
   Email: alberty2004@gmail.com

   Bo Hu
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876
   Email: bj.hubo@gmail.com

   Shanzhi Chen
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876

   Qinqin Chu
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876
   Email: qinqinchu@gmail.com

   Zhangfeng Hu
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876
   Email: zfhu2001@gmail.com

   Wenjun Li
   State Key Laboratory of Networking and Switching,
   Beijing University of Posts and Telecommunications
   Beijing, P.R.China, 100876
   liwenjunee@yahoo.cn












Yuan, et al.           Expires January 5, 2012               [Page 14]