idnits 2.17.00 (12 Aug 2021) /tmp/idnits14181/draft-wei-sfc-mobile-consideration-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 (June 30, 2014) is 2882 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6241' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'Krishnan' is defined on line 256, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT X.Wei 3 Intended Status: Informational Huawei Technologies 4 Expires: January 1, 2015 June 30, 2014 6 Interaction between SFC network and 3GPP network 7 draft-wei-sfc-mobile-consideration-00 9 Abstract 11 This document provides a discussion of how SFC (Service Function 12 Chain) domain could interact with carrier network to provide network 13 service for traffic. Here LTE (Long Term Evolution) network is used 14 as an example of carrier network for discussion. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Interaction between LTE network and SFC domain . . . . . . . . 4 57 2.1 Interaction model . . . . . . . . . . . . . . . . . . . . . 4 58 2.2 Information exchange . . . . . . . . . . . . . . . . . . . 6 59 3 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 5 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 64 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1 Introduction 69 Different kinds of network Service Function (SF) have been deployed 70 in current network to provide network service for traffic. But 71 current SF deployments are tightly coupled to network topology and 72 physical resources, and this limits the ability of an operator to 73 introduce new services and/or service functions. To overcome the 74 disadvantages of current SF deployments, flexible SFC (Service 75 Function Chain) is under discussion in IETF [SFC PS]. 77 Though SFC domain is typically deployed by the owner of carrier 78 network, here we treat SFC domain and carrier network as two separate 79 network domain. A typical relationship between carrier network and 80 SFC domain is shown in Figure 1. When network traffic goes through 81 SFC domain, the SFC domain needs to know how to steer the traffic, 82 i.e. which service chain the traffic should pass. The carrier network 83 and SFC domain should interact properly in order to provide network 84 service to traffic. 86 +---------------+ traffic +----------+ traffic--------+ 87 |Carrier Network| <=======> |SFC domain| <=====>|Internet| 88 +---------------+ +----------+ +--------+ 90 Figure 1 Relationship between carrier network and SFC domain 92 LTE (Long Term Evolution) network [TS23.401] is standardized by 3rd 93 Generation Partnership Project (3GPP), the basic architecture of LTE 94 network is shown in Figure 2, three network entities including 95 eNodeB, SGW and PDN-GW form the data path for user's traffic from UE 96 to IP service network, and MME (Mobility Management Entity) acts as a 97 central control point of the network. 99 +--------+ 100 | IP | 101 S1-MME +-------+ S11 |Networks| 102 +----|----| MME |----|----+ +--------+ 103 | | | | |SGi 104 | +-------+ | S5/ | 105 +----+ LTE-Uu +-------+ S1-U +-------+ S8 +-------+ 106 |UE |----|---|eNodeB |---|-----------------| SGW |--|---|PDN-GW | 107 | |========|=======|=====================|=======|======| | 108 +----+ +-------+ +-------+ +-------+ 110 Figure 2 Basic LTE network architecture 111 LTE network connects to IP service network through SGi interface 113 [TS29.061]. 115 Gi-LAN service area is presently used by mobile network operator to 116 differentiate their services to their subscribers; mobile network 117 operator could deploy any kinds of SFs, e.g. Firewall, video 118 optimizer, NAT (Network Address Translator), to provide network 119 service for user's traffic. 121 +-----------+ SGi +------+ +-----------+ 122 |LTE network| <======> |Gi-LAN|<========>|IP Networks| 123 +-----------+ +------+ +-----------+ 124 Figure 3 Gi-LAN for LTE network 126 This document use LTE network as an example to illustrate how carrier 127 network and SFC domain could cooperate to provide network service to 128 traffic. 130 1.1 Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 SFC domain: or SFC network, a network that implements SFC. 138 2. Interaction between LTE network and SFC domain 140 In this section, we will discuss how SFC domain could provide network 141 service for traffic in LTE network. 143 2.1 Interaction model 145 Before the discussion of interaction between LTE network and SFC 146 domain, we first introduce the concept of Logical Service Function 147 Chain (LSFC) and Physical Service Function Chain (PSFC). LSFC is a 148 service function chain which is consisted of a list of SF type, and 149 no specific SF instance is included in LSFC. 151 PSFC is a service function chain which is consisted of a list of SF 152 instance, so PSFC could be viewed as an instance of LSFC. Considering 153 of the requirements of load balance, there could be more than one 154 instance for one type of SF, so a LSFC could be mapped into one or 155 more PSFC. 157 LSFC stands for a requirement of service function chain for certain 158 traffic, and PSFC is a physical implementation that satisfies the 159 requirement. 161 When we take LTE network and SFC domain as two separate domains, LTE 162 network plays the role of producing network service requirements and 163 SFC domain plays the role of providing network service for LTE 164 network's traffic. 166 An overview of interaction between LTE network and SFC domain is 167 depicted in Figure 4. LTE network creates LSFC for traffic and sends 168 the LSFC to SFC domain, and then SFC domain is in charge of 169 translating LSFC to PSFC. 171 Besides LSFC, additional information such as subscriber ID, that 172 might be used but could not be accessed directly by SFC domain, will 173 also be conveyed in service chain request procedure. 175 service chain request 176 +----------------------------+ 177 | | 178 | | 179 +------|----+ traffic +----V-----+ 180 |LTE Network| <==============> |SFC domain| 181 +-----------+ +----------+ 183 Figure 4 Overview of Interaction between LTE network and SFC domain 185 There are sorts of information that could be used in creating of 186 LSFC: 188 - Mobile user's subscription information. For example, the network 189 operator could provide video optimization service for gold and silver 190 user's video traffic, but not for bronze user's traffic. 191 - Network status information. For example, the radio access type that 192 the mobile user currently attached to or the network congestion level 193 could affect the choice of video optimizer for video traffic. 194 - Agreement between content provider and network operator. Content 195 provider, e.g. YouTube, could rent TCP optimization or video 196 optimization function for its traffic, so for the traffic of content 197 provider that has service agreement with network operator certain 198 service function could be implemented. 199 - Application Characteristics. Application characteristics play very 200 important role in creating service chain for the traffic, different 201 kinds of application traffic, such as Web application and video 202 application, would definitely go through different service chain. 203 - QoS information of the service. QoS information of LTE network 204 traffic could affect the choice of specific SF. 206 Per operator's consideration, the combination of different 207 information can be used in creating LSFC for the traffic. 209 2.2 Information exchange 211 This sub-section discusses what information elements should be 212 conveyed in service chain request procedure from LTE network to SFC 213 domain as depicted in Figure 4. 215 As discussed in sub-section 2.1, LSFC will be conveyed in service 216 chain request. 217 +-----------+---------------------------------------------------+ 218 | Match rule| To identify which traffic the LSFC is specific to.| 219 +-----------+---------------------------------------------------+ 220 | LSFC | To specify network service function chain that | 221 | | will act on the traffic. | 222 +-----------+---------------------------------------------------+ 223 | Additional| SFC related auxiliary information such as User's | 224 | info | Subscriber ID. | 225 +-----------+---------------------------------------------------+ 227 3 IANA Considerations 229 This document requires no requirement for IANA. 231 4 Security Considerations 233 Security related issues is not involved. 235 5 Acknowledgments 237 Many thanks to John Kaippallimalil and Chunshan Xiong (Sam) for their 238 valuable comments. 240 6 References 242 6.1 Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 248 and A. Bierman, Ed., "Network Configuration Protocol 249 (NETCONF)", RFC 6241, June 2011. 251 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 252 Ed., "Diameter Base Protocol", RFC 6733, October 2012. 254 6.2 Informative References 256 [Krishnan] R. Krishnan et al. "draft-krishnan-sfc-long-lived-flow- 257 use-cases", April 21, 2014 258 [SFC PS] P. Quinn et al. "draft-ietf-sfc-problem-statement-07", 259 June 24, 2014 261 Authors' Addresses 263 Xinpeng Wei 264 EMail: weixinpeng@huawei.com