idnits 2.17.1 draft-medved-irs-topology-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2012) is 4218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-amante-irs-topology-use-cases-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Medved 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational H. Gredler 5 Expires: April 12, 2013 Juniper Networks 6 S. Previdi 7 Cisco Systems, Inc. 8 S. Amante 9 Level 3 Communications, Inc. 10 October 9, 2012 12 Topology API Requirements 13 draft-medved-irs-topology-requirements-00 15 Abstract 17 This document describes requirements for collecting topology data 18 from network elements and other sources, creating a coherent view of 19 the network topology from the collected data, and presenting the 20 topology view to various applications that need to: a) understand the 21 topology; and, b) interact/change the topology of the physical or 22 logical network. for reflecting changes to the topology back in 23 network elements.. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 12, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Topology Manager Requirements . . . . . . . . . . . . . . . . 5 63 3.1. General Requirements . . . . . . . . . . . . . . . . . . . 5 64 3.2. Data Model Requirements . . . . . . . . . . . . . . . . . 6 65 3.2.1. Layer 2 Data Model Requirements . . . . . . . . . . . 8 66 3.2.2. IP/MPLS Layer Data Model Requirements . . . . . . . . 9 67 3.3. Northbound (Client) API Requirements . . . . . . . . . . . 10 68 3.4. Southbound (Network & Device) API Requirements . . . . . . 11 69 4. Network Element Requirements . . . . . . . . . . . . . . . . . 12 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 74 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 [I-D.amante-irs-topology-use-cases] demonstrates the need for a 80 network function that would provide a common, standard-based topology 81 view to applications. This function is called 'Topology Manager' in 82 this document. which specifies requirements for the Topology Manager. 83 Topology Manager requirements fall into one of the following 84 categories: 86 General: describes general requirements for the Topology Manager 88 Data Model: describes requirements for the network topology data 89 model & view 91 Northbound (Client) API: describes requirements for Topology 92 Manager's communication with clients 94 Southbound (Network & Device) API: describes requirements for 95 Topology Manager's communication with Network Elements and other 96 topology data sources 98 Network Elements: describes requirements for the Network Element's 99 data model, capabilities, etc. required to support collection of 100 network topology data 102 The rest of this document is organized as follows. First, the 103 Topology Manager's operational model is described in Section 2. 104 Topology Manager requirements are presented in Section 3. Finally, 105 Network Element requirements are presented in Section 4.. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Operational Model 115 As defined in [I-D.amante-irs-topology-use-cases], the Topology 116 Manager performs the following tasks: 118 o Collection of topology data from multiple sources: Network 119 Elements, routing protocols, inventory collection, statistics 120 collection, etc, as discussed in 121 [I-D.amante-irs-topology-use-cases]. Note that some of the data 122 sources, such as statistics or inventory, will be used not only by 123 the Topology Manager, but by other applications as well. Note 124 also that topology data sources may reside in multiple IGP areas 125 or multiple ASes, and/or in multiple network layers. 127 o Creation of global topology view / common data model from the 128 collected data; the topology view can span multiple network layers 129 as well as multiple routing and switching domains. The global 130 view includes all network elements and resources existing in the 131 infrastructure, whether they are currently actively used or not. 132 An example consists of reconstructing the global view of the 133 network including router or switch ports that are available bot 134 not in use. 136 o Presentation of the network view / model to clients 137 (applications). The Topology Manager can create multiple 138 application-specific views from its common global topology 139 database. 141 The operational model is shown in Figure 1. 143 +------------+ +------------+ 144 | Client | | Client | 145 +------------+ +------------+ 146 ^ ^ 147 | Northbound API | 148 +---------------+----------------+ 149 | 150 | 151 +-------------------------+ 152 | Topology Manager | 153 ...<-->| +---------------------+ |<--> Peer Topology 154 | | Topology Data Model | | Managers 155 | +---------------------+ | 156 +-------------------------+ 157 ^ ^ Southbound APIs 158 Other Topology Sources | | 159 (BGP-LS, Statistics, -----+ | 160 Inventory) | SNMP, NetConf, IRS, OF, TL1, ... 161 +-------------------------+------------------------+ 162 | | | 163 +----------------+ +----------------+ +----------------+ 164 | Network Element| | Network Element| | Network Element| 165 | +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ | 166 | | Data Model | | | | Data Model | | | | Data Model | | 167 | +------------+ | | +------------+ | | +------------+ | 168 +----------------+ +----------------+ +----------------+ 170 Figure 1: Topology Manager operational model 172 Topology information from network elements is relayed into the 173 Topology Manager Function via its Southbound API, as shown in 174 Figure 1. Sources of topology information may be Network Elements at 175 different layers of the network, such as appliances, routers, L2 176 switches, optical transponders, optical switches. or monitoring, 177 provisioning and network analytics tools, such as Statistics 178 Collection or an Inventory subsystem. 180 The Topology Manager Function reconstructs the network/global view 181 (that can be on a per client or per application base) and distributes 182 it to its clients through northbound APIs. Examples of possible 183 northbound APIs are ReST, XMPP or Websockets. The Topology Manager 184 Function can be instantiated in a standalone server, be a part of a 185 comprehensive orchestration / data collection / presentation 186 framework (see [I-D.amante-irs-topology-use-cases]), or embedded in a 187 routing element. A client can be an application or a function in an 188 upper layer framework, such as a policy function. 190 Depending on the data it collects, a Topology Manager may not have 191 visibility into the entire network. In order too create a global 192 topology, the Topology Manager may get complementary partial 193 topologie views from other Topology Managers via a Peer Topology 194 Manager API. 196 3. Topology Manager Requirements 198 3.1. General Requirements 200 The general requirements are as follows: 202 TMF.GEN-1: IRS MUST define a common vocabulary that describes 203 attributes associated with topological components of a 204 network. This is more commonly referred to as a 205 "normalized" topology. 207 TMF.GEN-2: IRS MUST define a data model that describes the 208 topological components represented by the Topology 209 Manager service. This data model will be written using 210 a common vocabulary, that allows one to assemble the 211 components of a network topology so that one can, for 212 example, describe a physical link and all of its 213 associated physical layer attributes such as: media 214 type, bandwidth, MTU, etc. 216 TMF.GEN-3: The Topology Manager has a Northbound (Client) API and 217 multiple Southbound APIs for collecting topology data 218 from networks. Southbound APIs can be, for example, 219 SNMP, NETCONF, CLI, IRS, OpenFlow, or routing protocols 220 (IGPs/BGP). 222 TMF.GEN-4: The Topology Manager has an East-West (Peer Manager) API 223 to exchange topology information with peer Topology 224 Managers. Topologies exchanged with peer Topology 225 Managers can be real or abstract. Note that the East- 226 West API can be the same as the Northbound API. 228 TMF.GEN-5: The Topology Manager MUST be able to collect and process 229 topology data from hundreds of thousands of sources 230 (network elements, etc.). Being able to collect data 231 from large number of sources is especially important in 232 very large optical and transport network. 234 TMF.GEN-6: The Topology Manager SHOULD be able to provide multiple 235 application-specific views to different clients. 237 TMF.GEN-7: The Topology Manager MUST allow for bi-directional flow 238 of topology data between clients and the network: 239 clients MUST be able to get network topology information 240 and to inject policies and/or state related to network 241 topology. 243 TMF.GEN-8: The transport protocol on all Topology Manager APIs MUST 244 support incremental updates between Topology Managers or 245 between a Topology Manager and a client. 247 3.2. Data Model Requirements 249 The requirements for the topology data model are as follows: 251 TMF.DM-1: The topology data model MUST be able to describe 252 topology and characteristics of different network 253 layers: 255 * Optical DWDM (for future study) 257 * Optical OTN (for future study) 259 * L2 (Aggregated links, L2 topologies) 261 * IP/MPLS, 262 * VPNs 264 * Services, such as cloud services, or CDNs 266 TMF.DM-2: The topology data model MUST support multiple 267 administrative domains. 269 TMF.DM-3: The Topology Manager MUST provide data normalization, 270 i.e. various types of topology information from 271 different network elements at different network layers 272 and in different admin domains is processed into a 273 single, common format for clients' consumption. 275 TMF.DM-4: The topology data model MUST be able to convey enough 276 information so that a client can correlate topologies in 277 different layers and from multiple administrative 278 domains. 280 TMF.DM-5: The topology data model MUST support multi-layer 281 grouping of elements as a means of coalescing different 282 nodes and links into "network layers". For example, 283 links with IPv4 addresses might represent Layer 3 of the 284 network topology while links with Ethernet MAC addresses 285 might represent Layer 2. Furthermore, virtual private 286 networks can be represented using this grouping 287 mechanism. 289 TMF.DM-6: Association between components of different layers is 290 needed as a means of indicating relationships (i.e.: 291 dependency, stacking, etc...) between components where 292 layers are associated. For example, a layer 2 port 293 might have several IPv4 or IPv6 interfaces that utilize 294 it. These would be represented as associations to and 295 from these components. 297 TMF.DM-7: Both active and inactive topologies MUST be represented 298 in the topology database. Inactive topology is not 299 exhaustively seen in IGP routing protocols. It must be 300 retrieved by querying inventory in network elements, for 301 example new line cards inserted in a chassis, new 302 chassis, ports in the down state, etc. 304 TMF.DM-8: The topology data model MUST be hierarchical and MUST 305 support summarization of sub-topologies. Topology 306 summarization and creation of abstract topologies can be 307 provided by the Topology Manager or the Orchestration 308 Function 310 TMF.DM-9: The topology data model MUST be able to describe 311 abstract topologies. Abstract topologies can contain 312 real and abstract nodes and real and abstract links. An 313 abstract topology MAY be used by a provider to describe 314 characteristics of a transit network (bandwidth, delay, 315 protection, etc.) 317 TMF.DM-10: The topology data model MUST support dynamic data, such 318 as link and node utilizations (perhaps as optional 319 attributes). 321 TMF.DM-11: The topology data model MUST allow a user (operator) to 322 determine the path between two nodes. The path should 323 be traceable at all network layers that participate in 324 the delivery of packets between two nodes. For example, 325 for IP traffic exchanged between 2 routers, the user 326 should be able to identify all L2 switches and optical 327 switches that carry the traffic between the routers. 329 TMF.DM-12: The topology data model MUST support multiple BGP 330 Autonomous Systems and multiple IGP areas. Support for 331 multiple administrative domains is for further study. 333 TMF.DM-13: The topology data model MUST be human-friendly, i.e. not 334 SNMP MIBs, but something much more analogous to YANG 335 models. 337 TMF.DM-14: The data model SHOULD support topology abstraction, 338 allowing clients that consume topology information in a 339 constrained manner. For example, a client wishing to 340 view only interfaces and nodes present in a sub-graph of 341 the Layer 3 topology should be able to specify an 342 interest in this subset of information rather than 343 having to read out and parse through the entire set of 344 links and nodes. 346 3.2.1. Layer 2 Data Model Requirements 348 The requirements for the L2 topology data model are as follows: 350 TMF.DM.L2-1: Inventory, (link) status and counter information MUST 351 be retrieved from L2 Network Elements via NETCONF and 352 SNMP. 354 TMF.DM.L2-2: L2 Network Elements MUST be able to provide data 355 obtained from L2 topology discovery protocols. 357 3.2.2. IP/MPLS Layer Data Model Requirements 359 The requirements for the IP/MPLS topology data model are as follows: 361 TMF.DM.IP-1: The data model of the IP/MPLS layer MUST support both 362 link topology and prefixes. 364 TMF.DM.IP-2: Link topology may be retrieved from an IGP, BGP-LS, or 365 by getting node neighbor information directly from 366 network elements via a management protocol such as 367 SNMP, NETCONF or CLI. 369 TMF.DM.IP-3: Links in the IP/MPLS data model can include, among 370 others, one or more of the following link attributes: 372 * Local and Remote anchor node IDs (Router ID, AS#, 373 Area ID, MT Topology ID) 375 * Metrics 377 * Admin Group 379 * Max link bandwidth 381 * Unreserved / utilized bandwidth 383 * Link Protection type 385 * MPLS Protocol mask 387 * IS-IS DIS 389 * OSPF DR/BDR 391 * Link prefix 393 * Link characteristics (BW, delay, error rate) 395 * Link description 397 * Link-specific timers, (Hello & Holddown) 399 TMF.DM.IP-4: Nodes in the IP/MPLS data model MAY include one or 400 more of the following node attributes: 402 * Node Type: simple node / aggregate node 403 * Intra area router 405 * Inter area router (ISIS L1L2 or OSPF ABR) 407 * AS boundary router 409 * MPLS-VPN Edge router (PE) 411 * Tunnel head-end/tail-end 413 * Node ID:: Node ID (Router ID, AS#, Area ID, MT 414 Topology ID) 416 * Flags: Overload, Attached, External, ABR 418 * Node capabilities as defined in RFC5073 420 * BGP: aggregate IP prefix + mask (with associated 421 tie-down route information to inject the aggregate 422 route into BGP) 424 * BGP policy associated with a given iBGP/eBGP 425 neighbor; policy matching criteria can be, among 426 others, remote-AS, local-AS, Local-AS tweaks to 427 manipulate AS_PATH recv'd or transmitted, timers 428 (Hello, HoldTime), AFI/SAFI, route-map/ 429 policy-statements applied/active (including 430 associated prefix-lists, AS_PATH regexp filters, 431 etc. and resulting manipulation of BGP path 432 attributes, e.g.: changing LOCAL_PREF, MED, BGP 433 community, etc.) 435 * BGP statistics collection: number of IP paths/ 436 prefixes learned per neighbor 438 3.3. Northbound (Client) API Requirements 440 The requirements for the Topology Manager's northbound (client) 441 interface are as follows: 443 TMF.NB-1: The transport protocol between the Topology Manager and 444 its clients SHOULD have efficient encoding so that large 445 topologies can be transferred with reasonable 446 performance. 448 TMF.NB-2: The transport protocol MUST support flow-control in case 449 a client cannot digest updates fast enough from its 450 server. 452 TMF.NB-3: The transport protocol MUST support push of topology 453 updates from the Topology Manager to clients. 455 TMF.NB-4: The protocol MUST implement a mechanism through which a 456 client can efficiently determine the latest information 457 especially when it receives multiple copies of the same 458 topology from multiple Topology Managers. An example is 459 the IGP Sequence Number that is used on IGP routing 460 updates. 462 TMF.NB-5: The Northbound API MUST support publishing of events to a 463 dynamic list of clients/applications. This is helpful 464 for the Northbound API to signal events as they occur in 465 the network, e.g.: insertion or removal of linecards, 466 etc. 468 TMF.NB-6: The Northbound API SHOULD support subscription to events 469 from a dynamic list of clients/applications. This will 470 allow the Topology System to react dynamically when, for 471 example, new requests for services are asked to be 472 created. 474 TMF.NB-7: The Northbound API SHOULD allow clients to subscribe to a 475 rich assortment of attributes and/or data models so that 476 they are automatically notified of changes within the 477 network, (as a result of a node failure, card insertion, 478 etc.), as well as changes made by other upper-layer 479 applications to the network, (for example, addition/ 480 subtraction of physical links to the network during 481 network augmentation or optimization, etc.) 483 TMF.NB-8: The Northbound API MUST provide a means for non-routers 484 to communicate with the model. Until now, clients that 485 could gather network topology and inventory information 486 were generally limited to those that could speak routing 487 protocols. 489 3.4. Southbound (Network & Device) API Requirements 491 The requirements for the Topology Manager's southbound (network 492 element) interface are as follows: 494 TMF.SB-1: The transport protocol between the Topology Manager and 495 the topology data sources (Network Elements, etc.) 496 SHOULD have efficient encoding so that large data models 497 can be transferred with reasonable performance. 499 TMF.SB-2: The transport protocol MUST support incremental updates 500 from a Network Element to the Topology Manager. 502 TMF.SB-3: The transport protocol MUST support push of topology 503 updates from a Network Element to the Topology Manager. 505 4. Network Element Requirements 507 The requirements for the topology data model are as follows: 509 NE-1: Each network element SHOULD contain an inventory database, 510 which SHOULD be a definitive source of information with 511 respect to the physical HW and logical, locally significant 512 identifiers, e.g.: VLANs, deployed in the system. The 513 Topology Manager collects inventory data from network 514 elements and creates an authoritative view of physical 515 hardware deployed in the network. 517 NE-2: The inventory DB SHOULD be augmented with the physical 518 properties associated with the ports/interfaces that are 519 directly connected to the device, (e.g.: BW, media type, 520 etc.). 522 NE-3: The inventory DB MAY be augmented through the IRS framework 523 pushing information into the network element to, for example, 524 associate information the installer may have knowledge of, 525 but the network element may not be able to learn on its own, 526 e.g.: it's physical location (address), rack/bay information, 527 etc. 529 NE-4: Relevant network elements should automatically and 530 dynamically acquire information associated with their 531 immediately adjacent neighbors using protocols such as LLDP, 532 LMP, etc. A network element should further augment it's 533 physical port inventory DB with this information so that the 534 system can report on whom it's directly connected. 536 5. Acknowledgements 538 The authors would like to thank Alia Atlas, Chris Metz, Dave Ward, 539 and Tom Nadeau for their comments and input. 541 6. IANA Considerations 543 This memo includes no request to IANA. 545 7. Security Considerations 547 tbd. 549 8. Normative References 551 [I-D.amante-irs-topology-use-cases] 552 Amante, S., Medved, J., and T. Nadeau, "Topology API Use 553 Cases", draft-amante-irs-topology-use-cases-00 (work in 554 progress), October 2012. 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 Appendix A. Additional Stuff 561 This becomes an Appendix. 563 Authors' Addresses 565 Jan Medved 566 Cisco Systems, Inc. 567 170, West Tasman Drive 568 San Jose, CA 95134 569 USA 571 Email: jmedved@cisco.com 572 Hannes Gredler 573 Juniper Networks 574 USA 576 Email: hannes@juniper.net 578 Stefano Previdi 579 Cisco Systems, Inc. 580 170, West Tasman Drive 581 San Jose, CA 95134 582 USA 584 Email: sprevidi@cisco.com 586 Shane Amante 587 Level 3 Communications, Inc. 588 1025 Eldorado Blvd 589 Broomfield, CO 80021 590 USA 592 Email: shane@level3.net