Service Function Chaining W. Meng Internet-Draft C. Wang Intended status: Informational ZTE Corporation Expires: November 14, 2014 B. Khasnabish ZTE TX, Inc. May 13, 2014 Service Function Chaining Use Cases in Broadband draft-meng-sfc-broadband-usecases-01 Abstract This document discusses about service function use cases in different scenarios for each part of broadband network. The document provides analysis of different solutions and also describes the suitable scenarios that each solution may be deployed in. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 14, 2014. Copyright Notice Copyright (c) 2014 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Meng, et al. Expires November 14, 2014 [Page 1] Internet-Draft Service Function Chaining Use Cases May 2014 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Internet Access from Homes . . . . . . . . . . . . . . . . 5 3.1.1. Native IPv4 Network or Native IPv6 Network . . . . . . 5 3.1.2. IPv4/IPv6 Coexist Network . . . . . . . . . . . . . . 6 3.2. Internet Access from Enterprises . . . . . . . . . . . . . 13 3.3. Internet Access from Campuses . . . . . . . . . . . . . . 14 3.4. Added-value Service Access . . . . . . . . . . . . . . . . 14 3.4.1. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. VoIP/MoIP . . . . . . . . . . . . . . . . . . . . . . 15 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Service Function Chain Symmetry . . . . . . . . . . . . . 16 4.2. Deploying consideration . . . . . . . . . . . . . . . . . 16 4.2.1. Standalone mode . . . . . . . . . . . . . . . . . . . 16 4.2.2. Directly connecting mode . . . . . . . . . . . . . . . 18 4.3. Pool consideration . . . . . . . . . . . . . . . . . . . . 20 4.4. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 20 4.5. Unify home router . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Meng, et al. Expires November 14, 2014 [Page 2] Internet-Draft Service Function Chaining Use Cases May 2014 1. Introduction The object of SFC is trying to unload services from nodes in traditional network and deal with such services through service function chains. As increasingly large number of customers, The possibility of deployment SFC in broadband network seems emergency. And this document is aimed to analyze the possible deployment of SFC in broadband network. Meng, et al. Expires November 14, 2014 [Page 3] Internet-Draft Service Function Chaining Use Cases May 2014 2. Convention and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms about CGN/DS-Lite/Lightweight 4o6/MAP/NAT64 are defined in [RFC6888]/[RFC6333]/ [I-D.ietf-softwire-lw4over6]/ [I-D.ietf-softwire-map]/ [RFC6146]. The terms about SFC are defined in [I-D.ietf-sfc-problem-statement]. Meng, et al. Expires November 14, 2014 [Page 4] Internet-Draft Service Function Chaining Use Cases May 2014 3. Use cases The following sections highlight some of the most common broadband network use case scenarios and are in no way exhaustive. 3.1. Internet Access from Homes Figure 1 illustrates an abstract architecture of broadband network, including CPE sitted in home network, BNAS as broadband access network gateway,CR located in bone network and the Internet. +---+ +------+ +-----+ +---------+ |CPE|------| BNAS |--------| CR |------| Internet| +---+ +------+ +-----+ +---------+ Figure 1: Architecture of Broadband Network 3.1.1. Native IPv4 Network or Native IPv6 Network ----------------------------------------------------------------------------> +--- + +-------+ +-----+ +----------+ | | |DPI/DFI| | LB/ | |URL Filter|---| |--| UM |---| /Qos |---| FRR |---| /FW/PC | | | +----+ | +-------+ | +-----+ | +----------+ | +---+ +------+ | | | +-----+ +---------+ |CPE|--| BNAS-|-------|-----------|---------|-------------| CR |-----| Internet| +---+ +------+ +-----+ +---------+ Figure 2: Native IPv4 Network or Native IPv6 Network Figure 2 shows possible deployment of SFC in native IPv4 network or native IPv6 network. As UM(user management) function, which is the main funtion of BNAS in traditional network, consumes large memory and resources, it seems reasonable to represent user management function as a service function. 'BNAS-' means some functions have unburdened from traditional BNAS,such as user management,Qos,Load Balance and so forth. It seems that traditional BNAS is going to unload all the other extra functions from themselves, although now some extra functions are still imposed on them. Give that SFC is applied in Broadband network, the main SNs may cover: User Management, DPI, DFI, Qos, Load Balance, Fast Reroute, URL Filter,Firewall,Parental Control. And the possible order is not as strict as above. The upstream/downstream traffic may go through different permutations and combination of these SNs. For example: Meng, et al. Expires November 14, 2014 [Page 5] Internet-Draft Service Function Chaining Use Cases May 2014 SFC1: UM This SFC stands for the simplest of use case where a public broadband subscriber has no restriction in terms of bandwidth, flow capacity, access contents etc. SFC2: UM--Qos This SFC shows some bandwidth restrictions or several priority-based schedules are applied in this subscriber. Almost each home subscriber has an corresponding subscribed bandwidth, different services from a home have distinctive priority as well. As a result, this is a typical SFC used in internet access from homes. SFC3: UM--Qos--LB This SFC extends SFC2, which utilizes load balance to unburden one path from overload. This is also a typical senario in broadband network,especially in metropolitan area network. SFC4: UM--Qos--LB--URL Filter Based on SFC3, this SFC gives extra restrictions to the content that the subscriber want to access. SFC5: UM--Qos--Parental Control This is similar to SFC4,except there is no Load Balance. Another difference is that SFC5 offers some restrictions to downstream traffic in terms of content. SFC5 allows some legal or appropriate contents to flow to subscribers, while some illegal or inappropriate contents are blocking. 3.1.2. IPv4/IPv6 Coexist Network As showed below in figure 3, the main difference between IPv4/IPv6 native network and IPv4/IPv6 coexist network is whether there exists a NAT funtion. Although in IPv4 native network, there maybe exist NAT44 function as a result of limited IPv4 address, we try to put this scenario together with other IPv6 transition scenarioes in this section and discuss in detail. Meng, et al. Expires November 14, 2014 [Page 6] Internet-Draft Service Function Chaining Use Cases May 2014 ----------------------------------------------------------------------------> +--- + +--- + +-------+ +-----+ +----------+ | | | | |DPI/DFI| | LB/ | |URL Filter|---| |--| UM |---|NAT |---| /Qos |---| FRR |---| /FW/PC | | | +----+ | +----+ | +-------+ | +-----+ | +----------+ | +---+ +------+ | | | | +-----+ +---------+ |CPE|--| BNAS-|------|--------|-----------|---------|-------------| CR |---| Internet| +---+ +------+ +-----+ +---------+ Figure 3: IPv4/IPv6 Coexist Network Where NAT is deployed is based on the Internet Server Provider. It may be besides BNAS,which stands for distributed deployment, or besides CR,which represents central deployment. Above figure 3 just gives an example of a possible deployment position in distributed deployment scenario. This section tries to give some typical examples in IPv4/IPv6 coexist network, though there are others which are unnumbered. Also, in the following sections, the other SFs emphasized in section 3.1.1 are not highlighted, just try to keep the diagram simple and suitable for the draft's specification. 3.1.2.1. Simple NAT44 Figure 4 illustrates in a simple NAT44 scenario how SF-NAT is deployed. . : | ............... | External realm | ISP network--> |-------------+ | ++---|--++ | | SF-NAT | | ++---|--++ |-------------+ ++--|----+ ........... | BNAS | Internal realm ++------++ | | ISP network--> | | | | ++------++ ++------++ | CPE1 | | CPE2 | etc. ++------++ ++------++ Meng, et al. Expires November 14, 2014 [Page 7] Internet-Draft Service Function Chaining Use Cases May 2014 Figure 4: Simple NAT44 In distributed broadband networks, SNs may be deployed beside BNAS. These SNs may contain SF-NAT and other service functions such as UM,QOS,Load Balance,etc. Here gives an example of possible SFC in IPv4/IPv6 coexist network, which combines NAT function with the service functions in native IPv4/IPv6 network. SFC6: UM--Qos--NAT--LB--URL Filter SFC6 combines NAT function with SFC4, and represents the classical scenario in IPv4/IPv6 coexist network. After customers have subscribed, apply subscriber-based Qos policy, then transform private IPv4 address into public IPv4 address, and do five-tuple load balance for the outbound traffic. At last, monitor the outbound traffic and decide whether to pass them to the internet or block them. 3.1.2.2. DS-Lite Figure 5 describes a scenario of DS-lite. Meng, et al. Expires November 14, 2014 [Page 8] Internet-Draft Service Function Chaining Use Cases May 2014 +-----------+ | Host | +-----+-----+ | +---------|---------+ | CPE | +---------|---------+ +-----------------+ | +-----|------+ | | SF-SOFTWIRE| | +-----|------+ +-----------------+ ||| |||<-IPv4-in-IPv6 softwire ||| +--------|||--------+ | BNAS | +--------|||--------+ +----------------------+ | +----------|----------+ | | SF-SOFTWIRE | | | SF-NAT | | +----------|----------+ +-----------------+ | | --------|-------- / | \ | Internet | \ | / --------|-------- | | +-----+-----+ | IPv4 Host | +-----------+ Figure 5: DS-Lite SFC7: Softwire--UM--Softwire--NAT--LB--URL Filter When the outbound datagram is received by the CPE, the CPE sends it to a specific classifier which determines the datagram should be forwarded directly or dealed with DS-Lite process. Then the classifier sends the datagram within service header encapsulated to the first element of SFP which contains SF-SOFTWIRE instance. Next, the BNAS- receives the processed datagram, the BNAS- sends it Meng, et al. Expires November 14, 2014 [Page 9] Internet-Draft Service Function Chaining Use Cases May 2014 to a classifier and finds it a legal subscriber and need to be dealed with DS-Lite process. The SF-NAT creates and maintains the NAT mapping table, following the subsequent SFs. In other words, BNAS, itself, would not be aware of any stateful sessions. 3.1.2.3. MAP-E/Lightweight 4o6 +-----------+ | Host | +-----+-----+ | +---------|---------+ | CPE | +---------|---------+ +-----------------+ | +-----|------+ | | SF-NAT | | | SF-SOFTWIRE| | +-----|------+ +-----------------+ ||| |||<-IPv4-in-IPv6 softwire ||| +--------|||--------+ | BNAS | +--------|||--------+ +----------------------+ | +----------|----------+ | | SF-SOFTWIRE | | | SF-BINDING(SF-MAPE) | | +----------|----------+ +----------------------+ | | --------|-------- / | \ | Internet | \ | / --------|-------- | | +-----+-----+ | IPv4 Host | +-----------+ Figure 6: MAP-E/Lightweight 4o6 Meng, et al. Expires November 14, 2014 [Page 10] Internet-Draft Service Function Chaining Use Cases May 2014 The main difference between Lightweight 4o6/MAP-E and DS-Lite is where NAT happens. And the result is that Lightweight 4o6/MAP-E realizes NAT on the CPE, and then encapsulates translated IPv4 datagram in IPv6 Header and finally propagates the IPv4-in-IPv6 datagram in IPv6 tunnel to BNAS device. So here gives an example of this scenario: SFC8: NAT--Softwire--UM--Binding--LB--URL Filter In more detail, for outbound traffic in lw4o6 SFC scenario, When the datagram 1 is received by the home router, the CPE sends it to a specific classifier named which determines the datagram should be forwarded directly or dealed with lw4o6 process. Then the classifier sends the datagram within service header encapsulated to the first element of this SFP: SF-NAT. SF-NAT translates the IPv4 datagram and forwards translated IPv4 datagram to SF-SOFTWIRE, which encapsulates the datagram with the lwAFTR's IPv6 address as IPv6 encapsulated header and forwards this IPv4-in-IPv6 datagram (datagram 2) to the BNAS device. When the BNAS device receives such an IPv4-in-IPv6 datagram, the BNAS device sends it to a classifier and finds it need to be dealed with Lightweight 4o6 process. Then the classifier sends the datagram within service header encapsulated to the first element of SFP: SF- BINDING. This SF-BINDING creates a binding table about Lightweight 4o6 and decapsulates this datagram, and then propagates the datagram to internet. SFC9: NAT--Softwire--UM--MAPE--LB--URL Filter For outbound traffic in MAP-E SFC scenario, When the datagram 1 is received by the CPE, the CPE sends it to a specific classifier named which determines the datagram should be forwarded directly or dealed with MAP-E process. Then the classifier sends the datagram within service header encapsulated to the first element of this SFP: SF-NAT. SF-NAT translates the IPv4 datagram and forwards translated IPv4 datagram to SF-MAPE, which utilizes the MAP-E rules to encapsulate the datagram with the MAP BR's IPv6 address as IPv6 encapsulated header and forwards this IPv4-in-IPv6 datagram (datagram 2) to the BNAS device. When the BNAS device receives datagram 2, the BNAS device sends it to a classifier and finds it need to be dealed with MAP-E process. Then the classifier sends the datagram within service header encapsulated to the first element of SFP:SF-MAPE. This SF-MAPE utilizes the MAP-E rules to extract the IPv4 datagram, and then propagates the datagram to internet. Meng, et al. Expires November 14, 2014 [Page 11] Internet-Draft Service Function Chaining Use Cases May 2014 3.1.2.4. NAT64 +-----------+ | Host | +-----+-----+ | +---------|---------+ | CPE | +---------|---------+ --------|-------- / | \ | IPv6 Network | \ | / --------|-------- | +---------|---------+ +------------+ | BNAS | |DNS64 Server| +---------|---------+ +------------+ +-----------+ | +-----|------+ | | SF-NAT64 | | +-----|------+ +-----------+ --------|-------- / | \ | IPv4 Internet | \ | / --------|-------- Figure 7: NAT64 NAT64 scenario is similar with the scenario of simple NAT44. The only difference is SF-NAT64 should maintain rules that indicate how to translate a des-IPv6-address to an IPv4 address using a specific prefix64::/n. Where the NAT64 is deployed is also determined by Internet Server Provider. This figure is just an example where NAT64 is located nearby BNAS. Meng, et al. Expires November 14, 2014 [Page 12] Internet-Draft Service Function Chaining Use Cases May 2014 3.2. Internet Access from Enterprises ------------------------------------------------------------------------------------> +-------+ +-----+ +----------+ |DPI/DFI| | LB/ | |URL Filter|---| +-----+ |----| /Qos |---| FRR |---| /FW/PC | | |host1|--| +----------+ | +-------+ | +-----+ | +----------+ | +-----+ | |URL Filter| +-----+ | | +-----+ +---------+ ---| /FW/PC |--| SR- |-----------|---------|-------------| CR |---| Internet| +-----+ | +----------+ +-----+ +-----+ +---------+ |host2|--| +-----+ Figure 8: Internet access from enterprises Internet access from enterprises is another broadband network. They lease some ports or even some devices from Internet Server Provider. In addition to external ISP's service functions which is sitted on the way to internet, there maybe deploy many service functions in internal enterprise network for the sake of the security of enterprise network per se. Internal service functions may include: Firewall,used for transforming private IPv4 address to public IPv4 address,like nat function, URL Filter, used for restricting employees from access to non-work websites. As well as that, Parental control is used for monitoring employees' traffic and offers some constrains to certain websites or inappropriate contents. As for external service functions deployed by ISP, a typical service function is VPN, like L2VPN,L3VPN,IPsec,etc. But VPN is mainly used for interconnection between geographically separate sites of the same VPN, rather than internet access. Instead, there is a NAT function based on SR, converting inner traffic to the outer internet. Other external service functions involved in Internet access from enterprise network maybe similar to home network, for example, DPI,DFI,Qos,Load Balance, URL Filter,Firewall,Parental Control and so on. SFC10: URL Filter--FW---NAT---Qos---Load Balance----FW Here, you may see two FW functions. One is in the inner of enterprise, which represents the URL constrains from the perspective of enterprise. While the other one is sitted in the ISP network, out of the inner enterprise, and stands for the URL restrictions from the standpoint of ISP. Meng, et al. Expires November 14, 2014 [Page 13] Internet-Draft Service Function Chaining Use Cases May 2014 3.3. Internet Access from Campuses TBD 3.4. Added-value Service Access To promote their primary service, ISP try to provide value-added services to add value to the standard service offering. Here maybe focus on some significant value-added services in broadband network such as IPTV,VOIP,etc. 3.4.1. IPTV Figure 9 illustrates a possible deployment of IPTV network via SFC. <---------------------------------------------------- +----+ |STB1|-------| +----+ | | +----+ +-------+ +------+ |STB2|---| BNAS1-|----| Qos1 |---------| +----+ +-------+ +------+ | | | +----+ | | |STB3|-------| | +----+ | +---------+ +-----+ +----+ | DPI/DFI |-----| CDN | |STB4|-------| +---------+ +-----+ +----+ | | | | +----+ +-------+ +------+ | |STB5|---| BNAS2-|----| Qos2 |---------| +----+ +-------+ +------+ | +----+ | |STB6|-------| +----+ Figure 9: IPTV network via SFC IPTV is a IP multicast service, in which multi-subscribers should receive the same traffic from the multicast source like Content Distribution Network. Supposed there were six IPTV subscribers, from STB1 to STB6, they are located in different districts and they all need to receive traffic from Program 1. A possible SFC abstract here is : Meng, et al. Expires November 14, 2014 [Page 14] Internet-Draft Service Function Chaining Use Cases May 2014 SFC11: DPI--Qos1 |---Qos2 In SFC10, there are two different outputs, Qos1 and Qos2. Firstly, traffic from multicast source go through DPI, which used for detecting whether the multicast traffic are legal or unmalicious. After that, legal traffic propagate to different Qos, and next, each goes through different BNAS- to different STB subscirbers separately. 3.4.2. VoIP/MoIP TBD Meng, et al. Expires November 14, 2014 [Page 15] Internet-Draft Service Function Chaining Use Cases May 2014 4. Considerations 4.1. Service Function Chain Symmetry A complete end-to-end access in broadband network should consist of a set of service function instances in a specific order. Such as: a.1. Outbound : UM -> NAT Inbound : NAT -> UM a.2. Outbound : SOFTWIRE -> UM -> QoS -> SOFTWIRE -> NAT Inbound : NAT -> UM -> QoS -> SOFTWIRE -> SOFTWIRE a.3. Outbound : UM -> FIREWALL6 -> NAT64 Inbound : FIREWALL4 -> NAT64 -> UM etc. 4.2. Deploying consideration 4.2.1. Standalone mode In broadband networks, service function components are hanging next to routers such as CPEs/BNASs/CRs. All traffics would be received and steered by routers. Routers send the traffic to classifier in which traffic that matches classification criteria is forwarded along a given SFP to realize the specifications of an SFC. Meng, et al. Expires November 14, 2014 [Page 16] Internet-Draft Service Function Chaining Use Cases May 2014 +-----------+ | Host | +-----+-----+ | | +---------|---------+ +-------------------+ | | | ------------- | | CPE -----> | SFP | | | <----- -------------- | +---------|---------+ +-------------------+ | | --------|------- / | \ | ISP core network | \ | / ------- | ------- | | +---------|---------+ +-------------------+ | | | ----------- | | BNAS |----> | SFP | | | <----| ----------- | +---------|---------+ +-------------------+ | | --------|-------- / | \ | Internet | \ | / --------|-------- Figure 10: Standalone mode Take DS-Lite CGN for example. Outbound traffic: In the example shown in Figure X, a datagram received by the CPE from the host at address 10.0.0.1, using TCP DST port 10000, will be translated to a datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the Internet. When the datagram 1 is received by the CPE, the CPE sent it to a specific classifier which determines the datagram should be forwarded directly or dealed with DS-Lite process. Then the classifier sends the datagram within service header encapsulated to the first element Meng, et al. Expires November 14, 2014 [Page 17] Internet-Draft Service Function Chaining Use Cases May 2014 of SFP. SF-SOFTWIRE encapsulates the datagram in another datagram (datagram 2) and forwards it BACK to CPE over the softwire. The datagram 2 would be sent to the Dual-Stack Lite carrier-grade NAT by CPE. When the BNAS receives datagram 2, the BNAS sends it to a classifier and find it need to be dealed with DS-Lite process. Then the classifier send the datagram within service header encapsulated to the first element of SFP. SF-SOFTWIRE decapsulates the datagram 2 to datagram 1 and forwards it SF-NAT, which determines from its NAT table that the datagram received on the softwire with TCP SRC port 10000 should be translated to datagram 3 with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000. The translated datagram would be also sent back to BNAS for next forwarding. Inbound traffic: Figure x shows an inbound message received at the classifer. When the BNAS receives datagram 1, the BNAS sends it to a classifier. Then the classifier sends the datagram within service header encapsulated to the first element of SFP. SF- NAT looks up the IP/ TCP DST information in its translation table. In the example in Figure 3, the NAT changes the TCP DST port to 10000, sets the IP DST address to 10.0.0.1, and it will be sent back to BNAS to forwards the datagram to the softwire. The SF-SOFTWIRE of the CPE decapsulates the IPv4 datagram inbound softwire datagram and forwards it to the host. 4.2.2. Directly connecting mode There is another mode to deploy service function components. In broadband home networks, service function components are directly connected to the network. They are connected straight to a BNAS or Routers. Under this scenario, it seems like more costly than standalone mode during transition period. Meng, et al. Expires November 14, 2014 [Page 18] Internet-Draft Service Function Chaining Use Cases May 2014 | +-----------+ out | Host | | +-----+-----+ v | +---------|---------+ +-------------+ | |-out->classifier A | | | +------|------+ | CPE | | | | | | | out +---------/\--------+ | || | +<===== in =====+------v------+ | | | SFP A | | | +<----- out-----+------/\-----+ | || +---------v---------+ || | | || | | || | BNAS | || | | +------||-----+ | |==in=>classifier B | +---------|---------+ +-------------+ --------|-------- /\ / | \ || | METRO NETWORK | in \ | / || ---------^-------- . . +---------+---------+ | | | | +-------------+ | CR | | SFP N | | | +-------------+ | | +-------------------+ Figure 11: Directly connecting mode Take NAT44 for example. Outbound traffic: For directly connecting mode, the difference in dealing with traffic Meng, et al. Expires November 14, 2014 [Page 19] Internet-Draft Service Function Chaining Use Cases May 2014 is whether the network steer the traffic loopback. That means service function node could send datagrams directly to the next hop. For example, when the outbound datagram is received by the BNAS and processed by classifer A and SF-NAT which forward the processed datagram straight next to router. Inbound traffic: It is quite similar with the process of dealing with outbound traffic. when the inbound datagram is received by the router and processed by classifer B and SF-NAT which forward the processed datagram straight next to NAT BNAS. 4.3. Pool consideration In traditional networks, pools are configured in router one by one. Pool configuration means these IP addresses in each pool MUST be advertised for creating forward routing path to ensures that the message is routed to the correct target, especially to inbound traffic. Thus, pool location is a problem we must face to in SFC framework. In standalone mode shown in figure 6, pool could be configured in the classifier beside gateway and advertised by the gateway itself. The classifier would assign IP addresses to service functions for creating mapping table. Both-bound traffic should be forward to gateway first and then for NAT treatment in relative service function components. In Directly connecting mode shown in figure 7, pool could be configured in classifier B and advertised by classifier B for creating inbound routing path. There is a mechanism to manage the address pools centrally. Pools could be assigned to classifiers by management server which is handled by Operators centrally. 4.4. NAT traversal TBD 4.5. Unify home router TBD Meng, et al. Expires November 14, 2014 [Page 20] Internet-Draft Service Function Chaining Use Cases May 2014 5. IANA Considerations This memo includes no request to IANA. Meng, et al. Expires November 14, 2014 [Page 21] Internet-Draft Service Function Chaining Use Cases May 2014 6. Security Considerations TBD Meng, et al. Expires November 14, 2014 [Page 22] Internet-Draft Service Function Chaining Use Cases May 2014 7. Normative References [I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", draft-ietf-sfc-problem-statement-05 (work in progress), April 2014. [I-D.ietf-softwire-lw4over6] Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS- Lite Architecture", draft-ietf-softwire-lw4over6-08 (work in progress), March 2014. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP)", draft-ietf-softwire-map-10 (work in progress), January 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- Stack Lite", RFC 6519, February 2012. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. Meng, et al. Expires November 14, 2014 [Page 23] Internet-Draft Service Function Chaining Use Cases May 2014 Authors' Addresses Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: meng.wei2@zte.com.cn,vally.meng@gmail.com Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Bhumip Khasnabish ZTE TX, Inc. 55 Madison Avenue, Suite 160 Morristown, New Jersey 07960 USA Email: bhumip.khasnabish@ztetx.com Meng, et al. Expires November 14, 2014 [Page 24]