One document matched: draft-hares-i2rs-info-model-service-topo-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-hares-i2rs-info-model-service-topo-03"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="IM for service Topo">An Information model for service
topology</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="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Michael Wang" initials="M." surname="Wang">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>wangzitao@huawei.com</email>
</address>
</author>
<author fullname="Jianjie You" initials="J." surname="You">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>youjianjie@huawei.com</email>
</address>
</author>
<date year="2015"/>
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>As stated in [I.D-ietf-sfc-problem-statement], the service overlay is
independent of the network topology and allows operators to use whatever
overlay or underlay they prefer and to locate service nodes in the
network as needed.</t>
<t>This document extends the general topology model concept defined in
[I.D-medved-i2rs-topology-im] and focuses on defining information model
for service topology.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Network topology information can be collected from network by using
IGP or BGP-LS [I.D-draft-ietf-idr-ls-distribution]. Information model
for network topology provided in [I.D-medved-i2rs-topology-im] is built
based on such network topology information.</t>
<t>A service specific overlay utilized by Service chaining creates the
service topology. The overlay creates a path between service
function(SF) nodes. Service functions can be co-located on one SF Node
or physically separated across several SF Nodes with each having one or
more Service Functions. In either case, a service function may be
running in its own virtualized system space or natively on the hosting
system.</t>
<t>Within the service topology, an ordered set of Service functions will
be invoked for each packet that belongs to a given flow for which a SFC
will be applied. Adding new service function to SF Node in the topology
is easily accomplished, and no underlying network changes are required.
Furthermore, additional service Functions or Service Function instances,
for redundancy or load distribution purpose, can be added or removed to
the service topology as required.</t>
<t>As stated in [I.D-ietf-sfc-problem-statement], the service overlay is
independent of the network topology and allows operators to use whatever
overlay or underlay they prefer and to locate service nodes in the
network as needed.</t>
<t>This document extends the general topology model concept defined in
[I.D-medved-i2rs-topology-im] and focuses on defining information model
for service topology.</t>
</section>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC2119</xref>.</t>
</section>
<section title="Service Topology Information Model">
<t>This section specifies the service topology information model in
Routing Backus-Naur Form (RBNF, [RFC5511]). It also provides diagrams of
the main entities that the information model is comprised of.</t>
<section title="Model Overview">
<t>The abstract Topology Model contain a set of abstract nodes and a
list of abstract links. An abstract link connects two abstract nodes.
Service Function Chain Topo model and other service topo model can be
augumented from the abstract topology model with topology
specifics.</t>
<figure>
<artwork> +-----------------+
| Abstract |
| Topology Model |
| |
+--------|--------+
|
+------------------------+
| | |
| | |
+--------V--------+ +--------V--------+
|Service Function | | |
| Chain | | Other Service |
| Topology Model | | Topology Model |
+-----------------+ +-----------------+
</artwork>
</figure>
</section>
<section title="Abstract Topology Model: the Service-Topology Component">
<t>The following diagram contains an informal graphical depiction of
the main elements of the information model:</t>
<figure>
<artwork>
+----------------+
| topology |<...
+----------------+ :
* * : :
| | :...:
| |
+--------+ +--------+
...>| node |<.......|segment |<...
: +--------+<.......+--------+ :
: : * : : * : :
:..... | : : | :...:
| : : |
.....>+--------+<........: : |
: | TP |<..........: |
: ...>+--------+ |
: : |
: : .....................+---------+
.........................|Direction|
+---------+
</artwork>
</figure>
<t>The basic information model works as follows: A service topology
contains service nodes and segments. A segment connects two nodes (a
source and a destination)and have direction, may be unidirectional or
bidirectional. unidirectional is one where traffic is passed through
any two service node or a set of service nodes in one forwarding
direction only. Bidirectional is one where traffic is passed through
any two service nodes or a set of service nodes in both forwarding
directions. Each serivce node contains termination points. It occurs
before or after other service node, therefore each node may have its
upstream service node and/or downstream service node.</t>
<t>A service node may be dedicated to a tenant(e.g., an IPVPN
customer), globally shared among tenants, or available to be assigned
in whole or in part to a tenant or a set of tenants. Therefore service
Nodes can map onto and be supported by other network elements in the
underlying network, while Segment can map onto and be supported by
other links in the underlying network,e.g., one segment can be mapped
to two consecutive links stitching together. Service Topologies can
map onto other, underlay topologies.</t>
<t>The information model for the Service-Topology component is more
formally shown in the following diagram.</t>
<figure>
<artwork>
/* exterior definitions for service topology */
<service-topology> ::= (<topology>...)
/* Topology definitions */
<topology> ::= <TOPOLOGY_IDENTIFIER>
[<node-count>]
(<segment>...)
(<node>...)
[<topology-type>]
[<underlay-topologies>]
[<topology-extension>]
<node-count> ::= INTEGER-32;
<topology-type> ::= (
(<netconf> [<netconf-topology-type>])|
(<i2rs> [<i2rs-topology-type>])
<underlay-topologies> ::= (<TOPOLOGY_IDENTIFIER>...)
<topology-extension> ::=
<netconf-topology-extension> |
...
<segment> ::= <Segment_IDENTIFIER>
<source>
<destination>
[<direction>]
[<segment-extension> ]
<source> ::= <termination-point-reference>
<destination> ::= <termination-point-reference>
<termination-point-reference> ::= <SF_NODE_IDENTIFIER>
<direction> ::= (<Unidirection>)|
(<Bidirection>)
<segment-extension> ::= <netconf-segment-extension> |
<i2rs-segment-extension> |
...
<node> ::= <SF_NODE_IDENTIFIER>
(<termination-point>...)
[<NODE_TYPE>]
[<NEXT-HOP>]
[<node-extension>]
<termination-point> ::= <TERMINATION_POINT_IDENTIFIER>
[<supporting-termination-points>]
[<termination-point-extension>]
<supporting-termination-points> ::=
(<TERMINATION_POINT_IDENTIFIER>...)
< NODE-TYPE> ::=
(<Classifier-Node>)|
(<SF-Node>)|
(<SFF-Node>)
...
<NEXT-HOP> ::= (<NODE_IDENTIFIER>...)
<node-extension> ::= <Classifier-extension> |
<SF-Node-extension> |
<SFF-Node-extension>
...
</artwork>
</figure>
<t>The elements of the Service-Topology information model are as
follows: <list style="symbols">
<t>A service overlay can contain multiple topologies. Each
topology is captured in its own list element, distinguished via a
topology-id.</t>
<t>A topology has a certain type, such as NETCONF or I2RS. A
topology can even have multiple types simultaneously. The type, or
types, are captured in the list of "topology-type" components.</t>
<t>A topology contains segments and nodes, each captured in their
own list.</t>
<t>A node has a node-id. This distinguishes the node from other
nodes in the list. In addition, a node has a list of termination
points, used to terminate segment. An examples of a termination
point might be a physical or logical port or, more generally, an
interface.</t>
<t>A segment is identified by a segment-identifier, uniquely
identifying the portion of the network bounded by two service
nodes within the topology. segment are point-to- point and has
direction. The direction can be unidirectional or bidirectional.
Accordingly, a segment contains a source and a destination. Both
source and destination reference a corresponding node, as well as
a termination point on that node.</t>
<t>The topology, node, segment and direction elements can be
extended with topology-specific components (topology-extensions,
node-extension, segment-extension and direction-extension
respectively).</t>
</list></t>
<t>The topology model includes segment that are either bidirectional
unidirectional. Service function chain path is analogue to linked list
data structure and can be represented through a set of Ordered
segments from source to destination. Each node in the service overlay
may be located at different layer. The segment can be setup to steer
traffic through these specific service nodes at different layers or
bypass some specific service nodes at different layers.</t>
<t>The topology model only supports point to point and does not
support multipoint. Therefore Segments are terminated by a single
termination point, not sets of termination points. Connections
involving multihoming or segment aggregation schemes need to be
modeled using multiple point-to-point segment,e.g., connection from
service node A at lower layer to service node D at higher layer can
comprise a segment 1 from service node A to service node B and segment
2 from service node B to service node C and segment 3 from service
node C to service node D. By using segment aggregation, we can define
a new segment from service A to service node D which is supported by
segment 1,2 and 3.</t>
<t>Unlike network topology collection, the service topology
information may be not available from each SF by using IGP
advertisement or BGP- LS northbound distribution since SF may be not
located at network layer. However these SF at different layer may have
affinity with one SF node(e.g., SF egress node or SF ingress node or
SF enabled node),therefore service topology information associated
with Service nodes can be collected using RESTCONF/NETCONF interface
or I2RS interface for interrogation of a virtual device's state,
statistics and configuration.</t>
</section>
<section title="Model Extension: Service Function Chain Topology Component">
<figure>
<artwork> <Classifier-extension>::= <SFP>
<SFC-Policy>
<Matching-RULE>
<SFP> :: = <SF-List>
<SFF-List>
<SF-Node-extension> :: = <SF-Node-Locator>
<Support-Context-Type>
<SF-Type>
<SF-Inventory-data>
<SF-type> ::=
<firewall> |
<loadbalancer>|
<NAT44>|
<NAT64>|
<DPI>
<SFF-Node-extension>::=<SFFN-address>
<SFFN-Virtual-Context>
<Attached-service-add>
<Customer-Support-List>
<Customer-Support-Resource-List>
<SFFN-VNTopo>
<SFFN-Virtual-Context>::= <id>
</artwork>
</figure>
</section>
<section title="Model Extension: Inventory datastore Component">
<t>Inventory Data for service overlay can be obtained by using NETCONF
or I2RS and share to PCE, ALTO server or other topology manager
defined in [I.D-ietf-i2rs-architecture]. Information shared by them is
defined as the component, "inventory database". This component defines
a set of groupings with auxiliary information required and shared by
those other components.</t>
<figure>
<artwork>
<SF-inventory-data> ::=
<SF-capabilities>
<SF-administrative-info>
<SF-capabilities> ::=
(<supported-ACL-number >)|
(<virtual-context-number >)|
(<supported-packet-rate>)|
(<supported-bandwidth>)
<SF-administrative-info> :: =
(<Packet-rate-utilization>)|
(<Bandwidth-utilization-per-CoS>)|
(<Packet-rate-utilization-per-Cos>)|
(<Memory-utilization>)|
(<available-memory>)|
(<RIB-utilization-per-address-family>)|
(<FIB-utilization-per-address-family>)|
(<CPU-utilization>)|
(<Available storage>)|
(<Bandwidth-utilization>)|
(<Flow-resource-utilization-per-flow-type>)
</artwork>
</figure>
<t>This module details inventory node attributes:<list style="symbols">
<t>Inventory node attributes include SF-type,SF-capabilities and
SF- administrative-info.</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce any new security issues above those
identified in [RFC5511].</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5511">
<front>
<title>Routing Backus-Naur Form (RBNF): A Syntax Used to Form
Encoding Rules in Various Routing Protocol Specifications</title>
<author fullname="A.Farrel" initials="A." surname="Farrel">
<organization/>
</author>
<date month="April" year="2009"/>
</front>
<seriesInfo name="RFC" value="5511"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I.D-medved-i2rs-topology-im">
<front>
<title>An Information Model for Network Topologies</title>
<author fullname="J.Medved" initials="J." surname="Medved">
<organization/>
</author>
<author fullname="N.Bahadur" initials="N." surname="Bahadur">
<organization/>
</author>
<author fullname="A.Clemm" initials="A." surname="Clemm">
<organization/>
</author>
<author fullname="H. Ananthakrishnan" initials="H."
surname="Ananthakrishnan">
<organization/>
</author>
<date month="October" year="2003"/>
</front>
<seriesInfo name="ID" value="draft-medved-i2rs-topology-im-01"/>
</reference>
<reference anchor="I.D-bitar-i2rs-service-chaining">
<front>
<title>Interface to the Routing System (I2RS) for Service Chaining:
Use Cases and Requirements</title>
<author fullname="N.Bitar" initials="N." surname="Bitar">
<organization/>
</author>
<author fullname="G.Heron" initials="G." surname="Heron">
<organization/>
</author>
<author fullname="L.Fang" initials="L." surname="Fang">
<organization/>
</author>
<date month="July" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-bitar-i2rs-service-chaining-00"/>
</reference>
<reference anchor="I.D-draft-ietf-idr-ls-distribution">
<front>
<title>North-Bound Distribution of Link-State and TE Information
using BGP</title>
<author fullname="H.Gredler" initials="H." surname="Gredler">
<organization/>
</author>
<date month="May" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03"/>
</reference>
<reference anchor="I.D-ietf-sfc-problem-statement">
<front>
<title>Service Function Chaining Problem Statement</title>
<author fullname="P. Quinn" initials="P." surname="Quinn">
<organization/>
</author>
<date month="August" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-ietf-sfc-problem-statement-10"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:41 |