<?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.ietf-sfc-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sfc-architecture.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.ietf-netmod-acl-model  SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-acl-model.xml">
<!ENTITY I-D.boucadair-sfc-design-analysis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-sfc-design-analysis">
<!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.kini-i2rs-fb-fib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kini-i2rs-fb-fib-info-model.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">
<!ENTITY I-D.penno-sfc-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.penno-sfc-yang.xml">
<!ENTITY I-D.xia-sfc-yang-oam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xia-sfc-yang-oam.xml">
<!ENTITY I-D.wang-i2rs-rib-data-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-i2rs-rib-data-model.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-dunbar-i2rs-discover-traffic-rules-00" ipr="pre5378Trust200902">
  <front>
    <title abbrev="FB-RIB SF Filter Rules IM">An Information Model for Filter Rules for Discovery and Traffic for I2RS Filter-Based RIB </title>
	<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>
	<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="Jeff Tantsuara"  initials="J"  surname="Tantsura"> 
	<organization> Ericsson </organization>
	<address> 
	   <email> jeff.tantsura@ericsson.com</email>
	</address> 
	</author> 
    <date year="2015" />
    <area>Routing</area>
    <workgroup>I2RS Working Group</workgroup>
    <keyword>RTGWG</keyword>
<abstract>
<t>
This draft describes an I2RS Filter RIB information model for managing
	routers to steer traffic to their designated service functions or service function
	instances via the I2RS interface. The purpose of these filters is to guide the
	specific flows traversing their assigned Service Function Chains in the network.
</t>
</abstract>
  </front>
  <middle>
    <section title="Introduction">
	<t> This draft describes an I2RS Filter RIB information model for managing routers
	to steer traffic to their designated service functions or service function instances
	via the I2RS interface. The purpose of these filters is to guide the specific flows
	traversing along their assigned Service Function Chains in the network. 	
	</t> 
	<t> The I2RS Filter-Based RIB (FB-RIB) is described in 
	<xref target="I-D.kini-i2rs-fb-fib-info-model"></xref>.
	I2RS FB-RIBs are protocol independent RIBs. 
	</t>
	<t> An I2RS Filter-Based RIB (FB-RIB) is an entity that contains an ordered set of filters
	(match/action conditions) and a default RIB of the form found in 
	<xref target="I-D.ietf-i2rs-rib-info-model"></xref> An ordered set of filters implies that the 
	insertion of a filter router into a FB-RIB must allow for the insertion of a filter-route
	at a specific position and the deletion of a filter at a specific position.  The ability
	to change a route combines these two functions (deleting existing filter route rule and
	adding a new policy route). Each I2RS FB-RIB is contained within a routing instance, but
	one routing instance can contain multiple FB-RIBs.  Each routing instance is associated with
	a set of interface, a router-id, a default RIB. 
	</t>
	<t> <xref target="I-D.kini-i2rs-fb-fib-info-model"></xref>
      describes a generic filter form which has specific filters for L1, L2, L3, and Service level RIBs.
	  This document describes the FB-RIB filters for the following types of service level data forwarding: 
	  <list style="symbols">
	  <t> a) Traffic flow steering rules on a router for specific Service, Function Path (SFP)
	  or Rendered Service Path (RSP). 
	  </t>
	  <t> b) service function instance discovery traffic (E.g. ARP, ND, or other broadcast/multicast data).
	  </t> 
	  </list></t> 
      <t>
	  I2RS dynamic interface augments the service function configuration, status, and OAM information.
	  This augments yang data models proposed in <xref target="I-D.penno-sfc-yang"></xref>
	  and <xref target="I-D.xia-sfc-yang-oam"></xref>. These SFC yang module documents have not been adopted
	  by the SFC WG, but the best indication of this work.
	  </t> 
	  <t>Section 3 of this document provides Service-chaining related background for this Information model.
	  This includes background on service function chaining, deployment of service chaining, 
	  requirements for I2RS in service chaining. 
	  </t>
	  <t> Section 4 provides background on the generic I2rs Filter-Based RIBS, an how these
	  service level traffic filters fit into that generic model.</t>
	 	  
	  <t> Section 5 contains the description Information Model and Yang data model for traffic flow steering rules. 
	  </t>
	  <t> Section 6 contains the description of the Information Model for service function instance discovery
	  traffic and Yang data model for service function instance filters. 
	  </t>
	  <t> Section 7 contains the description of the I2RS SFC yang components the traffic features depend on.
	  These service features are being worked on by the SFC WG so shared definitions are necessary. 
      </t>
	  <t> Section 8 contains the security considerations for use of a data model that may arise from this
	  information model. This Information Model is only an intermediate step on the pathway to a deployable
	  yang data model.  
      </t> 	  
	</section> 
	<section title="Terminology"> 
	<t> 
	  <list style="hanging">
		<t hangText="FB-RIB: Filter-Based Routing Information Base "><vspace blankLines="1" /> The I2RS protocol
		independent RIBs operate on a set of interfaces, and contain a ordered list of filter rules
		(match-condition rules). </t> 
		<t hangText="NFV: Network Function Virtualization"><vspace blankLines="1" />
		   <xref target="NFV-Terminology"></xref>.</t> 
		<t hangText="RSP: Rendered SErvice Function Path (RSP) "><vspace blankLines="1" /> 
		  <xref target="I-D.ietf-sfc-architecture"></xref> </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="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="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="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>
     	<t hangText="VNF: Virtualized Network Function"><vspace blankLines="1" />
		<xref target="NFV-Terminology"></xref></t>
		<t hangText="Virtual Network Instance Identifier "> <vspace blankLines="1" /> Virtual Network Instance ID </t> 
		</list> 
	 </t>
	 </section> 

