<?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    |&lt;...
            +----------------+   :
              *           *  :   :
              |           |  :...:
              |           |
      +--------+        +--------+
  ...&gt;|  node  |&lt;.......|segment |&lt;...
  :   +--------+&lt;.......+--------+   :
  :    :   *             : :  *  :   :
  :.....   |             : :  |  :...:
           |             : :  |
.....&gt;+--------+&lt;........: :  |
:     |   TP   |&lt;..........:  |
: ...&gt;+--------+              |
: :                           |
: : .....................+---------+
.........................|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 */

   &lt;service-topology&gt; ::= (&lt;topology&gt;...)

   /* Topology definitions */
   &lt;topology&gt; ::= &lt;TOPOLOGY_IDENTIFIER&gt;
                   [&lt;node-count&gt;]
                   (&lt;segment&gt;...)
                   (&lt;node&gt;...)
                   [&lt;topology-type&gt;]
                   [&lt;underlay-topologies&gt;]
                   [&lt;topology-extension&gt;]

   &lt;node-count&gt; ::= INTEGER-32;
   &lt;topology-type&gt; ::= (
                       (&lt;netconf&gt; [&lt;netconf-topology-type&gt;])|
                       (&lt;i2rs&gt; [&lt;i2rs-topology-type&gt;])

   &lt;underlay-topologies&gt; ::= (&lt;TOPOLOGY_IDENTIFIER&gt;...)

   &lt;topology-extension&gt; ::= 
                            &lt;netconf-topology-extension&gt; |
                                    ...
   &lt;segment&gt; ::= &lt;Segment_IDENTIFIER&gt;
                 &lt;source&gt;
                 &lt;destination&gt;
                 [&lt;direction&gt;]
                 [&lt;segment-extension&gt; ]

   &lt;source&gt; ::= &lt;termination-point-reference&gt;
   &lt;destination&gt; ::= &lt;termination-point-reference&gt;

   &lt;termination-point-reference&gt; ::= &lt;SF_NODE_IDENTIFIER&gt;

   &lt;direction&gt; ::= (&lt;Unidirection&gt;)|
                   (&lt;Bidirection&gt;)

   &lt;segment-extension&gt; ::= &lt;netconf-segment-extension&gt; |
                           &lt;i2rs-segment-extension&gt; |
                             ...
   &lt;node&gt; ::= &lt;SF_NODE_IDENTIFIER&gt;
              (&lt;termination-point&gt;...)
              [&lt;NODE_TYPE&gt;]
              [&lt;NEXT-HOP&gt;]
              [&lt;node-extension&gt;]

   &lt;termination-point&gt; ::= &lt;TERMINATION_POINT_IDENTIFIER&gt;
                           [&lt;supporting-termination-points&gt;]
                           [&lt;termination-point-extension&gt;]
   &lt;supporting-termination-points&gt; ::=
                   (&lt;TERMINATION_POINT_IDENTIFIER&gt;...)
   &lt; NODE-TYPE&gt; ::=
                   (&lt;Classifier-Node&gt;)|
                   (&lt;SF-Node&gt;)|
                   (&lt;SFF-Node&gt;)
                  ...
   &lt;NEXT-HOP&gt; ::= (&lt;NODE_IDENTIFIER&gt;...)
   &lt;node-extension&gt; ::= &lt;Classifier-extension&gt; |
                        &lt;SF-Node-extension&gt; |
                     &lt;SFF-Node-extension&gt;
                              ...
</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>  &lt;Classifier-extension&gt;::= &lt;SFP&gt; 
                            &lt;SFC-Policy&gt;
                            &lt;Matching-RULE&gt;
   &lt;SFP&gt; :: = &lt;SF-List&gt; 
              &lt;SFF-List&gt;
  &lt;SF-Node-extension&gt; :: = &lt;SF-Node-Locator&gt;
                     &lt;Support-Context-Type&gt; 
                                 &lt;SF-Type&gt;  
                        &lt;SF-Inventory-data&gt;

      &lt;SF-type&gt; ::=
             &lt;firewall&gt; |
             &lt;loadbalancer&gt;|
             &lt;NAT44&gt;|
             &lt;NAT64&gt;|
              &lt;DPI&gt;

  &lt;SFF-Node-extension&gt;::=&lt;SFFN-address&gt;
                         &lt;SFFN-Virtual-Context&gt;
                         &lt;Attached-service-add&gt;
                         &lt;Customer-Support-List&gt;
                         &lt;Customer-Support-Resource-List&gt;
                         &lt;SFFN-VNTopo&gt;
&lt;SFFN-Virtual-Context&gt;::= &lt;id&gt;
</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>
&lt;SF-inventory-data&gt; ::=
                    &lt;SF-capabilities&gt;
                    &lt;SF-administrative-info&gt;

&lt;SF-capabilities&gt; ::=
                    (&lt;supported-ACL-number &gt;)|
                    (&lt;virtual-context-number &gt;)|
                    (&lt;supported-packet-rate&gt;)|
                    (&lt;supported-bandwidth&gt;)

&lt;SF-administrative-info&gt; :: =
                        (&lt;Packet-rate-utilization&gt;)|
                        (&lt;Bandwidth-utilization-per-CoS&gt;)|
                        (&lt;Packet-rate-utilization-per-Cos&gt;)|
                        (&lt;Memory-utilization&gt;)|
                        (&lt;available-memory&gt;)|
                        (&lt;RIB-utilization-per-address-family&gt;)|
                        (&lt;FIB-utilization-per-address-family&gt;)|
                        (&lt;CPU-utilization&gt;)|
                        (&lt;Available storage&gt;)|
                        (&lt;Bandwidth-utilization&gt;)|
                        (&lt;Flow-resource-utilization-per-flow-type&gt;)
</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>
