idnits 2.17.1 draft-bernstein-alto-topo-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 91 -- Looks like a reference, but probably isn't: '2' on line 92 -- Looks like a reference, but probably isn't: '3' on line 92 -- Looks like a reference, but probably isn't: '4' on line 92 -- Looks like a reference, but probably isn't: '5' on line 92 -- Looks like a reference, but probably isn't: '6' on line 93 -- Looks like a reference, but probably isn't: '7' on line 102 -- Looks like a reference, but probably isn't: '8' on line 102 -- Looks like a reference, but probably isn't: '9' on line 131 -- Looks like a reference, but probably isn't: '10' on line 155 -- Looks like a reference, but probably isn't: '11' on line 175 -- Looks like a reference, but probably isn't: '12' on line 181 -- Looks like a reference, but probably isn't: '13' on line 185 -- Looks like a reference, but probably isn't: '14' on line 227 == Outdated reference: A later version (-02) exists of draft-bernstein-alto-large-bandwidth-cases-00 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-20 == Outdated reference: A later version (-04) exists of draft-lee-alto-app-net-info-exchange-03 == Outdated reference: A later version (-06) exists of draft-yang-alto-topology-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG G. Bernstein, Ed. 3 Internet-Draft Grotto Networking 4 Intended status: Informational Y. Yang, Ed. 5 Expires: April 24, 2014 Yale University 6 Y. Lee, Ed. 7 Huawei Technologies 8 October 21, 2013 10 ALTO Topology Service: Uses Cases, Requirements, and Framework 11 draft-bernstein-alto-topo-00 13 Abstract 15 Exposing additional topology information of networks to applications 16 and users beyond that of the current ALTO protocol can enable many 17 important existing and emerging use cases, and many network providers 18 already provide additional information about their networks. At the 19 same time, there is no standard for exposing network topology in a 20 manner that provides simplification via abstraction to the 21 application layer and information hiding via abstraction to the 22 network provider. In this document, we provide a survey of use-cases 23 for extended network topology information, present some initial 24 requirements for such services, and then give a framework of how to 25 integrate such an extended ALTO topology service with network control 26 infrastructure. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Uses Cases . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Technology Specific Examples . . . . . . . . . . . . . . 4 66 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. ALTO Topology Framework . . . . . . . . . . . . . . . . . . . 5 68 4.1. Abstract Topology Representation . . . . . . . . . . . . 5 69 4.2. Sources of Raw Topology Information . . . . . . . . . . . 5 70 4.3. Service/Client Specific Topology Abstraction . . . . . . 5 71 4.4. Reservation System Compatibility . . . . . . . . . . . . 5 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 8.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Topology is a basic property of a network. Hence there is a spectrum 83 of use cases where an application (or user) can benefit from 84 obtaining some knowledge of the topology of the network that it uses 85 or considers using, beyond the "single-switch"abstraction topology 86 abstraction presented in the ALTO Base Protocol 87 [I-D.ietf-alto-protocol] as discussed in [I-D.yang-alto-topology]. 89 As a simple case, many networks already provide public views to their 90 topologies so that current or potential users of their networks can 91 learn more about their networks; for example, see Verizon [1]; 92 Comcast [2]; CenturyLink [3]; BT [4]; China Telecom [5]; Internet 2 93 [6]. A user (application) with such information may conduct a wide 94 variety of analysis, for example, in determining its service 95 provider(s). 97 For more advanced use cases such as in a programmatic setting, a 98 topology manager of a network may expose a topology of the network to 99 an application so that the application can provide its input 100 regarding the operations of the network. A concrete example setting 101 is the recent development of Software Defined Networking (SDN); for 102 example see OpenDayLight [7]; Maple [8]. 104 The objective of this document is three folds: (1) it surveys general 105 uses cases and existing designs of how network topologies are exposed 106 to applications; (2) it presents the requirements in exposing network 107 topologies; and (3) it gives a framework of how network topologies to 108 applications can be integrated into network control. 110 1.1. Requirements Language 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Uses Cases 118 Uses cases generally relate to some type of cost metric optimization, 119 application policy, resource requirements (bandwidth), and/or 120 performance criteria such as delay. In the following we give a non- 121 exhaustive list of uses cases for a extended ALTO topology service. 123 Large Bandwidth 124 Applications that make extensive use of network bandwidth 125 resources are discussed in 126 [I-D.bernstein-alto-large-bandwidth-cases]. In addition to a 127 general discussion of large bandwidth requirements specific 128 examples of video on demand and inter-data center networking 129 are given. An optimization example for a scheduled backup 130 service can be found at http://www.grotto-networking.com/ 131 BackupExample.html [9]. 133 Enhanced Reliability 134 GMPLS [RFC3945] and GMPLS routing [RFC4202] in particular 135 have included enhanced reliability support in the form of 136 shared risk link group (SRLG) information that lets a path 137 computation entity understand which links are at risk of 138 simultaneous failures (fate sharing). In addition in optical 139 networks link and node diverse paths are a common method to 140 enhance reliability [OptControl]. 142 However in many cases only the application may have a full 143 view of its reliability needs. For example consider a high 144 reliability application making use of multiple data centers 145 for redundancy and increased reliability, such reliability 146 would be significantly diminished if the paths to those data 147 centers shared similar fates. 149 Latency Sensitivity 150 From high performance gaming to high frequency trading 151 latency can critically impact application performance. 152 However, reductions in latency may need to be factored 153 against other costs or resource requirements. As mentioned 154 in http://cacm.acm.org/magazines/2013/10/168186-barbarians- 155 at-the-gateways/abstract [10] some high frequency trading 156 applications need to make use of both a low latency path and 157 a high bandwidth path. 159 Policy Enforcement 160 Many application specific requirements such as the HIPPA 161 privacy rule, can place restrictions on where a certain 162 customers data may be kept, or what geographic regions a 163 customers data can traverse, etc... Enhancing topology 164 information made available to an application can help it 165 ensure such requirements are satisfied. 167 2.1. Technology Specific Examples 169 Here we furnish a partial list of examples that illustrate one or 170 more properties desirable in an extended ALTO topology service. 172 SDN: Project Floodlight 173 Project floodlight provides limited inter switch topology 174 information https://github.com/wallnerryan/floodlight/blob/ 175 master/example/graphTopo.py [11]. 177 SDN: Open Daylight 178 The Open Daylight project is aiming to supply a "north bound" 179 topology service https://jenkins.opendaylight.org/controller/ 180 job/controller-merge/ws/opendaylight/northbound/topology/ 181 target/site/wsdocs/el_ns0_topology.html [12]. 183 Grid Computing - OGF NML 184 The Open Grid Forum has developed a general Network Markup 185 Language http://www.ogf.org/documents/GFD.206.pdf [13]. This 186 borrows concepts from GMPLS and ITU-T G.805 models. However, 187 it is not aimed at application layer users, but rather grid 188 computing operators. 190 Fiber Maps (multiple carriers) 191 TBD. 193 HPC - cluster placement problem 194 TBD. 196 3. Requirements 198 Formal requirements to come... 200 4. ALTO Topology Framework 202 The framework portion of this document, like most IETF frameworks, is 203 an informational section that shows how various systems could come 204 together to form an extended ALTO topology service. 206 4.1. Abstract Topology Representation 208 References [I-D.lee-alto-app-net-info-exchange] and 209 [I-D.yang-alto-topology] provide tentative models and encodings for 210 abstract topology representation. 212 4.2. Sources of Raw Topology Information 214 From management systems, to proprietary interfaces to routing 215 systems, to i2rs... 217 4.3. Service/Client Specific Topology Abstraction 219 Although only the topology/resource abstraction format would be 220 subject to standardization, this section will illustrate some 221 techniques that can be efficiently used to derived service and client 222 specific topology abstractions. References 223 [I-D.lee-alto-app-net-info-exchange] and [I-D.yang-alto-topology] 224 give examples of how raw network topology information can be 225 processed into abstracted application specific form. A lengthier 226 paper with more examples and technology considerations can be found 227 at [14]. 229 4.4. Reservation System Compatibility 231 As mentioned in the requirements ALTO topology extensions must be 232 able to work with technologies that require resource reservations as 233 well as those that don't. In implementing an overall system the 234 information supplied by an extended ALTO topology service will need 235 to be compatible with a "reservation system" if there is one. 237 At the IETF we have seem similar requirements for compatibility 238 between GMPLS routing and signaling systems, particularly via the 239 concept of loose routes. 241 5. Acknowledgements 243 Hopefully we'll have lots of interested folks commenting and we'll 244 give them credit here. 246 6. IANA Considerations 248 This memo includes no request to IANA. 250 7. Security Considerations 252 All drafts are required to have a security considerations section and 253 this will as we flesh it out. 255 8. References 257 8.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 264 8.2. Informative References 266 [I-D.bernstein-alto-large-bandwidth-cases] 267 Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth 268 Query and Control of Core Networks", draft-bernstein-alto- 269 large-bandwidth-cases-00 (work in progress), June 2011. 271 [I-D.ietf-alto-protocol] 272 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 273 ietf-alto-protocol-20 (work in progress), October 2013. 275 [I-D.lee-alto-app-net-info-exchange] 276 Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi, 277 "ALTO Extensions to Support Application and Network 278 Resource Information Exchange for High Bandwidth 279 Applications ", draft-lee-alto-app-net-info-exchange-03 280 (work in progress), October 2013. 282 [I-D.yang-alto-topology] 283 Yang, Y., "ALTO Topology Considerations", draft-yang-alto- 284 topology-00 (work in progress), July 2013. 286 [OptControl] 287 Bernstein, G., Rajagopalan, B., and D. Saha, "Optical 288 Network Control", 2004. 290 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 291 (GMPLS) Architecture", RFC 3945, October 2004. 293 [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in 294 Support of Generalized Multi-Protocol Label Switching 295 (GMPLS)", RFC 4202, October 2005. 297 Authors' Addresses 299 Greg M. Bernstein (editor) 300 Grotto Networking 301 Fremont, CA 302 US 304 Phone: +01 510 623 8575 305 Email: gregb@grotto-networking.com 307 Y. Richard Yang (editor) 308 Yale University 309 51 Prospect St 310 New Haven, CT 311 USA 313 Email: yry@cs.yale.edu 315 Young Lee (editor) 316 Huawei Technologies 317 1700 Alma Drive, Suite 500 318 Plano, TX 75075 319 USA 321 Phone: (927) 509-5599 322 Email: ylee@huawei.com