<section title="Informational Model Background- SFC ">
<t> 
 Section 3.1 provides the background on service function chaining (SFC), 
 and section 3.2 provides the I2RS use case requirements for the 
 basic service chaining.  Section 3.3 provides the overview of how filter
 rules for traffic flow for specific service function paths (SFPs)
 and rendered service paths (RSPs).  Section 3.4 provides the 
 background on service function instance discovery traffic and
 how the need for traffic filters. 
</t> 
<t> 
 Sections 3.5 provides information on SFC-USE-REQ01 from 
 <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>
 which specifies requirements related to the filtering of service
 chaining traffic flows.
</t>
<t> Section 3.6 provides information on
 SFC-USE-REQ02 use case from the same document.
 SFC-USE-REQ02 is related to handling service-discovery traffic flows. 
  </t>
  <t> 
  Section 3.7 describes Section 3.7 describes the following I2RS use case
  requirements: SFC-Use-REQ03, SFC-USE-REQ04, SFC-USE-REQ05, and SFC-USE-REQ06.
  These use case requirements define SF and SFF information which may be 
  necessary for the I2RS Client to process data related to the
  SFF traffic filters or service discovery traffic. 
  </t>  
<section title="Service Function Chaining">
<t>The Service Function Chain (SFC) <xref target="I-D.ietf-sfc-architecture"></xref> 
is defined as an ordered set of  abstract service functions (SFs) 
that must be applied to packets and/or flows
 that meet certain criteria. 
 </t> 
 <t> 
 The criteria of assigning packets to a service function chain can vary,
 some can be based on L3/L2 header fields, some can be based on L4 header,
 and some can be based on L5-L7 header, packet size, special events, or
 combination of all above. A match filter can be created either by long-term
 configuration or by the I2RS dynamic interface.  
 </t>
 <t> 
 For Service Chain with matching criteria that are beyond L2/L3 header, 
 such as L4-L7 header or other events, it is more economical to have some 
 specialized nodes with DPI capability to inspect the packets and associate 
 an identifier in the L2/L3 header to the packets that match the SFC criteria. 
 By doing so, the subsequent routers/switches only need to forward based on the
 identifier (a.k.a. Service Chain identifier). Again, Filters that examine
 service chain identifiers prior to forwarding traffic can be configured or
 dynamically created in the I2RS FB-RIB.
 </t> 
   <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>
   <t> IETF SFC WG has been chartered to create a new Service
   Chain Header that can carry Service Chain ID plus metadata 
   or/and the actual service function path in the header. 
   However, not every service chain implementation requires the 
   newly created service chain header. BESS WG is working on 
   service function chains using existing MPLS/BGP as the tunnel 
   and/or chain control.  </t>
   <t> <xref target="I-D.boucadair-sfc-design-analysis"></xref>
   describes several Service Function Chain mechanisms that 
   do not use new Service Chain Header.
   </t>
   <t> This draft describes an I2RS information model for
    <list >
   <t> managing Chain Classifier node to assign 
   specific identifier to the packets that match specific 
   criteria via the I2RS interface, </t>
   <t> managing routers to steer traffic to their designated
   service functions or service function instances via the
   I2RS interface, and 
   </t> 
   <t> retrieving SF connectivity to SFF via the I2RS interface for Topology Discovery. 
   </t> 
   </list>
   </t>
   <t> A service chain path identifies the exact SFF nodes and
   SF sequence visited by each SFF node for a specific service function chain.  
   </t> 
