idnits 2.17.1 draft-xuan-sfc-policy-sfp-adjustment-00.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 : ---------------------------------------------------------------------------- No issues found here. 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 (Jul 7, 2016) is 2844 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 83, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 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: Jan 2017 Jul 7, 2016 6 Policy-based Service Function Path Adjustment 7 draft-xuan-sfc-policy-sfp-adjustment-00 9 Abstract 11 This document describes about policy-based SFP adjustment which 12 covers two new use cases for SFP adjustment in addition to existing 13 use cases defined in [ietf-sfc-control-plane] and in 14 [irtf-nfvrg-resource-management]. These two use cases include 15 QoS and affinity policies. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on Jan 2017. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions 47 Relating to IETF Documents (http://trustee.ietf.org/license-info) 48 in effect on the date of publication of this document. Please 49 review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. 52 Table of Contents 54 1. Introduction...................................................3 55 2. Conventions used in this document..............................3 56 3. Service Function Path Adjustment...............................3 57 4. Policy architecture for SFC....................................4 58 5. Policy-based SFP adjustment....................................5 59 6. Alignment with control plane document..........................6 60 7. Security Considerations........................................6 61 8. IANA Considerations............................................6 62 9. References.....................................................6 63 9.1. Normative References......................................6 64 9.2. Informative References....................................6 66 1. Introduction 68 The SFP could be dynamically adjusted based on the state and 69 attributes of the SFP components. In some cases, the SFP adjustment 70 is carried out due to the failure of one SFP component or the 71 policies of network operators. This document describes about policy- 72 based SFP adjustment which covers two new use cases for SFP 73 adjustment in addition to existing use cases defined in 74 [ietf-sfc-control-plane] and in [irtf-nfvrg-resource-management]. 75 These two use cases include polices related to Quality of Service 76 treatment and affinity rules. 78 2. Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC-2119 [RFC2119]. 84 The terms about SFC, SFP, SFF, SF, and classifier are defined in 85 [RFC7665] and [ietf-sfc-control-plane] 87 3. Service Function Path Adjustment 89 As discribed in [RFC7665], the SFP is composed by the combination of 90 different SF instances, SFFs, and classifiers. One SFC can have more 91 than one SFPs. The SFP can be adjusted due to the failure of one SF in 92 the chain or load balancing requirements of the network operators. 93 These use cases are covered in the [ietf-sfc-control-plane] as below: 94 + SFP fail-over 95 + SFP with better latency 96 + Traffic engineered SFP 97 + SF/SFP load-balancing 99 Other use cases are also covered in [irtf-nfvrg-resource-management] 101 + Path Optimization 102 + Energy efficiency 103 4. Policy architecture for SFC 105 Figure 1 shows the policy architecture for service function chain. 106 The policies are described in high level languagues at policy 107 decision point (PDP) which will be translated into subsystem 108 configurations and enforced at enforcement points (PEP). 110 +------------+ 111 | Policy | 112 | decision | 113 +-----+------+ 114 | 115 +------|---------------------------------------+ 116 | +----v------+ | 117 | |Policy | SFC Control Plane | 118 +-------+ |enforcement| | 119 | | +-----------+ | 120 C1 +------------------^-------------^-------------+ 121 +------+--------------|C3+------------------------------------+ 122 | | +----+ | | | 123 | | | SF | |C2 |C2 | 124 | | +-+--+ | | | 125 | +----V--- --+ | | | | 126 | | SFC | +-+--+ +-+---+ +-+---+ | 127 | |Classifier +----^+SFF +-----^+SFF +-------^+SFF | | 128 | | Node +v----+(PEP)v-----+(PEP)+v-------+(PEP)| | 129 | +-----------+ +-+--+ +-+---+ +--+--+ | 130 | | | | | 131 | |C2 ---+--- | | 132 | | | | +----+------+ C4 | 133 | V +-+--+ +--+-+ | SFC Proxy +--> | 134 | | SF | |SF | +-----------+ | 135 | +----+ +----+ | 136 | |C3 |C3 | 137 | SFC Data Plane Components V V | 138 +-------------------------------------------------------------+ 140 Figure 1. Policy architecture for SFC 142 5. Policy-based SFP adjustment 144 We assume that the control plane which is responsible for calculating 145 the SFP has the global view and real-time status of network components 146 such as service function, service function forwarder. The control 147 plane knows the capacity, location of each network component. 148 The control plane also monitors the network metrics: workload, latency, 149 bandwidth of each component. Based on this information, the SFP 150 adjustment can be done based on the policies from network operators 151 as followings: 153 + QoS policies: depending on the service plan of each customer,the 154 new SFP is calculated which takes into account the QoS parameters 155 of that customer. For example, the customer with gold plan will be 156 served by the SFP which consists of SFs, SFFs, and classifiers 157 satisfying the QoS parameters of that gold plan. 159 +---------------------------------------------------------------+ 160 | Policy: "A customer with a Gold service plan" | 161 +------+----------------+----------------+-----------------+----+ 162 | | | | 163 + + + + 164 V V V V 165 +-------------+ +------------+ +------------+ +------------+ 166 |Service | |Service | |Classifier | | Networking | 167 |Function | |Function | | | | subsystem | 168 | | |Forwarder | | | | | 169 |Policy | |Policy | |Policy | | Policy | 170 |translation: | |translation:| |translation:| | Translation| 171 | | | | | | | | 172 |Selected SF | |Selected SFF| |Selected | | Give the | 173 |has low | |has strong | |classifier | | SFP best | 174 |working load | |capacity | |has strong | | latency | 175 |low latency | | | |capacity | | bandwidth | 176 | | | | | | | | 177 | | | | | | | | 178 +-------------+ +------------+ +------------+ +------------+ 180 Figure 2. Policy-based SFP adjustment 182 + Affinity and anti-affinity policies: the new SFP is calculated which 183 takes into account the affinity or anti-affinity policies. For example, 184 when a SF in the SFP fails, the replacement SF should satisfy some 185 anti-affinity policies defined by network operators for achieving 186 the resiliency. That is, the replacement SF and failed SF instances 187 should be located in the different physical hosts or hypervisors or 188 NFVIs. 190 + Traffic engineering and load balancing policies: mentioned in the 191 [ietf-sfc-control-plane] 192 6. Alignment with control plane document 194 This document adds two more use cases for SFP adjustment to the 195 control plane document [ietf-sfc-control-plane] of SFC WG. 197 7. Security Considerations 198 TBD. 200 8. IANA Considerations 202 TBD. 204 9. References 206 9.1. Normative References 208 [RFC7665] 209 J. Halpern, C. Pignataro, "Service Function Chaining 210 (SFC) architecture", IETF RFC 7665, Oct 2015 212 9.2. Informative References 214 [ietf-sfc-control-plane] 215 M. Boucadair, "Service Function Chaining (SFC) 216 Control Plane Components & Requirements", 217 draft-ietf-sfc-control-plane-06, May 2016 219 [irtf-nfvrg-resource-management] 221 Lee, S., Pack, S., Shin, M., and E. Paik, "Resource 222 Management in Service Chaining", draft-irtf-nfvrg- 223 resource-management-service-chain-03, Mar 2016. 225 Authors' Addresses 227 Truong-Xuan Do 228 Soongsil University 229 Changui Bldg. 403, 230 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 232 Phone: +82 10 4473 6869 233 Email: thespring1989@gmail.com 235 Younghan Kim 236 Soongsil University 237 11F Hyungnam Engineering Bldg. 1107, 238 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 240 Phone: +82-2-820-0904 241 Email: younghak@ssu.ac.kr