<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-sfc-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-problem-statement.xml">
<!ENTITY I-D.bitar-i2rs-service-chaining SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bitar-i2rs-service-chaining.xml">
<!ENTITY I-D.white-i2rs-use-case SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.white-i2rs-use-case.xml">
<!ENTITY I-D.hares-i2rs-info-model-policy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-policy.xml">
<!ENTITY I-D.hares-i2rs-info-model-service-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2rs-info-model-service-topo.xml">
<!ENTITY I-D.medved-i2rs-topology-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.medved-i2rs-topology-requirements.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-hares-dunbar-i2rs-sfc-policy-im-01" ipr="pre5378Trust200902">
  <front>
    <title abbrev="SFC Policy IM">An Information Model for Service Chaining Policy</title>
	<author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
	   <postal>
	      <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
      </address>
    </author>
	<author fullname="Linda Dunbar" initials="L" surname="Dunbar">
      <organization>Huawei</organization>
      <address>
	  <postal>
	      <street>6340 Legacy Drive, Suite 175</street>
          <city>Plano</city>
          <region>TX</region>
          <code>75024</code>
          <country>USA</country>
        </postal>
		 <phone>+1-469-277-5840 </phone> 
        <email>ldunbar@huawei.com</email>
      </address>
    </author>
    <date year="2014" />
    <area>Routing</area>
    <workgroup>I2RS Working Group</workgroup>
    <keyword>RTGWG</keyword>
<abstract>
<t>
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).
</t>
</abstract>
  </front>
  <middle>
    <section title="Introduction">
	<t> This draft describes an I2RS information model for managing the
	 Service Chain via the I2RS interface. 
	</t> 
	</section> 
	<section title="Definition of terms"> 
	<t> 
	  <list style="hanging">
		  
		<t hangText="NFV: Network Function Virtualization"><vspace blankLines="1" />
		   <xref target="NFV-Terminology"></xref>.</t> 
		<t hangText="SF: Service Function "><vspace blankLines="1" /> <xref target="I-D.ietf-sfc-problem-statement"></xref>. </t>
		<t hangText="SFF: Service Function Forwarder"> </t>
		<t hangText="Service Chain"><vspace blankLines="1" /> <xref target="I-D.bitar-i2rs-service-chaining"></xref>
		defines a service chain as an ordered set of services applied to a packet of flow. An example of this
		is a sequence of service function such as Chain#1 {s1, s4, s6} or Chain#2{s4, s7} at functional level.
		Also see the definition of Service Function Chain in <xref target="I-D.bitar-i2rs-service-chaining"></xref> </t> 
		<t hangText="Service Chain Instance Path" ><vspace blankLines="1" /> The actual Service Function Instance
		 Components selected for a service chain.  </t>
		<t hangText="SFFN: Service Function Forwarder Node"><vspace blankLines="1" /> 
		<xref target="I-D.bitar-i2rs-service-chaining"></xref>states service function can run:
		a) natively within a router (or routing system), b) on a virtual machine on a server or service engine,
		or in a dedicated standalone hardware appliance. 		</t>
		<t hangText="VNF: Virtualized Network Function"><vspace blankLines="1" />
		<xref target="NFV-Terminology"></xref></t>
		<t hangText="STOPO"><vspace blankLines="1" />Service topology is a topology of Service nodes (SFF). </t>
		<t hangText="SFFaddr: Service Node Address"><vspace blankLines="1" />
		<xref target="I-D.ietf-sfc-problem-statement"></xref> states this address should be IP Address, or tuple
		of (SFFaddr, host system IP address) or tuple of (host system IP address, system internal ID
		for service engine).</t>
		<t hangText="Service Type "> <vspace blankLines="1" /> <xref target="I-D.ietf-sfc-problem-statement"></xref>.</t>
		</list> 
	 </t>
	 </section> 

