idnits 2.17.1 draft-xu-homenet-traffic-class-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 46 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2013) is 3931 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) == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-fun-routing-class' is defined on line 438, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-07 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-src-routing-02 == Outdated reference: A later version (-02) exists of draft-acee-ospfv3-lsa-extend-00 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Xu 3 Internet-Draft S. Yang 4 Expires: January 16, 2014 J. Wu 5 Tsinghua University 6 F. Baker 7 Cisco Systems 8 July 15, 2013 10 Traffic Class Routing Protocol in Home Networks 11 draft-xu-homenet-traffic-class-00 13 Abstract 15 Home IT staff is generally unfamiliar with network operations, making 16 it desirable to provide a configuration-free mode of operation. 17 Policy-based routing (in the sense of configuring one router to 18 redirect traffic to another based on access control) and multi- 19 topology routing both require configuration, making them undesirable. 21 In this document, we propose a configuration-free mechanism, in which 22 packets will be routed towards the corresponding upstream ISPs based 23 on both destination and source addresses. 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 January 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Egress Router Behavior . . . . . . . . . . . . . . . . . 5 76 4.2. Interior Router Behavior . . . . . . . . . . . . . . . . 5 77 5. TC-LSA Format . . . . . . . . . . . . . . . . . . . . . . . . 5 78 6. Routing Table Structure . . . . . . . . . . . . . . . . . . . 7 79 7. Calculation of the Routing Table . . . . . . . . . . . . . . 8 80 8. Matching Rule . . . . . . . . . . . . . . . . . . . . . . . . 8 81 9. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 12.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 Home networks are growing both in device count and in complexity. 92 Today they generally contain both wired and wireless components, and 93 may require routing to place audio/visual entertainment traffic one 94 one path, office services on another, and wireless LANs (both IEEE- 95 style and 4G/LTE-style) on a third. Traditionally, we have 96 simplified networks using a single exit router and a default route. 98 Today, we might have multiple routers to wired upstream networks, and 99 by separate paths LTE services, "Smart Grid" services, or health 100 network services. Increasingly, such networks are multihomed, and 101 multihomed using diverse access network technologies. 103 Traditionally, routing protocols make routing decisions solely based 104 on destination IP addresses, packets towards the same destination 105 will be delivered to the same next hop no matter where they come 106 from. These protocols work well with simple home networks that have 107 only one egress router. However, in the multi-homing scenario, 108 packets may be dropped if forwarded only based on destination 109 addresses [RFC3704]. 111 Although many patch-like solutions, like policy-based routing (PBR), 112 multi-topology routing (MTR) and layer-3 VPN can solve the problem, 113 they complex the configurations in home networks, and are not 114 suitable for home IT staffs. We need a configuration-free solution 115 to help operators set up their home networks in the multi-homing 116 scenario. 118 In this document, we propose a configuration-free mechanism - traffic 119 class routing, based on OSPFv3, such that home networks can route 120 packets towards the corresponding upstream ISPs, according to both 121 destination and source addresses. 123 2. Terminology 125 Terminology used in this document: 127 o Traffic Class (TC): Identified by (destination prefix, source 128 prefix), all packets falling in the domain belong to the traffic 129 class. 131 o TC-Route: Identified by (destination prefix, source prefix, 132 value), where value is the administrative value applied to the 133 traffic class (destination prefix, source prefix). 135 o TC-LSA: Link state advertisement that communicates the 136 reachability for a traffic classes. 138 3. Overview 140 In a home network, traditionally, egress routers obtain delegated 141 prefixes from upstream ISPs using DHCPv6 with prefix options 142 [RFC3633]. The egress routers will then assign longer sub-prefixes 143 to the other links in the home network. Each router inside the home 144 network will act as standard OSPFv3 router, and forward packets based 145 on their destination addresses. 147 With traffic class routing, after obtaining delegated prefixes and 148 assigning sub-prefixes, egress routers will populate traffic classes 149 (with extended LSAs), rather than destination address only, into the 150 home network. Each router inside the home network will flood these 151 traffic classes information. When calculating the path towards a 152 destination address, routers will take the traffic classes into 153 considerations. Intrinsically, in traditional routing model, the 154 object being routed to is a destination prefix; in our routing model, 155 the object being routed might be a destination prefix given that the 156 packet sports a certain source prefix. 158 Each traffic class is associated with a cost, which is a single 159 dimensionless metric. 161 For example, a site is connected to the Internet through two ISPs, 162 ISP1 and ISP2. ISP1 delegates prefix P1 to the site, and ISP2 163 delegates prefix P2 to the site. After being delegated with P1, the 164 egress router E1 of the site will advertise a traffic class - {::/0, 165 P1}, into the site. After being delegated with P2, the egress router 166 E2 of the site will advertise a traffic class - {::/0, P2}, into the 167 site. Receiving these advertisements, interior router I1 will 168 compute two paths towards ::/0, one through router E1 for traffic 169 from P1, the other through E2 for traffic from P2. 171 +---------------+ +-----------------+ 172 | | | | 173 | ISP1: P1 | | ISP2: P2 | 174 | | | | 175 +--------+------+ +-----+-----------+ 176 | | 177 +--+---+ +--+---+ 178 |Router| |Router| 179 | BR1 | | BR2 | 180 +---+--+ +---+--+ 181 ------+---------- -----------+----- 182 | | 183 +---+--+ +---+--+ 184 |Router| |Router| 185 | E1 | | E2 | 186 +------+ +------+ +------+ 187 -+-------+Router+---------+- 188 | I1 | 189 +--+---+ 190 +--+---+ Address A in P1 191 | Host | 192 +------+ Address B in P2 194 Figure 1: Multi-homing Scenario in Home Networks 196 4. Router Behavior 198 All routers behave like traditional OSPFv3 routers, however, the 199 following behaviors are different with traditional OSPFv3 routers. 201 4.1. Egress Router Behavior 203 After obtaining delegated prefixes using DHCPv6 with prefix options, 204 an egress router should originate TC-LSAs, i.e., extended LSAs with 205 source prefixes appended. Egress routers then will advertise these 206 TC-LSAs into the home network. 208 Note that an egress router behaves like an interior router if it 209 receives a TC-LSA from other egress routers. 211 4.2. Interior Router Behavior 213 Receiving TC-LSAs from egress routers, an interior router should 214 store the TC-LSAs into its LSDB, and flood it to other routers. 215 After calculating a path to an egress router advertising 216 reachability, i.e., a destination prefix, the interior router should 217 decide which traffic class can follow this path towards the egress 218 router. If a traffic class can travel through two different paths, 219 then interior router should compare their costs, and select the path 220 with the lowest cost. 222 Interior routers contains a routing table that contains all necessary 223 information to forward an IP packet following the path of a traffic 224 class. After computing the path towards a traffic class, interior 225 routers should update the entry in the routing table if necessary, 226 e.g., change the next hop towards the traffic class. The routing 227 table structure will be described in Section 6. Calculation of 228 routing table will be illustrated in Section 7. 230 At last, interior routers should update the Forwarding Information 231 Base (FIB), which will be discussed in the next version of this 232 document. 234 5. TC-LSA Format 236 TC-LSA adds TLV extensions, which contains source prefix information, 237 based on original OSPFv3 LSA. We follow the TLV format in 238 [I-D.baker-ipv6-ospf-dst-src-routing] and extended LSA format in 239 [I-D.acee-ospfv3-lsa-extend]. 241 Each extended LSA includes the traditional LSA part in [RFC5340], and 242 one or more TLVs defined in [I-D.baker-ipv6-ospf-dst-src-routing]. 243 But we do not need all LSAs to be extended, the LSAs need to be 244 extended are as follows: 246 o Intra-Area-Prefix-LSA: The extended LSA has type 0x2029. 248 The extended LSA format for Intra-Area-Prefix-LSA in multi-homing is 249 as follows: 251 0 1 2 3 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | LS Age |0|0|1| LSA Type | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Link State ID | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Advertising Router | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | LS Sequence Number | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | LS Checksum | LSA Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | # Prefixes | Referenced LS Type | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Referenced Link State ID | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Referenced Advertising Router | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | PrefixLength | PrefixOptions | Metric | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Address Prefix | 273 | ... | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | ... | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | PrefixLength | PrefixOptions | Metric | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Address Prefix | 280 | ... | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | TLV Type | TLV Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | SPrefixLength | SPrefixOptions| 0 | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Source Address Prefix | 287 | ... | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | ... | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | TLV Type | TLV Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | SPrefixLength | SPrefixOptions| 0 | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Source Address Prefix | 296 | ... | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 1: Multi-homing Scenario in Home Networks 301 All LSA header fields are the same as defined in [RFC5340], except 302 the following: 304 o LSA type: The LSA type value is 0x2029, according to 305 [I-D.acee-ospfv3-lsa-extend]; 307 o LSA length: The length of the whole LSA header, including the 308 TLVs; 310 o TLV type: The type of IPv6 source prefix TLV, assigned by IANA; 312 o TLV length: The value is 20 as defined in 313 [I-D.baker-ipv6-ospf-dst-src-routing]; 315 o SPrefixLength, SPrefixOptions, Source Address Prefix: 316 Representation of the IPv6 address prefix, which is delegated from 317 the upstream ISP providers; 319 In the extended LSA, suppose there are n destination prefix d1, d2, 320 ..., dn, and m source prefix s1, s2, ..., sm, then the LSA carries 321 n*m TC-route announcement, (d1, s1, v1), (d1, s2, v1), ..., (d1, sm, 322 v1), (d2, s1, v2), (d2, s2, v2), ..., (dn, sm, vn), where vi is the 323 metric associated with destination prefix di. 325 6. Routing Table Structure 327 For traditional routing, the routing table structure contains all 328 needed information to forward IP packets to the right destination. 329 For example, destination prefixes are commonly structured into a 330 prefix trie, where each trie nodes contain the necessary information. 331 Routers can lookup and update the prefix trie. 333 With traffic classes, the routing table structure must contain all 334 needed information to forward IP packets following the right traffic 335 class, i.e., towards the related destination and from the related 336 source. For each routing table entry, there are two additional 337 fields other than the fields mentioned in [RFC5340]: 339 o Source IP Address: The IP address of the source in traffic class. 341 o Source Address Mask: If the source is a subnet, then it is 342 referred to as the subnet mask. 344 The routing table must provide interface for update and lookup in it. 345 For example, traffic classes can be structured into a two dimensional 346 (or two level) trie, where each trie node in the first dimension 347 points to a sub-trie in the second dimension. The trie nodes in the 348 second dimension contain the necessary information to forward IP 349 packets following the right traffic class. 351 7. Calculation of the Routing Table 353 The fundamental algorithm in OSPFv3 doesn't change. The algorithm 354 uses the SPF approach to calculate a path to the router advertising 355 reachability, and then uses the reachability advertisement to decide 356 what traffic should follow that route. What we are changing is the 357 reachability advertisement, in traiditional OSPFv3, the 358 advertisements, which is one or several kinds of LSAs, represent 359 destination prefixes; in this document, the advertisements, which is 360 one or several kinds of TC-LSAs, represent traffic classes. 362 Note that we do not have to change router-LSA and network-LSA in 363 [RFC5340]. Thus, the first stage of Section 4.8.1 in [RFC5340] 364 remains the same in this document. However, the second stage of 365 Section 4.8.1 in [RFC5340] should change by a little bit. Instead of 366 examining the list of the intra-area-prefix-LSAs, the list of 367 extended intra-area-prefix-LSAs is examined. The cost of any 368 advertised traffic class is the sum of the class' advertised metric 369 plus the cost of the transit vertex (either router or transit 370 network) indentified by extended intra-area-prefix-LSAs' referenced 371 LS type, referenced link state ID, and referenced advertising router 372 field. 374 8. Matching Rule 376 We also adopt the LMF (longest match first) rule when a packet 377 matches multiple routing entries. However, traffic class has two 378 dimensions, there might exist ambiguity. For example, if there 379 exists two routing entries, (d1, s1, nexthop1), (d2, s2, nexthop2), 380 where d1 is longer than d2 and s2 is longer than s1, then none entry 381 is longer than the other in both dimensions. In this situation, we 382 must insert an additional entry into the routing table, e.g., (d1, 383 s2, nexthop1) in the above example. The entry directs to nexthop1 384 rather than nexthop2, because we must guarantee reachability 385 according to the destination prefix. 387 9. Compatibility 389 Routers can also announce the traditional destination-based LSAs at 390 the same time. In this case, routers have to keep two routing 391 tables, one for destination prefix only, and the other for traffic 392 classes. When a packet arrives, routers first lookup in the routing 393 table storing traffic classes; If none entry matches, then routers 394 lookup in the routing table storing destination prefixes. 396 10. IANA Considerations 398 The newly LSA types and TLVs should be assigned by IANA, please refer 399 to [I-D.baker-ipv6-ospf-dst-src-routing] and 400 [I-D.acee-ospfv3-lsa-extend]. 402 11. Acknowledgments 404 Zheng Liu and Gautier Bayzelon provided useful input into this 405 document. 407 12. References 409 12.1. Normative References 411 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 412 Networks", BCP 84, RFC 3704, March 2004. 414 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 415 Host Configuration Protocol (DHCP) version 6", RFC 3633, 416 December 2003. 418 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 419 for IPv6", RFC 5340, July 2008. 421 12.2. Informative References 423 [I-D.ietf-homenet-arch] 424 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 425 "Home Networking Architecture for IPv6", draft-ietf- 426 homenet-arch-07 (work in progress), February 2013. 428 [I-D.baker-ipv6-ospf-dst-src-routing] 429 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 430 draft-baker-ipv6-ospf-dst-src-routing-02 (work in 431 progress), May 2013. 433 [I-D.acee-ospfv3-lsa-extend] 434 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 435 LSA Extendibility", draft-acee-ospfv3-lsa-extend-00 (work 436 in progress), May 2013. 438 [I-D.baker-fun-routing-class] 439 Baker, F., "Routing a Traffic Class", draft-baker-fun- 440 routing-class-00 (work in progress), July 2011. 442 Authors' Addresses 444 Mingwei Xu 445 Tsinghua University 446 Department of Computer Science, Tsinghua University 447 Beijing 100084 448 P.R. China 450 Phone: +86-10-6278-5822 451 Email: xmw@csnet1.cs.tsinghua.edu.cn 453 Shu Yang 454 Tsinghua University 455 Department of Computer Science, Tsinghua University 456 Beijing 100084 457 P.R. China 459 Phone: +86-10-6278-5822 460 Email: yangshu@csnet1.cs.tsinghua.edu.cn 462 Jianping Wu 463 Tsinghua University 464 Department of Computer Science, Tsinghua University 465 Beijing 100084 466 P.R. China 468 Phone: +86-10-6278-5983 469 Email: jianping@cernet.edu.cn 470 Fred Baker 471 Cisco Systems 472 Santa Barbara, California 93117 473 USA 475 Email: fred@cisco.com