Internet DRAFT - draft-chau-sfc-dynamic-forwarding-by-constraints
draft-chau-sfc-dynamic-forwarding-by-constraints
SFC working group CHAU
Internet Draft PARK
Intended status: <Informational> JUNG
Expires: December 10 , 2015 Soongsil University
June 30, 2015
Dynamic Forwarding by Constraint Options in SFC
draft-chau-sfc-dynamic-forwarding-by-constraints-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 30, 2015.
Copyright Notice
Copyright (c) 2015 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.
Chau, et al. Expires December 30, 2015 [Page 1]
Internet-Draft SFC Constraint June 2015
Abstract
This draft describes a Constraint-based Dynamic Control (CDC)
inserted into SFC architecture to support dynamic assignment of
Service Function (SF) with the use of filters functions. SFC
Operators only need to provide general conditions for a chaining
with CDC.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document............................ 3
3. Terminology ................................................. 3
4. Operational Procedures....................................... 4
4.1. Static Mode of Service Forwarding ...................... 4
4.2. Dynamic Mode of Service Forwarding ..................... 4
4.3. Logical conjunction in Dynamic SFC ..................... 4
4.4. Logical disjunction in Dynamic SFC ..................... 4
5. Constraint-based Headers..................................... 5
5.1. Constraint Header Format................................ 5
5.2. Base Header Format...................................... 5
5.3. Constraint Header Format................................ 6
6. Security Considerations...................................... 7
7. IANA Considerations ......................................... 7
8. References .................................................. 7
8.1. Normative References.................................... 7
8.2. Informative References.................................. 7
9. Acknowledgement ............................................. 7
Authors' Addresses ............................................. 8
1. Introduction
This draft describes a Constraint-based Dynamic Control (CDC) that
inserted into SFC architecture to support dynamic assignment of
Service Function (SF) with the use of filters functions.
Flow distribution, which is illustrated through Service Function
Chain (SFC) and Service Function Path (SFP), is a crucial point to
bring stability and improve performance to the SFC domain. Although
SFC and SFP are specified in most of the cases, there are some cases
where they can be decided through constraint options. Without
specific information, SFC Control Plane or SFF can decide
dynamically which SFC and SFP option is suitable for an incoming
flow using constraint options.
Some but not all use cases for the constraint options are:
Chau, et al. Expires December 30, 2015 [Page 2]
Internet-Draft SFC Constraint June 2015
o The SFP "must travel/must not travel" through one or more "type
of SF"
o The SFP "must travel/must not travel" through one or more
"organization"
o The SFP "may travel" through "type of service functions". The
"may" constraint means that this is an optional constraint.
o The SFP "must travel" through "type of service" "AND/OR" "another
type of service"
2. Conventions used in this document
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 RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
This draft uses the following terminologies defined by SFC-arch.
o SF: Service Function [SFC-arch]
o SFC: Service Function Chain [SFC-arch]
o SFF: Service Function Forwarder [SFC-arch]
o SFP: Service Function Path [SFC-arch]
o NSH: Network Service Header [SFC-nsh]
Here are the terminologies specific for this draft:
o CDC: Constraint-based Dynamic Control
o CNH: Constraint Header
o OrgID: Organization ID
o RCF: Related Constraint Field
Chau, et al. Expires December 30, 2015 [Page 3]
Internet-Draft SFC Constraint June 2015
4. Operational Procedures
4.1. Static Mode of Service Forwarding
When a Service Classification Function intends to put SFP and SFC
into Static Mode, it SHOULD NOT append CNH into target packet or
MUST append the CNH with the F bit set as 0.
On receipt of the packet, the SFF MUST treats packets without CNH as
normal SFC packet. The same process is applied with the following
cases:
o Packets that have CNH with F bit set as 0
o Packets that have CNH with F bit set as 1 and CLength bits set as
0.
4.2. Dynamic Mode of Service Forwarding
When a Service Classification Function intends to put SFP and SFC
into Dynamic Mode, it SHOULD NOT append CNH into target packet or
MUST append the CNH with the F bit set as 1 and CLength bit MUST be
more than 0.
On receipt of the packet, the SFF MUST treats packets as dynamic SFC
packet and processes based on information set on the base header and
constraint headers.
4.3. Logical conjunction in Dynamic SFC
When a Service Classification Function intends to make a conjunction
between constraint headers (for example: between constraint headers
A and B), it MUST appends the constraint header ID of B to the RCF
of constraint header A.
On receipt of the packet, the SFF MUST treats two constraint headers
same as A "AND" B.
4.4. Logical disjunction in Dynamic SFC
When a Service Classification Function intends to make a disjunction
between constraint headers, it MUST NOT append the constraint header
ID of any constraint header to the RCF of other constraint headers.
On receipt of the packet, the SFF MUST treats constraint headers
with zero value in RCF as "OR" logical.
Chau, et al. Expires December 30, 2015 [Page 4]
Internet-Draft SFC Constraint June 2015
5. Constraint-based Headers
A Constraint Header (CNH) contains single constraint information and
its related metadata. A Service Classification Function, which is
used to handle SFC policy and encapsulation, is also responsible for
adding CNHs to a packet and set the service forwarding mode to
dynamic when the packet reaches the boundary of SFC-enabled domain.
5.1. Constraint Header Format
A CNH consists of a 4-byte base header and constraint headers, as
shown in Figure 1 below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Constraint Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Constraint Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Constraint Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Constraint Header
Base header: provides basic information about the forwarding header.
Constraint header: provides information about constraint ID,
organization ID, service type, constraint option, related constraint
ID.
5.2. Base Header Format
Base header is an extension of NSH base format. One of the
reservation bit is used as Service Forwarding Mode information.
Chau, et al. Expires December 30, 2015 [Page 5]
Internet-Draft SFC Constraint June 2015
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|F|CLength|R| Length | MD Type | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Base Header Fields Descriptions
Except for the left-to-right count 4 to 8 bit, all field
descriptions are the same as described in [SFC-nsh]
F bit: Indicates that this packet is treated as dynamic/constraint
or static/normal mode. 0 bit indicates normal mode and 1 bit
indicates the dynamic mode.
CLength: The total Constraint header length.
5.3. Constraint Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | OrgID | Type | C |R|R| RC | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ID: The first 4 bits indicate the constraint ID (maximum is 16 of
constraints)
OrgID: The next 1-byte length which indicates the organization ID of
SFs. 0 value means any organization is possible.
Type: 4 bits that indicate the service type. For example: Web filter,
Mail filter, DLP?0 value means any type of service is possible.
C bits: Constraint bit which indicates the constraint that is given
to this header. An example can be must travel, must not travel, may
travel?The next two R bits are reserved for the development of
constraint condition.
Chau, et al. Expires December 30, 2015 [Page 6]
Internet-Draft SFC Constraint June 2015
Related Constraint ID (RC): Some constraints are related with other
constraints (like AND condition). This field indicates the relation
of this header to another header.
Other bits are reserved.
6. Security Considerations
(TBD)
7. IANA Considerations
(TBD)
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[SFC-arch] Quinn, P., Ed. and J. Halpern, Ed., "Service Function
Chaining (SFC) Architecture", 2014,
<http://datatracker.ietf.org/doc/draft-quinn-sfc-arch>.
[SFC-nsh] Quinn, P. and J. Guichard, "Network Service Header", 2014,
<http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh>
9. Acknowledgement
(TBD)
Chau, et al. Expires December 30, 2015 [Page 7]
Internet-Draft SFC Constraint June 2015
Authors' Addresses
Ngoc-Tu Chau
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: chaungoctu@ssu.ac.kr
Jungsoo Park
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: ddukki86@ssu.ac.kr
Souhwan Jung
Soongsil University
369, Sangdo-ro, Dongjak-gu,
Seoul 156-743, Korea
Email: souhwanj@ssu.ac.kr
Chau, et al. Expires December 30, 2015 [Page 8]
