One document matched: draft-hares-dunbar-i2rs-sfc-policy-im-00.xml
<?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-00" 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 Forwarding Node"><vspace blankLines="1" />
<xref target="I-D.bitar-i2rs-service-chaining"></xref>states service nodes can run:
a) natively within a 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 two 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>
</list>
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
<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 of SFC Flow Filtering Policies for
an existing service topology. </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 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. </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</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>
<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>
</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) Service function instances will respond to ARP (IPv4)/ND (IPv6) requests from its L2/L3 boundary router. </t>
<t> 2) The Service Chain Manager can get all the IP addresses of the service function instances needed
from a database or provisioning system. </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>
<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>)
</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 <SF-FILTER-NAME >
</t>
</section>
<section title="RBNF for Reporting Directly Attached Instances">
<t>
<figure>
<artwork>
<sf-instance-list> ::= <INSTANCE-LIST-NAME>
< SF-FILTER-NAME>
[<INTERFACE_IDENTIFIER>
|<ipv4-address-list>
|<ipv6-address-list>]]
</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>
<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.
</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>
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:39 |