Flow Release Notify
draft-jing-sfc-flow-release-notify-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | WeiDong Jing , Jingbo Zhao , Xuzhou Zhan , Hongbo Cai , Cui Wang | ||
| Last updated | 2016-07-07 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jing-sfc-flow-release-notify-00
SFC WG W. Jing
Internet-Draft J. Zhao
Intended status: Standards Track X. Zhan
Expires: January 8, 2017 H. Cai
C. Wang
ZTE Corporation
July 7, 2016
Flow Release Notify
draft-jing-sfc-flow-release-notify-00
Abstract
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
SFs and SFC Proxies do not know the termination of a service flow.
This document describes a method to notify the SFs and SFC Proxies
the termination of a service flow.
When one service flow goes through the SFP, there may create some
states in some SFs or SFC Proxies. However, when the service flow
terminates, the SFs and SFC Proxies are unaware of that and maintain
the states as well.This document describes a method to notify the SFs
and SFC Proxies the termination of a service flow and release the
resources occupied by the flow.
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 8, 2017.
Copyright Notice
Jing, et al. Expires January 8, 2017 [Page 1]
Internet-Draft Flow Release Notify July 2016
Copyright (c) 2016 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
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4
3. Defination of Flow Termination Message . . . . . . . . . . . . 5
4. Defination of Flow Termination Indicator . . . . . . . . . . . 6
4.1. Reserved Bit for FTI . . . . . . . . . . . . . . . . . . . 6
4.2. A bit in mandatory context header for FTI . . . . . . . . 7
4.3. TLV for FTI . . . . . . . . . . . . . . . . . . . . . . . 7
5. Classifier Behavior . . . . . . . . . . . . . . . . . . . . . 8
6. Service Function Forwarder behavior . . . . . . . . . . . . . 9
7. SFC Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 10
8. SFC-aware Service Function Behavior . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Jing, et al. Expires January 8, 2017 [Page 2]
Internet-Draft Flow Release Notify July 2016
1. Introduction
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
SFs and SFC Proxies allocate resources (e.g. memory) for service flow
in order to process the packets of service flow correctly.
Typically, in current SFC deployment, there are many SFC-unaware SFs
which need SFC Proxies to assist them to fulfill SFC forwarding.
When service flow goes through these SFC Proxies, there are states
created which really cost resources to assist the return traffic from
the SFC-unaware SFs to retrieve the original NSH encapsulation. When
a service flow terminates, the corresponding states/resources should
be cleaned up. Unfortunately, SFs and SFC Proxies do not know the
termination of a service flow. As a result of that, they cannot
release the resources immediately. Maybe one solution is to set
lifetime for these states, but how long the lifetime should be set is
an issue as well as what if the lifetime is asynchronous between
different SFs and SFC Proxies.
This document describes a synchronous method to notify the SFC-aware
SFs and SFC Proxies the termination of a service flow and then
release the resource occupied by the service flow synchronously.
Jing, et al. Expires January 8, 2017 [Page 3]
Internet-Draft Flow Release Notify July 2016
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 are all defined in rfc7665 and [I-D.ietf-sfc-nsh].
Jing, et al. Expires January 8, 2017 [Page 4]
Internet-Draft Flow Release Notify July 2016
3. Defination of Flow Termination Message
A packet with Flow Termination Indicator is treated as flow
termination message. Flow termination message is a NSH encapsulated
message. It is generated by Classifier, transported along the SFP
and ended at the end of SFP.
The original packet part or the original frame part of flow
termination message shall have sufficient information to identify the
flow that is to be terminated. The information that identify the
flow typically refers to IP five tuple.
+-------------------------------------------------------------+
| NSH Payload |
| (Original L2/L3 frame/packet or other as signaled by NSH) |
+-------------------------------------------------------------+
| |
| Network Service Header (NSH) with FTI |
+-------------------------------------------------------------+
| |
| L4 UDP Header |
+-------------------------------------------------------------+
| |
| L3 (IPv4|IPv6) Header |
+-------------------------------------------------------------+
| |
| L2 (Ethernet) Header |
+-------------------------------------------------------------+
Figure 1: Example of Flow Termination Indicator Format
Jing, et al. Expires January 8, 2017 [Page 5]
Internet-Draft Flow Release Notify July 2016
4. Defination of Flow Termination Indicator
Flow Termination Indicator is a flag in NSH header. There are 3
solutions to allocate Flow Termination Indicator: 1)a reserved bit of
the Base header; 2) a bit of the mandatory context header; 3) specify
a Variable Context Headers
4.1. Reserved Bit for FTI
A T bit of the Base header is allocated for Flow Termination
Indicator.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|T|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Reserved Bit for FTI
T bit: if set, identifies this is a Flow Termination Message.
Jing, et al. Expires January 8, 2017 [Page 6]
Internet-Draft Flow Release Notify July 2016
4.2. A bit in mandatory context header for FTI
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: A bit in mandatory context header for FTI
T bit: if set, identifies this is a Flow Termination Message.
4.3. TLV for FTI
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Class |C| Type |T|R|R| Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV for FTI
T bit: if set, identifies this is a Flow Termination Message.
C bit: should always unset.
TLV Class: TBD.
Type: TBD.
Len: always set to 0x0.
Jing, et al. Expires January 8, 2017 [Page 7]
Internet-Draft Flow Release Notify July 2016
5. Classifier Behavior
If classifier acquires the termination of flow, it may generate flow
termination message and send it to the SFP of the flow. How the
classifier detects the termination of flow is out of the scope of
this document. Here are some examples of how to detect the
termination of flow: in case of mobile network, classifier can be
collocated with PGW. As per 3GPP specification, PGW has interfaces
like S5/S8, Gx,Gy,S6b. All interfaces listed above can be used to
detect the termination of flow. On the other hand, Classifier may
have DPI function, which can observe the TCP FIN packet which is
termination signal of TCP flow.
Jing, et al. Expires January 8, 2017 [Page 8]
Internet-Draft Flow Release Notify July 2016
6. Service Function Forwarder behavior
SFF treats flow termination message as normal traffic in service
chain and forwards it according to SPI/SI.
Jing, et al. Expires January 8, 2017 [Page 9]
Internet-Draft Flow Release Notify July 2016
7. SFC Proxy Behavior
The proxy accepts packets from the SFF on behalf of the SF. It
removes the SFC encapsulation, and then uses a local attachment
circuit to deliver packets to SFC-unaware SFs. It also receives
packets back from the SF, reapplies the SFC encapsulation, and
returns them to the SFF for processing along the service function
path. refer to [RFC 7665]
Thus, it is necessary for SFC proxy to maintain a state for each IP
flows. When traffic is returned from the SFC-unaware SFs, SFC proxy
reapplies the SFC encapsulation according to the encapsulation
information stored in the state. Such states consume a lot of
memory, because millions of states would be maintained.
When SFC Proxy receives flow termination message, it should take
action to release the resources of the flow, which is identified by
the IP five tuple. And then decrements service index and returns the
flow termination message back to SFF.
Jing, et al. Expires January 8, 2017 [Page 10]
Internet-Draft Flow Release Notify July 2016
8. SFC-aware Service Function Behavior
When SFC-aware SF receives flow termination message, it should take
action to release the resources of the flow, which is identified by
the IP five tuple. And then decrements service index and returns the
flow termination message back to SFF.
Jing, et al. Expires January 8, 2017 [Page 11]
Internet-Draft Flow Release Notify July 2016
9. Security Considerations
TBD
Jing, et al. Expires January 8, 2017 [Page 12]
Internet-Draft Flow Release Notify July 2016
10. IANA Considerations
TLV Class and Type of MD-type=0x2 NSH header is to be allocated by
IANA.
TLV Class: TBD.
Type: TBD.
Jing, et al. Expires January 8, 2017 [Page 13]
Internet-Draft Flow Release Notify July 2016
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header",
draft-ietf-sfc-nsh-05 (work in progress), May 2016.
Jing, et al. Expires January 8, 2017 [Page 14]
Internet-Draft Flow Release Notify July 2016
Authors' Addresses
WeiDong Jing
ZTE Corporation
No.6 Huashen Rd, Yuhuatai District
Nanjing
China
Email: jing.weidong1@zte.com.cn
Jingbo Zhao
ZTE Corporation
No.6 Huashen Rd, Yuhuatai District
Nanjing
China
Email: zhao.jingbo@zte.com.cn
Xuzhou Zhan
ZTE Corporation
No.6 Huashen Rd, Yuhuatai District
Nanjing
China
Email: zhan.xuzhou@zte.com.cn
Hongbo Cai
ZTE Corporation
No.6 Huashen Rd, Yuhuatai District
Nanjing
China
Email: cai.hongbo@zte.com.cn
Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China
Email: wang.cui1@zte.com.cn
Jing, et al. Expires January 8, 2017 [Page 15]