</section> 
<section title="Installing Service Function Chain steering filters using I2RS "> 
<t> 
It is assumed that there is an external service function chain manager or an 
orchestration system that computes the Service Function Path including the 
sequence of SFF nodes and the sequence of service functions for flows to 
traverse within each SFF node. A service chain path identifies the exact 
SFF nodes and SF sequence visited by each SFF node for a specific service function chain.  
</t>
<t> 
It is beyond the scope of I2RS and this draft on how the Service Function Chain
 orchestration system computes the path.
</t>
<t>  
This Service Chain Orchestration System behaves as an I2RS client and uses I2RS 
interface to instruct routers what filter rules to dynamically install to guide
 traffic to and along service chain paths as shown in figure 2. The I2RS filter 
 rules include filter classification rules (match rules) and action upon matches 
 forwarding rules, encapsulation rules to next-hop service function, or next-hop SFF nodes). 
</t>
<t> 
The SFF Shim in the diagram below groups the additional work needed to for Service
 Functions and pass the steering policies to FB-RIB Manager described in
<xref target="I-D.kini-i2rs-fb-fib-info-model"></xref>.
 Here is the extra work needed by SFF agent:
 <list style="symbols">
 <t> Managing the mapping between Service Function Chain identifier (SFC-identifier) 
 and the local identifier on the link to service functions. Some service functions
 do not terminate the Service Chain ID carried by the packets; some service 
 functions need a different identifier, such as VLAN to differentiate flows. 
 </t>
 <t>Managing reachability to directly attached service functions, </t>
<t>Managing balancing among multiple ports that connected to different 
instances of the same service function type. 
</t>
</list>
</t>
<t> 
 The SFF Shim can be implemented as part of the orchestrator or as part of an I2RS broker. 
 This document focuses on the I2RS Client-1 to I2RS Agent-2 communication which 
 may need to query or modify the above functions. 
 </t>
 <t>
 <figure>
 <artwork>
         +------------------------------------------------+
         |Service Function Chain Manager or Orchestration | 
		 |     Shim - SFF                                 |
		 |                                                |
         |              I2RS client 2                     |
         +-----------------+------------------------------+
                           |
                           V 
                +----------+----------+
                |     I2RS Agent 1    |
                | +-------+ +-----+   |
                | |FB-RIB | | RIB |   |
                | +-------+ +-----+   |
                +---------------------+
                |    Routing System   |
                +---------------------+
                           ^
                           |
          +---------------------------------+
          |                                 |
          V                                 V
   +-------------+                   +-------------+
   |FIB manager 1|                   |FIB manager M|
   |   +-----+   |    ..........     |   +-----+   |
   |   | FIB |   |                   |   | FIB |   |
   |   +-----+   |                   |   +-----+   |
   +-------------+                   +-------------+
   Figure 2    SFF Shim Layer in relation to RIB Manager