<section title="Service Chaining Background">
   <t>
	<figure>
	<artwork>
	                           |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
	
	</artwork>
	</figure>
   </t>
</section>
<section title="Overview of information model for Service Chain"> 
<t> 
There are three major categories of information models for Service Chain management: 
<list> 
<t> 1) Service function instances discovery;</t>
<t> 2) Traffic flow steering rules on a router for specific service chain.</t>
<t> 3) Service Chain path computatino </t> 
</list> 
This document focuses on the  first (service function instance discovery),
 and the second (the traffic flow steering rules) as expressed in
I2RS policies. The third category, the Service Chain path 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 
<xref target="I-D.hares-i2rs-info-model-service-topo"></xref>.  Additional I2RS
modes on basic network policy (BNP IM) and Policy based Routing (PBR IM)
is contained in <xref target="I-D.hares-i2rs-info-model-policy"></xref>.
</t>
</section> 
<section title="Requirements for Service Function Forwarder Node (SFFN) Resources SFC Flow Filtering "> 
<t> This section reviews the requirements for SFC Flow Filtering Policies for
    an existing service for SFFNs within the SFC domain.  </t>
	<t> Inherent in the <xref target="I-D.ietf-sfc-problem-statement"></xref> 
	   is the need for policies that establish and
	    filter data flow on the Service chain
		pathways. This document defines an I2RS model to interface
		to the SFC's Service Function Forwarder (SFF) to install or change the
		the Policy controlling data flow to their designated and service functions and
		subsequent SFFN. </t>
	<t> The SFC use case 
	<xref target="I-D.bitar-i2rs-service-chaining"></xref> 
	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: </t>
	<t>
	  <list style="hanging">
	  <t hangText="SFC-Use-REQ01:Address (R)" ><vspace blankLines="1" /> has the following address requirements: 
		<list style="symbols">
		<t>IP address </t>
		<t> service-node tuple (service node IP address, Host system address)</t>
		<t> host-node tuple (hosting system IP-address, system internal identifier)</t>
		</list> 
		</t>
	    <t hangText="SFC-Use-REQ02:Supported Service Types (R/W) SHOULD include:"><vspace blankLines="1" /> 
		NAT, IP Firewall, Load balancer, DPI, and others. Note that the current SFC WG suggest
		that the SFF does not need to know the SFFN type to steer the data to their
		designated service function. Therefore, this parameter has been given "a forwarding"
        function value. </t> 		
		<t hangText="SFC-Use-REQ03:Virtual contexts (R/W)SHOULD include:"><vspace blankLines="1" />
		<list style="symbols">
		<t> Maximum Number of virtual contexts supported </t>
		<t> Current number of virtual contexts in use </t>
		<t> Number of virtual contexts available </t> 
		<t> Supported Context (VRF) </t>
		</list></t>
		<t hangText="SFC-Use-REQ04: Customers currently on node (R)"><vspace blankLines="1" /></t>
		<t hangText="SFC-Use-REQ05: Customer Support Table (per customer ID) (R) "> <vspace blankLines="1" /> with 
		the following contents per entry: 
		<list style="symbols">
		<t>Customer-id </t>
		<t> List of supported Virtual Contexts </t>
		</list></t>
		<t hangText="SFC-Use-REQ06: Service Resource Table (R/W) "><vspace blankLines="1" /> which includes: 
		<list style="symbols">
		<t> index: Comprised of service node, virtual context, service type </t>
		<t> service bandwidth capacity </t>
		<t> supported packet rate (packets/second) </t>
		<t> supported bandwidth (kps) </t>
		<t> IP Forwarding support: specified as routing-instance(s), RIBs, Address-families supported </t>
		<t> Maximum RIB-size </t>
		<t> Maximum Forward Data Base size </t>
		<t> Maximum Number of 64 bit statistics counters for policy accounting </t>
		<t> Maximum number of supported flows for services </t>
		</list></t>
		<t hangText="SFC-Use-REQ07: Virtual Network Topology (VNT) (R) "><vspace blankLines="1" /> which includes: 
	     <list style="symbols">
		<t> number of access points to which service topology applies </t>
		<t> topology of access points </t>
		</list> 
		</t>
		</list>
		</t>
