SFC working group CHAU Internet Draft PARK Intended status: 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, . [SFC-nsh] Quinn, P. and J. Guichard, "Network Service Header", 2014, 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]