</artwork>
</figure>
</t>
<t> The SFF client must be able to instruct the I2RS Agent to 
<list style="symbols">
<t> Add/Modify/Delete the filter routes in the FB-RIB 
based on SFF reachability and SF reachability (locally attached Service functions), 
</t>
<t> Add/Modify/Delete filter routes in the FB-FIB that 
direct load balancing for SFF reachability or SF reachability, 
</t>
<t>Allow FB-RIB filter routes that match a service 
function identifier to have a forwarding action via interfaces, 
local-links, tunnels or L3 nexthops or Service layer next-hops. 
(These type of features are utilized in the I2RS RIB Model
(<xref  target="I-D.ietf-i2rs-rib-info-model"></xref> 
and <xref target="I-D.wang-i2rs-rib-data-model"></xref>).
</t> 
</list>
</t>
</section>
<section title="SFC Service Layer Steering Policies">
<t> 
The SFF nodes are interconnected by tunnels (e.g. GRE or VxLAN) 
and the SF are attached to a SFF node via Ethernet link 
or other link types. Therefore, the steering policies to a 
SFF node for service function chain depends on if the 
packet comes from previous SFF or comes from a specific SF.  
Due to this fact, the SFC Service Layer Steering filter
routes need to be able to specify the ingress port/interface in the filter match. 
</t>
<t>
There are multiple different steering policies for one
flow within one SFF and each set of steering policies
 is specific for an ingress port/interface.  
</t>
<t>
<figure>
<artwork>
               figure 3 

           Ingress Port match
                        |
                        |
    +-------+--------+--+------+-------+-------+-------+-------+
    |       |        |         |       |       |       |       |
    |       |        |         |       |       |       |       |
  L3Header L2header L4 header VLAN    VN ID   size    event ..

</artwork>
</figure>
</t>
<t> The action has to be egress port specific. 
</t>
</section> 
<section title="Service Function Instances Discovery">
<t> 
Service Function Instance Discovery is not required to
have Service chain forwarding, but this function may provide a
useful service in many networks.
</t>
<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.  However, not every attached host
to a router is a service functions.  
</t>
<t>
It is assumed that the Service Function Chain Manager or Orchestration 
can get all the IP addresses or IP prefix of the service function instances 
from an external authoritative entity, such as a database or 
provisioning system. However, the SFC orchestration may not know how/where 
the service function instances are attached to the network, especially 
in an environment where virtualized hosts can be moved easily. 
</t>
<t>
Here is the procedure for Service Chain Orchestration system to
discover how/where service function instances are attached in the network:
<list>
<t> 1) The Service Chain Manager or orchestration can passed the Service 
function addresses or prefix to the relevant SFFs.  The SFFs 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>
<t>3) SFF nodes can report the directly reachable Service function 
instances to the Service Chain Manager/Controller.  
</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="I2RS Use Case Requirements for Service Flow Filtering">
<t> 
This section reviews the requirements for Flow Filtering Policies 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 flows on the SFFs along the Service 
Function Chain path. The SFC use case  <xref target="I-D.bitar-i2rs-service-chaining"></xref> 
and the <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref> suggest the 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 in filters: 
</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>
	</list>
</t>
</section>
<section title="I2RS Use Case Requirements Related to Service Discovery Traffic">
<t> 
The following I2RS Use Case Requirement specifies the following additional information
which may be used by the SFF SHIM layer (figure 2) 
</t>
<t> 
 <list style="hanging">
	    <t hangText="SFC-Use-REQ02:Supported Service Types (R/W)"><vspace blankLines="1" /> 
		abstract service function type, or can be vendor specific service function types. 
		</t>
