I2RS working group                                              S. Hares
Internet-Draft                                                     Q. Wu
Intended status: Standards Track                                 M. Wang
Expires: August 2, 2015                                           J. You
                                                                  Huawei
                                                        January 29, 2015


               An Information model for service topology
              draft-hares-i2rs-info-model-service-topo-03

Abstract

   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.

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 2, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Hares, et al.            Expires August 2, 2015                 [Page 1]


Internet-Draft             IM for service Topo              January 2015


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Service Topology Information Model  . . . . . . . . . . . . .   3
     3.1.  Model Overview  . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Abstract Topology Model: the Service-Topology Component .   3
     3.3.  Model Extension: Service Function Chain Topology
           Component . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Model Extension: Inventory datastore Component  . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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.

   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.

   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.

   As stated in [I.D-ietf-sfc-problem-statement], the service overlay is
   independent of the network topology and allows operators to use



Hares, et al.            Expires August 2, 2015                 [Page 2]


Internet-Draft             IM for service Topo              January 2015


   whatever overlay or underlay they prefer and to locate service nodes
   in the network as needed.

   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.

2.  Conventions used in this document

   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 RFC2119 [RFC2119].

3.  Service Topology Information Model

   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.

3.1.  Model Overview

   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.

                +-----------------+
                |    Abstract     |
                | Topology Model  |
                |                 |
                +--------|--------+
                         |
             +------------------------+
             |       |                |
             |       |                |
    +--------V--------+      +--------V--------+
    |Service Function |      |                 |
    |     Chain       |      |  Other Service  |
    | Topology Model  |      | Topology Model  |
    +-----------------+      +-----------------+

3.2.  Abstract Topology Model: the Service-Topology Component

   The following diagram contains an informal graphical depiction of the
   main elements of the information model:




Hares, et al.            Expires August 2, 2015                 [Page 3]


Internet-Draft             IM for service Topo              January 2015


               +----------------+
               |    topology    |<...
               +----------------+   :
                 *           *  :   :
                 |           |  :...:
                 |           |
         +--------+        +--------+
     ...>|  node  |<.......|segment |<...
     :   +--------+<.......+--------+   :
     :    :   *             : :  *  :   :
     :.....   |             : :  |  :...:
              |             : :  |
   .....>+--------+<........: :  |
   :     |   TP   |<..........:  |
   : ...>+--------+              |
   : :                           |
   : : .....................+---------+
   .........................|Direction|
                            +---------+

   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.

   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.

   The information model for the Service-Topology component is more
   formally shown in the following diagram.

      /* exterior definitions for service topology */

      <service-topology> ::= (<topology>...)

      /* Topology definitions */



Hares, et al.            Expires August 2, 2015                 [Page 4]


Internet-Draft             IM for service Topo              January 2015


      <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>)|



Hares, et al.            Expires August 2, 2015                 [Page 5]


Internet-Draft             IM for service Topo              January 2015


                      (<SF-Node>)|
                      (<SFF-Node>)
                     ...
      <NEXT-HOP> ::= (<NODE_IDENTIFIER>...)
      <node-extension> ::= <Classifier-extension> |
                           <SF-Node-extension> |
                        <SFF-Node-extension>
                                 ...

   The elements of the Service-Topology information model are as
   follows:

   o  A service overlay can contain multiple topologies.  Each topology
      is captured in its own list element, distinguished via a topology-
      id.

   o  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.

   o  A topology contains segments and nodes, each captured in their own
      list.

   o  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.

   o  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.

   o  The topology, node, segment and direction elements can be extended
      with topology-specific components (topology-extensions, node-
      extension, segment-extension and direction-extension
      respectively).

   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




Hares, et al.            Expires August 2, 2015                 [Page 6]


Internet-Draft             IM for service Topo              January 2015


   to steer traffic through these specific service nodes at different
   layers or bypass some specific service nodes at different layers.

   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.

   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.

3.3.  Model Extension: Service Function Chain Topology Component

























Hares, et al.            Expires August 2, 2015                 [Page 7]


Internet-Draft             IM for service Topo              January 2015


     <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>

3.4.  Model Extension: Inventory datastore Component

   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.


















Hares, et al.            Expires August 2, 2015                 [Page 8]


Internet-Draft             IM for service Topo              January 2015


   <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>)

   This module details inventory node attributes:

   o  Inventory node attributes include SF-type,SF-capabilities and SF-
      administrative-info.

4.  Security Considerations

   This document does not introduce any new security issues above those
   identified in [RFC5511].

5.  IANA Considerations

   This draft includes no request to IANA.

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.




Hares, et al.            Expires August 2, 2015                 [Page 9]


Internet-Draft             IM for service Topo              January 2015


6.2.  Informative References

   [I.D-bitar-i2rs-service-chaining]
              Bitar, N., Heron, G., and L. Fang, "Interface to the
              Routing System (I2RS) for Service Chaining: Use Cases and
              Requirements", ID draft-bitar-i2rs-service-chaining-00,
              July 2013.

   [I.D-draft-ietf-idr-ls-distribution]
              Gredler, H., "North-Bound Distribution of Link-State and
              TE Information using BGP", ID draft-ietf-idr-ls-
              distribution-03, May 2013.

   [I.D-ietf-sfc-problem-statement]
              Quinn, P., "Service Function Chaining Problem Statement",
              ID draft-ietf-sfc-problem-statement-10, August 2014.

   [I.D-medved-i2rs-topology-im]
              Medved, J., Bahadur, N., Clemm, A., and H.
              Ananthakrishnan, "An Information Model for Network
              Topologies", ID draft-medved-i2rs-topology-im-01, October
              2003.

Authors' Addresses

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com


   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: sunseawq@huawei.com










Hares, et al.            Expires August 2, 2015                [Page 10]


Internet-Draft             IM for service Topo              January 2015


   Michael Wang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: wangzitao@huawei.com


   Jianjie You
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: youjianjie@huawei.com



































Hares, et al.            Expires August 2, 2015                [Page 11]