Internet DRAFT - draft-doolan-teas-te-topo-mlconsiderations
draft-doolan-teas-te-topo-mlconsiderations
TEAS Working Group P. Doolan
Internet-Draft J. Sadler
Intended status: Informational Coriant
Expires: January 7, 2016 July 6, 2015
Considerations for the use of TEAS TE topology model in multi layer
applications
draft-doolan-teas-te-topo-mlconsiderations-00
Abstract
This document briefly describes an important inter layer use case for
TE topology information and considers requirements and operational
considerations the derive from it.
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 January 7, 2016.
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.
Doolan & Sadler Expires January 7, 2016 [Page 1]
Internet-DraftTE Topology model in multi layer applications July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. Layer networks . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Single Layer Network . . . . . . . . . . . . . . . . . . 3
3.2. Multi Layer Networks . . . . . . . . . . . . . . . . . . 4
4. Optical network as a virtual switch . . . . . . . . . . . . . 7
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
One motivation for the definition and use of YANG models is to allow
'automation' of network configuration and operation. Automation is
particulary attractive in when offering services like Network as a
Service (NAAS). The word 'service' implies that an operator's
customers have a high degree of flexibility in their use of the
network resources provided by the service this leads to concepts such
as Network on Demand (NoD). Automation is key to the effective
realisation services of this type. Management/control of multilayer
networks is also an area where automation may be useful. SDN is a
key part of the automation toolkit and there is an emerging
realisation that (standard) information and data models are a key
part of this technology. It is important that we develop YANG models
that support the needs of the application(s) and that we provide
guidance as to their potential limitations as well. We point some
simple additions to the current TEAS TE-topology model
[IETF-TEAS-TOPO] which are necessary to support some applications.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Layer networks
We first illustrate a topology server/service in the context of a
single layer network and then generalise to the multilayer case. You
need to be able to reference and, therefore, name the thing you
attach to.
Doolan & Sadler Expires January 7, 2016 [Page 2]
Internet-DraftTE Topology model in multi layer applications July 2015
3.1. Single Layer Network
Figure 1 shows an illustration of the major components of a single
layer network. The managment, control and data planes are familiar
and well understood concepts in IETF and elsewhere. The 'Topology
server' component is, perhaps, less familiar but its function is
straightforward, it provides an interface - shown here as the
'Topology Service Interface' (TSI) - through which clients may
examine and, perhaps, control the network's topology. The term
'client(s)' is used here soley to conotate an entity that uses the
Topology Service Interface without futher distinction. There are
many ways in which a topology service could be implemented and many
protocols and encodings that could be used for one. In this document
consider the case where the objects can be manipulated via that
inteface are described by the YANG model described in [IETF-TEAS-TE-
TOPO]. Note that 'YANG models' are but one component of TSI
In Figure 1 the nodes A and Z are border nodes of what may be an
arbitrarily complex network which we illustrate and refer to on the
line between them in the illustration as an 'abstract A-Z topology'.
Further recognise that the notations CPA and CPZ stand for 'concrete'
- to distinguish them from abstract - ports on nodes A and Z, i.e
they are ports on those nodes which do not yet have links attached
but which may eventually, in the case that is of particular interest
to us here, have client equipment attached.
Doolan & Sadler Expires January 7, 2016 [Page 3]
Internet-DraftTE Topology model in multi layer applications July 2015
Topology Service |
Interface ---> ----------
|
+---------------------+ +---------+
|Management(OSS) plane|<-------->|Topology |
+---------------------+ |Server |
^ ^ +---------+
| | ^
| v |
| +----------------+ |
| |Control plane |<--------------+
| +----------------+
| ^
| |
v v
+-----------------------------+
| Data plane |
| +---+ +---+ |
| | |---------------| | |
CPA| A | abstract | Z |CPZ
| | | AZ topology | | |
| +---+ +---+ |
+-----------------------------+
Figure 1
If we consider the layer network in Figure it should be clear that
the topology server can only provide details of the topology of the
network resources under its control.
3.2. Multi Layer Networks
Most networks or combinations of networks that are of practical
interest have multiple layers and/or technolgies. Figure 2 shows a
hierarchical client/server arrangement of two networks;a specific
example is a transport network - the server layer - providing
connectivity to a - client layer - router network. The 'concrete'
ports of figure 1 have here become client ports that are connected to
ports in the server layer (SPA, SPZ).
Note that in general there may be multiple layers in such a hierarchy
and we talk of being able to recurse through it i.e to find instances
of the same model at the different layers. In Figure 2 we show the
bottom two layers only, the server layer is recognizable as a layer
where the recursion terminates because there is no server layer (or
topology server) below it whereas the client layer, in contrast, has
Doolan & Sadler Expires January 7, 2016 [Page 4]
Internet-DraftTE Topology model in multi layer applications July 2015
a topology server with a TSI that is capable of supporting (higher)
client layers.
Doolan & Sadler Expires January 7, 2016 [Page 5]
Internet-DraftTE Topology model in multi layer applications July 2015
Topology Service |
Interface ---> ----------
|
+---------+
+---------------------+ | Server |
|Management(OSS) plane|<------------>| Topology|
+---------------------+ +----->| Client |
^ ^ | +---------+
| | | ^
| v | |
| +----------------+ | |
| |Control plane |<------+ |
| +----------------+ |
| ^ |
v v |
+-----------------------------+ |
| Client layer data plane | |
| +---+ +---+ | |
| | |---------------| | | |
+---->CPA| A | abstract link | Z |CPZ<--+ |
| | | | | | | | |
| | +---+ +---+ | | |
| +-----------------------------+ | |
| | |
| Client layer | |
-----------------------------------------------|-----------
| Server layer | |
| | +---------+
| +---------------------+ | | |
| |Management(OSS) plane|<----------|->| Topology|
| +---------------------+ +---|->| Server |
| ^ ^ | | +---------+
| | v | |
| | +----------------+ | |
| | |Control plane |<------+ |
| | +----------------+ |
| | ^ |
| v v |
| +-----------------------------+ |
| | Server layer data plane | |
| | +---+ +---+ | |
| | | |---------------| | | |
+---->SPA| A | server layer | Z |SPZ<--+
| | | connection | | |
| +---+ +---+ |
+-----------------------------+
Figure 2
Doolan & Sadler Expires January 7, 2016 [Page 6]
Internet-DraftTE Topology model in multi layer applications July 2015
In Figure 2 the 'concrete' ports refered to previously have become
'client' ports and are connected to ports in the server layer (SPA,
SPZ). In the general case the client and server networks may use
different technologies (e.g Etherenet and OTN) and in that case
adaptation between those must be effected somewhere.
In a multilayer network the ports we illustrate are on different
sides of what is, in the general case, a policy boundary of some
sort. Configurations of this sort have been studied in a number of
other organizations [ITU-T_G.8080] [OIF] and the ports and links
joining them have various names therein e.g termination and
adaptation point (TAP), transitional link etc. The coordination,
translation, resolution of TAP names between client and server layer
control entities is often a clerical operation of some kind and is
thus a suitable candidate for automation.
It is well known that in SDN controllers provide interfaces to allow
manipulation of objects representing the resources unders their
control, such as those represented by the data model in [IETF-TEAS-
TOPO]. These interfaces are used by other SDN software components
known variously as higher level controllers, orchestrators or
applications and these may be adjuncts or extensions of the
capabilities of existing EMS, NMS and OSS components.
We previously explained - in the single network layer example - that
what we represent as an abstract link may be an arbitrarily complex
network, the same applies at the server layer where what is shown as
the server layer connection represents an arbitrarily complex path
through that layer.
Although we allow abstract representation of an arbitrarily complex
network and recognise that modelling of such should, subject to
policy etc, allow examination of more or less detail of the
underlying (real) resources many applications can be satisfied using
a very abstract model. In the limit we can represent the network as
an abstract or virtual switch. We examine this case below.
4. Optical network as a virtual switch
In the case where a network operator is providing transport service
for router interconnect a very simple i.e highly abstract
representation of the topology may be adequate for a large class of
customers, specifically we suggest that representing the (optical)
network as a virutal siwtch is sufficient for many applications.
In such a highly abstract and therefore simple model the topology
service of the optical server layer represents client ports (SPA and
SPZ in Figure 2) as connected ports on a abstract virtual switch. By
Doolan & Sadler Expires January 7, 2016 [Page 7]
Internet-DraftTE Topology model in multi layer applications July 2015
making the virtual switch abstract, in the sense that is used in
[IETF-TEAS-TOPO] arbitrary detail can be provided, subject to policy,
to those clients that require it.
Support of this model requires a number of modifications to [IETF-
TEAS-TOPO]. An object must be provided to model the ports; amongst
the neccesary attributes are that the ports MUST be capable of being
'named' and MUST support switching types as defined in [RFC7074]. A
virtual switch object MUST be provided that supports port objects and
connections between them.
Future versions of this draft will provide YANG definitions for these
objects.
5. Acknowledgments
Xian Zhang of Huawei suggested the Network on Demand application.
Bin Yeong Yoon of ETRI provided some early review and encouragement.
6. Normative References
[IETF-TEAS-TOPO]
IETF, "(work in progress)YANG Data Model for TE Topologies
draft-ietf-teas-yang-te-topo-00", 2014,
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-
00>.
[ITU-T_G.8080]
ITU-T, "ITU-T G.8080 - Architecture for the automatically
switched optical network; 02/2012", 2012,
<http://www.itu.int/rec/T-REC-G.8080/en>.
[OIF] ITU-T, "External Network-Network Interface (E-NNI)
OSPFv2-based Routing - 2.0 (Intra-Carrier) Implementation
Agreement; 07/2011", 2012,
<http://www.oiforum.com/public/documents/
OIF_ENNI_OSPF_02.0.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Doolan & Sadler Expires January 7, 2016 [Page 8]
Internet-DraftTE Topology model in multi layer applications July 2015
Paul Doolan
Coriant
Munich, Germany
Phone: +1 972 357 5822
Email: paul.doolan@coriant.com
Jonathan Sadler
Coriant
Chicago, USA
Email: jonathan.sadler@coriant.com
Doolan & Sadler Expires January 7, 2016 [Page 9]
