idnits 2.17.1 draft-xuan-sfc-chain-high-availability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 50 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Oct 20, 2015) is 3108 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 92, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Truong-Xuan Do 2 Internet Draft Younghan Kim 3 Intended status: Informational Soongsil University, Korea 4 Expires: April 2016 Oct 20, 2015 6 High Availability mechanism for Service Function Chains 7 draft-xuan-sfc-chain-high-availability-01 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 2016. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions 39 Relating to IETF Documents (http://trustee.ietf.org/license-info) 40 in effect on the date of publication of this document. Please 41 review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes mechanisms to achieve the high 47 availability of the service function chains. This document 48 considers the high availability in the perspective of entire chain. 49 This means the SFC control plane needs to take into account some 50 metrics related service chain in addition to individual service 51 functions. This document covers both stateless and stateful service 52 functions as well. 54 Table of Contents 56 1. Introduction...................................................3 57 2. Conventions used in this document..............................3 58 3. High availability architecture of SFC..........................4 59 3.1. Metrics for back-up SFPs..................................5 60 3.2 SFP with all stateless service functions...................6 61 3.3 SFP with stateful service funtions.........................7 62 4. Security Considerations........................................8 63 5. IANA Considerations............................................8 64 6. References.....................................................8 65 6.1. Normative References......................................8 66 6.2. Informative References....................................8 68 1. Introduction 70 Service function chaining currently is redesigned with the support 71 of the software-defined network (SDN) and network function 72 virtualization (NFV) which provide more flexible and dynamical 73 end-to-end services. 75 In order to ensure the high availability of service function 76 chains, some traditional mechanisms for individual service function 77 are reused (e.g. Active/Standby or Active/Active). These mechanisms 78 are based on the deployment of the backup or redundant service 79 functions. The recovery of whole service chain relies on the 80 recovery of individual service function. 82 This document describe a mechanism which ensure the high 83 availability of service chain based on some metrics of whole chain. 84 The mechanism also considers both stateless and stateful service 85 functions in the chain. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [RFC2119]. 93 The terms about SFC are defined in [RFC7498] and 94 [I-D.ietf-sfc-architecture] 95 3. High availability architecture of SFC 97 Figure 1. shows the architecture for achieving the high 98 availability of the SFC. We make assumptions that each service 99 function has several instances which are connected to different 100 service function forwarders (SFF). Each service function path (SFP) 101 is created by the combination of different service instances of 102 different service functions. We propose a new entity called SFC 103 HA manager which is responsible for monitoring metrics which belong 104 not only to the individual service functions, such as fail-over, 105 load condition, but also the whole service chain, such as, latency, 106 total load, and traffic engineering. The SFC HA Manager takes 107 responsibilities of making the backup SFPs. SFC HA manager should 108 be located in the control plane part [I-D.ietf-sfc-control-plane] 109 of SFC architecture 111 [SFC HA Manager] 113 +****************+********+***>> back-up SFP 114 +|.......+........|........|.........+.....>> current SFP 115 || | | | | 116 SFI1 SFI2 SFI2 SFI3 SFI3 117 | | | | | 118 +---+----+ +----+---+ | 119 | | | 120 SFFI1 SFFI2 SFFI3 122 Figure 1. High availability architecture of SFC 123 3.1. Metrics for back-up SFPs 125 Some metrics for whole service function chain are listed below: 127 Fail-over: a back-up SFP with the replacement of failed service 128 functions 130 Total latency: a back-up SFP with better latency 132 Total bandwidth: a back-up SFP with highest bandwidth 134 Total path: a back-up SFP with shortest path 136 Total load: a back-up SFP with the lowest load 138 Traffic engineering: a back-up SFP with the pre-defined traffic 139 engineering goals 140 3.2 SFP with all stateless service functions 142 Procedures for making a back-up service function path 144 + Gather and monitor the states of current service function paths 145 + Evaluate the current SFPs based on collected data and above 146 metrics 147 + HA manager makes back-up SFPs for current SFP 148 + When a critical event occurs, the back-up SFP can be invoked and 149 replace the current SFP. 150 + The information about new SFP (back-up) is updated to all 151 corresponding SFFs. 153 3.3 SFP with stateful service funtions 155 Procedures for making a back-up service function path 157 + Gather and monitor the states of current service function paths 158 + Evaluate the current SFPs based on collected data and above 159 metrics 160 + HA manager makes back-up SFPs for current SFP 161 - For stateful service functions in the SFP, internal state 162 management for each service function is required and 163 synchronized with the same kind of service function when 164 creating a back-up SFP 165 - State synchronization can be handled by the direct 166 communication between two same kind service functions 168 + When a critical event occurs, the back-up SFP can be invoked and 169 replace the current SFP. 170 + The information about new SFP (back-up) is updated to all 171 corresponding SFFs. 173 4. Security Considerations 175 TBD. 177 5. IANA Considerations 179 TBD. 181 6. References 183 6.1. Normative References 185 [RFC7498] 186 Quinn, P. and T. Nadeau, "Problem Statement for Service 187 Function Chaining", RFC 7498, April 2015. 189 6.2. Informative References 191 [I-D.ietf-sfc-architecture] 193 Halpern, J. and C. Pignataro, "Service Function Chaining 194 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 195 in progress), July 2015. 197 [I-D.ietf-sfc-control-plane] 198 H. Li, Q. Wu, O. Huang, etc. al., "Service Function 199 Chaining (SFC) Control Plane Components & Requirements", 200 draft-ietf-sfc-control-plane-00, Aug 2015 201 Authors' Addresses 203 Truong-Xuan Do 204 Soongsil University 205 4F Hyungnam Engineering Bldg. 424, 206 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 208 Phone: +82 10 4473 6869 209 Email: xuan@dcn.ssu.ac.kr 211 Younghan Kim 212 Soongsil University 213 4F Hyungnam Engineering Bldg. 424, 214 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 216 Phone: +82-2-820-0904 217 Email: younghak@ssu.ac.kr