</section>
	
		<section title="Service Forwarder Node RBNF">
		<t>
		<figure>
		<artwork>
		&lt;SFF_node&gt; ::= &lt;SFFN_address&gt; 	/*SFC-Use-REQ01 */
				[&lt;Attached_Service_node&gt;]	/*SFC-Use-REQ02 */
				[&lt;SFFN_virtual_contexts&gt;]	/*SFC-Use-REQ03 */
				[&lt;SFFN_customer_cnt&gt;]	 /*SFC-Use-REQ04 */
				[&lt;SFFN_Customer_support_table&gt;]	/*SFC-Use-REQ05 */
				[&lt;SFFN_Service_Resource_table&gt;]	/*SFC-Use-REQ06 */
				[&lt;SFFN_VNTopo&gt;] 		/*SFC-Use-07*/
		
		&lt;SFFN_address&gt; ::== &lt;ip_address&gt; 
		
		&lt;Attached_Service_node&gt; ::= 
				| [ (&lt;service-node-ip_address&gt;
				  	 &lt;host-system-ip_address&gt;)]
				| [ (&lt;hosting-system-ip_address&gt;
				     &lt;system-internal_ID&gt;)]
					 
			&lt;service-node-ip_address&gt; ::= &lt;ip_address&gt;
			&lt;host-system-ip_address&gt; ::= &lt;ip_address&gt;
			&lt;hosting-system-ip_address&gt; ::= &lt;ip_address&gt;
			&lt;system-internal_ID&gt; ::= INTEGER-64;
		
		/* SFC-Use-02 */
		&lt;SFFN_supported_types&gt; ::= &lt;Attached_Service_node_types&gt;
		
		
		
		/* These are the types specified by the SFC-REQ-02] 
			&lt;SF_Types&gt; ::= [&lt;SF_TYPE_FW&gt;]
								   [&lt;SF_TYPE_LB&gt;]
								   [&lt;SF_TYPE_DPI&gt;]
								   [&lt;SF_TYPE_NAT&gt;]
		/* SFC-Use-03 */					...
		&lt;SFFN_virtual_contexts&gt; ::== &lt;VContext_max&gt;
						&lt;VContext_current_inuse&gt;
						&lt;VContext_current_avail&gt;
						&lt;SFFN_Types&gt;
		
		/*SFC-Use-04 */				
		&lt;SFFN_customer_cur_cnt&gt; ::= INTEGER; 
		
        /* SFC-Use-05: Customer Support Table per Customer ID */
		&lt;SFFN_customer_table&gt; ::= [&lt;SFFN_customer&lt; ...]
		
		&lt;SFFN_customer&gt; ::= &lt;SFFN_customer_Name&gt;
						  &lt;SFFN_customer_ID&gt;		
						  &lt;SFFN_customers_contexts&gt;
						  
		&lt;SFFN_customers_contexts&gt; ::= &lt;SFFN_Types&gt;
		
		/*SFC-Use-REQ06 */	
		&lt;SFFN_Service_Resource_table&gt; ::=  &lt;SFF_Service_resource_index&gt;
					&lt;SFFN-SR_service_BW_capacity&gt;
					&lt;SFFN-SR_packet_rate_max&gt;
					&lt;SFFN-SR_BW&gt;
					&lt;SFFN-SR_IP_fwd_instance_list&gt;
					&lt;SFFN-SR_MAX_RIB&gt;
					&lt;SFFN-SR_MAX_FIB&gt;
					&lt;SFFN-SR_MAX_COUNTER64&gt;
					&lt;SFFN-SR_MAX_Flows&gt;

			&lt;SFF_Service_resource_index&gt; := &lt;SFFN_Address&gt;
					&lt;VContext_ID&gt;
					&lt;Service_types&gt;

		/*SFC-Use-REQ07 
		 * SFC_topology is defined by 
		 * ietf-hares-i2rs-service-topology
		 * which includes node code 
		 */
		&lt;SFF_VNT&gt; ::= &lt;SFC_Topology&gt;
								
		</artwork>
		</figure>
		</t>
		</section> 
 