</list>
</t> 
<t> Note: The current SFC WG suggest hat the SFF does not need to know the SF type 
on the node in order to steer the data to their designated service function.  
However, the information can help is the service discovery. 
</t>
</section>
<section title="I2RS Use Case Requirements Related to SFF SHIM function">
<t> 
The I2RS Use Case Requirements specify the following additional information that
this draft suggest may be used by the SFF SHIM layer (figure 2) to calculate flow filters. 
These features are the following:   
	<list style="hanging">		
		<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> topology of access points </t>
		</list> 
		</t>
		</list>
		</t>
</section>
</section>	
<section title="Filter-Based RIB Background" >
<t>
Filter based (FB) routing matches fields in the IP header plus other higher 
layer packet information. Filters with a match-action pair allow the filters 
to impact the forwarding of packets.  Actions may impact forwarding or set 
something in the packet that will impact forwarding.  	
</t>
<t>
A Filter-Based RIB (Routing Information Base) contains a list of filters (match-action conditions)
and a default RIB of the form found in <xref target="I-D.ietf-i2rs-rib-info-model"></xref>
The default RIB routes any packet not matched by the order list of filter rules.  
An order set of filters implies that the I2RS agent must be able to insert a 
filter route at a specific position and delete a filter route at a specific position.  
Changing a route is simply a combination of the two (delete a route and add a new route). 
</t>
<t> 
The Filter-Based RIB found in <xref target="I-D.kini-i2rs-fb-fib-info-model"></xref> allows for a
generic filter that supports L1, L2, L3, and Service matches in the match-condition, 
or a more specific match-condition filter (E.g. ACL filters found in 
<xref target="I-D.ietf-netmod-acl-model"></xref>.
</t>
<t>
 Each Filter-Based RIB (FB-RIB)is contained within a routing instance, but 
 one routing instance may contain multiple RB-FIBs.  In I2RS Models, each 
 routing instance is associated with a set of interfaces, a router-id, a 
 list of I2RS RIBs, and a list of FB-RIBs.  Only some of the interfaces within 
 the routing instance may be associated with a FB-RIB. Each FB-RIB also 
 designates a default destination-based RIB (FB-RIB Default RIB) that 
 forward traffic not matched by the filters.  Any traffic not match by 
 the FB-RIB filters or the FB-RIB Default RIB is dropped. 
 </t>
 <t> 
 Packets arriving on an interface associated with an FB-RIB will be 
 forwarded based on a match to the filters in a FB-RIB associated with
 that interface. The processing of the packet does the following:  
 <list style="symbols">
 <t>if a packet successfully matches, the rule-actions are applied. </t>
 <t>If a packet does not successful match a filter, the filter
 route processing goes to the next filter in the list. This continues
 until all filter routes are matched. 
 </t>
 <t>If no match has been found within the FB-RIBs on the FB-RIB list, 
 then the packet will be forward to the FB-RIB Default RIB specified by 
 the FB-RIB.  If non-exists, then the packet will be discarded.
 </t>
 <t>If no match is found in the FB-RIB Default RIB, the packet
 will be discarded. 
 </t>
 </list>
</t>
</section> 
 <section title="Information Model for Traffic steering rules">
 <t>
 The semantics of traffic steering rules is "Match" and "Action". 
 This draft uses the generic match-action filters described in 
 <xref target="I-D.kini-i2rs-fb-fib-info-model"></xref>
 which provides filters at L1, L2, L3, L4, Service packets  
</t>
<t>  
The match filters for SFF need to support the fields in a packet
 and packet meta-data: 
 <list style="symbols">
   <t>Layer 2: ingress port, destination MAC, 
    source MAC, VLAN ID, GRE Keys, and L2 packet size;
   </t>
   <t> Layer 3:MPLS label, destination IP, source IP, VN-ID,
    layer 3 packet size, 
   </t>
<t> Layer 4: TCP port and UDP port,
</t>
<t> Service Chain Identifier (Service-level) 
</t>
</list>
</t>
<t> The generic match-action filters provide a generic filter
format for match actions for packets that examine these L1-L4, and 
service layer fields.
</t>
<t> 
A SFF node may not support some of the matching criteria listed above. 
It is important that Service Function Chain Orchestration System can 
retrieve the type of FB-RIB filters supported matching criteria by I2RS agent in the SFF nodes.
</t>
<t>  
The Actions for traffic steering could be to steer traffic to the attached
service function via a specific port with specific VLAN-ID added,
or forward traffic to the next SFF node(s) with specific VxLAN header.  
</t>
<t>
When steering to the attached service function, the action may include such things as: 
<list style="symbols">
<t>	adding VLAN-ID tags, </t>
<t> removing service header fields of a packet have to be removed
  if packets with a certain header are not supported by the attached service functions; </t> 
<t> Forwarding traffic out a particular interface or tunnel.</t>    
</list>
</t> 
<section title="5.1 Existing FB-RIB information in RBNF Form" >
<t>
<figure>
<artwork>

     &lt;FB-RIB-match-action&gt;::= [&lt;BNP_GENERIC-MATCH_ACTION&gt;
				  &lt;generic-match-action-rule&gt;] | 
				 [&lt;ACL_MATCH_ACTION&gt;&lt;acl-list-entry-name&gt;]

     &lt;generic-match-action-rule&gt;::= &lt;bnp-term-match&gt;&lt;bnp-action&gt;
                                     &lt;bnp-forward&gt; 
   
      &lt;bnp-term-match&gt;:: = &lt;interface-match&gt; 
                           &lt;L1-match&gt; 
                           &lt;L2-match&gt;
                           &lt;L3-match&gt;
                           &lt;L4-match&gt;
                           &lt;Service-header-match&gt;

 	 &lt;bnp-action&gt;::= &lt;NACTIONS&gt; 
                     &lt;qos-actions&gt; 
                     &lt;forwarding-actions&gt; 

 	&lt;qos-actions&gt;::= &lt;L1-qos-action&gt;
                     &lt;L2-qos-action&gt;
                     &lt;L3-qos-action&gt;
                     &lt;L4-qos-action&gt;
                     &lt;Service-qos-action&gt;      

    &lt;bnp-forward&gt;:: &lt;fb-std-forward&gt; &lt;fb-std-drop&gt;
    &lt;fb-std-forward&gt;::= [&lt;INTEFACE-ID&gt; [&lt;preference&gt;]] |
			[&lt;rib-nexthop&gt;&lt;rib-attributes&gt;]

     &lt;fb-std-drop&gt;::= &lt;Forward&gt;&lt;Drop&gt; 
</artwork>
</figure>
</t>
<t>
<figure>
<artwork>
	# Generic interface filter from RIB and FB-FIB
    # Assumed from generic filtering yang document  

	  &lt;interface-match&gt;:: = &lt;interface-list&gt; &lt;port-list&gt; 
      &lt;interface-list&gt;:: = [&lt;INTERFACE_IDENTIFIER&gt; . . . ] 
      &lt;port-list&gt;::==  [&lt;PORT_IDENTIFER&gt; . . . ]       
             		
      &lt;L2-match&gt;:: = [&lt;L2-type-match_entry&gt; . . .] 
      &lt;l2-matches_entry&gt;]::=[&lt;L2-DMAC-MATCH&gt; &lt;destination-mac&gt;]  
               [&lt;L2_SMAC-MATCH&gt; &lt;source-mac&gt;] 
               [&lt;L2_DMAC-SRC-MATCH&gt;&lt;destination-mac&gt;&lt;source-mac&gt;]  
               [&lt;L2_MMAC-DMAC-MATCH&gt; &lt;multicast-mac&gt;]  
               [&lt;L2_VLAN-Match&gt; &lt;vlan-id&gt;]
          	   [&lt;L2-packet-size&gt;]

			   
		  &lt;L3-match&gt;::= [&lt;L3-match-entry&gt; ...] 

		  &lt;L3-match-entry&gt;::= [&lt;LABEL_MATCH&gt; &lt;label&gt;]
			   [&lt;DESTINATION_ADDRESS_MATCH&gt; &lt;ip-address&gt;]
               [&lt;SOURCE_ADDRESS_MATCH&gt;&lt;ip-address&gt;]
               [&lt;DESTINATION-SOURCE_ADDRESS_MATCH&gt;
                    &lt;ip-address&gt;&lt;ip-address&gt;]
                [&lt;IP-Packet-Type&gt;&lt;ip-packet-type&gt;]
                [&lt;IPv6-Flow-Type&gt;&lt;ipv6-flow-id&gt;] 
                [&lt;L3-packet-size&gt;]
            

        &lt;ip-address&gt; ::= &lt;IPV4_ADDRESS&gt;
                    |&lt;ipv4-prefix &gt;
                    |&lt;IPV6_ADDRESS&gt;
                    |&lt;ipv6-prefix &gt;]

		 &lt;ip-packet-type&gt;::=[&lt;IPv4&gt;&lt;IPv4-packet-type&gt;]
                               [&lt;IPv6&gt;&lt;IPv6-packet-type&gt;]
 # this is a partial list of the all types
 # which is used by this IM model 
