idnits 2.17.1 draft-fu-sfc-topology-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-sfc-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 14, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Q. Fu, Ed. 3 Internet-Draft China Mobile 4 Intended status: Informational J. Halpern 5 Expires: April 16, 2016 Ericsson 6 H. Deng 7 China Mobile 8 October 14, 2015 10 The topology of service function chaining 11 draft-fu-sfc-topology-01 13 Abstract 15 This document proposes a deployment topology of Service Function 16 Chaining(SFC). The topology is in accordance with the SFC 17 architecture in [I-D.ietf-sfc-architecture]. Currently, such 18 architecture only includes architectural concepts, principles, and 19 components used in the construction of composite services through 20 deployment of SFCs, without any instruction for the field deployment. 21 It is still difficult to map from the architecture to a real 22 deployment of SFC. In this document, we propose this topology which 23 will give instructions for the field deployments. We further propose 24 a VCPE usecase of SFC in the transport network, which explains the 25 details of the deployment topology. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 16, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Topology of SFC in current network . . . . . . . . . . . . . 4 64 4. vCPE usecase of SFC . . . . . . . . . . . . . . . . . . . . . 5 65 5. Topology of VCPE Deployment . . . . . . . . . . . . . . . . . 6 66 6. Details of VCPE deployment in the MPLS-TP Network . . . . . . 8 67 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8. Informative References . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 The definition and instantiation of an ordered set of service 74 functions and subsequent 'steering' of traffic through them is termed 75 as Service Function Chaining (SFC). The definition of SFC can be 76 found in [I-D.ietf-sfc-problem-statement]. In 77 [I-D.ietf-sfc-architecture], an architecture for SFC is proposed, 78 which includes the basic architectural concepts, principles, and 79 components used in the construction of SFCs. The high level logical 80 architecture of SFC is shown in Figure.1, and a detailed architecture 81 is shown in Figure.2. The definition and functions for the 82 components in these figures can be found in 83 [I-D.ietf-sfc-architecture]. 85 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 . +--------------+ +------------------~~~ 87 . | Service | SFC | Service +---+ +---+ 88 . |Classification| Encapsulation | Function |sf1|...|sfn| 89 +---->| Function |+---------------->| Path +---+ +---+ 90 . +--------------+ +------------------~~~ 91 . SFC-enabled Domain 92 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Figure 1: High Level Logical Architecture for SFC 96 +----------------+ +----------------+ 97 | SFC-aware | | SFC-unaware | 98 |Service Function| |Service Function| 99 +-------+--------+ +-------+--------+ 100 | | 101 SFC Encapsulation No SFC Encapsulation 102 | SFC | 103 +---------+ +----------------+ Encapsulation +---------+ 104 |SFC-Aware|-----------------+ \ +------------|SFC Proxy| 105 | SF | ... ----------+ \ \ / +---------+ 106 +---------+ \ \ \ / 107 +-------+--------+ 108 | SF Forwarder | 109 | (SFF) | 110 +-------+--------+ 111 | 112 SFC Encapsulation 113 | 114 ... SFC-enabled Domain ... 115 | 116 Network Overlay Transport 117 | 118 _,....._ 119 ,-' `-. 120 / `. 121 | Network | 122 `. / 123 `.__ __,-' 124 `'''' 126 Figure 2: Detailed Architecture for SFC 128 However, the architecture proposed in [I-D.ietf-sfc-architecture] 129 provides little instructions for field deployment of SFC. The 130 definitons for each component are abstract and are difficult to be 131 mapped to current network. Therefore, in this document, a topology 132 of field deployment of SFC is proposed. We further propose a usecase 133 of vCPE using SFC to fully explain the topology. 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Topology of SFC in current network 143 Figure.3 shows the topology of deployment of SFC in the current 144 network. In general, there are two choices of the deployment of the 145 SFs. One is to locate in the data centers of Operators. And the 146 other is to co-locate with the Openrator Gateways(GWs). Such GWs can 147 be in the aggregate networks or the core networks. These two 148 deployments both have their advantages. For the first one, the 149 traffic do not need to travel to the DC and back. For the second 150 one, it will be easier for us to manage and maintain these SFC 151 devices. 153 The Operator GWs should act as SCF(Service Classification Function) 154 and SFF (Service function Forwarder) in the SFC architecture. This 155 SFF should be responsible for adding SFC-header to the packets. 156 Multiple SFFs can be deployed after the GW in large scale use cases, 157 so as to avoid large volume of traffic returning to the GW 158 continiously. 160 The deployment topology of colocating the SCF and SFF will simplify 161 the classification and forwarding. SFF can add the SFC header to the 162 traffic flow directly according to the SCF result, and can support 163 re-classification easily. In the meantime, in some usecases, the SCF 164 can act as classifier of traffic flows so as to classify the traffic 165 that need to go through the SFC region and the others that do not 166 need. In the following VCPE usecase, we can show the colocation of 167 the GW with the SCF and the SFF can greatly simplify the network 168 deployment. However, such topology will complicate the Operator GW. 169 There are other deployments that the SCF and/or the SFF are located 170 outside the GW, in which case interaction and interface between the 171 GW, the SCF, and the SFF is required. 173 +---------------+ 174 |SFC Unaware SF3| 175 +------+--------+ 176 | 177 | 178 +-----+ +-----+ +----+----+ 179 | SF1 | | SF2 | |SFC Proxy| 180 +--+--+ +--+--+ +--+------+ 181 | | | 182 +------+ | +-----+ 183 | | | 184 +--+-+ +-+--+ +-+--+ 185 |SFF1| |SFF2| |SFF3| 186 +--+-+ +-+--+ +-+--+ 187 | | | 188 +-+-----+------+--+ 189 |GW | 190 +------+ | +-----+ +-----+ | +----------+ 191 | User +-------------+-+ SCF +-+ SFF +-+-----------+ Internet | 192 +------+ | +-----+ +-----+ | +----------+ 193 +-----------------+ 195 Figure 3: Topology for SFC in the Mobile Networks 197 4. vCPE usecase of SFC 199 In this document, we also propose a usecase of Service Function 200 Chaining (SFC) to realize virtual CPE in the Transport Network. Such 201 VCPE would provide value-added services, including L4-L7 network 202 functions to the traditional transport network customers. In order 203 to flexibly control the traffic flow, we also introduce SDN- 204 controller (Software Define Network Controller) into the transport 205 network. The SDN-controller is responsible for directing the traffic 206 of certain enterprise customer, who has paid for the VCPE services, 207 to the VCPE servers. 209 The concept of VCPE is to shift most of the networking and service 210 functionalities from the customer side to the network side. In this 211 way, the customer side's equipment, that is the CPE, can be 212 simplified. The VCPE refers to one or a set of equipments at the 213 network side to execute the networking and service functionalities 214 used to be executed at the CPE. In such architecture, the CPE can be 215 a simple L2 switch, which is only responsible for forwarding packets 216 to a certain next hop. The VCPE can be realized by a SFC in the 217 physical network or the virtual network, in which the traffic of each 218 customer is directed to one or several Service Founctions (SF) 219 specified by the customer. 221 5. Topology of VCPE Deployment 223 Following the topology given in the previous section, we will propose 224 a usecase of VCPE deployment in the current Transport network. The 225 traditional transport network uses static allocation mechanism in 226 general. In order to provide network connection between different 227 locations for the enterprise customers, traditional transport network 228 should allocate dedicated lines between each pair of the locations. 229 Such architecture is not suitable when the enterprise customers 230 require LAN access, and moreover, L3-L7 functions among different 231 locations. Therefore, we introduce Virtual Customer Premise 232 Equipment (VCPE) into the Transport network. By utilizing SFC, the 233 VCPE can provide value-added services, such as firewall (FW), NAT, 234 and etc., to the traditional transport network customers. With the 235 emergance of the NFV technologies, these services can be one or a set 236 of VNFs on the VCPE servers. Such architecture provides an agile 237 mechanism for operators to launch value-added services for the 238 transport network. 240 Figure 4 shows the topology of deployment of the usecase for VCPE in 241 the transport network. The solid lines indicate data traffic flows, 242 while the dash lines indicate control traffic flows. In this 243 architecture, the CPEs are located at different branches of the 244 enterprise customer, and act as L2 forwarding switches. The VCPE is 245 located at the DC, or co-located with the aggregate GW. 247 +-----------------------+ 248 .....+ SDN-Controller +............ 249 : +----+------------------+ : 250 : : : 251 : : +------------------------+ : 252 : : | VCPE | : 253 : : | +---+ +---+ +---+ | : 254 : : | |SF1| |SF2| |SF3| | : 255 : : | +-+-+ +-+-+ +-+-+ | : 256 : : | | | | | : 257 : : | +-+--+ +-+--+ +-+--+ | : 258 : : | |SFF1| |SFF2| |SFF3| | : 259 : : + +-+--+ +-+--+ +-+--+ | : 260 : : +---+-------+-------+----+ : 261 : : +---+ | +---+ : 262 : : | | | : 263 +---+------+ : +--+---+---+-+ +----+-----+ 264 | +-+---+ | .......++---+ +---+| | +-+---+ | 265 | | CPE +--+---------++SCF+--+SFF++-----+--+ CPE | | 266 | +-----+ | |+---+ +---+| | +-----+ | 267 |Enterprise| | Aggregate | |Enterprise| 268 | Branch | | Network GW | | Branch | 269 +----------+ +------------+ +----------+ 271 Figure 4: Topology of Deployment of VCPE in the transport network 273 All of the CPEs and the Aggregate Network GW can be controlled by the 274 SDN-controller. When the enterprise customer selects a set of the 275 value-added services, the SDN-controller will inform the CPE of the 276 customer to direct the traffic flow to a certain Aggregate Network GW 277 connected to the VCPE. The GW acts as SCF and SFF in the SFC region. 278 It is responsible for classifing the traffic flow of the customers 279 and adding SFC header. And then it will act as SFF and forward the 280 traffic tothe other SFFs in the VCPE based on the SFP (Service 281 Function Path). When finishing the SFP, the GW will remove the SFC 282 header and forward the traffic flow to the destination CPE. All 283 these traffic flows are directed under the control of the SDN 284 controller. 286 There could be another architecture without the SDN controller, in 287 which case, the SCF is used to classify which flow shoud go through 288 the VCPE and enter the SFC region, and which flow should follow the 289 traditional transport network routine and should be forwarded 290 directly to the destination CPE. 292 6. Details of VCPE deployment in the MPLS-TP Network 294 Since MPLS-TP is widely used in the current transport network, we are 295 going to propose this usecase based on the MPLS-TP transport network. 296 The traditional transport network is only responsible for providing 297 MPLS-TP connection between each two destinations. No L3-L7 services 298 can be provided based on it. By introducing VCPE at the aggregate/ 299 core network, and using SFC, multiple L3-L7 services can be provided 300 using the widely deployed MPLS-TP network. 302 In the MPLS-TP packet, the PW lable, adhere to the packet by the CPE 303 device at the customer side of the PTN network, can be used to 304 classify service type. Such information can be used for Service 305 Clasification Function. Extra label can also be added into the PW 306 lable to indicate user/network specifics. Therefore, the SFC can do 307 the service clasification mapping based on the PW lable in the MPLS- 308 TP packets. In the meantime, MPLS-TP packets should also be 309 transfered to L3 packets before entering the Service Function Region, 310 and should be re-encapsulated to the MPLS-TP packets after leaving 311 the Service Function Region. According to the deployment topology, 312 the aggregate GW is acting as both ingress and egress GW of the SFC 313 region. In this case, the aggregate GW should record the mapping 314 relationship of the IP address and PW/LSP label of each packet, and 315 should make sure pf adding the exact same MPLS-TP header to the 316 packets when they finish the SFP and exit the SFC region, so that the 317 packet can continue its path in the transport network using the MPLS- 318 TP header. Therefore, in the MPLT-TP network, the aggregate GW 319 shoule follow the following steps when an MPLS-TP packet arrives at 320 the aggregate network. 322 1) Mapping PW lable to a certain Service Founction Path 324 2) Recording mapping between IP address and PW/LSP lable, so as to 325 re-encapsulate the L3 packets with a certain IP address. 327 3) Transfering MPLS-TP packets to L3 packets by taking off the MPLS- 328 TP header. 330 4) Adding SFC header into the L3 packets. 332 5) Acting as the SFF by forwarding the L3 packets according to the 333 SFP. 335 6) Taking off the SFC header when the SFP finishes. 337 7) Transfering the L3 packets to MPLS-TP packets by adding 338 corresponding MPLS-TP header according to the recorded mapping. 340 8) Forwarding the MPLS-TP Packets to the destination. 342 For step 2, the following table should be maintained by the GW, in 343 which SFP indicates Service Function Path. 345 IP address | LSP label |PW label | SFP 346 -----------+-----------+---------+------ 347 IP1 | LSP1 | PW1 | SFP1 348 IP2 | LSP2 | PW2 | SFP2 349 IP3 | LSP3 | PW3 | SFP3 351 Figure 5: Mapping table in the GW 353 This proposed approach can reuse the existing MPLS-TP network, so 354 that operators can use the same transport network platform to support 355 both the traditional private line service and value added NFV 356 services. From the proposed steps, we can see that colocate the SCF 357 and the SFF with the GW can greatly simplify the whole deployment, 358 since we don't need to coordinate the mapping info between the SCF 359 and the GW and the SFF. 361 7. Conclusion 363 In this document, a topology of SFC is proposed. Such topology 364 follows the definition and components of the SFC architecture in 365 [I-D.ietf-sfc-architecture]. Comparing with the abstract 366 architecture proposed, such topology provides deployable guidelines 367 for SFC. 369 A usecase of VCPE using SFC in the MPLS-TP transport network is 370 further proposed to detailed the deployment topology. Such usecase 371 provides an agile mechanism for launching new value-added services in 372 the transport network. SFC is used in the VCPE to chain different 373 SFs for different flows according to the customers' specification. 374 In the meantime, traffic flows are directed with the help of the SDN- 375 controller according to the customers' specification. 377 8. Informative References 379 [I-D.ietf-sfc-architecture] 380 Halpern, J. and C. Pignataro, "Service Function Chaining 381 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 382 in progress), July 2015. 384 [I-D.ietf-sfc-problem-statement] 385 Quinn, P. and T. Nadeau, "Service Function Chaining 386 Problem Statement", draft-ietf-sfc-problem-statement-13 387 (work in progress), February 2015. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 Authors' Addresses 396 Qiao Fu (editor) 397 China Mobile 398 Xuanwumenxi Ave. No.32 399 Beijing 400 China 402 Email: fuqiao1@outlook.com 404 Joel. Halpern 405 Ericsson 407 Email: jmh@joelhalpern.com 409 Hui Deng 410 China Mobile 411 Xuanwumenxi Ave. No.32 412 Beijing 413 China 415 Email: denghui@chinamobile.com