idnits 2.17.1 draft-scharf-alto-topology-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 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2014) is 3587 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) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-04) exists of draft-clemm-i2rs-yang-network-topo-00 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-09 == Outdated reference: A later version (-09) exists of draft-wu-alto-te-metrics-03 == Outdated reference: A later version (-06) exists of draft-yang-alto-topology-03 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG M. Scharf 3 Internet-Draft Alcatel-Lucent Bell Labs 4 Intended status: Standards Track July 2, 2014 5 Expires: January 3, 2015 7 Path-Vector and Node-Edge Topology Maps in ALTO 8 draft-scharf-alto-topology-00 10 Abstract 12 The Application-Layer Traffic Optimization (ALTO) service defines 13 network and cost maps to provide basic network information. This 14 document motivates an optional extension of ALTO for the definition 15 of additional topology properties. The ALTO extension supports both 16 path-vector and node-edge topology maps. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Endpoint-Centric Network Topology Models . . . . . . . . . . 3 55 3.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Topology Models . . . . . . . . . . . . . . . . . . . . . 4 57 4. Topology Encoding Formats for ALTO . . . . . . . . . . . . . 5 58 4.1. Map Service Extension . . . . . . . . . . . . . . . . . . 5 59 4.2. Path-Vector Format . . . . . . . . . . . . . . . . . . . 6 60 4.3. Node-Edge Format . . . . . . . . . . . . . . . . . . . . 8 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . 10 67 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The Application-Layer Traffic Optimization (ALTO) service 73 [I-D.ietf-alto-protocol] provides network information (e.g., basic 74 network location structure and preferences of network paths) with the 75 goal of modifying network resource consumption patterns while 76 maintaining or improving application performance. The basic 77 information of ALTO is based on abstract maps of a network. These 78 maps provide a simplified view, yet enough information about a 79 network for applications to effectively utilize them. 81 Applications using an ALTO service typically consist of instances 82 running at endpoints. This is why ALTO maps provide abstract cost 83 and/or ranking information between network endpoints. Yet, for 84 selected use cases of ALTO, it is desirable to have a more detailed 85 representation of the network. For instance, in settings with 86 multiple application source-destination pairs with multiple links, 87 such a representation could help avoid bottleneck or failed links. 89 Topology models for ALTO are also discussed in other related 90 documents. A full solution to extend ALTO is defined in 91 [I-D.yang-alto-topology]. An earlier survey of use-cases for 92 extended network topology information can also be found in 93 [I-D.bernstein-alto-topo]. Further related work has been published 94 in [I-D.lee-alto-app-net-info-exchange] and 95 [I-D.bernstein-alto-large-bandwidth-cases]. 97 This document specifies two graph representation formats that can be 98 used in ALTO. Both formats are optional, and it is up to the 99 operator of an ALTO service to decide whether to offer this data in 100 addition to the standard network and cost maps of an ALTO service. 101 The graph representation defined in this document is based on 102 existing ALTO abstraction (e.g., PIDs) and complements the existing 103 path-based ALTO cost map representation. Together, they provide a 104 more complete but still abstract representation of networks for 105 informed traffic optimization among endpoints. 107 This document does not intend to model topology internals not 108 affecting endpoints, such as routing protocol internals. A data 109 model for network topologies with routing protocol externals can for 110 instance be found in [I-D.clemm-i2rs-yang-network-topo]. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Endpoint-Centric Network Topology Models 120 3.1. Use Cases 122 This document focuses on exposure of network topology properties that 123 matter to endpoints. Usually, applications instances at network 124 endpoints (hosts) only have to care about end-to-end network 125 properties of the paths between those endpoints. The basic ALTO 126 services, i.e., either the Network and Cost Map service or the 127 Endpoint Cost service, can be used to express end-to-end 128 characteristics of paths between endpoints, as explained e.g. in 129 [I-D.ietf-alto-deployments] and [I-D.wu-alto-te-metrics]. 131 However, there are a number of use cases in which it is difficult to 132 expose topological properties to applications using only the 133 mechanisms in the base ALTO protocol [I-D.ietf-alto-protocol]. These 134 uses cases are typically characterized by multiple application 135 source-destination pairs: 137 o Shared bottleneck detection: As explained for instance in 138 [I-D.ietf-alto-deployments], ALTO can be used to avoid excessive 139 use of bottleneck links by recommending communication with 140 endpoints not using that bottleneck. However, if multiple 141 application transfers shall be scheduled, e.g., by a bandwidth 142 calendaring application, it can be difficult to determine whether 143 the resulting communication would hit a common bottleneck unless 144 the applications are aware of links that would be used by multiple 145 transfers. This would benefit from an ALTO extension that can 146 return shared parts of paths used by transfers between different 147 endpoints (e.g., given by IP addresses). 149 o Resilience improvement: Applications requiring high reliability 150 can be interested in understanding if there is a risk of 151 simultaneous failures on multiple path between application 152 instances. For instance, transport networks can provide certain 153 shared risk link group (SRLG) information that provides insight 154 which links are at risk of simultaneous failures due to fate 155 sharing. Applications requiring high reliability may then prefer 156 the use of endpoints with disjoint paths. 158 o Multi-homing and multi-pathing: If endpoints are multi-homed, 159 i.e., if hosts have more than one IP address, it can be useful to 160 know if there are multiple paths between these endpoints. For 161 instance, applications could leverage such information to decide 162 whether to explictly enable Multipath TCP [RFC6824]. 164 None of these use cases requires an application to understand routing 165 protocol internals, such as the entries in Routing Information Base 166 (RIB) of routers in the network. While it may be possible to derive 167 such information from corresponding models, such as 168 [I-D.clemm-i2rs-yang-network-topo], ALTO targets general-purpose 169 applications that typically have no understanding of RIB data, 170 different routing protocols, etc. Therefore, ALTO requires a more 171 abstract solution to express topology details. An optional ALTO 172 graph representation solution allows disclosure of such information 173 to ALTO clients. 175 3.2. Topology Models 177 This document specifies two optional, abstract graph representation 178 format for ALTO, which can reveal for instance coupling of links on a 179 path. This section introduces the topology model. The formal 180 specification follows in the next section. 182 There are two different graph representation formats that could be 183 used to generalize the existing ALTO network and cost maps and reveal 184 path coupling: 186 o Path-vector format: This format describes the topology between 187 given endpoints by an enumeration of the path traversed between 188 the source and destination. The advantage of this format is that 189 it can consider the outcome of network-internal routing policies 190 (e.g., preferring paths other than the shortest path given by 191 routing metrics). However, for a large network with many paths 192 there is a large representation overhead. 194 o Node-edge format: A graph encoding with nodes and edges can be 195 very compact, depending on the average node degree, and it can 196 also be much smaller than the full mesh of costs between endpoints 197 that is used by ALTO cost maps. Yet, a downside is that a single 198 graph may not convey network routing policies. 200 Since both formats have advantages and drawbacks, this document 201 allows the use of both formats, and it is up to the ALTO service to 202 decide whether to support it. 204 Both formats can reuse the PID concept that is used in ALTO to 205 abstract topology details, as explained in [I-D.ietf-alto-protocol] 206 and [I-D.ietf-alto-deployments]. 208 4. Topology Encoding Formats for ALTO 210 This section defines an OPTIONAL extension of ALTO for topology 211 encoding in JSON format [RFC4627]. An ALTO service announces the 212 support of these formats in the Information Resource Directory (IRD) 213 [I-D.ietf-alto-protocol]. 215 TODO: Currently, the formats are illustrated by examples only. The 216 full formal specification is TBD. 218 4.1. Map Service Extension 220 The graph encoding uses the existing PID concept and ALTO map service 221 [I-D.ietf-alto-protocol]. Basically, both in the path-vector and in 222 the node-edge encoding, a PID is generalized as a node in the 223 topology. If an ALTO server server uses either format, it MAY return 224 PIDs without an IPv4 or IPv6 address mapping. 226 For instance, consider the following network topology. For the sake 227 of simplicity, "H1", "H2", ... as well as "R1", "R2", ... are also 228 used as PID names in the following examples. 230 10.0.1.1/24 10.0.3.1/24 231 +----+ +----+ +----+ 232 | H1 |----. .----| R3 |------| H3 | 233 +----+ \+----+ +----+/ +----+ +----+ 234 | R1 |======| R2 | 235 +----+ /+----+ +----+\ +----+ +----+ 236 | H2 |----' '----| R4 |------| H4 | 237 +----+ +----+ +----+ 238 10.0.2.1/24 10.0.4.1/24 240 R1, R2, ... are transit nodes in the topology. The objective of 241 topology encoding formats is to represent their relations. Yet, the 242 addresses of those routers (e.g., interface or system IP addresses) 243 may not matter to applications. Therefore, PIDs representing those 244 nodes may not have a valid IP address mapping. In ALTO, it is up to 245 an ALTO server to define what a PID represents. A PID can both refer 246 to a single node (such as a router), a subnet, a whole network, etc. 248 A corresponding ALTO network map query according to 249 [I-D.ietf-alto-protocol] would be: 251 GET /networkmap HTTP/1.1 252 Host: alto.example.com 253 Accept: application/alto-networkmap+json, 254 application/alto-error+json 256 For the given example, this would return: 258 HTTP/1.1 200 OK 259 Content-Length: TBD 260 Content-Type: application/alto-networkmap+json 262 { 263 "meta": { 264 ... 265 }, 266 "network-map": { 267 "H1": { "ipv4": [ "10.0.1.0/24" ] }, 268 "H2": { "ipv4": [ "10.0.2.0/24" ] }, 269 "H3": { "ipv4": [ "10.0.3.0/24" ] }, 270 "H4": { "ipv4": [ "10.0.4.0/24" ] }, 271 "R1": { }, "R2": { }, "R3": { }, "R4": { }, 272 "Default": { 273 "ipv4": [ "0.0.0.0/0" ], "ipv6": [ "::/0" ] 274 } 275 } 276 } 278 R1, R2, R3, and R4 are transient PIDs on the path between endsystems. 279 If their IP addresses do not matter, they can be omitted. If an 280 identification of such nodes was required, one could introduce other 281 identifiers. This is left for further study. 283 4.2. Path-Vector Format 285 This extension uses a new media type "application/alto- 286 pathvector+json". An ALTO service MAY use the path-vector format as 287 optional extension. In the path-vector format, an ALTO cost map 288 consists of an ordered sequence of PIDs. Using the same query 289 mechanisms like the base ALTO protocol [I-D.ietf-alto-protocol], an 290 ALTO query for path-vector information would be: 292 GET /costmap/pathvector HTTP/1.1 293 Host: alto.example.com 294 Accept: application/alto-pathvector+json, 295 application/alto-error+json 297 The corresponding response of an ALTO server would be: 299 HTTP/1.1 200 OK 300 Content-Length: TBA 301 Content-Type: application/alto-pathvector+json 303 { 304 "meta": { 305 ... 306 "cost-type": {"cost-mode": "pathvector"} 307 }, 308 "cost-map" : { 309 "H1": { 310 "H2": [ "R1" ], 311 "H3": [ "R1", "R2", "R3" ] 312 "H4": [ "R1", "R2", "R4" ] 313 }, 314 "H2": { ... }, 315 "H3": { ... }, 316 "H4": { ... }, 317 "Default": { ... } 318 } 319 } 321 In the most simple form, a path vector consists of an ordered 322 sequence of PIDs from a source to a destination. It is also possible 323 to extend the path vector format by integrating cost metrics in the 324 vector. A corresponding format is left for further study in this 325 document. 327 In general, the cost values between any PIDs can always be determined 328 using the standard cost map of ALTO [I-D.ietf-alto-protocol]. As an 329 example, the following query is also possible for the path-vector 330 cost mode: 332 GET /costmap/num/routingcost HTTP/1.1 333 Host: alto.example.com 334 Accept: application/alto-costmap+json, 335 application/alto-error+json 337 A corresponding response of an ALTO server could be, fully using the 338 syntax and semantics of [I-D.ietf-alto-protocol]: 340 HTTP/1.1 200 OK 341 Content-Length: TBD 342 Content-Type: application/alto-costmap+json 344 { 345 "meta" : { 346 ... 347 "cost-type": {"cost-mode": "numerical", 348 "cost-metric": "routingcost" 349 } 350 }, 351 "cost-map": { 352 "H1": { "R1": 1 }, 353 "H2": { "R1": 5 }, 354 "R1": { "H1": 1, "H2": 5, "R2": 9 }, 355 "R2": { "R1": 9, "R3": 4, "R4": 7 }, 356 ... 357 } 358 } 360 In addition to the standard metric "routing cost", also other metrics 361 for ALTO cost maps could be used, such as the ones described in 362 [I-D.wu-alto-te-metrics]. 364 4.3. Node-Edge Format 366 As an alternative representation, an ALTO service MAY also expose map 367 data in a node-edge format. The node-edge format basically returns a 368 list of edges between the PIDs given by the network map. The 369 response SHOULD also include a list of the nodes, which is identical 370 to the ALTO network map. Adding the list of nodes enables a client 371 to process the full graph with a single query. This extension uses 372 the new media type "application/alto-nodeedge+json". In the 373 following a query for a node-edge map is shown: 375 GET /costmap/nodeedge HTTP/1.1 376 Host: alto.example.com 377 Accept: application/alto-nodeedge+json, 378 application/alto-error+json 380 In the given example, the response in node-edge format would be as 381 follows: 383 HTTP/1.1 200 OK 384 Content-Length: TBA 385 Content-Type: application/alto-nodeedge+json 387 { 388 "meta": { 389 ... 390 "cost-type": {"cost-mode": "nodeedge"} 391 }, 392 "nodes": { 393 "H1": { "ipv4": [ "10.0.1.0/24" ] }, 394 "H2": { "ipv4": [ "10.0.2.0/24" ] }, 395 "H3": { "ipv4": [ "10.0.3.0/24" ] }, 396 "H4": { "ipv4": [ "10.0.4.0/24" ] }, 397 "R1": { }, "R2": { }, "R3": { }, "R4": { }, 398 "Default": { 399 "ipv4": [ "0.0.0.0/0" ], "ipv6": [ "::/0" ] 400 } 401 } 402 "edges": [ 403 "E1": { "src": "H1", "dst": "R1", 404 "type": "directed", 405 "cost": [ { "cost-metric": "delay", 406 "value": "3" 407 }, { 408 "cost-metric": "availbw", 409 "value": "50" 410 }, { 411 "cost-metric" : "risk-group", 412 "value" : ["SLRG3"] 413 } ] 414 }, 415 "E2": { "src": "R1", "dst": "R2", 416 "type": "directed", 417 "cost": [ { "cost-metric": "delay", 418 "value": "3" 419 }, { 420 "cost-metric": "availbw", 421 "value": "50" 422 } ] 423 }, 424 ... 425 } 426 } 428 The node-edge format re-uses the PID as identifiers for nodes. It 429 requires a new set of identifiers for the edges. For those 430 identifies, the same syntax constraints like for PIDs are used. 432 Within one response, each edge must be uniquely identified by an edge 433 identifier. 435 Edges can be characterized by the same attributes like ALTO cost 436 maps, including one or more cost metrics. For instance, the cost 437 metrics defined in [I-D.wu-alto-te-metrics] can be used for edges. 438 The specification of further edge properties is for further study. 440 5. IANA Considerations 442 TBD 444 6. Security Considerations 446 TBD 448 7. Conclusion 450 TBD 452 8. References 454 8.1. Normative References 456 [I-D.ietf-alto-protocol] 457 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 458 ietf-alto-protocol-27 (work in progress), March 2014. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC4627] Crockford, D., "The application/json Media Type for 464 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 466 8.2. Informative References 468 [I-D.bernstein-alto-large-bandwidth-cases] 469 Bernstein, G. and Y. Lee, "Use Cases for High Bandwidth 470 Query and Control of Core Networks", draft-bernstein-alto- 471 large-bandwidth-cases-02 (work in progress), July 2012. 473 [I-D.bernstein-alto-topo] 474 Bernstein, G., Yang, Y., and Y. Lee, "ALTO Topology 475 Service: Uses Cases, Requirements, and Framework", draft- 476 bernstein-alto-topo-00 (work in progress), October 2013. 478 [I-D.clemm-i2rs-yang-network-topo] 479 Clemm, A., Ananthakrishnan, H., Medved, J., Tkacik, T., 480 Varga, R., and N. Bahadur, "A YANG Data Model for Network 481 Topologies", draft-clemm-i2rs-yang-network-topo-00 (work 482 in progress), February 2014. 484 [I-D.ietf-alto-deployments] 485 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 486 "ALTO Deployment Considerations", draft-ietf-alto- 487 deployments-09 (work in progress), February 2014. 489 [I-D.lee-alto-app-net-info-exchange] 490 Lee, Y., Dhody, D., Wu, Q., Bernstein, G., and T. Choi, 491 "ALTO Extensions to Support Application and Network 492 Resource Information Exchange for High Bandwidth 493 Applications in TE networks", draft-lee-alto-app-net-info- 494 exchange-04 (work in progress), October 2013. 496 [I-D.wu-alto-te-metrics] 497 Wu, W., Yang, Y., Lee, Y., Dhody, D., and S. Randriamasy, 498 "ALTO Traffic Engineering Cost Metrics", draft-wu-alto-te- 499 metrics-03 (work in progress), June 2014. 501 [I-D.yang-alto-topology] 502 Bernstein, G., Lee, Y., Roome, B., Scharf, M., and Y. 503 Yang, "ALTO Topology Extensions", draft-yang-alto- 504 topology-03 (work in progress), July 2014. 506 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 507 "TCP Extensions for Multipath Operation with Multiple 508 Addresses", RFC 6824, January 2013. 510 Appendix A. Contributors 512 This document is an outcome of very valuable discussions with Y. 513 Richard Yang, Young Lee, and Greg M. Bernstein during IETF 89. 515 Author's Address 517 Michael Scharf 518 Alcatel-Lucent Bell Labs 519 Lorenzstrasse 10 520 Stuttgart 70435 521 Germany 523 Email: michael.scharf@alcatel-lucent.com