| I2RS Working Group | S. Hares |
| Internet-Draft | L. Dunbar |
| Intended status: Informational | Huawei |
| Expires: January 3, 2015 | July 2, 2014 |
An Information Model for Service Chaining Policy
draft-hares-dunbar-i2rs-sfc-policy-im-00
This draft describes an I2RS information model for managing the service chain steering policy rules to a router via the I2RS interface (SFC-Policy IM).
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 3, 2015.
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 described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
This draft describes an I2RS information model for managing the Service Chain via the I2RS interface.
|1 ----- |n |21 ---- |2m
+---+---+ +---+---+ +-+---+ +--+-----+
| SF#1 | |SF#n | |SF#i1| |SF#im |
| | | | | | | |
+---+---+ +---+---+ +--+--+ +--+--+--+
: : : : :
: : : : :
\ / \ /
+--------------+ +--------+ +---------+
-- >| Chain | | SFF | ------ | SFF | ---->
|classifier | |Node-1 | | Node-i |
+--------------+ +----+---+ +----+--+-+
\ | /
\ | SFC Encapsulation /
\ | /
,. ......................................._
,-' `-.
/ `.
| Network |
`. /
`.__.................................. _,-'
Figure 1 Framework of Service Chain
There are two major categories of information models for Service Chain management: [I-D.hares-i2rs-info-model-service-topo]. Additional I2RS modes on basic network policy (BNP IM) and Policy based Routing (PBR IM) is contained in [I-D.hares-i2rs-info-model-policy].
This document focuses on the second - the traffic flow steering rules as expressed in I2RS policies. The Service function instance discovery and computation is out of scope for this document. An I2RS information model for Service Topology with its Traffic Engineering Databased (TED) and associated inventory can be found in
This section reviews the requirements of SFC Flow Filtering Policies for an existing service topology.
Inherent in the [I-D.ietf-sfc-problem-statement] is the need for policies that establish and filter data flow on the Service Topology pathways. This document defines an I2RS model to interface to the SFC's Service Function Forwarding (SFF) to change the the Policy controlling data flow and service.
The SFC use case [I-D.bitar-i2rs-service-chaining] suggests SFF resources that must be on each SFF Node (SFFN). The SFFN resources include the following elements that the I2RS Client-I2RS Agent protocol can utilize:
<SFF_node> ::= <SFFN_address> /*SFC-Use-REQ01 */
[<SFFN_supported_types>] /*SFC-Use-REQ02 */
[<SFFN_virtual_contexts>] /*SFC-Use-REQ03 */
[<SFFN_customer_cnt>] /*SFC-Use-REQ04 */
[<SFFN_Customer_support_table>] /*SFC-Use-REQ05 */
[<SFFN_Service_Resource_table>] /*SFC-Use-REQ06 */
[<SFFN_VNTopo>] /*SFC-Use-07*/
<SFFN_address> ::== [<ip_address>]
| [ (<service-node-ip_address>
<host-system-ip_address>)]
| [ (<hosting-system-ip_address>
<system-internal_ID>)]
<service-node-ip_address> ::= <ip_address>
<host-system-ip_address> ::= <ip_address>
<hosting-system-ip_address> ::= <ip_address>
<system-internal_ID> ::= INTEGER-64;
/* SFC-Use-02 */
<SFFN_supported_types> ::= <SFFN_Types>
<SFFN_Types> ::= [<SFF_TYPE_FW>]
[<SFF_TYPE_LB>]
[<SFF_TYPE_DPI>]
[<SFF_TYPE_NAT>]
/* SFC-Use-03 */ ...
<SFFN_virtual_contexts> ::== <VContext_max>
<VContext_current_inuse>
<VContext_current_avail>
<SFFN_Types>
/*SFC-Use-04 */
<SFFN_customer_cur_cnt> ::= INTEGER;
/* SFC-Use-05: Customer Support Table per Customer ID */
<SFFN_customer_table> ::= [<SFFN_customer< ...]
<SFFN_customer> ::= <SFFN_customer_Name>
<SFFN_customer_ID>
<SFFN_customers_contexts>
<SFFN_customers_contexts> ::= <SFFN_Types>
/*SFC-Use-REQ06 */
<SFFN_Service_Resource_table> ::= <SFF_Service_resource_index>
<SFFN-SR_service_BW_capacity>
<SFFN-SR_packet_rate_max>
<SFFN-SR_BW>
<SFFN-SR_IP_fwd_instance_list>
<SFFN-SR_MAX_RIB>
<SFFN-SR_MAX_FIB>
<SFFN-SR_MAX_COUNTER64>
<SFFN-SR_MAX_Flows>
<SFF_Service_resource_index> := <SFFN_Address>
<VContext_ID>
<Service_types>
/*SFC-Use-REQ07
* SFC_topology is defined by
* ietf-hares-i2rs-service-topology
* which includes node code
*/
<SFF_VNT> ::= <SFC_Topology>
A Service function instance can be either attached to a router via a physical interface or instantiated on a virtual machine that is attached to a router. Following are our assumptions:
Service Chain Manager/Controller
^ |
| | A: Set filter for
B: | | the interested service
Router reports the | | function instances
Directly attached | |
Service Function | |
Instances | V
+------+---+-------------+
| Router |
++-----+----------+------+
/ | | \
/ | | \
+-+-+ +-+-+ +-+-+ +-+-+
| |... | | | | ... | |
+---+ +---+ +---+ +---+ Server racks
| |... | | | | ... | | for hosting
+---+ +---+ +---+ +---+ Service
| |... | | | | ... | | Function
+---+ +---+ +---+ +---+ Instances
Figure 1: Service Function Instances
Service Function Instances placement can be managed by entities that are not integrated with Service Chain Manager. Therefore, it is necessary for the Service Chain Manager to discover all the Service Function Instances that might be needed for a specific service chain. Service Chain Manager can send down the filter periodically or on-demand (i.e. when there is a request for building a specific service chain for a client).
Some service function instances are attached to router via tunnels, e.g. VxLAN. Service Function Instances might be partitioned by clients, which are differentiated by different network ID (e.g. VNID, VPN ID, etc). Some filter will carry the network ID (tenant ID, or VPN ID) to get specific service functions.
The I2RS Client can operate as the service chain manager/controller communicating with the I2RS Agents operating in the router or I2RS Agents operating on the service function instances in the server racks to discover and control specific service function instances.
The I2RS Client-Agent must be able to discover the I2RS Agent associated with a specific Service Function instance by querying for: SFFN Address,SFFN type, or SFFN virtual context or SFFN Customer;
<interested-SF-filter> ::= <SF-FILTER-NAME>
[<ipv4-address-list>|<ipv6-address-list>]
[<client-identifier>]
<ipv4-address-list> ::= ((<ipv4-address>
|<ipv4-prefix>) ...)
<ipv4-prefix> ::= <IPV4_ADDRESS><IPV4_PREFIX_LENGTH>
<ipv6-address-list> = ((<ipv6-address>
|<ipv6-prefix>) ...)
<ipv6-prefix> ::= <IPV6_ADDRESS><IPV6_PREFIX_LENGTH>
<client-identifier> ::= <client-identifier-type>
<client-identifier >
<client-identifier-type> ::= <GRE>
| <VxLAN>
| <NVGRE>
<client-identifier > ::= (<VXLAN> <VXLAN_IDENTIFIER>)
| (<NVGRE> <VIRTUAL_SUBNET_ID>)
| (<GRE> <GRE_KEY>)
When a router receives the filter of the interested Service Function Instances, it can scan through all its interfaces to check if any of the addresses in the filter list are attached to the interfaces. For the Service Function Instances attached via Layer 2, the router can send ARP/ND to get the matching instances to respond. For the Service Function Instances attached via Layer 3, the router can use Ping to check if the addresses in the filter are attached.
The response should be grouped by <SF-FILTER-NAME >
<sf-instance-list> ::= <INSTANCE-LIST-NAME>
< SF-FILTER-NAME>
[<INTERFACE_IDENTIFIER>
|<ipv4-address-list>
|<ipv6-address-list>]]
The semantics of traffic steering rules is "Match" and "Action", similar to the "route" described in [I-D.ietf-i2rs-rib-info-model]. However, there are more matching criteria for traffic steering rules.
match
|
|
+-------+-------+-------+--------+-------+-----------+-----
| | | | | | |
| | | | | | |
IPv4 IPv6 tunnel MAC VLAN VxLAN ID Interface
(Unicast/Multicast SAFI)
The steering rules include matches on combinations of:
<SFC-Policy> ::= <steering-rules>
<steering-rules> ::= <match> <action>
<match> ::= <address>
|<label>
|<interface>
|<l4-field>
|<packet-size>
<address> ::= <ip-address>
|<multicast-address>
|<mac-address>]
<ip-address> ::= <IPV4_ADDRESS>
|<ipv4-prefix >
|<IPV6_ADDRESS>
|<ipv6-prefix >]
<label> ::= [MPLS_LABEL] | <VXLAN-ID> | <GRE-KEY>
<l4-field>::= <TCP_PORT> | <UDP-PORT>
<action> ::= <nexthop-list>
|<drop-policy>
|<metadata>
<drop-policy> ::= <PASS>|<DROP>
<metadata> ::= [<ATTACH> <object>] | <detach>
The I2RS interface of a router should allow "write" and "read" of above objects.
The SC use cases described in this document assumes use of I2RS programmatic interfaces described in the I2RS framework mentioned in [I-D.ietf-i2rs-architecture]. This document does not change the underlying security issues inherent in the existing in [I-D.ietf-i2rs-architecture].
This draft includes no request to IANA.
We'd like to thank Qin Wu for his comments on this document relating to the service topologies.
| [I-D.ietf-i2rs-architecture] | Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-00, August 2013. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.bitar-i2rs-service-chaining] | Bitar, N., Heron, G., Fang, L., ramki, r., Leymann, N., Shah, H. and W. Haddad, "Interface to the Routing System (I2RS) for Service Chaining: Use Cases and Requirements", Internet-Draft draft-bitar-i2rs-service-chaining-01, February 2014. |
| [I-D.hares-i2rs-info-model-policy] | Hares, S. and W. Wu, "An Information Model for Network policy", Internet-Draft draft-hares-i2rs-info-model-policy-01, February 2014. |
| [I-D.hares-i2rs-info-model-service-topo] | Hares, S., Wu, W. and X. Guan, "An Information model for service topology", Internet-Draft draft-hares-i2rs-info-model-service-topo-00, February 2014. |
| [I-D.ietf-i2rs-rib-info-model] | Bahadur, N., Folkes, R., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-01, October 2013. |
| [I-D.ietf-sfc-problem-statement] | Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", Internet-Draft draft-ietf-sfc-problem-statement-00, January 2014. |
| [I-D.medved-i2rs-topology-requirements] | Medved, J., Previdi, S., Gredler, H., Nadeau, T. and S. Amante, Topology API Requirements", Internet-Draft draft-medved-i2rs-topology-requirements-00, February 2013. |
| [I-D.white-i2rs-use-case] | White, R., Hares, S. and R. Fernando, "Use Cases for an Interface to the Routing System", Internet-Draft draft-white-i2rs-use-case-00, February 2013. |
| [NFV-Terminology] | Network Functions Virtualization (NFV); Terminology for Main Concepts in NFV", . | , "