A YANG Data Model for Service Topology
draft-wang-i2rs-yang-service-topo-dm-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Zitao Wang , Qin Wu , Susan Hares | ||
| Last updated | 2015-01-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-i2rs-yang-service-topo-dm-00
I2RS Z. Wang
Internet-Draft Q. Wu
Intended status: Standards Track S. Hares
Expires: July 26, 2015 Huawei
January 22, 2015
A YANG Data Model for Service Topology
draft-wang-i2rs-yang-service-topo-dm-00
Abstract
This document defines a YANG data model for the 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 July 26, 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
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.
Wang, et al. Expires July 26, 2015 [Page 1]
Internet-Draft service topology January 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Service Topology data Model . . . . . . . . . . . . . . . . . 4
3.1. Model Overview . . . . . . . . . . . . . . . . . . . . . 4
3.2. Service Topology Yang . . . . . . . . . . . . . . . . . . 4
3.3. Node list . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Segment list . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Extension of the model: Service Function Chain Topology . 8
3.5.1. classifier-extension . . . . . . . . . . . . . . . . 8
3.5.2. sf-node-extension . . . . . . . . . . . . . . . . . . 8
3.5.3. sff-node-extension . . . . . . . . . . . . . . . . . 9
4. Service Topology data hierarchy . . . . . . . . . . . . . . . 10
5. Service Topology YANG Module . . . . . . . . . . . . . . . . 12
6. SFC Topology YANG Module . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
An overlay network is a virtual network of nodes and logical links
that is built on top of an existing network with the purpose to
implement a network service that is not available in the existing
network.
The service topology is used to represent how overlay network
elements(e.g., abstract node) are interconnected to each other. The
typical example of the service topology is SFC based service topology
which is built from an ordered set of service functions and the
service function paths between the service function nodes [draft-
ietf-sfc-architecture].
The service topology is built on top of one or several underlying
networks. In case multi-tenancy is needed, Multiple service
topologies can be built on top of the same underlying network. Each
tenant can only see its own service topology.But all the tenant's
service topology can be mapped into the same network topology.
Unlike the network topology, the service topology is abstraction of
network topology or aggregation of the network topology. It may be
not possible to collect service topology information from the same
routing protocol as network topology since there is no another
control plane protocol running on top of the underlying networks.
This document defines a YANG data model for the service topology
Wang, et al. Expires July 26, 2015 [Page 2]
Internet-Draft service topology January 2015
2. Definitions and Acronyms
Datastore: A conceptual store of instantiated management information,
with individual data items represented by data nodes which are
arranged in hierarchical manner.
Data subtree: An instantiated data node and the data nodes that are
hierarchically contained within it.
NETCONF: Network Configuration Protocol.
URI: Uniform Resource Identifier.
YANG: A data definition language for NETCONF.
Classification: Locally instantiated policy and customer/network/
service profile matching of traffic flows for identification of
appropriate outbound forwarding actions.
Classifier: An element that performs Classification.
Service Function Chain (SFC): A service function chain defines a set
of abstract service functions and ordering constraints that must be
applied to packets and/or frames selected as a result of
classification.
Service Function (SF): A function that is responsible for specific
treatment of received packets.
Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the network to one
or more connected service functions according to information carried
in the SFC encapsulation, as well as handling traffic coming back
from the SF.
Metadata: provides the ability to exchange context information
between classifiers and SFs and among SFs.
Service Function Path (SFP): The SFP provides a level of indirection
between the fully abstract notion of service chain as a sequence of
abstract service functions to be delivered, and the fully specified
notion of exactly which SFF/SFs the packet will visit when it
actually traverses the network.
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].
Wang, et al. Expires July 26, 2015 [Page 3]
Internet-Draft service topology January 2015
3. Service Topology data Model
This section describe the architecture and the tree diagram of the
service topology yang data model.
3.1. Model Overview
The abstract Topology yang Model contain a set of abstract nodes and
a list of abstract links. Service Function Chain Topo yang model and
other service topo model can be augumented from the abstract topology
model with SFC base topology specifics.
The following Figure depicts the relationship of service topology
yang model to the abstract topology yang model.
+-----------------+
| Abstract |
| Topology Model |
| |
+--------|--------+
|
+------------------------+
| | |
| | |
+--------V--------+ +--------V--------+
|Service Function | | |
| Chain | | Other Service |
| Topology Model | | Topology Model |
+-----------------+ +-----------------+
The relationship of service topology yang model to the abstract
topology yang model
3.2. Service Topology Yang
The following figure provide the structure of service topology yang
model. Each node is printed as:
Wang, et al. Expires July 26, 2015 [Page 4]
Internet-Draft service topology January 2015
<status> <flags> <name> <opts> <type>
<status> is one of:
+ for current
x for deprecated
o for obsolete
<flags> is one of:
rw for configuration data
ro for non-configuration data
-x for rpcs
-n for notification
<name> is the name of the node
If the node is augmented into the tree from another module, its
name is printed as <prefix>:<name>.
<opts> is one of:
? for an optional leaf or choice
! for a presence container
* for a leaf-list or list
[<keys>] for a list's keys
<type> is the name of the type for leafs and leaf-lists
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
+--rw node-count uint32
+--rw topology-type!
+--rw topology-extension!
+--rw underlay-topologies*[topology-id]
| +--rw topology-id network-id
+--rw node* [node-id]
| +--rw node-id node-id
...
+--rw segment*[segment-id]
+--rw segment-id link-id
...
The service topo yang model contains a service-topology list. And
each service-topology list contains service-topo-id leaf, node-count
leaf, topology-type container, topology-extension container,
underlay-topologies list, service node list and segment list.
o Different service-topology list is distinguished via the leaf
service-topo-id.
Wang, et al. Expires July 26, 2015 [Page 5]
Internet-Draft service topology January 2015
o The node-count leaf can be used to indicate the number of nodes
which contained in the service-topology list.
o The topology-type specify the topology type, such as NETCONF or
I2RS. A service topology can even have multiple types
simultaneously. So in this document a topology-type container is
defined.
o The topology-extension container can be used to augment the service
topology model by topology specifics.
o Service Nodes/Segments can map onto and be supported by other
network elements/links in the underlying network, and the Service
Topologies can map onto other underlay topologies.
3.3. Node list
The following figure provide the node list of the service topo yang
model:
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
......
+--rw node* [node-id]
| +--rw node-id node-id
| +--rw termination-point*[termination-point-id]
| | +--rw termination-point-id node-id
| | +--rw support-termination-points*[support-point-id]
| | | +--rw support-point-id node-id
| | +--rw termination-point-extension!
| +--rw node-type!
| | +--rw classifier-node? string
| | +--rw sf-node? string
| | +--rw sff-node? string
| +--rw next-hop*[hop-id]
| | +--hop-id node-id
| +--rw node-extension!
| | +--rw classifier-extension!
| | +--rw sf-node-extension!
| | +--rw sff-node-extension!
Each service segment list contains a node-id leaf, a termination-
point list, a next-hop list, a node-type container and a node-
extension container.
Wang, et al. Expires July 26, 2015 [Page 6]
Internet-Draft service topology January 2015
o The node-id leaf can be used to distinguish the different service
node.
o The termination list can be used to terminate segment. An examples
of a termination point might be a physical or logical port or, more
generally, an interface.
o The node-type container can used to indicate the type node, such
classifier, a sf or a sff.
o The node-extension container can be used to augment the node list
by node specifics, for example: classifier extension, sf extension,
sff extension.
3.4. Segment list
The following figure provide the Segment list of the service topo
yang model:
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
......
+--rw segment* [segment-id]
| +--rw segment-id link-id
| +--rw source
| | +--rw source-id node-id
| | +--rw termination-point-reference*[source-support-id]
| | | +--rw source-support-id node-id
| +--rw destination
| | +--rw destination-id node-id
| | +--rw termination-point-reference*[destination-support-id]
| | | +--rw destination-support-id node-id
| +--ro direction!
| | +--ro unidirection? boolean
| | +--ro bidirection? boolean
| +--rw segment-extension!
| | +--rw netconf-segment-extension!
| | +--rw i2rs-segment-extension!
Each service node list contains a segment-id leaf, a source
container, a destination container, a direction container and a
segment-extension container.
o The segment-id leaf can be used to distinguish the different
service segment.
Wang, et al. Expires July 26, 2015 [Page 7]
Internet-Draft service topology January 2015
o The source/destination container include a node-id and a
termination-point-reference list. Both source and destination
reference a corresponding node, as well as a termination point on
that node.
o The segment-extension container can be used to augment the segment
list by segment specifics. Such as netconf segment extension, i2rs
segment extension.
3.5. Extension of the model: Service Function Chain Topology
3.5.1. classifier-extension
In SFC, the classifier is used to locally instantiated policy and
customer/network/service profile matching of traffic flows for
identification of approriate outbound forwarding actions.
The following figure provide the classifier-extension of the service
topo yang model:
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
......
+--rw node* [node-id]
| +--rw node-id node-id
......
| +--rw node-extension!
| | +--rw classifier-extension!
| | | +--rw classifier-id node-id
| | | +--rw sfc-policy uint32
| | | +--rw sfp!
| | | | +--rw sfp-id uint32
| | | | +--rw sf-list*[sf-id]
| | | | | +--rw sf-id node-id
| | | | +--rw sff-list*[sff-id]
| | | | | +--rw sff-id node-id
.......
3.5.2. sf-node-extension
The sf is a function that is responsible for specific treatment of
received packets. As a logical component.
The following figure provide the sf-node-extension of the service
topo yang model:
Wang, et al. Expires July 26, 2015 [Page 8]
Internet-Draft service topology January 2015
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
......
+--rw node* [node-id]
| +--rw node-id node-id
......
| +--rw node-extension!
| | +--rw classifier-extension!
.......
| | +--rw sf-node-extension!
| | | +--rw sf-id node-id
| | | +--rw sf-node-locator uint32
| | | +--rw sf-type!
| | | | +--rw firewall? uint32
| | | | +--rw loadbalancer? uint32
| | | | +--rw NAT44? uint32
| | | | +--rw NAT64? uint32
| | | | +--rw DPI? uint32
| | +--rw sf-inventory-data!
.......
3.5.3. sff-node-extension
The service function forwarder is responsible for delivering traffic
received from the network to one or more connected service functions
according to information carried in the SFC encapsulation, as well as
handling traffic coming back from the SF.
The following figure provide the sff-node-extension of the service
topo yang model:
Wang, et al. Expires July 26, 2015 [Page 9]
Internet-Draft service topology January 2015
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
......
+--rw node* [node-id]
| +--rw node-id node-id
......
| +--rw node-extension!
| | +--rw classifier-extension!
| | +--rw sf-node-extension!
.......
| | +--rw sff-node-extension!
| | | +--rw sff-id node-id
| | | +--rw (sffn-address)?
| | | | +--:(ipv4-address)
| | | | | +--rw ipv4-address? inet:ipv4-address
| | | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address
| | | +--rw sffn-virtual-context!
| | | | +--rw context-id uint32
| | | +--rw Attached-service-address!
| | | | +--rw service-node*[service-node-id]
| | | | | +--rw service-node-id node-id
| | | | +--rw host-system*[host-system-id]
| | | | +--rw host-system-id uint32
| | | +--rw customer-support*[customer-id]
| | | | +--rw customer-id uint32
| | | +--rw customer-service-resource*[customer-resource-id]
| | | | +--rw customer-resource-id node-id
| | | +--rw sffn-vntopo!
.......
4. Service Topology data hierarchy
The complete data hierarchy related to the service topology YANG
model is presented below.
Wang, et al. Expires July 26, 2015 [Page 10]
Internet-Draft service topology January 2015
module: service topo
+--rw service-topologise!
+--rw service-topology* [service-topo-id]
+--rw service-topo-id network-id
+--rw node-count uint32
+--rw topology-type!
+--rw topology-extension!
+--rw underlay-topologies*[topology-id]
| +--rw topology-id network-id
+--rw node* [node-id]
| +--rw node-id node-id
| +--rw termination-point*[termination-point-id]
| | +--rw termination-point-id node-id
| | +--rw support-termination-points*[support-point-id]
| | | +--rw support-point-id node-id
| | +--rw termination-point-extension!
| +--rw node-type!
| | +--rw classifier-node? string
| | +--rw sf-node? string
| | +--rw sff-node? string
| +--rw next-hop*[node-id]
| | +--hop-id node-id
| +--rw node-extension!
| | +--rw classifier-extension!
| | +--rw sf-node-extension!
| | +--rw sff-node-extension!
+--rw segment* [segment-id]
| +--rw segment-id link-id
| +--rw source
| | +--rw source-id node-id
| | +--rw termination-point-reference*[source-support-id]
| | | +--rw source-support-id node-id
| +--rw destination
| | +--rw destination-id node-id
| | +--rw termination-point-reference*[destination-support-id]
| | | +--rw destination-support-id node-id
| +--ro direction!
| | +--ro unidirection? boolean
| | +--ro bidirection? boolean
| +--rw segment-extension!
| | +--rw netconf-segment-extension!
| | +--rw i2rs-segment-extension!
data hierarchy of Service Topology
Wang, et al. Expires July 26, 2015 [Page 11]
Internet-Draft service topology January 2015
5. Service Topology YANG Module
<CODE BEGINS> file "service-topo.yang"
module service-topo {
yang-version 1;
namespace "urn:TBD:params:xml:ns:yang:service-topo";
prefix stopo;
import ietf-inet-types {
prefix inet;
}
organization "IETF I2RS Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines service topology yang data model";
typedef node-id {
type inet:uri;
}
typedef network-id {
type inet:uri;
}
typedef link-id {
type inet:uri;
}
container service-topologies {
description
"Contains configuration related data. Within the container
is list of service topologies.";
list service-topology{
key "service-topo-id";
description
"Define the list of service-topology within the network";
leaf service-topo-id{
type network-id;
description
"the identifier for a service topology";}
leaf node-count{
type uint32;
description
"Number of nodes within a service topology.";}
container topology-type{
description
" This container contains several leaf to specify the topology type,
such as NETCONF or I2RS. A service topology can even have
Wang, et al. Expires July 26, 2015 [Page 12]
Internet-Draft service topology January 2015
multiple types simultaneously. And this container can
be used to augment the service topology model by topology specifics.";}
container topology-extension{
description
" The topology-extension container can be used to augment
the service topology model by topology specifics.";}
list underlay-topologies {
key "topology-id";
description
"Define the list of underlay-topologies within the service-topology list";
leaf topology-id {
type network-id;
description
"It is presumed that a datastore will contain many topologies. To
distinguish between topologies it is vital to have UNIQUE
topology identifiers.";}
}
list node {
key "node-id";
description
"Define the list of node within the service-topology list";
leaf node-id {
type node-id;
description
"The identifier of a node in the service topology.";}
list termination-point{
key "termination-point-id";
description
"Define the list of termination-point within the node list";
leaf termination-point-id {
type node-id;
description
"The identifier of the termination point of the node";}
list support-termination-points{
key "support-point-id";
description
"Define the list of support-point-id within the termination-point list";
leaf support-point-id {
type node-id;
Wang, et al. Expires July 26, 2015 [Page 13]
Internet-Draft service topology January 2015
description
"the identifier of the support node of the termination point";}
}
container termination-point-extension{
description
"The termination-point-extension container can be used to augment
the service topology model by topology specifics.";}
}
container node-type{
description
"The node-type container can used to indicate the type node,
such classifier, a sf or a sff. And this container can be used
to augment the service topology model by topology specifics. ";
leaf classifier-node {
type string;
description
"To indicate the node is a classifier";}
leaf sf-node {
type string;
description
"To indicate the node is a service function(sf)";}
leaf sff-node {
type string;
description
" To indicate the node is a service function forward(sff)";}
}
list next-hop{
key "hop-id";
description
"Define the list of next-hop within the node list";
leaf hop-id {
type node-id;
description
"The identifier of the next hop of the node";}
}
container node-extension{
description
" The node-extension container can be used to augment
the service topology model by topology specific nodes.";
container classifier-extension {
Wang, et al. Expires July 26, 2015 [Page 14]
Internet-Draft service topology January 2015
description
"The classifier-extension container contains the extensions
of the classifier";}
container sf-node-extension {
description
"The sf-extension container contains the extensions of the sf.";}
container sff-node-extension {
description
" The sff-extension container contains the extensions of the sff. ";}
}
} //end the node list
list segment{
key "segment-id";
description
"Define the list of segment within the service-topology list.";
leaf segment-id{
type link-id;
description
" The segment-id leaf can be used to distinguish
the different service segment.";}
container source{
description
"The source container contains the source node
and the termination point reference list.";
leaf source-id{
type node-id;
description
"The identifier of the source node of the segment.";}
list termination-point-reference{
key "source-support-id";
leaf source-support-id{
type node-id;
description
"The identifier of the termination point of the source node.";}
}//end the termination-point-reference list
}//end the source container
container destination{
description
"The destination container contains the source node
and the termination point reference list.";
Wang, et al. Expires July 26, 2015 [Page 15]
Internet-Draft service topology January 2015
leaf destination-id{
type node-id;
description
"The identifier of the destination node of the segment.";}
list termination-point-reference{
key "destination-support-id";
leaf destination-support-id{
type node-id;
description
"The identifier of the termination point of the source node.";}
}//end the termination-point-reference list
}//end the destination container
container direction{
leaf unidirection{
type boolean;
description
"Indicates whether the segment is unidirection or not.";}
leaf bidirection{
type boolean;
description
"Indicates whether the segment is bidirection or not.";}
} //end the direction container
container segment-extension{
description
"The segment-extension container can be used to augment
the segment list by segment specifics. Such as
netconf segment extension, i2rs segment extension.";
container netconf-segment-extension {
description
"To contain the netconf segment extension.";}
container i2rs-segment-extension {
description
"To contain the i2rs segment extension.";}
} //end the segment-extension container
}//end the segment list
}//end the service-topology list
}
}
<CODE ENDS>
6. SFC Topology YANG Module
<CODE BEGINS>file "sfc-topo@2013-12-23.yang"
module sfc-topo {
yang-version 1;
Wang, et al. Expires July 26, 2015 [Page 16]
Internet-Draft service topology January 2015
namespace "urn:TBD:params:xml:ns:yang:sfc-topology";
prefix "sfc-topo";
import service-topo {
prefix "stopo";
}
import ietf-inet-types {
prefix "inet";
}
organization "IETF I2RS Working Group";
contact
"wangzitao@huawei.com";
description
"This module defines sfc topology yang data model";
typedef node-id {
type inet:uri;
}
augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:classifier-extension"{
leaf classifier-id{
type node-id;
description
"The identifier of the classifier.";}
leaf sfc-policy{
type uint32;
description
"Indicate the policy of sfc.";}
container sfp{
description
"contains several sfps.";
leaf sfp-id{
type uint32;
description
"The identifier of the sfp.";}
list sf-list{
key "sf-id";
leaf sf-id{
type node-id;
description
"The identifier of the sf which include in the sfp.";}
}
list sff-list{
key "sff-id";
leaf sff-id{
type node-id;
description
"The identifier of the sff which include in the sfp.";}
}
}//end the sfp container
}//end the classifier-extension
Wang, et al. Expires July 26, 2015 [Page 17]
Internet-Draft service topology January 2015
augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:sf-node-extension"{
leaf sf-id{
type node-id;
description
"The identifier of the service function(sf).";}
leaf sf-node-locator{
type uint32;
description
"To indicate the service function (sf) locator";}
container sf-type{
leaf firewall{
type uint32;
description
"To indicate the service function (sf) is firewall.";}
leaf loadbalancer{
type uint32;
description
"To indicate the service function (sf) is loadbalancer.";}
leaf NAT44{
type uint32;
description
"To indicate the service function (sf) is NAT44.";}
leaf NAT64{
type uint32;
description
"To indicate the service function (sf) is NAT64.";}
leaf DPI{
type uint32;
description
"To indicate the service function (sf) is DPI.";}
}//end the sf-type container
container sf-inventory-data{
description
"The container of the inventory data of service function (sf).";
}
}//end the sf-node-extension
augment "/stopo:service-topologies/stopo:service-topology/stopo:node/stopo:node-extension/stopo:sff-node-extension"{
leaf sff-id{
type node-id;
description
"The identifier of the service function forward (sff).";}
choice sffn-address{
description
"The address of the service function forward (sff) node";
case ipv4-address{
leaf ipv4-address{
type inet:ipv4-address;}
Wang, et al. Expires July 26, 2015 [Page 18]
Internet-Draft service topology January 2015
}
case ipv6-address{
leaf ipv6-address{
type inet:ipv6-address;}
}
}//end the choice sffn-address
container sffn-virtual-context{
leaf context-id{
type uint32;
description
"the identifier of the sffn virtual context.";}
}
container Attached-service-address{
list service-node{
key "service-node-id";
leaf service-node-id{
type node-id;
description
"The identifier of the service node.";}
}//end the service-node list
list host-system{
key "host-system-id";
leaf host-system-id{
type uint32;
description
"The identifier of the host system.";}
}//end the service-node list
} //end the attached-service-address container
list customer-support{
key "customer-id";
leaf customer-id{
type uint32;
description
"The identifier of the customer.";}
}//end the customer-support list
list customer-service-resource{
key "customer-resource-id";
leaf customer-resource-id{
type node-id;
description
"The identifier of the customer resource.";}
}//end the customer-service-resource list
container sffn-vntopo{
description
"This container can be use to contain the virtual network topology of
Sffn. And it can be augment by specific virtual network topology.";
}//end the sffn-vntopo container
}//end the sff-node-extension
Wang, et al. Expires July 26, 2015 [Page 19]
Internet-Draft service topology January 2015
}
<CODE ENDS>
7. Security Considerations
TBD.
8. IANA Considerations
TBD.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241', June 2011.
[draft-ietf-sfc-architecture-02]
Halpern, J., "Service Function Chaining (SFC)
Architecture", ID draft-ietf-sfc-architecture-02, May
2014.
Authors' Addresses
Zitao(Michael) Wang
Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: wangzitao@huawei.com
Qin Wu
Huawei Technologies,Co.,Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Phone: +86 25 56623633
Email: bill.wu@huawei.com
Wang, et al. Expires July 26, 2015 [Page 20]
Internet-Draft service topology January 2015
Susan Hares
Huawei Technologies,Co.,Ltd
7453 Hickory Hill
Saline, MI 48176
USA
Email: Email: shares@ndzh.com
Wang, et al. Expires July 26, 2015 [Page 21]