<section title="Information Model for Service Chain Function Instance Discovery">
<t>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:
 <list>
 <t> 1) The Service Chain Manager can get all the IP addresses or IP prefix of the
      service function instances needed from a database or provisioning
      system, and passed to the relevant routers. The Routers can send ARP/ND broadcast/multicast messages
	  to all the attached nodes. </t> 

 
 <t> 2) Service function instances will respond to ARP (IPv4)/ND (IPv6)
      requests from its L2/L3 boundary router.</t>

  </list>
  </t>
  <t>
  <figure>
  <artwork>
  
                    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  
	</artwork>
	</figure>
	</t>
</section>
 <section title="Information Model for Interested Service Function Instances">
 <t> 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). 
 </t>
 <t> 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. </t>
 <t>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.  </t>
  <t> 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;
	  </t>
</section>	  
<section title="SFFN Instances Addresses">
	<t>
	<figure>
	<artwork>
	
	&lt;interested-SF-filter&gt; ::= &lt;SF-FILTER-NAME&gt;
                         [&lt;ipv4-address-list&gt;|&lt;ipv6-address-list&gt;] 
                         [&lt;client-identifier&gt;]

	&lt;ipv4-address-list&gt; ::= ((&lt;ipv4-address&gt;
							|&lt;ipv4-prefix&gt;) ...)
	&lt;ipv4-prefix&gt; ::= &lt;IPV4_ADDRESS&gt;&lt;IPV4_PREFIX_LENGTH&gt;
	&lt;ipv6-address-list&gt; = ((&lt;ipv6-address&gt;
							|&lt;ipv6-prefix&gt;) ...)
	&lt;ipv6-prefix&gt; ::= &lt;IPV6_ADDRESS&gt;&lt;IPV6_PREFIX_LENGTH&gt;

	&lt;client-identifier&gt; ::= &lt;client-identifier-type&gt;
						&lt;client-identifier &gt;
	&lt;client-identifier-type&gt; ::= &lt;GRE&gt; 
							| &lt;VxLAN&gt;
							| &lt;NVGRE&gt;

    &lt;client-identifier &gt; ::= (&lt;VXLAN&gt; &lt;VXLAN_IDENTIFIER&gt;)
						| (&lt;NVGRE&gt; &lt;VIRTUAL_SUBNET_ID&gt;)
						| (&lt;GRE&gt; &lt;GRE_KEY&gt;)
	</artwork>
	</figure>
	</t>
</section>

<section title="Information Model for Reporting Directly Attached Instances">
<t>
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. 
</t>
<t> The response should be grouped by &lt;SF-FILTER-NAME &gt;
</t>
</section>
<section title="RBNF for Reporting Directly Attached Instances">
<t>
<figure>
<artwork>
    &lt;sf-instance-list&gt; ::= &lt;INSTANCE-LIST-NAME&gt; 
				&lt; SF-FILTER-NAME&gt;
				[&lt;INTERFACE_IDENTIFIER&gt;
				|&lt;ipv4-address-list&gt;
				|&lt;ipv6-address-list&gt;]]

