< draft-ietf-teas-sf-aware-topo-model-01.txt   draft-ietf-teas-sf-aware-topo-model-02.txt >
Network Working Group I. Bryskin Network Working Group I. Bryskin
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational X. Liu Intended status: Informational X. Liu
Expires: December 30, 2018 Volta Networks Expires: March 25, 2019 Volta Networks
Y. Lee Y. Lee
J. Guichard
Huawei Technologies Huawei Technologies
June 28, 2018 L. Contreras
Telefonica
D. Ceccarelli
Ericsson
J. Tantsura
Nuage Networks
September 21, 2018
SF Aware TE Topology YANG Model SF Aware TE Topology YANG Model
draft-ietf-teas-sf-aware-topo-model-01 draft-ietf-teas-sf-aware-topo-model-02
Abstract Abstract
This document describes a YANG data model for TE network topologies This document describes a YANG data model for TE network topologies
that are network service and function aware. that are network service and function aware.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 34 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 30, 2018. This Internet-Draft will expire on March 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 4 2. Modeling Considerations . . . . . . . . . . . . . . . . . . . 6
3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 5 3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 7
4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 6 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 13 5. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 15
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15 6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . 24
9.3. Normative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Companion YANG Model for Non-NMDA Compliant Appendix A. Companion YANG Model for Non-NMDA Compliant
Implementations . . . . . . . . . . . . . . . . . . 24 Implementations . . . . . . . . . . . . . . . . . . 26
A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 24 A.1. SF Aware TE Topology State Module . . . . . . . . . . . . 26
Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 26 Appendix B. Data Examples . . . . . . . . . . . . . . . . . . . 28
B.1. A Topology with Multiple Connected Network Functions . . 26 B.1. A Topology with Multiple Connected Network Functions . . 28
B.2. A Topology with an Encapsulated Network Service . . . . . 31 B.2. A Topology with an Encapsulated Network Service . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Use Cases for SF Aware Topology Models . . . . . . . 37
C.1. Exporting SF/NF Information to Network Clients and Other
Network SDN Controllers . . . . . . . . . . . . . . . . . 37
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks . 38
C.3. Managing SFCs with TE Constraints . . . . . . . . . . . . 39
C.4. SFC Protection and Load Balancing . . . . . . . . . . . . 40
C.5. Network Clock Synchronization . . . . . . . . . . . . . . 43
C.6. Client - Provider Network Slicing Interface . . . . . . . 43
C.7. Dynamic Assignment of Regenerators for L0 Services . . . 43
C.8. Dynamic Assignment of OAM Functions for L1 Services . . . 45
C.9. SFC Abstraction and Scaling . . . . . . . . . . . . . . . 46
C.10. Dynamic Compute/VM/Storage Resource Assignment . . . . . 46
C.11. Application-aware Resource Operations and Management . . 47
C.12. IANA Considerations . . . . . . . . . . . . . . . . . . . 48
C.13. Security Considerations . . . . . . . . . . . . . . . . . 48
C.14. Acknowledgements . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
Normally network connectivity services are discussed as a means to
inter-connect various abstract or physical network topological
elements, such as ports, link termination points and nodes
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te]. However, the
connectivity services, strictly speaking, interconnect not the
network topology elements per-se, rather, located on/associated with
the various network and service functions [RFC7498] [RFC7665]. In
many scenarios it is beneficial to decouple the service/network
functions from the network topology elements hosting them, describe
them in some unambiguous and identifiable way (so that it would be
possible, for example, to auto-discover on the network topology
service/network functions with identical or similar functionality and
characteristics) and engineer the connectivity between the service/
network functions, rather than between their current topological
locations.
Today a network offers to its clients far more services than just Today a network offers to its clients far more services than just
connectivity across the network. Large variety of physical, logical connectivity across the network. Large variety of physical, logical
and/or virtual service functions, network functions and transport and/or virtual service functions, network functions and transport
functions (collectively named in this document as SFs) could be functions (collectively named in this document as SFs) could be
allocated for and assigned to a client. As described in allocated for and assigned to a client. As described in the appendix
[I-D.ietf-teas-use-cases-sf-aware-topo-model], there are some of this document, there are some important use cases, in which the
important use cases, in which the network needs to represent to the network needs to represent to the client SFs at the client's disposal
client SFs at the client's disposal as topological elements in as topological elements in relation to other elements of a topology
relation to other elements of a topology (i.e. nodes, links, link and (i.e. nodes, links, link and tunnel termination points) used by the
tunnel termination points) used by the network to describe itself to network to describe itself to the client. Not only would such
the client. Not only would such information allow for the client to information allow for the client to auto-discover the network's SFs
auto-discover the network's SFs available for the services available for the services provisioned for the client, it would also
provisioned for the client, it would also allow for the client allow for the client selecting the SFs, duel-optimizing the selection
selecting the SFs, duel-optimizing the selection on the SF location on the SF location on the network and connectivity means (e.g. TE
on the network and connectivity means (e.g. TE tunnels) to inter- tunnels) to inter-connect the SFs. Consequently thus would give to
connect the SFs. Consequently thus would give to both the network both the network and the client powerful means for the service
and the client powerful means for the service function chain (SFC function chain (SFC [RFC7498] [RFC7665]) negotiation to achieve most
[RFC7498] [RFC7665]) negotiation to achieve most efficient and cost efficient and cost effective (from the network point of view) and
effective (from the network point of view) and most optimal yet most optimal yet satisfying all necessary constraints of SFCs (from
satisfying all necessary constraints of SFCs(from the client's point the client's point of view).
of view).
This document defines a YANG data model that allows service functions This document defines a YANG data model that allows service functions
to be represented along with TE topology elements. to be represented along with TE topology elements.
1.1. Terminology 1.1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
o Network Function (NF): A functional block within a network
infrastructure that has well-defined external interfaces and well-
defined functional behaviour [ETSI-NFV-TERM]. Such functions
include message router, CDN, session border controller, WAN
cceleration, DPI, firewall, NAT, QoE monitor, PE router, BRAS, and
radio/fixed access network nodes.
o Network Service: Composition of Network Functions and defined by
its functional and behavioural specification. The Network Service
contributes to the behaviour of the higher layer service, which is
characterized by at least performance, dependability, and security
specifications. The end-to-end network service behaviour is the
result of the combination of the individual network function
behaviours as well as the behaviours of the network infrastructure
composition mechanism [ETSI-NFV-TERM].
o Service Function (SF): A function that is responsible for specific
treatment of received packets. A service function can act at
various layers of a protocol stack (e.g., at the network layer or
other OSI layers). As a logical component, a service function can
be realized as a virtual element or be embedded in a physical
network element. One or more service functions can be embedded in
the same network element. Multiple occurrences of the service
function can exist in the same administrative domain. A non-
exhaustive list of service functions includes: firewalls, WAN and
application acceleration, Deep Packet Inspection (DPI), server
load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HTTP header
enrichment functions, and TCP optimizers. The generic term "L4-L7
services" is often used to describe many service functions
[RFC7498].
o Service Function Chain (SFC): A service function chain defines an
ordered or partially ordered set of abstract service functions and
ordering constraints that must be applied to packets, frames, and/
or flows selected as a result of classification. An example of an
abstract service function is a firewall. The implied order may
not be a linear progression as the architecture allows for SFCs
that copy to more than one branch, and also allows for cases where
there is flexibility in the order in which service functions need
to be applied. The term "service chain" is often used as
shorthand for "service function chain" [RFC7498].
o Connectivity Service: Any service between layer 0 and layer 3
aiming at delivering traffic among two or more end customer edge
nodes connected to provider edge nodes. Examples include L3VPN,
L2VPN etc.
o Link Termination Point (LTP): A conceptual point of connection of
a TE node to one of the TE links, terminated by the TE node.
Cardinality between an LTP and the associated TE link is 1:0..1
[I-D.ietf-teas-yang-te-topo].
o Tunnel Termination Point (TTP): An element of TE topology
representing one or several of potential transport service
termination points (i.e. service client adaptation points such as
WDM/OCh transponder). TTP is associated with (hosted by) exactly
one TE node. TTP is assigned with the TE node scope unique ID.
Depending on the TE node's internal constraints, a given TTP
hosted by the TE node could be accessed via one, several or all TE
links terminated by the TE node [I-D.ietf-teas-yang-te-topo].
The following terms are defined in [RFC7950] and are not redefined The following terms are defined in [RFC7950] and are not redefined
here: here:
o augment o augment
o data model o data model
o data node o data node
1.2. Tree Diagrams 1.2. Tree Diagrams
skipping to change at page 5, line 7 skipping to change at page 7, line 7
with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN]. with the help of ETSI models Virtual Links (VLs) [ETSI-NFV-MAN].
This option is especially useful when the costs of the local chaining This option is especially useful when the costs of the local chaining
are negligible as compared to ones of the end-to-end SFCs said local are negligible as compared to ones of the end-to-end SFCs said local
SFCs are part of. SFCs are part of.
Section 3 and 4 provide the YANG model structure and the YANG module Section 3 and 4 provide the YANG model structure and the YANG module
for SF-aware Topology. Section 5 and 6 provide the YANG model for SF-aware Topology. Section 5 and 6 provide the YANG model
structure and the YANG module for Data Center Compute Node resource structure and the YANG module for Data Center Compute Node resource
abstraction. This provides an example of SF2LTP CM where DC compute abstraction. This provides an example of SF2LTP CM where DC compute
nodes are connected to LTPs at the remote ends of the corresponding nodes are connected to LTPs at the remote ends of the corresponding
TE links. This use-case is described in Section 12 of TE links. This use-case is described in Section 10 of Appendix C.
[I-D.ietf-teas-use-cases-sf-aware-topo-model].
3. Model Structure 3. Model Structure
module: ietf-te-topology-sf module: ietf-te-topology-sf
augment /nw:networks/nw:network/nw:network-types/tet:te-topology: augment /nw:networks/nw:network/nw:network-types/tet:te-topology:
+--rw sf! +--rw sf!
augment /nw:networks/nw:network/nw:node/tet:te augment /nw:networks/nw:network/nw:node/tet:te
/tet:te-node-attributes: /tet:te-node-attributes:
+--rw service-function +--rw service-function
+--rw connectivity-matrices +--rw connectivity-matrices
skipping to change at page 18, line 4 skipping to change at page 19, line 49
leaf total { type uint32; units 'GB'; } leaf total { type uint32; units 'GB'; }
leaf used { type uint32; units 'GB'; } leaf used { type uint32; units 'GB'; }
leaf free { type uint32; units 'GB'; } leaf free { type uint32; units 'GB'; }
} }
grouping vcpu { grouping vcpu {
leaf total { type uint16; } leaf total { type uint16; }
leaf used { type uint16; } leaf used { type uint16; }
leaf free { type uint16; } leaf free { type uint16; }
} }
grouping hypervisor {
grouping hypervisor {
container ram { container ram {
uses ram; uses ram;
} }
container disk { container disk {
uses disk; uses disk;
} }
container vcpu { container vcpu {
uses vcpu; uses vcpu;
skipping to change at page 22, line 28 skipping to change at page 24, line 23
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[ETSI-NFV-MAN] [ETSI-NFV-MAN]
ETSI, "Network Functions Virtualisation (NFV); Management ETSI, "Network Functions Virtualisation (NFV); Management
and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December and Orchestration", ETSI GS NFV-MAN 001 V1.1.1, December
2014. 2014.
[I-D.ietf-teas-use-cases-sf-aware-topo-model]
Bryskin, I., Liu, X., Guichard, J., Lee, Y., Contreras,
L., Ceccarelli, D., and J. Tantsura, "Use Cases for SF
Aware Topology Models", draft-ietf-teas-use-cases-sf-
aware-topo-model-00 (work in progress), June 2018.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), December 2017. progress), December 2017.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-16 (work in Topologies", draft-ietf-teas-yang-te-topo-18 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-netmod-revised-datastores] [I-D.ietf-netmod-revised-datastores]
Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore and R. Wilton, "Network Management Datastore
Architecture", draft-ietf-netmod-revised-datastores-10 Architecture", draft-ietf-netmod-revised-datastores-10
(work in progress), January 2018. (work in progress), January 2018.
9.2. Informative References 9.2. Informative References
skipping to change at page 24, line 5 skipping to change at page 25, line 10
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[I-D.ietf-netmod-yang-tree-diagrams] [I-D.ietf-netmod-yang-tree-diagrams]
Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
ietf-netmod-yang-tree-diagrams-06 (work in progress), ietf-netmod-yang-tree-diagrams-06 (work in progress),
February 2018. February 2018.
9.3. Normative References
[ETSI-NFV-TERM]
ETSI, "Network Functions Virtualisation (NFV); Terminology
for Main Concepts in NFV", ETSI GS NFV 003 V1.2.1,
December 2014.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and
I. Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work
in progress), July 2018.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
DOI 10.17487/RFC3022, January 2001,
<https://www.rfc-editor.org/info/rfc3022>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[I-D.ietf-sfc-hierarchical]
Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", draft-
ietf-sfc-hierarchical-11 (work in progress), June 2018.
[I-D.defoy-netslices-3gpp-network-slicing]
Foy, X. and A. Rahman, "Network Slicing - 3GPP Use Case",
draft-defoy-netslices-3gpp-network-slicing-02 (work in
progress), October 2017.
[_3GPP.28.801]
3GPP, "Study on management and orchestration of network
slicing for next generation network", 3GPP TR 28.801
V2.0.0, September 2017,
<http://www.3gpp.org/ftp/Specs/html-info/28801.htm>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations Appendix A. Companion YANG Model for Non-NMDA Compliant Implementations
The YANG module ietf-te-topology-sf defined in this document is The YANG module ietf-te-topology-sf defined in this document is
designed to be used in conjunction with implementations that support designed to be used in conjunction with implementations that support
the Network Management Datastore Architecture (NMDA) defined in the Network Management Datastore Architecture (NMDA) defined in
[I-D.ietf-netmod-revised-datastores]. In order to allow [I-D.ietf-netmod-revised-datastores]. In order to allow
implementations to use the model even in cases when NMDA is not implementations to use the model even in cases when NMDA is not
supported, the following companion module, ietf-te-topology-sf-state, supported, the following companion module, ietf-te-topology-sf-state,
is defined as state model, which mirrors the module ietf-te-topology- is defined as state model, which mirrors the module ietf-te-topology-
sf defined earlier in this document. However, all data nodes in the sf defined earlier in this document. However, all data nodes in the
skipping to change at page 35, line 9 skipping to change at page 37, line 9
} }
] ]
} }
] ]
} }
] ]
} }
} }
Appendix C. Use Cases for SF Aware Topology Models
C.1. Exporting SF/NF Information to Network Clients and Other Network
SDN Controllers
In the context of Service Function Chain (SFC) orchestration one
existing problem is that there is no way to formally describe a
Service or Network Function in a standard way (recognizable/
understood by a third party) as a resource of a network topology
node.
One implication of this is that there is no way for the orchestrator
to give a network client even a ball-park idea as to which network's
SFs/NFs are available for the client's use/control and where they are
located in the network even in terms of abstract topologies/virtual
networks configured and managed specifically for the client.
Consequently, the client has no say on how the SFCs provided for the
client by the network should be set up and managed (which SFs are to
be used and how they should be chained together, optimized,
manipulated, protected, etc.).
Likewise, there is no way for the orchestrator to export SF/NF
information to other network controllers. The SFC orchestrator may
serve, for example, a higher level controller (such as Network
Slicing Orchestrator), with the latter wanting at least some level of
control as to which SFs/NFs it wants on its SFCs and how the Service
Function Paths (SFPs) are to be routed and provisioned, especially,
if it uses services of more than one SFC orchestrator.
The issue of exporting of SF/NF information could be addressed by
defining a model, in which formally described/recognizable SF/NF
instances are presented as topological elements, for example, hosted
by TE, L3 or L2 topology nodes (see Figure 1). The model could
describe whether, how and at what costs the SFs/NFs hosted by a given
node could be chained together, how these intra-node SFCs could be
connected to the node's Service Function Forwarders (SFFs, entities
dealing with SFC NSHs and metadata), and how the SFFs could be
connected to the node's Tunnel and Link Termination Points (TTPs and
LTPs) to chain the intra-node SFCs across the network topology.
Figure 1: SF/NF aware TE topology
C.2. Flat End-to-end SFCs Managed on Multi-domain Networks
SFCs may span multiple administrative domains, each of which
controlled by a separate SFC controller. The usual solution for such
a scenario is the Hierarchical SFCs (H-SFCs), in which the higher
level orchestrator controls only SFs located on domain border nodes.
Said higher level SFs are chained together into higher level SFCs via
lower level (intra-domain) SFCs provisioned and controlled
independently by respective domain controllers. The decision as to
which higher level SFCs are connected to which lower level SFCs is
driven by packet re-classification every time the packet enters a
given domain. Said packet re-classification is a very time-consuming
operation. Furthermore, the independent nature of higher and lower
level SFC control is prone to configuration errors, which may lead to
long lasting loops and congestions. It is highly desirable to be
able to set up and manage SFCs spanning multiple domains in a flat
way as far as the data plane is concerned (i.e. with a single packet
classification at the ingress into the multi-domain network but
without re-classifications on domain ingress nodes).
One way to achieve this is to have the domain controllers expose SF/
NF- aware topologies, and have the higher level orchestrator operate
on the network-wide topology, the product of merging of the
topologies catered by the domain controllers. This is similar in
spirit to setting up, coordinating and managing the transport
connectivity (TE tunnels) on a multi-domain multi-vendor transport
network.
C.3. Managing SFCs with TE Constraints
Some SFCs require per SFC link/element and end-to-end TE constrains
(bandwidth, delay/jitter, fate sharing/diversity. etc.). Said
constraints could be ensured via carrying SFPs inside overlays that
are traffic engineered with the constrains in mind. A good analogy
would be orchestrating delay constrained L3 VPNs. One way to support
such L3 VPNs is to carry MPLS LSPs interconnecting per-VPN VRFs
inside delay constrained TE tunnels interconnecting the PEs hosting
the VRFs.
Figure 2: L3 VPN with delay constraints
Planning, computing and provisioning of TE overlays to constrain
arbitrary SFCs, especially those that span multiple administrative
domains with each domain controlled by a separate controller, is a
very difficult challenge. Currently it is addressed by pre-
provisioning on the network of multiple TE tunnels with various TE
characteristics, and "nailing down" SFs/NFs to "strategic" locations
(e.g. nodes terminating many of such tunnels) in a hope that an
adequate set of tunnels could be found to carry the SFP of a given
TE-constrained SFC. Such an approach is especially awkward in the
case when some or all of the SFs/NFs are VNFs (i.e. could be
instantiated at multiple network locations).
SF/NF-aware TE topology model in combination with TE tunnel model
will allow for the network orchestrator (or a client controller) to
compute, set up and manipulate the TE overlays in the form of TE
tunnel chains (see Figure 3).
Said chains could be duel-optimized compromising on optimal SF/NF
locations with optimal TE tunnels interconnecting them. The TE
tunnel chains (carrying multiple similarly constrained SFPs) could be
adequately constrained both at individual TE tunnel level and at the
chain end-to-end level.
Figure 3: SFC with TE constraints
C.4. SFC Protection and Load Balancing
Currently the combination of TE topology & tunnel models offers to a
network controller various capabilities to recover an individual TE
tunnel from network failures occurred on one or more network links or
transit nodes on the TE paths taken by the TE tunnel's connection(s).
However, there is no simple way to recover a TE tunnel from a failure
affecting its source or destination node. SF/NF-aware TE topology
model can decouple the association of a given SF/NF with its location
on the network topology by presenting multiple, identifiable as
mutually substitutable SFs/NFs hosted by different TE topology nodes.
So, for example, if it is detected that a given TE tunnel destination
node is malfunctioning or has gone out of service, the TE tunnel
could be re-routed to terminate on a different node hosting
functionally the same SFs/NFs as ones hosted by the failed node (see
Figures 6).
This is in line with the ACTN edge migration and function mobility
concepts [RFC8453]. It is important to note that the described
strategy works much better for the stateless SFs/NFs. This is
because getting the alternative stateful SFs/NFs into the same
respective states as the current (i.e. active, affected by failure)
are is a very difficult challenge.
Figure 4: SFC recovery: SF2 on node NE1 fails
At the SFC level the SF/NF-aware TE topology model can offer SFC
dynamic restoration capabilities against failed/malfunctioning SFs/
NFs by identifying and provisioning detours to a TE tunnel chain, so
that it starts carrying the SFC's SFPs towards healthy SFs/NFs that
are functionally the same as the failed ones. Furthermore, multiple
parallel TE tunnel chains could be pre-provisioned for the purpose of
SFC load balancing and end-to-end protection. In the latter case
said parallel TE tunnel chains could be placed to be sufficiently
disjoint from each other.
Figure 5: SFC recovery: SFC SF1-SF2-SF6 is recovered after SF2 on
node N1 has failed
Figure 6: SFC recovery: SFC SF1-SF2-SF6 is recovered after node N1
has failed
C.5. Network Clock Synchronization
Many current and future network applications (including 5g and IoT
applications) require very accurate time services (PTP level, ns
resolution). One way to implement the adequate network clock
synchronization for such services is via describing network clocks as
NFs on an NF-aware TE topology optimized to have best possible delay
variation characteristics. Because such a topology will contain
delay/delay variation metrics of topology links and node cross-
connects, as well as costs in terms of delay/delay variation of
connecting clocks to hosting them node link and tunnel termination
points, it will be possible to dynamically select and provision bi-
directional time-constrained deterministic paths or trees connecting
clocks (e.g. grand master and boundary clocks) for the purpose of
exchange of clock synchronization information. Note that network
clock aware TE topologies separately provided by domain controllers
will enable multi-domain network orchestrator to set up and
manipulate the clock synchronization paths/trees spanning multiple
network domains.
C.6. Client - Provider Network Slicing Interface
3GPP defines network slice as "a set of network functions and the
resources for these network functions which are arranged and
configured, forming a complete logical network to meet certain
network characteristics" [I-D.defoy-netslices-3gpp-network-slicing]
[_3GPP.28.801]. Network slice could be also defined as a logical
partition of a provider's network that is owned and managed by a
tenant. SF/NF-aware TE topology model has a potential to support a
very important interface between network slicing clients and
providers because, on the one hand, the model can describe
holistically and hierarchically the client's requirements and
preferences with respect to a network slice functional, topological
and traffic engineering aspects, as well as of the degree of resource
separation/ sharing between the slices, thus allowing for the client
(up to agreed upon extent) to dynamically (re-)configure the slice or
(re-)schedule said (re-)configurations in time, while, on the other
hand, allowing for the provider to convey to the client the slice's
operational state information and telemetry the client has expressed
interest in.
C.7. Dynamic Assignment of Regenerators for L0 Services
On large optical networks, some of provided to their clients L0
services could not be provisioned as single OCh trails, rather, as
chains of such trails interconnected via regenerators, such as 3R
regenerators. Current practice of the provisioning of such services
requires configuration of explicit paths (EROs) describing identity
and location of regenerators to be used. A solution is highly
desirable that could:
o Identify such services based, for example, on optical impairment
computations;
o Assign adequate for the services regenerators dynamically out of
the regenerators that are grouped together in pools and
strategically scattered over the network topology nodes;
o Compute and provision supporting the services chains of optical
trails interconnected via so selected regenerators, optimizing the
chains to use minimal number of regenerators, their optimal
locations, as well as optimality of optical paths interconnecting
them;
o Ensure recovery of such chains from any failures that could happen
on links, nodes or regenerators along the chain path.
NF-aware TE topology model (in this case L1 NF-aware L0 topology
model) is just the model that could provide a network controller (or
even a client controller operating on abstract NF-aware topologies
provided by the network) to realize described above computations and
orchestrate the service provisioning and network failure recovery
operations (see Figure 7).
Figure 7: Optical tunnel as TE-constrained SFC of 3R regenerators.
Red trail (not regenerated) is not optically reachable, but blue
trail (twice regenerated) is
C.8. Dynamic Assignment of OAM Functions for L1 Services
OAM functionality is normally managed by configuring and manipulating
TCM/MEP functions on network ports terminating connections or their
segments over which OAM operations, such as performance monitoring,
are required to be performed. In some layer networks (e.g.
Ethernet) said TCMs/MEPs could be configured on any network ports.
In others (e.g. OTN/ODUk) the TCMs/MEPs could be configured on some
(but not all network ports) due to the fact that the OAM
functionality (i.e. recognizing and processing of OAM messages,
supporting OAM protocols and FSMs) requires in these layer networks
certain support in the data plane, which is not available on all
network nodes. This makes TCMs/MEPs good candidates to be modeled as
NFs. This also makes TCM/MEP aware topology model a good basis for
placing dynamically an ODUk connection to pass through optimal OAM
locations without mandating the client to specify said locations
explicitly.
Figure 8: Compute/storage resource aware topology
C.9. SFC Abstraction and Scaling
SF/NF-aware topology may contain information on native SFs/NFs (i.e.
SFs/NFs as known to the provider itself) and/or abstract SFs/NFs
(i.e. logical/macro SFs/NFs representing one or more SFCs each made
of native and/or lower level abstract SFs/NFs). As in the case of
abstracting topology nodes, abstracting SFs/NFs is hierarchical in
nature - the higher level of SF/NF-aware topology, the "larger"
abstract SFs/NFs are, i.e. the larger data plane SFCs they represent.
This allows for managing large scale networks with great number of
SFs/NFs (such as Data Center interconnects) in a hierarchical, highly
scalable manner resulting in control of very large number of flat in
the data plane SFCs that span multiple domains.
C.10. Dynamic Compute/VM/Storage Resource Assignment
In a distributed data center network, virtual machines for compute
resources may need to be dynamically re-allocated due to various
reasons such as DCI network failure, compute resource load balancing,
etc. In many cases, the DCI connectivity for the source and the
destination is not predetermined. There may be a pool of sources and
a pool of destination data centers associated with re-allocation of
compute/VM/storage resources. There is no good mechanism to date to
capture this dynamicity nature of compute/VM/storage resource
reallocation. Generic Compute/VM/Storage resources can be described
and announced as a SF, where a DC hosting these resources can be
modeled as an abstract node. Topology interconnecting these abstract
nodes (DCs) in general is of multi-domain nature. Thus, SF-aware
topology model can facilitate a joint optimization of TE network
resources and Compute/VM/Storage resources and solve Compute/VM/
Storage mobility problem within and between DCs (see Figure 8).
C.11. Application-aware Resource Operations and Management
Application stratum is the functional grouping which encompasses
application resources and the control and management of these
resources. These application resources are used along with network
services to provide an application service to clients/end-users.
Application resources are non-network resources critical to achieving
the application service functionality. Examples of application
resources include: caches, mirrors, application specific servers,
content, large data sets, and computing power. Application service
is a networked application offered to a variety of clients (e.g.,
server backup, VM migration, video cache, virtual network on-demand,
5G network slicing, etc.). The application servers that host these
application resources can be modeled as an abstract node. There may
be a variety of server types depending on the resources they host.
Figure 9 shows one example application aware topology for video cache
server distribution.
Figure 9: Application aware topology
C.12. IANA Considerations
This document has no actions for IANA.
C.13. Security Considerations
This document does not define networking protocols and data, hence is
not directly responsible for security risks.
C.14. Acknowledgements
The authors would like to thank Maarten Vissers, Joel Halpern, and
Greg Mirsky for their helpful comments and valuable contributions.
Authors' Addresses Authors' Addresses
Igor Bryskin Igor Bryskin
Huawei Technologies Huawei Technologies
EMail: Igor.Bryskin@huawei.com EMail: Igor.Bryskin@huawei.com
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
EMail: xufeng.liu.ietf@gmail.com EMail: xufeng.liu.ietf@gmail.com
Young Lee Young Lee
Huawei Technologies Huawei Technologies
EMail: leeyoung@huawei.com EMail: leeyoung@huawei.com
Jim Guichard
Huawei Technologies
EMail: james.n.guichard@huawei.com
Luis Miguel Contreras Murillo
Telefonica
EMail: luismiguel.contrerasmurillo@telefonica.com
Daniele Ceccarelli
Ericsson
EMail: daniele.ceccarelli@ericsson.com
Jeff Tantsura
Nuage Networks
EMail: jefftant.ietf@gmail.com
 End of changes. 19 change blocks. 
50 lines changed or deleted 501 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/