#  							   
	&lt;IPv4-packet-type&gt;:: = &lt;ARP&gt;&lt;ICMP&gt;          
	&lt;IPv6-packet-type&gt;:: == &lt;ND&gt;            
	&lt;L4-match&gt;:: [&lt;TCP_PORT&gt; | &lt;UPD-Port&gt; ]  

    &lt;label&gt; ::= [&lt;MPLS_LABEL&gt;] | &lt;GRE-KEY&gt;
     &lt;L4-field&gt;::= &lt;TCP_PORT&gt; | &lt;UDP-PORT&gt;

	&lt;Service-Match&gt;::== [&lt;SERVICE_CHAIN_MATCH&gt;&lt;service-chain-matches&gt;]
		[&lt;L3VPN_SERIVCE_MATCH&gt;&lt;L3VPN-feature-matches&gt;] 

	&lt;Service-QOS-Actions::&gt; == [&lt;SERVICE_CHAIN_QOS&gt;
                 &lt;service-chain-qos-actions&gt;]
				  [&lt;L3VPN_QOS_ACTIONS&gt;
					  &lt;l3vpn-qos-actions&gt;]
</artwork>
</figure>
</t>
</section>
<section title="5.2. SFF Filters in RBNF Form">
<t>
<figure>
<artwork>
#definitions unique to the SFF filter rules 
# SFF

  &lt;Service-chain-matches&gt;::= &lt;SF-MATCH-NAME&gt;&lt;sf-filter-name&gt; 
         [&lt;SF-MATCH&gt;&lt;sf-match&gt; . . .  ]
		  [&lt;SFF-MATCH&gt; &lt;sff-match&gt; . . . ]   
  		  [&lt;SF-MATCH&gt;&lt;sf-match&gt; . . . ] 
		  [&lt;SFC-ID-Match&gt; &lt;sfc-match&gt; . . . ] 
		  [&lt;SFC-Client-Match&gt;&lt;service-client-identifier&gt; . . . ]
         
