| I2RS working group | S. Hares |
| Internet-Draft | Q. Wu |
| Intended status: Standards Track | X. Guan |
| Expires: August 2, 2015 | Huawei |
| January 29, 2015 |
An Information model for service topology
draft-hares-i2rs-info-model-service-topo-02
This service model is a protocol independent topoology for the interface to routing system (I2RS).
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 (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 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.
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 whatever overlay or underlay they prefer and to locate service nodes in the network as needed.
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].
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.
The following diagram contains an informal graphical depiction of the main elements of the information model:
+----------------+
| 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 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.
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.
The information model for the Service-Topology component is more formally shown in the following diagram.
/* 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>
...
The elements of the Service-Topology information model are as follows:
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.
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 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.
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.
<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>
This module details traffic-engineering node attributes:
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.
<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:
This document does not introduce any new security issues above those identified in [RFC5511].
This draft includes no request to IANA.
| [I-D.ietf-i2rs-architecture] | Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-00, August 2013. |
| [I-D.ietf-i2rs-usecase-reqs-summary] | Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Internet-Draft draft-ietf-i2rs-usecase-reqs-summary-00, November 2014. |
| [I-D.ietf-sfc-problem-statement] | Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", Internet-Draft draft-ietf-sfc-problem-statement-00, January 2014. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 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. |
| [I-D.ietf-idr-ls-distribution] | Gredler, H., Medved, J., Previdi, S., Farrel, A. and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", Internet-Draft draft-ietf-idr-ls-distribution-03, May 2013. |