</artwork>
</figure>
</t>
</section>
<section title="Information Model for Traffic steering rules">
<t>
The semantics of traffic steering rules is "Match" and "Action", similar to the
 "route" described in <xref target="I-D.ietf-i2rs-rib-info-model"></xref>. However, 
 there are more matching criteria for traffic steering rules. </t>
 <t>
 <figure>
 <artwork>
                      match                           
                         |
                         |
    +-------+-------+-------+--------+-------+-----------+-----
    |       |       |       |        |       |           |
    |       |       |       |        |       |           |
   IPv4    IPv6   tunnel    MAC     VLAN   VxLAN ID Interface   
     (Unicast/Multicast SAFI)
	 
 </artwork>
 </figure>
 </t>
 <t> The steering rules include matches on combinations of: 
 <list style="symbols">
 <t> Addresses: IP addresses (IPv4/IPv6), Multicast IP addresses, MAC Addresses; </t>
 <t> Label fields: MPLS labels, VLAN-IDs, GRE-Keys </t>
 <t> interfaces </t>
 <t> Layer 4 fields </t>
 <t> packet sizes </t> 
 </list>
 </t> 
 </section>
 <section title="Traffic Steering Rules RBNF">
 <t>
 <figure>
 <artwork>
     &lt;SFC-Policy&gt; ::= &lt;steering-rules&gt;
	 
     &lt;steering-rules&gt; ::= &lt;match&gt; &lt;action&gt;
        &lt;match&gt; ::= &lt;address&gt;
					|&lt;label&gt;
					|&lt;interface&gt;
					|&lt;l4-field&gt;
					|&lt;packet-size&gt;
        &lt;address&gt; ::= &lt;ip-address&gt;
					|&lt;multicast-address&gt;
					|&lt;mac-address&gt;]
        &lt;ip-address&gt; ::= &lt;IPV4_ADDRESS&gt;
					|&lt;ipv4-prefix &gt;
					|&lt;IPV6_ADDRESS&gt;
					|&lt;ipv6-prefix &gt;]
        &lt;label&gt; ::= [MPLS_LABEL] | &lt;VXLAN-ID&gt; | &lt;GRE-KEY&gt;
        &lt;l4-field&gt;::= &lt;TCP_PORT&gt; | &lt;UDP-PORT&gt;

        &lt;action&gt; ::= &lt;nexthop-list&gt;
					|&lt;drop-policy&gt;
					|&lt;metadata&gt;
        &lt;drop-policy&gt; ::= &lt;PASS&gt;|&lt;DROP&gt;
        &lt;metadata&gt; ::= [&lt;ATTACH&gt; &lt;object&gt;] | &lt;detach&gt;

		The I2RS interface of a router should allow "write" and "read" of above objects. 
 </artwork>
 </figure>
 </t>
 </section>
<section anchor="Security" title="Security Considerations">
<t>
The SC use cases described in this document assumes use of I2RS programmatic
interfaces described in the I2RS framework mentioned
in <xref target="I-D.ietf-i2rs-architecture"></xref>. This document does not change 
the underlying security issues inherent in the existing in   
<xref target="I-D.ietf-i2rs-architecture"></xref>.
</t>
</section>
 <section anchor="IANA" title="IANA Considerations">
   <t>This draft includes no request to IANA.</t>
 </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
 We'd like to thank Qin Wu for his comments on this document
 relating to the service topologies. 
</t>
</section>
</middle>
  <back>
    <references title="Normative References">
      &RFC2119;
      &I-D.ietf-i2rs-architecture;
    </references>
    <references title="Informative References">
	  &I-D.ietf-i2rs-rib-info-model;
	  &I-D.ietf-sfc-problem-statement;
	  &I-D.bitar-i2rs-service-chaining;
	  &I-D.white-i2rs-use-case;
	  &I-D.hares-i2rs-info-model-policy;
	  &I-D.hares-i2rs-info-model-service-topo;
	  &I-D.medved-i2rs-topology-requirements;
	     <reference anchor="NFV-Terminology" target="http://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.01.01_60/gs_NFV003v010101p.pdf">
       <front>
      <title>Network Functions Virtualization (NFV); Terminology for Main Concepts in NFV</title>
      <author/>
      <date/>
    </front>
   </reference>
 

    </references>
  </back>
</rfc>

