Internet DRAFT - draft-medved-irs-topology-requirements
draft-medved-irs-topology-requirements
Internet Engineering Task Force J. Medved
Internet-Draft Cisco Systems, Inc.
Intended status: Informational H. Gredler
Expires: April 12, 2013 Juniper Networks
S. Previdi
Cisco Systems, Inc.
S. Amante
Level 3 Communications, Inc.
October 9, 2012
Topology API Requirements
draft-medved-irs-topology-requirements-00
Abstract
This document describes requirements for collecting topology data
from network elements and other sources, creating a coherent view of
the network topology from the collected data, and presenting the
topology view to various applications that need to: a) understand the
topology; and, b) interact/change the topology of the physical or
logical network. for reflecting changes to the topology back in
network elements..
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 April 12, 2013.
Copyright Notice
Copyright (c) 2012 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
Medved, et al. Expires April 12, 2013 [Page 1]
Internet-Draft Topology API Requirements October 2012
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3
3. Topology Manager Requirements . . . . . . . . . . . . . . . . 5
3.1. General Requirements . . . . . . . . . . . . . . . . . . . 5
3.2. Data Model Requirements . . . . . . . . . . . . . . . . . 6
3.2.1. Layer 2 Data Model Requirements . . . . . . . . . . . 8
3.2.2. IP/MPLS Layer Data Model Requirements . . . . . . . . 9
3.3. Northbound (Client) API Requirements . . . . . . . . . . . 10
3.4. Southbound (Network & Device) API Requirements . . . . . . 11
4. Network Element Requirements . . . . . . . . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Medved, et al. Expires April 12, 2013 [Page 2]
Internet-Draft Topology API Requirements October 2012
1. Introduction
[I-D.amante-irs-topology-use-cases] demonstrates the need for a
network function that would provide a common, standard-based topology
view to applications. This function is called 'Topology Manager' in
this document. which specifies requirements for the Topology Manager.
Topology Manager requirements fall into one of the following
categories:
General: describes general requirements for the Topology Manager
Data Model: describes requirements for the network topology data
model & view
Northbound (Client) API: describes requirements for Topology
Manager's communication with clients
Southbound (Network & Device) API: describes requirements for
Topology Manager's communication with Network Elements and other
topology data sources
Network Elements: describes requirements for the Network Element's
data model, capabilities, etc. required to support collection of
network topology data
The rest of this document is organized as follows. First, the
Topology Manager's operational model is described in Section 2.
Topology Manager requirements are presented in Section 3. Finally,
Network Element requirements are presented in Section 4..
1.1. 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].
2. Operational Model
As defined in [I-D.amante-irs-topology-use-cases], the Topology
Manager performs the following tasks:
o Collection of topology data from multiple sources: Network
Elements, routing protocols, inventory collection, statistics
collection, etc, as discussed in
[I-D.amante-irs-topology-use-cases]. Note that some of the data
sources, such as statistics or inventory, will be used not only by
the Topology Manager, but by other applications as well. Note
Medved, et al. Expires April 12, 2013 [Page 3]
Internet-Draft Topology API Requirements October 2012
also that topology data sources may reside in multiple IGP areas
or multiple ASes, and/or in multiple network layers.
o Creation of global topology view / common data model from the
collected data; the topology view can span multiple network layers
as well as multiple routing and switching domains. The global
view includes all network elements and resources existing in the
infrastructure, whether they are currently actively used or not.
An example consists of reconstructing the global view of the
network including router or switch ports that are available bot
not in use.
o Presentation of the network view / model to clients
(applications). The Topology Manager can create multiple
application-specific views from its common global topology
database.
The operational model is shown in Figure 1.
+------------+ +------------+
| Client | | Client |
+------------+ +------------+
^ ^
| Northbound API |
+---------------+----------------+
|
|
+-------------------------+
| Topology Manager |
...<-->| +---------------------+ |<--> Peer Topology
| | Topology Data Model | | Managers
| +---------------------+ |
+-------------------------+
^ ^ Southbound APIs
Other Topology Sources | |
(BGP-LS, Statistics, -----+ |
Inventory) | SNMP, NetConf, IRS, OF, TL1, ...
+-------------------------+------------------------+
| | |
+----------------+ +----------------+ +----------------+
| Network Element| | Network Element| | Network Element|
| +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ |
| | Data Model | | | | Data Model | | | | Data Model | |
| +------------+ | | +------------+ | | +------------+ |
+----------------+ +----------------+ +----------------+
Figure 1: Topology Manager operational model
Medved, et al. Expires April 12, 2013 [Page 4]
Internet-Draft Topology API Requirements October 2012
Topology information from network elements is relayed into the
Topology Manager Function via its Southbound API, as shown in
Figure 1. Sources of topology information may be Network Elements at
different layers of the network, such as appliances, routers, L2
switches, optical transponders, optical switches. or monitoring,
provisioning and network analytics tools, such as Statistics
Collection or an Inventory subsystem.
The Topology Manager Function reconstructs the network/global view
(that can be on a per client or per application base) and distributes
it to its clients through northbound APIs. Examples of possible
northbound APIs are ReST, XMPP or Websockets. The Topology Manager
Function can be instantiated in a standalone server, be a part of a
comprehensive orchestration / data collection / presentation
framework (see [I-D.amante-irs-topology-use-cases]), or embedded in a
routing element. A client can be an application or a function in an
upper layer framework, such as a policy function.
Depending on the data it collects, a Topology Manager may not have
visibility into the entire network. In order too create a global
topology, the Topology Manager may get complementary partial
topologie views from other Topology Managers via a Peer Topology
Manager API.
3. Topology Manager Requirements
3.1. General Requirements
The general requirements are as follows:
TMF.GEN-1: IRS MUST define a common vocabulary that describes
attributes associated with topological components of a
network. This is more commonly referred to as a
"normalized" topology.
TMF.GEN-2: IRS MUST define a data model that describes the
topological components represented by the Topology
Manager service. This data model will be written using
a common vocabulary, that allows one to assemble the
components of a network topology so that one can, for
example, describe a physical link and all of its
associated physical layer attributes such as: media
type, bandwidth, MTU, etc.
Medved, et al. Expires April 12, 2013 [Page 5]
Internet-Draft Topology API Requirements October 2012
TMF.GEN-3: The Topology Manager has a Northbound (Client) API and
multiple Southbound APIs for collecting topology data
from networks. Southbound APIs can be, for example,
SNMP, NETCONF, CLI, IRS, OpenFlow, or routing protocols
(IGPs/BGP).
TMF.GEN-4: The Topology Manager has an East-West (Peer Manager) API
to exchange topology information with peer Topology
Managers. Topologies exchanged with peer Topology
Managers can be real or abstract. Note that the East-
West API can be the same as the Northbound API.
TMF.GEN-5: The Topology Manager MUST be able to collect and process
topology data from hundreds of thousands of sources
(network elements, etc.). Being able to collect data
from large number of sources is especially important in
very large optical and transport network.
TMF.GEN-6: The Topology Manager SHOULD be able to provide multiple
application-specific views to different clients.
TMF.GEN-7: The Topology Manager MUST allow for bi-directional flow
of topology data between clients and the network:
clients MUST be able to get network topology information
and to inject policies and/or state related to network
topology.
TMF.GEN-8: The transport protocol on all Topology Manager APIs MUST
support incremental updates between Topology Managers or
between a Topology Manager and a client.
3.2. Data Model Requirements
The requirements for the topology data model are as follows:
TMF.DM-1: The topology data model MUST be able to describe
topology and characteristics of different network
layers:
* Optical DWDM (for future study)
* Optical OTN (for future study)
* L2 (Aggregated links, L2 topologies)
* IP/MPLS,
Medved, et al. Expires April 12, 2013 [Page 6]
Internet-Draft Topology API Requirements October 2012
* VPNs
* Services, such as cloud services, or CDNs
TMF.DM-2: The topology data model MUST support multiple
administrative domains.
TMF.DM-3: The Topology Manager MUST provide data normalization,
i.e. various types of topology information from
different network elements at different network layers
and in different admin domains is processed into a
single, common format for clients' consumption.
TMF.DM-4: The topology data model MUST be able to convey enough
information so that a client can correlate topologies in
different layers and from multiple administrative
domains.
TMF.DM-5: The topology data model MUST support multi-layer
grouping of elements as a means of coalescing different
nodes and links into "network layers". For example,
links with IPv4 addresses might represent Layer 3 of the
network topology while links with Ethernet MAC addresses
might represent Layer 2. Furthermore, virtual private
networks can be represented using this grouping
mechanism.
TMF.DM-6: Association between components of different layers is
needed as a means of indicating relationships (i.e.:
dependency, stacking, etc...) between components where
layers are associated. For example, a layer 2 port
might have several IPv4 or IPv6 interfaces that utilize
it. These would be represented as associations to and
from these components.
TMF.DM-7: Both active and inactive topologies MUST be represented
in the topology database. Inactive topology is not
exhaustively seen in IGP routing protocols. It must be
retrieved by querying inventory in network elements, for
example new line cards inserted in a chassis, new
chassis, ports in the down state, etc.
TMF.DM-8: The topology data model MUST be hierarchical and MUST
support summarization of sub-topologies. Topology
summarization and creation of abstract topologies can be
provided by the Topology Manager or the Orchestration
Function
Medved, et al. Expires April 12, 2013 [Page 7]
Internet-Draft Topology API Requirements October 2012
TMF.DM-9: The topology data model MUST be able to describe
abstract topologies. Abstract topologies can contain
real and abstract nodes and real and abstract links. An
abstract topology MAY be used by a provider to describe
characteristics of a transit network (bandwidth, delay,
protection, etc.)
TMF.DM-10: The topology data model MUST support dynamic data, such
as link and node utilizations (perhaps as optional
attributes).
TMF.DM-11: The topology data model MUST allow a user (operator) to
determine the path between two nodes. The path should
be traceable at all network layers that participate in
the delivery of packets between two nodes. For example,
for IP traffic exchanged between 2 routers, the user
should be able to identify all L2 switches and optical
switches that carry the traffic between the routers.
TMF.DM-12: The topology data model MUST support multiple BGP
Autonomous Systems and multiple IGP areas. Support for
multiple administrative domains is for further study.
TMF.DM-13: The topology data model MUST be human-friendly, i.e. not
SNMP MIBs, but something much more analogous to YANG
models.
TMF.DM-14: The data model SHOULD support topology abstraction,
allowing clients that consume topology information in a
constrained manner. For example, a client wishing to
view only interfaces and nodes present in a sub-graph of
the Layer 3 topology should be able to specify an
interest in this subset of information rather than
having to read out and parse through the entire set of
links and nodes.
3.2.1. Layer 2 Data Model Requirements
The requirements for the L2 topology data model are as follows:
TMF.DM.L2-1: Inventory, (link) status and counter information MUST
be retrieved from L2 Network Elements via NETCONF and
SNMP.
TMF.DM.L2-2: L2 Network Elements MUST be able to provide data
obtained from L2 topology discovery protocols.
Medved, et al. Expires April 12, 2013 [Page 8]
Internet-Draft Topology API Requirements October 2012
3.2.2. IP/MPLS Layer Data Model Requirements
The requirements for the IP/MPLS topology data model are as follows:
TMF.DM.IP-1: The data model of the IP/MPLS layer MUST support both
link topology and prefixes.
TMF.DM.IP-2: Link topology may be retrieved from an IGP, BGP-LS, or
by getting node neighbor information directly from
network elements via a management protocol such as
SNMP, NETCONF or CLI.
TMF.DM.IP-3: Links in the IP/MPLS data model can include, among
others, one or more of the following link attributes:
* Local and Remote anchor node IDs (Router ID, AS#,
Area ID, MT Topology ID)
* Metrics
* Admin Group
* Max link bandwidth
* Unreserved / utilized bandwidth
* Link Protection type
* MPLS Protocol mask
* IS-IS DIS
* OSPF DR/BDR
* Link prefix
* Link characteristics (BW, delay, error rate)
* Link description
* Link-specific timers, (Hello & Holddown)
TMF.DM.IP-4: Nodes in the IP/MPLS data model MAY include one or
more of the following node attributes:
* Node Type: simple node / aggregate node
Medved, et al. Expires April 12, 2013 [Page 9]
Internet-Draft Topology API Requirements October 2012
* Intra area router
* Inter area router (ISIS L1L2 or OSPF ABR)
* AS boundary router
* MPLS-VPN Edge router (PE)
* Tunnel head-end/tail-end
* Node ID:: Node ID (Router ID, AS#, Area ID, MT
Topology ID)
* Flags: Overload, Attached, External, ABR
* Node capabilities as defined in RFC5073
* BGP: aggregate IP prefix + mask (with associated
tie-down route information to inject the aggregate
route into BGP)
* BGP policy associated with a given iBGP/eBGP
neighbor; policy matching criteria can be, among
others, remote-AS, local-AS, Local-AS tweaks to
manipulate AS_PATH recv'd or transmitted, timers
(Hello, HoldTime), AFI/SAFI, route-map/
policy-statements applied/active (including
associated prefix-lists, AS_PATH regexp filters,
etc. and resulting manipulation of BGP path
attributes, e.g.: changing LOCAL_PREF, MED, BGP
community, etc.)
* BGP statistics collection: number of IP paths/
prefixes learned per neighbor
3.3. Northbound (Client) API Requirements
The requirements for the Topology Manager's northbound (client)
interface are as follows:
TMF.NB-1: The transport protocol between the Topology Manager and
its clients SHOULD have efficient encoding so that large
topologies can be transferred with reasonable
performance.
Medved, et al. Expires April 12, 2013 [Page 10]
Internet-Draft Topology API Requirements October 2012
TMF.NB-2: The transport protocol MUST support flow-control in case
a client cannot digest updates fast enough from its
server.
TMF.NB-3: The transport protocol MUST support push of topology
updates from the Topology Manager to clients.
TMF.NB-4: The protocol MUST implement a mechanism through which a
client can efficiently determine the latest information
especially when it receives multiple copies of the same
topology from multiple Topology Managers. An example is
the IGP Sequence Number that is used on IGP routing
updates.
TMF.NB-5: The Northbound API MUST support publishing of events to a
dynamic list of clients/applications. This is helpful
for the Northbound API to signal events as they occur in
the network, e.g.: insertion or removal of linecards,
etc.
TMF.NB-6: The Northbound API SHOULD support subscription to events
from a dynamic list of clients/applications. This will
allow the Topology System to react dynamically when, for
example, new requests for services are asked to be
created.
TMF.NB-7: The Northbound API SHOULD allow clients to subscribe to a
rich assortment of attributes and/or data models so that
they are automatically notified of changes within the
network, (as a result of a node failure, card insertion,
etc.), as well as changes made by other upper-layer
applications to the network, (for example, addition/
subtraction of physical links to the network during
network augmentation or optimization, etc.)
TMF.NB-8: The Northbound API MUST provide a means for non-routers
to communicate with the model. Until now, clients that
could gather network topology and inventory information
were generally limited to those that could speak routing
protocols.
3.4. Southbound (Network & Device) API Requirements
The requirements for the Topology Manager's southbound (network
element) interface are as follows:
Medved, et al. Expires April 12, 2013 [Page 11]
Internet-Draft Topology API Requirements October 2012
TMF.SB-1: The transport protocol between the Topology Manager and
the topology data sources (Network Elements, etc.)
SHOULD have efficient encoding so that large data models
can be transferred with reasonable performance.
TMF.SB-2: The transport protocol MUST support incremental updates
from a Network Element to the Topology Manager.
TMF.SB-3: The transport protocol MUST support push of topology
updates from a Network Element to the Topology Manager.
4. Network Element Requirements
The requirements for the topology data model are as follows:
NE-1: Each network element SHOULD contain an inventory database,
which SHOULD be a definitive source of information with
respect to the physical HW and logical, locally significant
identifiers, e.g.: VLANs, deployed in the system. The
Topology Manager collects inventory data from network
elements and creates an authoritative view of physical
hardware deployed in the network.
NE-2: The inventory DB SHOULD be augmented with the physical
properties associated with the ports/interfaces that are
directly connected to the device, (e.g.: BW, media type,
etc.).
NE-3: The inventory DB MAY be augmented through the IRS framework
pushing information into the network element to, for example,
associate information the installer may have knowledge of,
but the network element may not be able to learn on its own,
e.g.: it's physical location (address), rack/bay information,
etc.
NE-4: Relevant network elements should automatically and
dynamically acquire information associated with their
immediately adjacent neighbors using protocols such as LLDP,
LMP, etc. A network element should further augment it's
physical port inventory DB with this information so that the
system can report on whom it's directly connected.
Medved, et al. Expires April 12, 2013 [Page 12]
Internet-Draft Topology API Requirements October 2012
5. Acknowledgements
The authors would like to thank Alia Atlas, Chris Metz, Dave Ward,
and Tom Nadeau for their comments and input.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
tbd.
8. Normative References
[I-D.amante-irs-topology-use-cases]
Amante, S., Medved, J., and T. Nadeau, "Topology API Use
Cases", draft-amante-irs-topology-use-cases-00 (work in
progress), October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Additional Stuff
This becomes an Appendix.
Authors' Addresses
Jan Medved
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
USA
Email: jmedved@cisco.com
Medved, et al. Expires April 12, 2013 [Page 13]
Internet-Draft Topology API Requirements October 2012
Hannes Gredler
Juniper Networks
USA
Email: hannes@juniper.net
Stefano Previdi
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
USA
Email: sprevidi@cisco.com
Shane Amante
Level 3 Communications, Inc.
1025 Eldorado Blvd
Broomfield, CO 80021
USA
Email: shane@level3.net
Medved, et al. Expires April 12, 2013 [Page 14]