&lt;sf-filter-name&gt; = &lt;SF_FILTER_NAME&gt; 

#Section 7 povides the definition for &lt;service-client-identifier&gt;

 
# Service function definition comes from the [I-D.penno-sfc-yang-13]
# (Note: Additional filters may be added here]

        &lt;sf-match&gt;:: = [&lt;SF_TYPE&gt;&lt;sfc-sft-service-function-type&gt;]
                        [&lt;SF_NAME&gt;&lt;string&gt;] 
                        [&lt;SF_REST-URI&gt;&lt;inet:uri&gt;]	

		&lt;sfc-match&gt;::= &lt;SFC_CHAIN_NAME&gt;&lt;string&gt; 
       
# Service Chain QOS functions 
 
  &lt;service-chain-qos-actions&gt;::=[&lt;sff-qos-action&gt;]
								    [&lt;isfi-qos-actions&gt;] 

   
	&lt;sff-qos-action&gt;::= [&lt;SFF-ingress-action&gt;]
						  [&lt;SFF-steering-action&gt;] 
                        [&lt;SFF-egress-action&gt;]
 
	&lt;SFF-ingress-action&gt; :: = [&lt;sff-ingress-vlan&gt;]
	                               [&lt;sff-ingress-mac&gt;]
 
     &lt;sff-ingress-vlan&gt; :: = [&lt;VXLAN_REMOVAL_TYPE]
                        &lt;decapsulate-VxLAN-header&gt; 
						&lt;filter-decapsulated-packet&gt;

     &lt;sff-ingress-mac&gt;::= [&lt;MAC_HEADER_REMOVAL_TYPE&gt;
							 &lt;remove MAC-Header&gt;
							&lt;encapsulate-ID&gt;]

    &lt;SFF-egress-action&gt; :: &lt;encapsulation-metho0d&gt; 
							  | &lt;metadata&gt;

    &lt;metadata&gt; ::= [&lt;ATTACH&gt; &lt;object&gt;] |
                    	&lt;detach&gt;

     &lt;encapsulation-method&gt;::=&lt;add-VXLAN-header&gt;
                             |&lt;add-VLAN&gt;

