service function chain W. Meng
Internet-Draft C. Wang
Intended status: Infomational ZTE Corporation
Expires: January 5, 2015 C. Xie
China Telecom
B. Khasnabish
ZTE TX, Inc.
July 4, 2014
service function chain Use Cases in Broadband
draft-meng-sfc-broadband-usecases-02
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 January 5, 2015.
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
Meng, et al. Expires January 5, 2015 [Page 1]
Internet-Draft service function chain Use Cases July 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . . 12
3.3. Internet Access from Campuses . . . . . . . . . . . . . . 13
3.4. Added-value Service Access . . . . . . . . . . . . . . . . 13
3.4.1. Destination Address Accounting(DAA) . . . . . . . . . 13
3.4.2. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3. VoIP/MoIP . . . . . . . . . . . . . . . . . . . . . . 16
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Service Function Chain Symmetry . . . . . . . . . . . . . 17
4.2. Deploying consideration . . . . . . . . . . . . . . . . . 17
4.2.1. Standalone mode . . . . . . . . . . . . . . . . . . . 17
4.2.2. Directly connecting mode . . . . . . . . . . . . . . . 19
4.3. Pool consideration . . . . . . . . . . . . . . . . . . . . 21
4.4. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 21
4.5. Unify home router . . . . . . . . . . . . . . . . . . . . 21
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. Normative References . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Meng, et al. Expires January 5, 2015 [Page 2]
Internet-Draft service function chain Use Cases July 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 aims to illustrate the possibly typical and unified service
function chains in Broadband Networks and analyze the possible
deployments of diverse service function chains in broadband network.
In figure 1, here outlines the possible SFC deployment architecture
in Broadband Networks.
+-----------+ +-----------+
| Host1 | ... | HostN |
+-----+-----+ +-----+-----+
| |
+-----+-----+ +-----+-----+
| CPE | | CPE |
+-----+-----+ +-----+-----+
| |
|---------|---------|
|
+-------+---------+
| SFCs |
. +-------+---------+ .
. | .
+-------|---------+ +-------|---------+ +-------|---------+
| BNAS | | BNAS | | BNAS | ...
+-------|---------+ +-------|---------+ +-------|---------+
| | |
+---------------------|--------------------+
|
+------+------+
| SFCs |
+------+------+
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
Figure 1: SFC Architecture of Broadband Network
Meng, et al. Expires January 5, 2015 [Page 3]
Internet-Draft service function chain Use Cases July 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 SFC are defined in [I-D.ietf-sfc-problem-statement].
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].
Meng, et al. Expires January 5, 2015 [Page 4]
Internet-Draft service function chain Use Cases July 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 2 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 2: Architecture of Broadband Network
Also, the Broadband Forum(BBF) is developing a study document(SD-
326), which aims to study market requirements and usecases for
Flexible Service Chaining. Some usecases in SD-326 are referenced
here, and as well as that, this document tries to develop more
typical usecases in Broadband Networks.
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 3: Native IPv4 Network or Native IPv6 Network
Figure 3 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.
Meng, et al. Expires January 5, 2015 [Page 5]
Internet-Draft service function chain Use Cases July 2014
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. 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:
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
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 4, 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 or NAT444 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 them in detail.
Meng, et al. Expires January 5, 2015 [Page 6]
Internet-Draft service function chain Use Cases July 2014
---------------------------------------------------------------------------->
+--- + +--- + +-------+ +-----+ +----------+
| | | | |DPI/DFI| | LB/ | |URL Filter|---|
|--| UM |---|NAT |---| /Qos |---| FRR |---| /FW/PC | |
| +----+ | +----+ | +-------+ | +-----+ | +----------+ |
+---+ +------+ | | | | +-----+ +---------+
|CPE|--| BNAS-|------|--------|-----------|---------|-------------| CR |---| Internet|
+---+ +------+ +-----+ +---------+
Figure 4: IPv4/IPv6 Coexist Network
Whether NAT stands for NAT44 or NAT64 or NAT46 depends on the the
Internet Server Provider. It may be NAT44, which reflects the
communication between IPv4 private customer IPv4 Server. Or it may
be NAT64, which means the communication between IPv6 customer and
IPv4 Server. And where NAT is deployed is based on the Internet
Server Provider as well. It may be besides BNAS,which stands for
distributed deployment, or besides CR,which represents central
deployment.
Above figure 4 just gives a simple example of a possible deployment
position in distributed deployment scenario. Actually, there are
some other complicated IPv6 transition scenarioes . And this section
tries to give some typical examples in IPv4/IPv6 coexist network, and
conclude a feasible SFC architecture in IPv4/IPv6 coexist network.
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. NAT44
Figure 5 illustrates in a simple NAT44 scenario how SF-NAT is
deployed.
Meng, et al. Expires January 5, 2015 [Page 7]
Internet-Draft service function chain Use Cases July 2014
.
:
|
............... |
External realm |
ISP network--> |-------------+
| ++---|----++
| | SF-NAT44 |
| ++---|----++
|-------------+
++--|----+
........... | BNAS- |
Internal realm ++------++
| |
ISP network--> | |
| |
++------++ ++------++
| CPE1 | | CPE2 | etc.
++------++ ++------++
Figure 5: 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.
Meng, et al. Expires January 5, 2015 [Page 8]
Internet-Draft service function chain Use Cases July 2014
3.1.2.2. NAT64
+-----------+
|IPv6 Host |
+-----+-----+
|
+---------|---------+
| CPE |
+---------|---------+
--------|--------
/ | \
| IPv6 Network |
\ | /
--------|--------
|
+---------|---------+ +------------+
| BNAS | |DNS64 Server|
+---------|---------+ +------------+
+-----------+
| +-----|------+
| | SF-NAT64 |
| +-----|------+
+-----------+
--------|--------
/ | \
| IPv4 Internet |
\ | /
--------|--------
Figure 6: 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-. It also may be situated nearby CR.
3.1.2.3. DS-Lite
Figure 7 describes a scenario of DS-lite, which completes IPv4
communication between IPv4 private customer and IPv4 server across
IPv6 network. And the main principle of DS-Lite is to encapsulate
IPv4 packets in IPv6 Header and forward this IPv4-in-IPv6 packets to
CGN device and enforce NAT function in this device.
Meng, et al. Expires January 5, 2015 [Page 9]
Internet-Draft service function chain Use Cases July 2014
+-----------+
| IPv4 Host |
+-----+-----+
|
+---------|---------+
| CPE- |
+---------|---------+
+-----------------+
| +-----|--------+
| | SF-Dslite-Enc|
| +-----|--------+
+-----------------+
|||
|||<-IPv4-in-IPv6 softwire
|||
+--------|||--------+
| BNAS- |
+--------|||--------+
+----------------------+
| +----------|----------+
| | SF-Dslite-Dec |
| | SF-NAT |
| +----------|----------+
+-----------------+
|
|
--------|--------
/ | \
| IPv4 Internet |
\ | /
--------|--------
Figure 7: DS-Lite
SFC7: Dslite-Enc---UM---Dslite-Dec---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. if the datagram
should be dealed with DS-Lite process, then the classifier sends the
datagram within service header encapsulated to Softwire-SN which
contains SF-Dslite-Encapsulation instance. In this instance, it
fulfils DS-Lite encapsulate and then encapsulates overlay header and
forward this datagram to nexthop in the traditional network.
Next, the BNAS- receives the processed datagram, the BNAS- sends it
to a classifier and finds it a legal subscriber and need to be dealed
Meng, et al. Expires January 5, 2015 [Page 10]
Internet-Draft service function chain Use Cases July 2014
with DS-Lite process. then, this datagram is forwarded to SF-Dslite-
Decapsulation to decapsulate DS-Lite encapsulation. And next,
forwarded to SF-NAT to create and maintain the NAT mapping table.
After that, completes the subsequent SFs. In other words, BNAS-,
itself, would not be aware of any stateful sessions.
3.1.2.4. MAP-E
+-----------+
| IPv4 Host |
+-----+-----+
|
+---------|---------+
| CPE- |
+---------|---------+
+-----------------+
| +-----|-------+
| | SF-NAT |
| | SF-MAPE-Enc |
| +-----|-------+
+-----------------+
|||
|||<-IPv4-in-IPv6 softwire
|||
+--------|||--------+
| BNAS- |
+--------|||--------+
+----------------------+
| +----------|---+
| | SF-MAPE-Dec |
| +----------|---+
+----------------------+
|
|
--------|--------
/ | \
| IPv4 Internet |
\ | /
--------|--------
Figure 8: MAP-E
The main difference between MAP-E and DS-Lite is where NAT happens.
And the result is that 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 or
CR device. So here gives an example of this scenario:
Meng, et al. Expires January 5, 2015 [Page 11]
Internet-Draft service function chain Use Cases July 2014
SFC8: NAT---MAPE-Enc---UM---MAPE-Dec---LB---URL Filter
In more detail, for outbound traffic in MAP-E SFC scenario, When the
datagram is received by the home router, the CPE sends it to a
specific classifier which determines the datagram should be forwarded
directly or dealed with MAP-E process. if the datagram should be
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-Enc, which encapsulates the datagram with
the MAP BR IPv6 address in 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 MAP-E process. Then the classifier sends the datagram within
service header encapsulated to SF-MAPE-Dec. This SF-MAPE-Dec
decapsulates this datagram, and then propagates the datagram to other
SFs in this chain.
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 9: 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 for external service functions deployed by ISP, a typical service
Meng, et al. Expires January 5, 2015 [Page 12]
Internet-Draft service function chain Use Cases July 2014
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 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.
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. Destination Address Accounting(DAA)
Figure 10 illustrates a possible deployment of DAA funtion in
broadband network.
+-----+
|host1|--|
+-----+ | +-------+ +----------+ +-----+ +---------+
--| CPE |---| BRAS+DAA |------| CR |---| Internet|
+-----+ | +-------+ +----------+ +-----+ +---------+
|host2|--|
+-----+
Figure 10: DAA Deployment in broadband network
In this diagram, DAA assists BRAS to accomplish finer-granularity
outbound filter or/and inbound filter based on destination IP
address. But,in central deployment scenario of DS-Lite, there is a
Meng, et al. Expires January 5, 2015 [Page 13]
Internet-Draft service function chain Use Cases July 2014
IPv4-in-IPv6 tunnel from CPE to CR. As a result of that, BRAS cannot
identify the true IPv4 destination address in this IPv4-in-IPv6
packets. And then, BRAS cannot enforce DAA function to manage the
subscriber more flexibly.
SFC11: DAA----Dslite-Enc----Dslite-Dec----NAT
+-----------+ +-----------+
| Host1 | | Host2 |
+-----+-----+ +-----+-----+
| |
+-----|-----+ +-----|-----+
| CPE2- | | CPE2- |
+-----|-----+ +-----|-----+
| |
|---------|---------|
|
+-------|---------+
| SF-DAA |
+-------|---------+
|
+-------|---------+
| SF-Dslite-Enc |
+-------|---------+
|
|||
|||<--softwire
|||
+--------|||--------+
| CR |
+--------|||--------+
+----------------------+
| +----------|-----+
| | SF-Dslite-Dec |
| | SF-NAT |
| +----------|-----+
+----------------------+
|
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
Figure 11: DAA + Softwire Deployment in broadband network
Meng, et al. Expires January 5, 2015 [Page 14]
Internet-Draft service function chain Use Cases July 2014
3.4.2. IPTV
Figure 12 illustrates a possible deployment of IPTV network via SFC.
<----------------------------------------------------
+----+
|STB1|-------|
+----+ |
|
+----+ +-------+ +------+
|STB2|---| BNAS1-|----| Qos1 |---------|
+----+ +-------+ +------+ |
| |
+----+ | |
|STB3|-------| |
+----+ |
+---------+ +-----+
+----+ | DPI/DFI |-----| CDN |
|STB4|-------| +---------+ +-----+
+----+ | |
| |
+----+ +-------+ +------+ |
|STB5|---| BNAS2-|----| Qos2 |---------|
+----+ +-------+ +------+
|
+----+ |
|STB6|-------|
+----+
Figure 12: 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 are 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 :
SFC11: DPI--Qos1
|---Qos2
In SFC11, as for the inbound traffic, 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.
Meng, et al. Expires January 5, 2015 [Page 15]
Internet-Draft service function chain Use Cases July 2014
3.4.3. VoIP/MoIP
TBD
Meng, et al. Expires January 5, 2015 [Page 16]
Internet-Draft service function chain Use Cases July 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 January 5, 2015 [Page 17]
Internet-Draft service function chain Use Cases July 2014
+-----------+
| Host |
+-----+-----+
|
|
+---------|---------+ +-------------------+
| | | ------------- |
| CPE -----> | SFP | |
| <----- -------------- |
+---------|---------+ +-------------------+
|
|
--------|-------
/ | \
| ISP core network |
\ | /
------- | -------
|
|
+---------|---------+ +-------------------+
| | | ----------- |
| BNAS |----> | SFP | |
| <----| ----------- |
+---------|---------+ +-------------------+
|
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
Figure 13: 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 January 5, 2015 [Page 18]
Internet-Draft service function chain Use Cases July 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 January 5, 2015 [Page 19]
Internet-Draft service function chain Use Cases July 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 14: Directly connecting mode
Take NAT44 for example.
Outbound traffic:
For directly connecting mode, the difference in dealing with traffic
Meng, et al. Expires January 5, 2015 [Page 20]
Internet-Draft service function chain Use Cases July 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 January 5, 2015 [Page 21]
Internet-Draft service function chain Use Cases July 2014
5. IANA Considerations
This memo includes no request to IANA.
Meng, et al. Expires January 5, 2015 [Page 22]
Internet-Draft service function chain Use Cases July 2014
6. Security Considerations
TBD
Meng, et al. Expires January 5, 2015 [Page 23]
Internet-Draft service function chain Use Cases July 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-07
(work in progress), June 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-10 (work
in progress), June 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 January 5, 2015 [Page 24]
Internet-Draft service function chain Use Cases July 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
Xie Chongfeng
China Telecom
Room 502, No.118, Xizhimennei Street
Beijing
China
Email: xiechf01@gmail.com,xiechf@ctbri.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 January 5, 2015 [Page 25]