idnits 2.17.1 draft-medved-i2rs-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2013) is 4085 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-amante-irs-topology-use-cases-00 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Interface to the Routing System (I2RS) J. Medved 3 Internet-Draft S. Previdi 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 21, 2013 H. Gredler 6 T. Nadeau 7 Juniper Networks, Inc. 8 S. Amante 9 Level 3 Communications, Inc. 10 February 17, 2013 12 Topology API Requirements 13 draft-medved-i2rs-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) leverage topology information in order to improve 22 application specific mechanisms such as path selection, resources 23 reservation, etc. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 21, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Operational Model . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Topology Manager Requirements . . . . . . . . . . . . . . . . 5 67 3.1. Topology Manager Requirements . . . . . . . . . . . . . . 5 68 3.1.1. General Requirements . . . . . . . . . . . . . . . . . 5 69 3.1.2. Data Model Requirements . . . . . . . . . . . . . . . 6 70 3.1.3. Northbound (Client) API Requirements . . . . . . . . . 10 71 3.1.4. Southbound (Network & Device) API Requirements . . . . 11 72 4. Network Element Requirements . . . . . . . . . . . . . . . . . 11 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 [I-D.amante-irs-topology-use-cases] demonstrates the need for a 84 network function that would provide a common, standard-based topology 85 view to applications. This function is called 'Topology Manager' in 86 this document. which specifies requirements for the Topology Manager. 87 Topology Manager requirements fall into one of the following 88 categories: 90 General: describes general requirements for the Topology Manager. 92 Data Model: describes requirements for the network topology data 93 model & view. 95 Northbound (Client) API: describes requirements for Topology 96 Manager's communication with clients. 98 Southbound (Network & Device) API: describes requirements for 99 Topology Manager's communication with Network Elements and other 100 topology data sources. 102 Network Elements: describes requirements for the Network Element's 103 data model, capabilities, etc. required to support collection of 104 network topology data. 106 The rest of this document is organized as follows. First, the 107 Topology Manager's Operational Model is described in Section 2. 108 Topology Manager requirements are presented in Section 3. Finally, 109 Network Element requirements are presented in Section 4. 111 2. Operational Model 113 As defined in [I-D.amante-irs-topology-use-cases], the Topology 114 Manager performs the following tasks: 116 Collection of topology data from multiple sources: Network 117 Elements, routing protocols, inventory collection, statistics 118 collection, etc, as discussed in 119 [I-D.amante-irs-topology-use-cases]. Note that some of the data 120 sources, such as statistics or inventory, will be used not only by 121 the Topology Manager, but by other applications as well. Note 122 also that topology data sources may reside in multiple IGP areas 123 or multiple ASes, and/or in multiple network layers. 125 Creation of global topology view (i.e.: a common data model) from 126 the collected data; the topology view can span multiple network 127 layers as well as multiple Autonomous Systems. The global view 128 includes all network elements and resources existing in the 129 infrastructure, whether they are actively used or not. An example 130 consists of reconstructing the global view of the network 131 including router or switch ports that are available but not in 132 use. 134 Presentation of the network view to clients (applications). The 135 Topology Manager can create multiple application-specific views 136 from its common global topology database. 138 The operational model is shown in Figure 1. 140 +------------+ +------------+ 141 | Client | | Client | 142 +------------+ +------------+ 143 ^ ^ 144 | Northbound API | 145 +---------------+----------------+ 146 | 147 | 148 +-------------------------+ 149 | Topology Manager | 150 ...<-->| +---------------------+ |<--> Peer Topology 151 | | Topology Data Model | | Managers 152 | +---------------------+ | 153 +-------------------------+ 154 ^ ^ Southbound APIs 155 Other Topology Sources | | 156 (BGP-LS, Statistics, -----+ | SNMP, NetConf, I2RS, 157 Inventory) | OF, TL1, ... 158 +-------------------------+------------------------+ 159 | | | 160 +----------------+ +----------------+ +----------------+ 161 | Network Element| | Network Element| | Network Element| 162 | +------------+ |<-LLDP->| +------------+ |<-LMP->| +------------+ | 163 | | Data Model | | | | Data Model | | | | Data Model | | 164 | +------------+ | | +------------+ | | +------------+ | 165 +----------------+ +----------------+ +----------------+ 167 Figure 1: Topology Manager operational model 169 Topology information from network elements is relayed into the 170 Topology Manager Function via its Southbound API, as shown in 171 Figure 1. Sources of topology information may be Network Elements at 172 different layers of the network, such as appliances, routers, L2 173 switches, optical transponders, optical switches or monitoring, 174 provisioning and network analytics tools, such as Statistics 175 Collection subsystems or an Inventory subsystem. 177 The Topology Manager Function reconstructs the network/global view 178 (that can be on a per client or per application base) and distributes 179 it to its clients through northbound APIs. Examples of possible 180 northbound APIs are ReST, XMPP or Websockets. The Topology Manager 181 Function can be instantiated in a standalone server, be a part of a 182 comprehensive orchestration, data collection, presentation framework 183 (see [I-D.amante-irs-topology-use-cases]), or embedded in a routing 184 element. A client can be an application or a function in an upper 185 layer framework, such as a policy function. 187 Depending on the data it collects, a Topology Manager may not have 188 visibility into the entire network. In order to create a global 189 topology, the Topology Manager may get complementary partial topology 190 views from other Topology Managers via a Peer Topology Manager API. 192 3. Topology Manager Requirements 194 Distribution of all links available in the infrastructure is 195 certainly possible, however not desirable from a scaling and privacy 196 point of view. Therefore an implementation may support link to path 197 aggregation. Rather than advertising all specific links of a domain, 198 a topology manager may advertise an "aggregate link" between a non- 199 adjacent pair of nodes. The "aggregate link" represents the 200 aggregated set of link properties between a pair of non-adjacent 201 nodes. The actual methods to compute the path properties (of 202 bandwidth, metric) are outside the scope of this document. The 203 decision whether to advertise all specific links or aggregated links 204 is an operator's policy choice. To highlight the varying levels of 205 exposure, the following deployment examples shall be discussed. 207 3.1. Topology Manager Requirements 209 3.1.1. General Requirements 211 The general requirements are as follows: 213 TMF-GEN-1: I2RS MUST define a common vocabulary that describes 214 attributes associated with topological components of a network. 215 This is more commonly referred to as a "normalized" topology. 217 TMF-GEN-2: I2RS MUST define a data model that describes the 218 topological components represented by the Topology Manager 219 service. This data model will be written using a common 220 vocabulary, that allows one to assemble the components of a 221 network topology so that one can, for example, describe a physical 222 link and all of its associated physical layer attributes such as: 223 media type, bandwidth, MTU, etc. 225 TMF-GEN-3: The Topology Manager has a Northbound (Client) API and 226 multiple Southbound APIs for collecting topology data from 227 networks. Southbound APIs can be, for example, SNMP, NETCONF, 228 CLI, I2RS, OpenFlow, or routing protocols (e.g.: IGPs/BGP/BGP-LS). 230 TMF-GEN-4: The Topology Manager has an East-West (Peer Manager) 231 API to exchange topology information with peer Topology Managers. 232 Topologies exchanged with peer Topology Managers can be real or 233 abstract. Note that the East- West API can be the same as the 234 Northbound or Southbound APIs. 236 TMF-GEN-5: The Topology Manager MUST be able to collect and 237 process topology data from hundreds of thousands of sources 238 (network elements, etc.). Being able to collect data from large 239 number of sources is especially important in very large networks. 241 TMF-GEN-6: The Topology Manager SHOULD be able to provide multiple 242 application-specific views to different clients. 244 TMF-GEN-7: The Topology Manager MUST support the flow of topology 245 data and network (routing or security) policies from the network 246 as well as Inventory and Statistics Collection warehouses to 247 clients. The ability for the Topology Manger to support bi- 248 directional flow of topology data and network policies between 249 clients and the network is currently out-of-scope. 251 TMF-GEN-8: The transport protocol on all Topology Manager APIs 252 MUST support incremental updates between Topology Managers or 253 between a Topology Manager and a client. 255 3.1.2. Data Model Requirements 257 The requirements for the topology data model are as follows: 259 TMF-DM-1: The topology data model MAY be able to describe topology 260 and characteristics of different network layers: 262 * Optical DWDM (for future study) 264 * Optical OTN (for future study) 266 * L2 (Aggregated links, L2 topologies) 268 * IP/MPLS 269 * VPNs 271 * Services, such as cloud services, or CDNs 273 TMF-DM-2: The topology data model MUST support multiple Autonomous 274 System deployments. 276 TMF-DM-3: The Topology Manager MUST provide data normalization, 277 i.e. various types of topology information from different network 278 elements at different network layers and in different admin 279 domains is processed into a single, common format for clients' 280 consumption. 282 TMF-DM-4: The topology data model MUST be able to convey enough 283 information so that a client can correlate topologies in different 284 layers and from multiple Autonomous Systems. 286 TMF-DM-5: The topology data model MUST support multi-layer 287 grouping of elements as a means of coalescing different nodes and 288 links into "network layers". For example, links with IPv4 289 addresses might represent Layer 3 of the network topology while 290 links with Ethernet MAC addresses might represent Layer 2. 291 Furthermore, virtual private networks can be represented using 292 this grouping mechanism. 294 TMF-DM-6: Association between components of different layers is 295 needed as a means of indicating relationships (i.e.: dependency, 296 stacking, etc...) between components where layers are associated. 297 For example, a layer 2 port might have several IPv4 or IPv6 298 interfaces that utilize it. These would be represented as 299 associations to and from these components. 301 TMF-DM-7: Both active and inactive topologies MUST be represented 302 in the topology database. Inactive topology is not exhaustively 303 seen in IGP routing protocols. It must be retrieved by querying 304 inventory in network elements, for example new line cards inserted 305 in a chassis, new chassis, ports in the down state, etc. 307 TMF-DM-8: The topology data model MUST be hierarchical and MUST 308 support summarization of sub-topologies. Topology summarization 309 and creation of abstract topologies can be provided by the 310 Topology Manager or the Orchestration Function. 312 TMF-DM-9: The topology data model MUST be able to describe 313 abstract topologies. Abstract topologies can contain real and 314 abstract nodes and real and abstract links. An abstract topology 315 MAY be used by a provider to describe characteristics of a transit 316 network (bandwidth, delay, protection, etc.) 317 TMF-DM-10: The topology data model MUST support dynamic data, such 318 as link and node utilizations (perhaps as optional attributes). 320 TMF-DM-11: The topology data model MUST allow a user (operator) to 321 determine the path between two nodes. The path MAY be traceable 322 at all network layers that participate in the delivery of packets 323 between two nodes. For example, for IP traffic exchanged between 324 2 routers, the user should be able to identify all underlying L2 325 switches that carry the traffic between the routers. 327 TMF-DM-12: The topology data model MUST support multiple BGP 328 Autonomous Systems and multiple IGP areas. Support for multiple 329 administrative domains is for further study. 331 TMF-DM-13: The topology data model MUST be human-friendly, i.e. 332 not SNMP MIBs, but something much more analogous to YANG models. 334 TMF-DM-14: The data model SHOULD support topology abstraction, 335 allowing clients that consume topology information in a 336 constrained manner. For example, a client wishing to view only 337 interfaces and nodes present in a sub-graph of the Layer 3 338 topology should be able to specify an interest in this subset of 339 information rather than having to read out and parse through the 340 entire set of links and nodes. 342 3.1.2.1. IP/MPLS Layer Data Model Requirements 344 The requirements for the IP/MPLS topology data model are as follows: 346 TMF-DM-IP-1: The data model of the IP/MPLS layer MUST support both 347 link topology and prefixes. 349 TMF-DM-IP-2: Link topology may be retrieved from an IGP, BGP-LS 350 ([I-D.ietf-idr-ls-distribution]), or by getting node neighbor 351 information directly from network elements via a management 352 protocol such as SNMP, NETCONF or CLI. 354 TMF-DM.IP-3: Links in the IP/MPLS data model includes, among 355 others, one or more of the following link attributes: 357 * Local and Remote anchor node IDs (Router ID, AS#, Area ID, MT 358 Topology ID) 360 * Metrics 361 * Admin Group 363 * Max link bandwidth 365 * Unreserved / utilized bandwidth 367 * Link Protection type 369 * MPLS Protocol mask 371 * Link prefix 373 * Link characteristics (BW, delay, error rate) 375 * Link description 377 * Link-specific timers, (Hello & Holddown) 379 TMF-DM.IP-4: Nodes in the IP/MPLS data model MAY include one or 380 more of the following node attributes: 382 * Node Type: simple node / aggregate node 384 * Intra area router 386 * Inter area router (ISIS L1L2 or OSPF ABR) 388 * AS boundary router 390 * MPLS-VPN Edge router (PE) 392 * Tunnel head-end/tail-end 394 * Node ID:: Node ID (Router ID, AS#, Area ID, MT Topology ID) 396 * Flags: Overload, Attached, External, ABR 398 * Node capabilities as defined in [RFC5073] 400 * BGP: aggregate IP prefix + mask (with associated tie-down 401 route information to inject the aggregate route into BGP) 403 * BGP policy associated with a given iBGP/eBGP neighbor; policy 404 matching criteria can be, among others, remote-AS, local-AS, 405 Local-AS tweaks to manipulate AS_PATH recv'd or transmitted, 406 timers (Hello, HoldTime), AFI/SAFI, route-map/policy-statements 407 applied/active (including associated prefix-lists, AS_PATH 408 regexp filters, etc. and resulting manipulation of BGP path 409 attributes, e.g.: changing LOCAL_PREF, MED, BGP community, 410 etc.) 412 * BGP statistics collection: number of IP paths/prefixes 413 learned per neighbor 415 3.1.3. Northbound (Client) API Requirements 417 The requirements for the Topology Manager's northbound (client) 418 interface are as follows: 420 TMF-NB-1: The transport protocol between the Topology Manager and 421 its clients MUST have efficient encoding so that large topologies 422 can be transferred with reasonable performance. 424 TMF-NB-2: The transport protocol MUST support flow-control in case 425 a client cannot digest updates fast enough from its server. 427 TMF-NB-3: The transport protocol MUST support push of topology 428 updates from the Topology Manager to clients. 430 TMF-NB-4: The protocol MUST implement a mechanism through which a 431 client can efficiently determine the latest information especially 432 when it receives multiple copies of the same topology from 433 multiple Topology Managers. An example is the IGP Sequence Number 434 that is used on IGP routing updates. 436 TMF-NB-5: The Northbound API MUST support publishing of events to 437 a dynamic list of clients/applications. This is helpful for the 438 Northbound API to signal events as they occur in the network, 439 e.g.: insertion or removal of linecards, etc. 441 TMF-NB-6: The Northbound API SHOULD support subscription to events 442 from a dynamic list of clients/applications. This will allow the 443 Topology System to react dynamically when, for example, new 444 requests for services are asked to be created. 446 TMF-NB-7: The Northbound API SHOULD allow clients to subscribe to 447 a rich assortment of attributes and/or data models so that they 448 are automatically notified of changes within the network, (as a 449 result of a node failure, card insertion, etc.), as well as 450 changes made by other upper-layer applications to the network, 451 (for example, addition/subtraction of physical links to the 452 network during network augmentation or optimization, etc.). 454 TMF-NB-8: The Northbound API MUST provide a means for non-routers 455 to communicate with the model. Until now, clients that could 456 gather network topology and inventory information were generally 457 limited to those that could speak routing protocols. 459 3.1.4. Southbound (Network & Device) API Requirements 461 The requirements for the Topology Manager's southbound (network 462 element) interface are as follows: 464 TMF-SB-1: The transport protocol between the Topology Manager and 465 the topology data sources (Network Elements, etc.) SHOULD have 466 efficient encoding so that large data models can be transferred 467 with reasonable performance. 469 TMF-SB-2: The transport protocol MUST support incremental updates 470 from a Network Element to the Topology Manager. 472 TMF-SB-3: The transport protocol MUST support push of topology 473 updates from a Network Element to the Topology Manager. 475 4. Network Element Requirements 477 The requirements for the topology data model are as follows: 479 NE-1: Each network element SHOULD contain an inventory database, 480 which SHOULD be a definitive source of information with respect to 481 the physical HW and logical, locally significant identifiers, 482 e.g.: VLANs, deployed in the system. The Topology Manager 483 collects inventory data from network elements and creates an 484 authoritative view of physical hardware deployed in the network. 486 NE-2: The inventory DB SHOULD be augmented with the physical 487 properties associated with the ports/interfaces that are directly 488 connected to the device, (e.g.: BW, media type, etc.). 490 NE-3: The inventory DB MAY be augmented through the I2RS framework 491 pushing information into the network element to, for example, 492 associate information the installer may have knowledge of, but the 493 network element may not be able to learn on its own, e.g.: it's 494 physical location (address), rack/bay information, etc. 496 NE-4: Relevant network elements should automatically and 497 dynamically acquire information associated with their immediately 498 adjacent neighbors using protocols such as LLDP, LMP, etc. A 499 network element should further augment it's physical port 500 inventory DB with this information so that the system can report 501 on whom it's directly connected. 503 5. Acknowledgements 505 The authors would like to thank Alia Atlas, Chris Metz, and Dave Ward 506 for their comments and input. 508 6. IANA Considerations 510 This memo includes no request to IANA. 512 7. Security Considerations 514 TBD. 516 8. References 518 8.1. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 8.2. Informative References 525 [I-D.amante-irs-topology-use-cases] 526 Amante, S., Medved, J., and T. Nadeau, "Topology API Use 527 Cases", draft-amante-irs-topology-use-cases-00 (work in 528 progress), October 2012. 530 [I-D.ietf-idr-ls-distribution] 531 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 532 Ray, "North-Bound Distribution of Link-State and TE 533 Information using BGP", draft-ietf-idr-ls-distribution-01 534 (work in progress), October 2012. 536 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 537 Extensions for Discovery of Traffic Engineering Node 538 Capabilities", RFC 5073, December 2007. 540 Authors' Addresses 542 Jan Medved 543 Cisco Systems, Inc. 544 170, West Tasman Drive 545 San Jose, CA 95134 546 US 548 Email: jmedved@cisco.com 550 Stefano Previdi 551 Cisco Systems, Inc. 552 Via Del Serafico, 200 553 Rome 00142 554 Italy 556 Email: sprevidi@cisco.com 558 Hannes Gredler 559 Juniper Networks, Inc. 560 1194 N. Mathilda Ave. 561 Sunnyvale, CA 94089 562 US 564 Email: hannes@juniper.net 566 Thomas Nadeau 567 Juniper Networks, Inc. 568 1194 N. Mathilda Ave. 569 Sunnyvale, CA 94089 570 US 572 Email: tnadeau@juniper.net 574 Shane Amante 575 Level 3 Communications, Inc. 576 1025 Eldorado Blvd 577 Broomfield, CO 80021 578 US 580 Email: shane@level3.net