One document matched: draft-hares-i2rs-info-model-service-topo-01.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-01"
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="Xiaoran Guan" initials="X." surname="Guan">
<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>guanxiaoran@huawei.com</email>
</address>
</author>
<date year="2014" />
<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-quinn-nsc-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-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-quinn-nsc-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="Base 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 a
set of SF nodes in one forwarding direction only. Bidirectional is one
where traffic is passed through a set of SF nodes in both forwarding
directions. Each SF node contains termination points. It occurs before
or after other service node, therefore each node may have its upstream
SF node and/or downstream SF node.</t>
<t>A SF 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 SF Nodes can map
onto and be supported by other SF nodes, while Segment can map onto
and be supported by other segments,e.g., one segment can be mapped to
two consecutive segments stitching together. Service Topologies can
map onto other, underlay topologies. However in some cases when some
services are dedicated to a tenant or topology information are not
gathered using IGP or BGP, Service Topologies should be independent
from network topology and therefore should not 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>...)
<STopo> ::= (<topology> ...)
/* Topology definitions */
<topology> ::= <TOPOLOGY_IDENTIFIER>
[<node-count>]
(<segment>...)
(<node>...)
[<topology-type>]
[<underlay-topologies>]
[<topology-extension>]
<node-count> ::= INTEGER-32;
<topology-type> ::= (<snmp> [<snmp-topology-type>]) |
(<ipfix> [<ipfix-topology-type>])|
(<i2rs> [<i2rs-topology-type>])
<underlay-topologies> ::= (<TOPOLOGY_IDENTIFIER>...)
<topology-extension> ::= <snmp-topology-extension> |
<ipfix-topology-extension> |
<igp-topology-extension> |
<bgp-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> ::= <snmp-segment-extension> |
<ipfix-segment-extension> |
...
<node> ::= <SF_NODE_IDENTIFIER>
(<termination-point>...)
[<SF-NODE_TYPE>]
[<NEXT-HOP>]
[<SF-node-extension>]
<termination-point> ::= <TERMINATION_POINT_IDENTIFIER>
[<supporting-termination-points>]
[<termination-point-extension>]
<supporting-termination-points> ::=
(<TERMINATION_POINT_IDENTIFIER>...)
<SF_NODE-TYPE> ::=
(<SF-Ingress-Node>)|
(<SF-Enabled-Node>)|
(<SF-Egress-Node>)
...
<NEXT-HOP> ::= (<SF_NODE_IDENTIFIER>...)
<node-extension> ::= <SF-Ingress-Node-extension> |
<SF-Enable-Node-extension> |
<SF-Egress-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 SNMP or IPFIX. 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 segment 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 SF nodes between SFC ingress node and SFC egress node can be
collected using IGP or BGP-LS from egress network node or ingress
network node. Alternatively, the service node may rely on SNMP or
IPFIX interface for interrogation of a virtual device's state,
statistics and configuration.</t>
</section>
<section title="The TED (Traffic Engineering Data) Component">
<t>Traffic Engineering Data for service overlay can be built or
supplemented from other sources inventory management system 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, "TED". This component defines a set of groupings with
auxiliary information required and shared by those other
components.</t>
<figure>
<artwork>
<SF-TED_Ext> ::= <SF-Enable-Node-Extension>
<SF-Node-Locator>
<Supported-Context-Type>
[<FIB-Size>]
[<RIB-Size>]
[<MAC-Forwarding-Table-Size>]
<SF-Chain-Index>
[(<SF-Identifier>
<SF-Type>
<Customer-ID>...
<SF-inventory-data>)...]
<SF-type> ::=
<firewall> |
<loadbalancer>|
<NAT44>|
<NAT64>|
<DPI>
</artwork>
</figure>
<t>This module details traffic-engineering node attributes:<list
style="symbols">
<t>TED node attributes include SF-Node-Locator, SF-Type and
SF-Identifier, SF-Chain-Index and inventory-data information.</t>
</list></t>
</section>
<section title="Inventory datastore Component">
<t>Inventory Data for service overlay can be obtained by using SNMP or
IPFIX 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-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></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></organization>
</author>
<author fullname="N.Bahadur" initials="N." surname="Bahadur">
<organization></organization>
</author>
<author fullname="A.Clemm" initials="A." surname="Clemm">
<organization></organization>
</author>
<author fullname="H. Ananthakrishnan" initials="H."
surname="Ananthakrishnan">
<organization></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></organization>
</author>
<author fullname="G.Heron" initials="G." surname="Heron">
<organization></organization>
</author>
<author fullname="L.Fang" initials="L." surname="Fang">
<organization></organization>
</author>
<date month="July" year="2013" />
</front>
<seriesInfo name="ID" value="draft-bitar-i2rs-service-chaining-00" />
</reference>
<reference anchor="I.D-draft-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></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:26:33 |