</artwork>
</figure>
</t>
</section>
</section>
<section title="6. 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 service chain manager/controller acts like an I2RS Client to
   communicate 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>  
 <t>
 <figure>
 <artwork>
	 &lt;issf-match-match-filters&gt;::= &lt;sfc-filter-name&gt;
		 [ &lt;SFC-Client-Match&gt;&lt;service-client-identifier&gt;   
          [[ &lt;L3-match-entry&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 title="RPC 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> 
<figure>
<artwork>

#This RPC assumes FB-RIB filter is there but inactive
# 
   rpcs: 
    +--x-Check-Attached-IP-Address-in-Filter
          +--FB-RIB-Rule FB-RIB:rule:rule-name			
          +--FB-RIB-rule-group FB-RIB:rule-group


# The response should be grouped by SF-FILTER-NAME per routing instance
#response should be 
 +--x-response-
    +--ro instance-name 
    +--ro FB-filter-name
    +  ro sfc-filter-name
    +--ro attached-address
       +--ro IPv4-address-list
       +--ro IPv6-address-list           

</artwork>
</figure>
</t>
</section>
<section title="RBNF for Reporting Directly Attached Instances">
<t>
<figure>
<artwork>
        
          
RBNF for Reporting Directly Attached Instances

       &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>

<section title="Service Function Forwarder Nodes I2RS Information"> 
<t>
The following I2RS constructs are necessary to support the service function
forwarder node functions required. These functions may be needed by the SFF shim material. 
These functions are not contained in 
<xref target="I-D.penno-sfc-yang"></xref> or <xref target="I-D.xia-sfc-yang-oam"></xref>.
If the SFF_node related information structures are global configuration/state 
functions, then these should be added to SFC to <xref target="I-D.penno-sfc-yang"></xref>
and I2RS definitions can share grouping definitions with this I2RS state.  
</t>
<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 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>
<t> I2RS FB-FIBs will filter packets in the traffic stream, modify packets
(via actions), and forward data packet. These I2RS FB-RIB filters operate dynamically on the
the packets. The FB-RIB filters in the I2RS Agent may in turn be changed dynamically 
by the I2RS Client. The dynamic nature of the changes does not change the fundamental
actions of routers, but rate is change is increased. 
</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.ietf-sfc-architecture;
	  &I-D.ietf-i2rs-usecase-reqs-summary;
	  &I-D.boucadair-sfc-design-analysis;
	  &I-D.penno-sfc-yang;
	  &I-D.xia-sfc-yang-oam;
	  &I-D.kini-i2rs-fb-fib-info-model;
	  &I-D.bitar-i2rs-service-chaining;
	  &I-D.ietf-netmod-acl-model;
	  &I-D.wang-i2rs-rib-data-model;
	  &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>

