1 00:00:00,000 --> 00:00:02,490 The following content is provided under a Creative 2 00:00:02,490 --> 00:00:04,059 Commons license. 3 00:00:04,059 --> 00:00:06,360 Your support will help MIT OpenCourseWare 4 00:00:06,360 --> 00:00:10,720 continue to offer high quality educational resources for free. 5 00:00:10,720 --> 00:00:13,350 To make a donation or view additional materials 6 00:00:13,350 --> 00:00:17,290 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,290 --> 00:00:18,294 at ocw.mit.edu. 8 00:00:25,723 --> 00:00:28,140 PROFESSOR: So we're going to talk about routing protocols. 9 00:00:28,140 --> 00:00:32,130 And today we're going to talk about how routing protocols 10 00:00:32,130 --> 00:00:33,422 handle failures. 11 00:00:33,422 --> 00:00:34,130 So I'm going to-- 12 00:00:34,130 --> 00:00:37,770 I want to bring everybody back onto the same page with respect 13 00:00:37,770 --> 00:00:39,900 to where we are in the story. 14 00:00:39,900 --> 00:00:45,930 So in terms of routing protocols, 15 00:00:45,930 --> 00:00:58,290 if you imagine a network topology like this, and let's 16 00:00:58,290 --> 00:01:00,322 say that links have costs associated with them. 17 00:01:00,322 --> 00:01:02,280 So I'm just going to make up some numbers here. 18 00:01:11,040 --> 00:01:13,020 We studied two classes of routing protocols. 19 00:01:13,020 --> 00:01:17,040 And we looked at these in the absence of any failures. 20 00:01:17,040 --> 00:01:20,280 The first is the distance vector protocol, or more generally, 21 00:01:20,280 --> 00:01:24,330 vector protocols where, in an advertisement sent 22 00:01:24,330 --> 00:01:27,390 from one node to another, each node sends 23 00:01:27,390 --> 00:01:28,990 a subset of its routing table. 24 00:01:28,990 --> 00:01:32,550 In other words, it sends two columns from its routing table. 25 00:01:32,550 --> 00:01:34,560 Recall that the routing table at every node 26 00:01:34,560 --> 00:01:40,740 contains a destination, a route, which 27 00:01:40,740 --> 00:01:45,420 is a link, the name of the link, and a cost. 28 00:01:45,420 --> 00:01:47,790 And in a distance vector protocol, 29 00:01:47,790 --> 00:01:51,210 you send these two columns. 30 00:01:51,210 --> 00:01:54,270 You send these tuples for all of the destinations that you know. 31 00:01:54,270 --> 00:01:57,480 And that's what's spread out to all of the other nodes. 32 00:01:57,480 --> 00:02:01,380 In contrast-- so this is distance vector. 33 00:02:01,380 --> 00:02:05,610 In contrast, in a link state protocol, 34 00:02:05,610 --> 00:02:07,560 what you're sending to all of the other nodes 35 00:02:07,560 --> 00:02:10,710 is information about all of the links that you have. 36 00:02:10,710 --> 00:02:12,450 And in particular, you send information 37 00:02:12,450 --> 00:02:21,150 about the neighbor in your topology 38 00:02:21,150 --> 00:02:25,650 together with the link cost to that neighbor, 39 00:02:25,650 --> 00:02:30,180 whereas here it's the cost of the route to the destination 40 00:02:30,180 --> 00:02:30,780 that you send. 41 00:02:34,250 --> 00:02:36,980 In the distance vector protocol, the computation of the routes 42 00:02:36,980 --> 00:02:37,890 is distributed. 43 00:02:37,890 --> 00:02:40,640 So every node kind of computes and updates 44 00:02:40,640 --> 00:02:44,810 its routing table using the Bellman-Ford update step, which 45 00:02:44,810 --> 00:02:47,420 essentially updates the route to a destination 46 00:02:47,420 --> 00:02:49,730 if you find a better route to the destination. 47 00:02:49,730 --> 00:02:52,450 Or if you find that the route to the destination has-- 48 00:02:52,450 --> 00:02:54,530 that you currently have "has a changed cost," 49 00:02:54,530 --> 00:02:57,340 in which case, you update your routing table. 50 00:02:57,340 --> 00:03:00,253 In a link state protocol, the computation is not distributed. 51 00:03:00,253 --> 00:03:01,670 What is distributed is the process 52 00:03:01,670 --> 00:03:06,410 of flooding this information of the local links. 53 00:03:06,410 --> 00:03:08,840 That's why it's called a link state protocol. 54 00:03:08,840 --> 00:03:11,170 And the computation of the routes themselves 55 00:03:11,170 --> 00:03:11,840 are centralized. 56 00:03:11,840 --> 00:03:15,020 Each node just runs a shortest path computation-- 57 00:03:15,020 --> 00:03:18,530 for example, Dijkstra's shortest path computation. 58 00:03:18,530 --> 00:03:21,290 And in a link state protocol, as long as all of the nodes run 59 00:03:21,290 --> 00:03:23,730 exactly the same computation-- in other words, 60 00:03:23,730 --> 00:03:27,440 they all try to minimize or optimize the same metric-- 61 00:03:27,440 --> 00:03:29,420 then you're guaranteed that all of the nodes 62 00:03:29,420 --> 00:03:31,523 end up computing the correct routes, 63 00:03:31,523 --> 00:03:33,440 and that when you send a packet from one node, 64 00:03:33,440 --> 00:03:35,480 it will reach the destination, assuming 65 00:03:35,480 --> 00:03:37,820 there's a path in the network. 66 00:03:37,820 --> 00:03:39,747 And in the problem set-- 67 00:03:39,747 --> 00:03:40,830 maybe not in the problems. 68 00:03:40,830 --> 00:03:42,620 Certainly at the back of the chapter, 69 00:03:42,620 --> 00:03:44,810 there are problems on what happens 70 00:03:44,810 --> 00:03:47,630 if some nodes run one protocol and another node 71 00:03:47,630 --> 00:03:48,630 runs another protocol. 72 00:03:48,630 --> 00:03:51,260 For example, you might have-- imagine a routing protocol 73 00:03:51,260 --> 00:03:54,320 where one of the nodes is doing minimum cost routes and another 74 00:03:54,320 --> 00:03:56,000 node is doing shortest paths-- 75 00:03:56,000 --> 00:03:58,280 in terms of the number of hops, not costs. 76 00:03:58,280 --> 00:04:00,530 And if you have that, you might end up in a situation 77 00:04:00,530 --> 00:04:04,243 where, in fact, the routing doesn't work correctly. 78 00:04:04,243 --> 00:04:05,660 But assuming that all of the nodes 79 00:04:05,660 --> 00:04:08,530 are on the same optimization in a link state protocol, 80 00:04:08,530 --> 00:04:10,340 they'll all get the correct answer. 81 00:04:10,340 --> 00:04:12,230 And similarly, in a distance vector protocol, 82 00:04:12,230 --> 00:04:14,210 actually the update rule can do anything, 83 00:04:14,210 --> 00:04:16,519 as long as the nodes believe that this route-- 84 00:04:16,519 --> 00:04:19,339 and they perform some sort of an update to the routing table 85 00:04:19,339 --> 00:04:22,610 entry consistent with the information that they hear, 86 00:04:22,610 --> 00:04:24,640 then the routing will work. 87 00:04:24,640 --> 00:04:26,390 Now, what happens when there are failures? 88 00:04:26,390 --> 00:04:27,840 And how does it work? 89 00:04:27,840 --> 00:04:31,380 So let's say that you run this protocol and this topology. 90 00:04:31,380 --> 00:04:32,990 And you give it enough time. 91 00:04:32,990 --> 00:04:35,420 Once you hear all of the advertisements 92 00:04:35,420 --> 00:04:37,790 and compute the routes of the different nodes, 93 00:04:37,790 --> 00:04:42,110 if you look at this node over here, 94 00:04:42,110 --> 00:04:45,410 C four destination D would have a route-- 95 00:04:45,410 --> 00:04:48,910 let's call this link L0. 96 00:04:48,910 --> 00:04:50,210 It will have a route, L0. 97 00:04:50,210 --> 00:04:53,270 And the cost of that route would be three. 98 00:04:53,270 --> 00:04:57,800 And similarly at B here, once it converges you'd have-- 99 00:04:57,800 --> 00:05:00,920 for destination D, let's imagine this link is called L0, 100 00:05:00,920 --> 00:05:04,670 as well, at node B. You might have L0 101 00:05:04,670 --> 00:05:11,560 and the cost would be four, and similarly at the other nodes. 102 00:05:11,560 --> 00:05:14,810 Now, let's say what happens is that some sort of a failure 103 00:05:14,810 --> 00:05:15,620 occurs. 104 00:05:15,620 --> 00:05:17,480 And failures could be one of-- 105 00:05:17,480 --> 00:05:21,950 a variety of failures could occur that cause the routing 106 00:05:21,950 --> 00:05:23,030 to get screwed up. 107 00:05:23,030 --> 00:05:25,280 So one of the failures-- the easiest form of failure-- 108 00:05:25,280 --> 00:05:26,990 is that a packet could be lost. 109 00:05:26,990 --> 00:05:29,000 In particular, an advertisement could be lost. 110 00:05:40,633 --> 00:05:42,050 The second thing that could happen 111 00:05:42,050 --> 00:05:43,370 is that a link could fail. 112 00:05:47,020 --> 00:05:48,710 I mean, if it's a wire, maybe a backhoe 113 00:05:48,710 --> 00:05:51,950 runs over it, which is actually more common than you think. 114 00:05:51,950 --> 00:05:55,250 In fact, you could have undersea cables 115 00:05:55,250 --> 00:05:58,130 where sharks bite them and they get destroyed. 116 00:05:58,130 --> 00:06:00,477 I mean, lots of things could happen. 117 00:06:00,477 --> 00:06:01,310 So links could fail. 118 00:06:01,310 --> 00:06:03,040 And the third thing that could happen, 119 00:06:03,040 --> 00:06:04,790 which is more common than you might think, 120 00:06:04,790 --> 00:06:07,550 is that entire switches could fail or nodes could fail. 121 00:06:13,820 --> 00:06:16,700 Since we actually don't know how to write bug-free software, 122 00:06:16,700 --> 00:06:18,470 software bugs may cause things to fail. 123 00:06:18,470 --> 00:06:19,920 They may cause things to crash. 124 00:06:19,920 --> 00:06:22,400 In fact, they may cause things to fail in mysterious ways 125 00:06:22,400 --> 00:06:25,890 where it looks like it's not failed, 126 00:06:25,890 --> 00:06:28,640 but in fact, there's a fault in the software causing 127 00:06:28,640 --> 00:06:30,800 you to send bad advertisements. 128 00:06:30,800 --> 00:06:32,780 And for this course, we won't worry about this. 129 00:06:32,780 --> 00:06:35,300 We'll actually worry about only a class of failures 130 00:06:35,300 --> 00:06:37,360 that we think of as fail stop. 131 00:06:40,202 --> 00:06:41,660 What I mean by that is if it fails, 132 00:06:41,660 --> 00:06:44,565 it just stops, as opposed to it fails and then it gives you 133 00:06:44,565 --> 00:06:46,940 wrong information, which is actually a lot harder to deal 134 00:06:46,940 --> 00:06:48,980 with, because it's much better for you 135 00:06:48,980 --> 00:06:51,350 to fail and just stop rather than for the node 136 00:06:51,350 --> 00:06:53,450 to fail and pretend that it's correct and send you 137 00:06:53,450 --> 00:06:54,290 bad information. 138 00:06:54,290 --> 00:06:56,120 That's a lot harder to deal with. 139 00:06:56,120 --> 00:07:00,020 We'll worry about that later, not in 6.02. 140 00:07:00,020 --> 00:07:01,530 Anyway, these things could happen. 141 00:07:01,530 --> 00:07:04,050 So let's concretely assume that you have this topology here. 142 00:07:04,050 --> 00:07:07,430 And what happens is this link fails. 143 00:07:11,810 --> 00:07:15,060 Now, if you did nothing and you had that link fail, 144 00:07:15,060 --> 00:07:17,660 what would happen? 145 00:07:17,660 --> 00:07:20,570 Now, let's look at it node by node. 146 00:07:20,570 --> 00:07:24,410 What would happen here is that C would end up 147 00:07:24,410 --> 00:07:28,162 with no route to the destination, because what 148 00:07:28,162 --> 00:07:30,620 would happen is assuming that C has some way of discovering 149 00:07:30,620 --> 00:07:32,960 that this fault has happened, it would have 150 00:07:32,960 --> 00:07:34,170 no route to the destination. 151 00:07:34,170 --> 00:07:36,650 But if it doesn't discover the fault had happened, 152 00:07:36,650 --> 00:07:38,280 it has this route to the destination. 153 00:07:38,280 --> 00:07:39,990 But if it sends packets on that link, 154 00:07:39,990 --> 00:07:41,780 it wouldn't reach the other side. 155 00:07:41,780 --> 00:07:42,722 Packets would be lost. 156 00:07:42,722 --> 00:07:44,180 But assuming that it discovers, has 157 00:07:44,180 --> 00:07:46,460 a way of discovering that this link has failed, 158 00:07:46,460 --> 00:07:49,170 it has no route to the destination. 159 00:07:49,170 --> 00:07:51,230 Now, B has a route to the destination. 160 00:07:51,230 --> 00:07:52,940 It has this link. 161 00:07:52,940 --> 00:07:58,150 But in fact, the next advertisement from C, 162 00:07:58,150 --> 00:07:59,820 if C were to make another advertisement, 163 00:07:59,820 --> 00:08:02,070 would tell it that it had no route to the destination. 164 00:08:02,070 --> 00:08:04,400 But if it did nothing, if you did nothing in the protocol, 165 00:08:04,400 --> 00:08:06,200 B thinks it has a route to the destination. 166 00:08:06,200 --> 00:08:09,313 But in fact, it reaches C and it's actually a dead end 167 00:08:09,313 --> 00:08:10,730 because it reaches C and C doesn't 168 00:08:10,730 --> 00:08:11,730 know what to do with it. 169 00:08:11,730 --> 00:08:13,670 It just drops the packet. 170 00:08:13,670 --> 00:08:16,660 The technical term for this is a dead end. 171 00:08:16,660 --> 00:08:17,540 You send packets. 172 00:08:17,540 --> 00:08:19,290 You think you're reaching the destination. 173 00:08:19,290 --> 00:08:21,880 But it's actually getting dropped. 174 00:08:21,880 --> 00:08:22,435 What about S? 175 00:08:22,435 --> 00:08:24,060 Does S have a route to the destination? 176 00:08:24,060 --> 00:08:27,420 Well, S doesn't have a route to the destination, either, 177 00:08:27,420 --> 00:08:29,170 because the right route to the destination 178 00:08:29,170 --> 00:08:35,720 would probably have been this link over here 179 00:08:35,720 --> 00:08:37,567 because the cost was 2 plus 1 plus 3. 180 00:08:37,567 --> 00:08:39,650 And that wouldn't have a route to the destination. 181 00:08:39,650 --> 00:08:41,150 It would have a route, but the route 182 00:08:41,150 --> 00:08:43,200 would lead to a dead end at C. And in fact, 183 00:08:43,200 --> 00:08:45,350 in this particular example, no node 184 00:08:45,350 --> 00:08:47,870 would have a route to the destination in terms 185 00:08:47,870 --> 00:08:50,300 of the routing table itself. 186 00:08:50,300 --> 00:08:52,640 No node would have a route that actually worked, 187 00:08:52,640 --> 00:08:54,710 in that the route wouldn't correspond 188 00:08:54,710 --> 00:08:56,705 to an actual working path. 189 00:08:56,705 --> 00:08:58,580 But if you look at the picture, clearly there 190 00:08:58,580 --> 00:09:00,288 are other ways to get to the destination. 191 00:09:00,288 --> 00:09:02,450 I mean, we designed this topology presumably 192 00:09:02,450 --> 00:09:04,650 because we had some sort of redundancy. 193 00:09:04,650 --> 00:09:07,730 So if this failed, what you would like to have 194 00:09:07,730 --> 00:09:09,740 is for C to use one of the other paths. 195 00:09:09,740 --> 00:09:13,570 C might use this path or C might use this path. 196 00:09:13,570 --> 00:09:15,738 Or C might-- yeah, those are the two possible paths 197 00:09:15,738 --> 00:09:16,280 it could use. 198 00:09:16,280 --> 00:09:18,830 And similarly, S might use-- 199 00:09:18,830 --> 00:09:21,480 should use that path, and so forth. 200 00:09:21,480 --> 00:09:23,330 So what you want is a routing protocol 201 00:09:23,330 --> 00:09:27,210 that converges to the new correct answer, 202 00:09:27,210 --> 00:09:28,958 assuming there is a new correct answer. 203 00:09:28,958 --> 00:09:30,500 And if there's no new correct answer, 204 00:09:30,500 --> 00:09:33,930 it converges to whatever the best possible answer is. 205 00:09:33,930 --> 00:09:36,110 So to some destinations, you could have a route, 206 00:09:36,110 --> 00:09:38,310 and to some destinations, you don't have a route. 207 00:09:38,310 --> 00:09:42,410 So what you want is, as long as there is a connected path, 208 00:09:42,410 --> 00:09:45,230 there is a path between a source and a destination, 209 00:09:45,230 --> 00:09:47,300 you would like that source to end up 210 00:09:47,300 --> 00:09:51,110 with a route that corresponds to some good working path, 211 00:09:51,110 --> 00:09:54,170 and in particular, converges to the new minimum 212 00:09:54,170 --> 00:09:57,540 cost working path between the source and the destination. 213 00:09:57,540 --> 00:10:00,620 So that's the statement of the problem. 214 00:10:00,620 --> 00:10:04,670 And we're going to solve that problem today for both distance 215 00:10:04,670 --> 00:10:05,937 vector and link scale. 216 00:10:05,937 --> 00:10:07,520 And interestingly, the idea that we're 217 00:10:07,520 --> 00:10:11,410 going to use the same idea in both cases. 218 00:10:11,410 --> 00:10:14,390 And the idea is, just like we built a redundant topology 219 00:10:14,390 --> 00:10:17,540 by having alternate paths between places, 220 00:10:17,540 --> 00:10:20,510 we're just going to repeat advertisements. 221 00:10:20,510 --> 00:10:23,030 And we're going to repeat the process of processing 222 00:10:23,030 --> 00:10:24,890 these advertisements. 223 00:10:24,890 --> 00:10:26,600 It's a very simple idea. 224 00:10:26,600 --> 00:10:29,870 And the general plan-- there are three steps to the plan. 225 00:10:29,870 --> 00:10:33,740 The first step in the plan is to periodically check-- 226 00:10:33,740 --> 00:10:36,170 every neighbor is responsible for checking 227 00:10:36,170 --> 00:10:38,900 the health of-- every node is responsible for checking 228 00:10:38,900 --> 00:10:41,390 the health of its neighbors. 229 00:10:41,390 --> 00:10:43,430 So that's the step, which we're going 230 00:10:43,430 --> 00:10:45,080 to call neighbor aliveness. 231 00:10:50,780 --> 00:10:53,350 And the protocol we're going to use for that 232 00:10:53,350 --> 00:10:56,273 is called the hello protocol. 233 00:10:56,273 --> 00:10:57,690 It's a very, very simple protocol. 234 00:10:57,690 --> 00:11:00,250 I'll describe it in a moment. 235 00:11:00,250 --> 00:11:02,400 And we're going to use this idea that every node is 236 00:11:02,400 --> 00:11:06,460 responsible for checking whether each of its neighbors is alive. 237 00:11:06,460 --> 00:11:10,200 And if it determines that a neighbor is not alive, 238 00:11:10,200 --> 00:11:14,010 it assumes the neighbor is dead and removes 239 00:11:14,010 --> 00:11:16,860 it from various tables and data structures and so on. 240 00:11:16,860 --> 00:11:18,450 And in fact, this fail stop assumption 241 00:11:18,450 --> 00:11:20,575 is pretty crucial for us, because the assumption is 242 00:11:20,575 --> 00:11:23,400 that when a failure occurs of a node, that in fact, 243 00:11:23,400 --> 00:11:25,100 the node doesn't respond. 244 00:11:25,100 --> 00:11:27,600 If a failure occurs of a link, the assumption here, as well, 245 00:11:27,600 --> 00:11:29,430 is that the link stops responding. 246 00:11:29,430 --> 00:11:32,652 You don't get to send packets or receive packets over that link. 247 00:11:32,652 --> 00:11:34,860 And for now, we're going to assume that every link is 248 00:11:34,860 --> 00:11:35,590 bidirectional. 249 00:11:35,590 --> 00:11:38,250 So you send packets in both directions. 250 00:11:38,250 --> 00:11:41,400 In reality, there are unidirectional network links. 251 00:11:41,400 --> 00:11:43,680 And you have to deal with the problem differently. 252 00:11:43,680 --> 00:11:46,100 Not going to worry about that. 253 00:11:46,100 --> 00:11:48,420 So there is a protocol called the hello protocol 254 00:11:48,420 --> 00:11:53,340 that runs to detect if your neighbor is alive or not. 255 00:11:53,340 --> 00:11:57,550 The second step in our answer is to make the advertisements 256 00:11:57,550 --> 00:11:58,050 periodic. 257 00:12:05,020 --> 00:12:07,680 And the third step is, what do you 258 00:12:07,680 --> 00:12:09,390 do when you receive an advertisement? 259 00:12:09,390 --> 00:12:10,958 When you receive an advertisement, 260 00:12:10,958 --> 00:12:12,750 you collect a bunch of these advertisements 261 00:12:12,750 --> 00:12:15,230 that you receive from various neighbors. 262 00:12:15,230 --> 00:12:17,430 In the link state protocol, it's these link state 263 00:12:17,430 --> 00:12:18,110 advertisements. 264 00:12:18,110 --> 00:12:21,010 In the distance vector protocol, it's these distance vector 265 00:12:21,010 --> 00:12:23,070 tuple advertisements. 266 00:12:23,070 --> 00:12:25,840 And then you run a periodic integration process. 267 00:12:36,410 --> 00:12:43,210 So if you look at it with a timeline, 268 00:12:43,210 --> 00:12:46,210 every node asynchronously-- in other words, 269 00:12:46,210 --> 00:12:48,192 independent of the other nodes. 270 00:12:48,192 --> 00:12:49,900 You don't have to synchronize the clocks. 271 00:12:49,900 --> 00:12:52,060 Every node has its own clock. 272 00:12:52,060 --> 00:12:56,140 And every node does these two steps periodically. 273 00:12:56,140 --> 00:13:03,209 So from time to time, it sends an advertisement. 274 00:13:08,200 --> 00:13:09,700 It just says, in distance vector, 275 00:13:09,700 --> 00:13:12,850 just sends these two columns to its neighbors. 276 00:13:12,850 --> 00:13:14,590 In the link state advertisement, it just 277 00:13:14,590 --> 00:13:16,450 sends out its link state information, 278 00:13:16,450 --> 00:13:18,880 and the flooding process works. 279 00:13:18,880 --> 00:13:20,500 And then from time to time, there's 280 00:13:20,500 --> 00:13:22,720 this integration of these advertisements that happen. 281 00:13:31,170 --> 00:13:32,680 Et cetera. 282 00:13:32,680 --> 00:13:34,690 Now the beautiful part of these protocols 283 00:13:34,690 --> 00:13:36,643 is that I've shown this picture here 284 00:13:36,643 --> 00:13:38,560 with these integrations happening interspersed 285 00:13:38,560 --> 00:13:39,550 with the advertisements. 286 00:13:39,550 --> 00:13:41,300 That doesn't actually have to be the case. 287 00:13:41,300 --> 00:13:43,810 You could do them pretty much arbitrarily as long 288 00:13:43,810 --> 00:13:45,970 as you do them periodically. 289 00:13:45,970 --> 00:13:47,860 The beautiful part of these protocols 290 00:13:47,860 --> 00:13:50,800 is that every node asynchronously running 291 00:13:50,800 --> 00:13:52,960 these advertisement steps and these integration 292 00:13:52,960 --> 00:13:56,350 steps, as long as they do this periodically, 293 00:13:56,350 --> 00:13:58,810 in the end what you get as a property called 294 00:13:58,810 --> 00:14:01,012 eventual convergence. 295 00:14:12,840 --> 00:14:17,760 What that means is, assuming you have all sorts of failures 296 00:14:17,760 --> 00:14:20,430 and any pattern of packet losses, link failures, 297 00:14:20,430 --> 00:14:25,360 and switches, and then you freeze the system 298 00:14:25,360 --> 00:14:29,230 and assume that no more failures happen, then what 299 00:14:29,230 --> 00:14:35,095 eventual convergence means is that in some finite time, 300 00:14:35,095 --> 00:14:36,970 all of the nodes in the network will converge 301 00:14:36,970 --> 00:14:38,590 to correct routing state. 302 00:14:38,590 --> 00:14:41,050 That is, in these routing protocols, all of the nodes 303 00:14:41,050 --> 00:14:43,525 will end up with an answer that's consistent with what 304 00:14:43,525 --> 00:14:44,650 you are trying to optimize. 305 00:14:44,650 --> 00:14:49,810 For example, minimum cost paths to all the destinations. 306 00:14:49,810 --> 00:14:52,150 Now, proving that under an arbitrary model 307 00:14:52,150 --> 00:14:55,450 of when these advertisements and integration steps are all 308 00:14:55,450 --> 00:14:57,930 asynchronous and being done at random times 309 00:14:57,930 --> 00:14:59,170 is a little involved. 310 00:14:59,170 --> 00:15:01,750 And we're not going to attempt that in this course. 311 00:15:01,750 --> 00:15:03,370 The notes talk a little bit about how 312 00:15:03,370 --> 00:15:05,082 you get eventual convergence when 313 00:15:05,082 --> 00:15:06,790 you assume that all the nodes are running 314 00:15:06,790 --> 00:15:09,852 very periodic advertisement steps interspersed 315 00:15:09,852 --> 00:15:10,810 with integration steps. 316 00:15:10,810 --> 00:15:12,590 The proof is really not that important. 317 00:15:12,590 --> 00:15:15,090 What's more important is for you to understand the intention 318 00:15:15,090 --> 00:15:16,460 behind why it works. 319 00:15:16,460 --> 00:15:18,130 So I'll do that by some examples here. 320 00:15:21,065 --> 00:15:23,190 I have to also tell you what the Hello protocol is. 321 00:15:23,190 --> 00:15:23,948 I'll get to that. 322 00:15:23,948 --> 00:15:25,740 But for now, just assume it's a module that 323 00:15:25,740 --> 00:15:29,590 tells you if the neighbor is alive or not. 324 00:15:29,590 --> 00:15:31,360 So is this plan clear to everybody? 325 00:15:31,360 --> 00:15:33,500 It's just this same idea, except every node's 326 00:15:33,500 --> 00:15:34,500 doing this periodically. 327 00:15:34,500 --> 00:15:36,250 So in practice, you might do this every 30 328 00:15:36,250 --> 00:15:38,970 seconds or every three minutes or something like that. 329 00:15:38,970 --> 00:15:41,910 Of course, the longer the time between advertisements, 330 00:15:41,910 --> 00:15:44,460 the longer it's going to take for the protocol 331 00:15:44,460 --> 00:15:47,090 to converge after a failure or a set of failures. 332 00:15:47,090 --> 00:15:50,730 And the shorter the time, it takes a quicker amount of time 333 00:15:50,730 --> 00:15:51,240 to converge. 334 00:15:51,240 --> 00:15:55,100 But you end up doing a lot more work. 335 00:15:55,100 --> 00:15:58,830 And moreover, in practice, many failures are transient. 336 00:15:58,830 --> 00:16:02,440 So a link may fail for a few seconds and then come back up. 337 00:16:02,440 --> 00:16:05,740 And so it's in practice not that useful to converge very, 338 00:16:05,740 --> 00:16:08,438 very quickly or react very, very quickly. 339 00:16:08,438 --> 00:16:10,230 It's important to converge quickly once you 340 00:16:10,230 --> 00:16:11,500 start the convergence process. 341 00:16:11,500 --> 00:16:15,750 But once you-- detecting that a neighbor is alive or dead 342 00:16:15,750 --> 00:16:17,260 on the timescale of a few packets 343 00:16:17,260 --> 00:16:21,780 is sometimes too fast, because sometimes failures 344 00:16:21,780 --> 00:16:24,310 last for very little time and then they go away. 345 00:16:24,310 --> 00:16:25,740 And in the meantime, you have done all this work 346 00:16:25,740 --> 00:16:27,220 to converge to a new routing state. 347 00:16:27,220 --> 00:16:28,790 And then when the link comes back up, 348 00:16:28,790 --> 00:16:31,290 you're going to do more work to come back to the old answer. 349 00:16:31,290 --> 00:16:34,000 You may as well have just been a little lazy. 350 00:16:34,000 --> 00:16:36,690 And so deciding these times is tricky. 351 00:16:36,690 --> 00:16:40,830 And there's no real systematic way of doing it in practice. 352 00:16:40,830 --> 00:16:43,680 But the trade-off is usually between how quickly you 353 00:16:43,680 --> 00:16:45,780 wish to converge and how much work 354 00:16:45,780 --> 00:16:49,940 you're willing to expand in making that convergence happen. 355 00:16:49,940 --> 00:16:50,940 So is the plan clear? 356 00:16:50,940 --> 00:16:52,690 It's just this same protocol, except we're 357 00:16:52,690 --> 00:16:55,860 going to do this periodically. 358 00:16:55,860 --> 00:16:56,580 OK. 359 00:16:56,580 --> 00:16:58,780 So the first step is this enable liveness, 360 00:16:58,780 --> 00:17:00,990 or the hello protocol. 361 00:17:00,990 --> 00:17:03,030 So that protocol is actually very easy. 362 00:17:03,030 --> 00:17:08,760 Every node-- you have a set of links coming out of the node 363 00:17:08,760 --> 00:17:10,938 and then neighbors at the other end of it. 364 00:17:10,938 --> 00:17:12,480 So the problem is that the node needs 365 00:17:12,480 --> 00:17:16,940 to decide which of these links is working or not working 366 00:17:16,940 --> 00:17:20,560 and which of the neighbors are still there versus not there. 367 00:17:20,560 --> 00:17:22,560 And the way the protocol works is 368 00:17:22,560 --> 00:17:26,700 that every node in the system on each of its links-- 369 00:17:26,700 --> 00:17:28,405 let's call these nodes ABC. 370 00:17:32,360 --> 00:17:35,540 On each of these links sends out-- 371 00:17:35,540 --> 00:17:38,780 periodically sends out only to its neighbors 372 00:17:38,780 --> 00:17:41,810 a packet called a Hello packet. 373 00:17:41,810 --> 00:17:44,090 And the Hello packet usually has a sequence number 374 00:17:44,090 --> 00:17:48,260 on it, an incrementing sequence number. 375 00:17:48,260 --> 00:17:50,380 The idea is now very, very simple. 376 00:17:50,380 --> 00:17:54,490 This may be sent periodically, say, every 10 seconds. 377 00:17:54,490 --> 00:17:58,300 If n finds that a certain number of hello packets-- 378 00:17:58,300 --> 00:18:01,720 it hasn't heard from its neighbor, one of its neighbors, 379 00:18:01,720 --> 00:18:04,240 in some time-- that is, perhaps three hello packets are 380 00:18:04,240 --> 00:18:06,850 missing, or four hello packets are missing in a row-- 381 00:18:06,850 --> 00:18:10,860 it just decides that that neighbor is dead. 382 00:18:10,860 --> 00:18:12,160 It's a very simple idea. 383 00:18:12,160 --> 00:18:15,340 So you send out hello packets periodically 384 00:18:15,340 --> 00:18:25,540 and if k successive missing hello packets 385 00:18:25,540 --> 00:18:29,030 implies the neighbor from which those packets are missing 386 00:18:29,030 --> 00:18:29,530 is dead. 387 00:18:35,110 --> 00:18:36,790 Now, in response, what happens is 388 00:18:36,790 --> 00:18:42,610 that all of the routes that this node had that 389 00:18:42,610 --> 00:18:45,880 went via that neighbor, via that link, 390 00:18:45,880 --> 00:18:47,710 are eliminated from the routing table. 391 00:18:47,710 --> 00:18:50,350 And you could do that by either simply removing 392 00:18:50,350 --> 00:18:53,290 the entry from the routing table or by keeping 393 00:18:53,290 --> 00:18:55,450 the entry in the routing table but making-- 394 00:18:55,450 --> 00:18:57,640 for those destinations-- and replacing 395 00:18:57,640 --> 00:19:02,350 the cost from whatever the value was to infinity. 396 00:19:02,350 --> 00:19:06,970 And it's probably a better idea to replace it with infinity. 397 00:19:06,970 --> 00:19:08,080 I'm not exactly sure why. 398 00:19:08,080 --> 00:19:10,618 That's kind of what most people do. 399 00:19:10,618 --> 00:19:12,160 I think the reason is that you'd like 400 00:19:12,160 --> 00:19:14,500 to know that that destination exists in the network. 401 00:19:14,500 --> 00:19:16,750 And then when the later route arrives, you can fix it. 402 00:19:16,750 --> 00:19:20,420 But you could just remove it, as well. 403 00:19:20,420 --> 00:19:22,920 The other thing that happens is, if you were in a link state 404 00:19:22,920 --> 00:19:27,142 protocol, what you would then do is on the next advertisement 405 00:19:27,142 --> 00:19:28,600 of the link state, you would simply 406 00:19:28,600 --> 00:19:31,780 eliminate that link and that neighbor altogether. 407 00:19:31,780 --> 00:19:35,590 So you would not advertise this link and this neighbor 408 00:19:35,590 --> 00:19:37,360 as existing anymore. 409 00:19:37,360 --> 00:19:39,370 And when that link state advertisement floods 410 00:19:39,370 --> 00:19:41,910 through the network, all of the other nodes 411 00:19:41,910 --> 00:19:43,480 through the flooding process would 412 00:19:43,480 --> 00:19:46,030 determine that that node has gone away 413 00:19:46,030 --> 00:19:47,318 and that link has gone away. 414 00:19:47,318 --> 00:19:49,360 And then when they run Dijkstra's algorithm again 415 00:19:49,360 --> 00:19:51,992 and recompute the routes, they will no longer 416 00:19:51,992 --> 00:19:53,200 assume that that link exists. 417 00:19:53,200 --> 00:19:57,130 And they may find new routes to the destination. 418 00:19:57,130 --> 00:19:59,620 So that's what the hello protocol does. 419 00:19:59,620 --> 00:20:02,530 And so how you pick k, again, it's the same trade-off. 420 00:20:02,530 --> 00:20:05,050 It depends on how quickly you want 421 00:20:05,050 --> 00:20:08,050 to converge to a real failure. 422 00:20:08,050 --> 00:20:09,975 And picking this is difficult. For example, 423 00:20:09,975 --> 00:20:11,350 if you were on a wireless network 424 00:20:11,350 --> 00:20:14,440 where the normal packet loss probability might 425 00:20:14,440 --> 00:20:19,810 be 10%, something high, then waiting for a larger 426 00:20:19,810 --> 00:20:21,700 number of successive failed packets 427 00:20:21,700 --> 00:20:25,060 is a good idea, because just because a packet's lost 428 00:20:25,060 --> 00:20:27,465 or two packets are lost doesn't mean the link has failed. 429 00:20:27,465 --> 00:20:29,590 On the other hand, if you were running on a highly, 430 00:20:29,590 --> 00:20:32,440 highly reliable link in terms of packet loss-- like, 431 00:20:32,440 --> 00:20:35,200 you were running on some dedicated optical link where 432 00:20:35,200 --> 00:20:38,860 the packet loss rate is one part in a million-- 433 00:20:38,860 --> 00:20:42,070 then a single packet missing or two packets missing 434 00:20:42,070 --> 00:20:44,900 would be a good indication that that link has actually failed 435 00:20:44,900 --> 00:20:47,620 or that node at the other end of the link has failed, 436 00:20:47,620 --> 00:20:50,720 and therefore, k could be small. 437 00:20:50,720 --> 00:20:53,710 So again, it totally depends on the actual system context 438 00:20:53,710 --> 00:20:55,792 and the normal packet loss rates, 439 00:20:55,792 --> 00:20:57,250 because what you're trying to do is 440 00:20:57,250 --> 00:20:58,875 to make sure you react to real failure, 441 00:20:58,875 --> 00:21:01,205 not to simply packet loss. 442 00:21:01,205 --> 00:21:03,080 There's really no way to tell the difference. 443 00:21:03,080 --> 00:21:05,920 There's no way to tell the difference between a link that 444 00:21:05,920 --> 00:21:09,670 really has failed versus a link with a high packet loss rate. 445 00:21:09,670 --> 00:21:10,683 It's a heuristic. 446 00:21:10,683 --> 00:21:12,100 And in fact, there's really no way 447 00:21:12,100 --> 00:21:14,740 to tell between a node that has actually failed and gone away 448 00:21:14,740 --> 00:21:17,470 and a node that's just heavily overloaded 449 00:21:17,470 --> 00:21:19,810 and is extremely slow in responding. 450 00:21:19,810 --> 00:21:21,130 There's no way to tell. 451 00:21:21,130 --> 00:21:22,690 So these are all heuristics that you 452 00:21:22,690 --> 00:21:30,033 have to work with and try to solve the problem. 453 00:21:30,033 --> 00:21:31,450 So sometimes you may get it wrong. 454 00:21:31,450 --> 00:21:33,040 Sometimes you may find that a link has-- 455 00:21:33,040 --> 00:21:35,415 you may declare a link to have failed when, in fact, it's 456 00:21:35,415 --> 00:21:36,600 still fine. 457 00:21:36,600 --> 00:21:37,930 But that's life. 458 00:21:37,930 --> 00:21:40,250 And you just have to deal with it. 459 00:21:40,250 --> 00:21:43,270 So is the story clear so far as to how we deal 460 00:21:43,270 --> 00:21:44,455 with routing and a failure? 461 00:21:44,455 --> 00:21:46,330 So we're going to apply that to this picture. 462 00:21:46,330 --> 00:21:49,180 And you'll find that the answer will work. 463 00:21:49,180 --> 00:21:50,384 Yes? 464 00:21:50,384 --> 00:21:53,352 AUDIENCE: [INAUDIBLE]. 465 00:21:53,352 --> 00:21:54,060 PROFESSOR: Right. 466 00:21:54,060 --> 00:21:55,920 Like I said, what it-- 467 00:21:55,920 --> 00:21:57,870 let me repeat this. 468 00:21:57,870 --> 00:22:01,867 What it does is, first of all, it really 469 00:22:01,867 --> 00:22:04,200 now assumes that both the node and the link have failed. 470 00:22:04,200 --> 00:22:05,550 It doesn't really know. 471 00:22:05,550 --> 00:22:10,320 Now, it can definitively assume that the link has failed. 472 00:22:10,320 --> 00:22:12,750 The node may still be alive, because it may well be 473 00:22:12,750 --> 00:22:15,600 that there is a path like that. 474 00:22:15,600 --> 00:22:21,328 And n wants to find that route via A to that destination. 475 00:22:21,328 --> 00:22:22,870 So what it does is really two things. 476 00:22:22,870 --> 00:22:24,930 The first thing it does is it may 477 00:22:24,930 --> 00:22:28,175 have routes in its routing table going through that link. 478 00:22:28,175 --> 00:22:29,550 This link is now considered dead. 479 00:22:29,550 --> 00:22:31,470 And therefore, it should remove those routes. 480 00:22:31,470 --> 00:22:33,390 And then in subsequent advertisements, 481 00:22:33,390 --> 00:22:35,920 it should make sure that the cost to that destination 482 00:22:35,920 --> 00:22:40,560 is infinity, which is why you would remove it and replace 483 00:22:40,560 --> 00:22:42,452 the cost to be infinity so that you tell 484 00:22:42,452 --> 00:22:44,160 the other guys that previously I told you 485 00:22:44,160 --> 00:22:46,530 I could get to B with the cost of five, 486 00:22:46,530 --> 00:22:48,408 but really now it's infinity. 487 00:22:48,408 --> 00:22:50,700 The second thing that's done in the link state protocol 488 00:22:50,700 --> 00:22:53,580 is when you advertise-- you no longer advertise that link. 489 00:22:53,580 --> 00:22:55,380 So really, the answer to your question 490 00:22:55,380 --> 00:22:57,450 is it assumes that the link has failed. 491 00:22:57,450 --> 00:23:01,050 It makes no determination about the node. 492 00:23:01,050 --> 00:23:01,550 Yes? 493 00:23:01,550 --> 00:23:03,008 AUDIENCE: [INAUDIBLE]. 494 00:23:06,410 --> 00:23:07,543 PROFESSOR: Yes. 495 00:23:07,543 --> 00:23:08,960 A good protocol-- and this will be 496 00:23:08,960 --> 00:23:11,390 tested in your lab eight, in p-set eight, 497 00:23:11,390 --> 00:23:13,890 is if a link fence and eventually comes back up, 498 00:23:13,890 --> 00:23:16,670 we would like for you to actually find that answer. 499 00:23:16,670 --> 00:23:18,893 And this is an important requirement. 500 00:23:18,893 --> 00:23:20,810 So if the broadcast-- that's why all the stuff 501 00:23:20,810 --> 00:23:22,970 that's done in the background is done periodically. 502 00:23:22,970 --> 00:23:24,230 So if a link comes back up, you want 503 00:23:24,230 --> 00:23:25,355 to find the correct answer. 504 00:23:28,710 --> 00:23:31,560 Any other questions? 505 00:23:31,560 --> 00:23:32,060 OK. 506 00:23:32,060 --> 00:23:35,717 So let me apply this idea to this picture here. 507 00:23:35,717 --> 00:23:37,550 So what happened here was this thing failed. 508 00:23:37,550 --> 00:23:39,998 So C is, at this point in time-- 509 00:23:39,998 --> 00:23:42,290 let's assume we're doing distance vector, this protocol 510 00:23:42,290 --> 00:23:46,430 here-- so C is going to assume that this link has failed. 511 00:23:46,430 --> 00:23:48,770 And therefore, it tells all of the other guys 512 00:23:48,770 --> 00:23:50,930 in its next advertisement-- 513 00:23:50,930 --> 00:23:54,260 it tells these other guys that it no longer 514 00:23:54,260 --> 00:24:00,500 has a route to destination D. And it does that 515 00:24:00,500 --> 00:24:03,350 by sending in its next link state advertisement. 516 00:24:03,350 --> 00:24:06,820 Previously, it would have sent-- 517 00:24:06,820 --> 00:24:08,020 you know what? 518 00:24:08,020 --> 00:24:09,637 Did I tell everybody that you send out 519 00:24:09,637 --> 00:24:11,470 the destination and the route in the links-- 520 00:24:11,470 --> 00:24:12,370 in the advertisement? 521 00:24:12,370 --> 00:24:13,390 I may have done that. 522 00:24:13,390 --> 00:24:16,100 I meant the destination and the cost. 523 00:24:16,100 --> 00:24:20,450 So maybe I should call this the cost and change that to route. 524 00:24:20,450 --> 00:24:23,320 So this is the stuff that's sent in the advertisements. 525 00:24:23,320 --> 00:24:25,940 And these two columns are in the routing table. 526 00:24:25,940 --> 00:24:29,680 But anyway, right now here what would 527 00:24:29,680 --> 00:24:33,100 be advertised as D at a cost of three, 528 00:24:33,100 --> 00:24:35,830 we replace that now with D with the cost 529 00:24:35,830 --> 00:24:37,960 of infinity in our advertisements 530 00:24:37,960 --> 00:24:39,440 to our neighbors. 531 00:24:39,440 --> 00:24:41,530 So that's what C would advertise. 532 00:24:41,530 --> 00:24:45,430 And B, when it receives that, would now 533 00:24:45,430 --> 00:24:48,190 find that the route that it gets along here 534 00:24:48,190 --> 00:24:50,020 had previously a cost of four. 535 00:24:50,020 --> 00:24:52,480 But now it says that it's replaced 536 00:24:52,480 --> 00:24:53,640 with the cost of infinity. 537 00:24:53,640 --> 00:24:54,940 So it will replace-- 538 00:24:54,940 --> 00:24:57,070 this routing table entry would go away. 539 00:24:57,070 --> 00:25:01,180 And it would replace it with no route and a cost of infinity. 540 00:25:01,180 --> 00:25:03,340 And that's what would propagate. 541 00:25:03,340 --> 00:25:06,000 Now, these advertisements are done periodically. 542 00:25:06,000 --> 00:25:08,350 So what D is doing, of course, is 543 00:25:08,350 --> 00:25:11,507 to send out two advertisements, one this way and one that way. 544 00:25:11,507 --> 00:25:13,090 Now, this thing is not going to reach, 545 00:25:13,090 --> 00:25:16,510 because this link no longer is alive. 546 00:25:16,510 --> 00:25:18,310 But this advertisement works. 547 00:25:18,310 --> 00:25:22,630 So when A receives the next distance vector advertisement 548 00:25:22,630 --> 00:25:28,540 from D, it now knows that it has a cost-- you know, 549 00:25:28,540 --> 00:25:31,390 that link is actually alive and it has a route going there. 550 00:25:31,390 --> 00:25:34,000 Now, this particular example is a little tricky, 551 00:25:34,000 --> 00:25:36,970 because what's happening here, of course, is that A previously 552 00:25:36,970 --> 00:25:39,620 had two ways of getting to D-- 553 00:25:39,620 --> 00:25:43,030 4 plus 3 this way, or 7 that way. 554 00:25:43,030 --> 00:25:45,580 If it were previously using that, 555 00:25:45,580 --> 00:25:49,090 then A would also have no route to the destination. 556 00:25:49,090 --> 00:25:51,400 And then it would have to wait for this guy 557 00:25:51,400 --> 00:25:52,870 to send that route. 558 00:25:52,870 --> 00:25:56,620 So when it sent that route, A would now have a valid route 559 00:25:56,620 --> 00:25:57,820 to the destination. 560 00:25:57,820 --> 00:26:01,420 And in A's next advertisement, it would send that route over 561 00:26:01,420 --> 00:26:02,230 to these two guys. 562 00:26:02,230 --> 00:26:06,980 So it would send out saying that D is at cost seven. 563 00:26:06,980 --> 00:26:08,480 And it would do the same thing here. 564 00:26:08,480 --> 00:26:12,400 The D is at cost 7 to C. Now, C, when 565 00:26:12,400 --> 00:26:13,840 it receives the next advertisement 566 00:26:13,840 --> 00:26:16,990 that D is at cost 7, compares that route 567 00:26:16,990 --> 00:26:20,800 against its current route, which is now infinity, and replaces 568 00:26:20,800 --> 00:26:24,490 in its routing table entry D infinity with D, 569 00:26:24,490 --> 00:26:29,000 this link here, and a cost of 4 plus 7, which is 11. 570 00:26:29,000 --> 00:26:32,470 So it would replace it with D. Let me call this L1, L1, 571 00:26:32,470 --> 00:26:34,480 and a cost of 11. 572 00:26:34,480 --> 00:26:36,580 And then on its next advertisement, 573 00:26:36,580 --> 00:26:40,750 C would send that out to B according to that advertisement 574 00:26:40,750 --> 00:26:41,740 schedule. 575 00:26:41,740 --> 00:26:46,300 And similarly here, S, when it receives this from A 576 00:26:46,300 --> 00:26:48,070 would, on its next advertisement, 577 00:26:48,070 --> 00:26:50,980 after integrating the route to destination D, 578 00:26:50,980 --> 00:26:53,320 which would have a cost of 1 plus 7, 8, 579 00:26:53,320 --> 00:26:56,860 it would send out an advertisement this way, 580 00:26:56,860 --> 00:27:00,940 which would have a cost of 8. 581 00:27:00,940 --> 00:27:03,010 And B, when it receives both of these things, 582 00:27:03,010 --> 00:27:09,450 would compare a cost of 8 on this link against a cost of 1 583 00:27:09,450 --> 00:27:13,080 plus 4 plus 7, which is 12. 584 00:27:13,080 --> 00:27:14,970 And it would find that 8 is smaller than 12. 585 00:27:14,970 --> 00:27:16,860 And therefore, B would use this way 586 00:27:16,860 --> 00:27:18,600 of getting to the destination. 587 00:27:18,600 --> 00:27:19,920 Does that make sense? 588 00:27:19,920 --> 00:27:20,828 Yes? 589 00:27:20,828 --> 00:27:22,190 AUDIENCE: [INAUDIBLE]. 590 00:27:28,605 --> 00:27:30,480 PROFESSOR: Well, it's receiving hello packets 591 00:27:30,480 --> 00:27:32,100 from all its neighbors. 592 00:27:32,100 --> 00:27:35,160 And it's just, if a link is alive and a hello shows up, 593 00:27:35,160 --> 00:27:36,043 it processes it. 594 00:27:36,043 --> 00:27:37,710 And the moment the first hello shows up, 595 00:27:37,710 --> 00:27:39,765 it declares the link to be alive again. 596 00:27:39,765 --> 00:27:41,640 Finding that someone is alive is a lot easier 597 00:27:41,640 --> 00:27:43,765 than finding that they're dead, at least if they're 598 00:27:43,765 --> 00:27:44,810 in networks. 599 00:27:44,810 --> 00:27:46,872 It's probably true in life, too. 600 00:27:46,872 --> 00:27:48,330 But it's certainly true of networks 601 00:27:48,330 --> 00:27:50,100 because all you have to know-- 602 00:27:50,100 --> 00:27:53,520 I mean, assuming there's no malicious nodes, detecting 603 00:27:53,520 --> 00:27:55,650 that a node is alive, it takes one packet. 604 00:27:55,650 --> 00:27:57,840 Detecting that a node is dead, you're not sure. 605 00:27:57,840 --> 00:27:59,190 Maybe the link was down. 606 00:27:59,190 --> 00:28:00,690 Maybe it was just a transit failure. 607 00:28:00,690 --> 00:28:02,580 Maybe a packet was lost. 608 00:28:02,580 --> 00:28:04,980 So it's a lot harder to find that something has crashed 609 00:28:04,980 --> 00:28:08,400 than it is to find that something's working. 610 00:28:08,400 --> 00:28:13,410 But yeah, so you keep listening for hello packets. 611 00:28:13,410 --> 00:28:15,420 OK, so this is how it converges. 612 00:28:15,420 --> 00:28:19,020 Now eventually, of course, because there's 613 00:28:19,020 --> 00:28:21,060 some correct working path, eventually it 614 00:28:21,060 --> 00:28:23,700 will all converge to the correct answer. 615 00:28:23,700 --> 00:28:26,790 If later at some point and then this link comes back up, 616 00:28:26,790 --> 00:28:29,565 the same thing occurs, because all of this stuff 617 00:28:29,565 --> 00:28:30,690 is being done periodically. 618 00:28:30,690 --> 00:28:32,460 And so periodically, these advertisements 619 00:28:32,460 --> 00:28:33,610 are going to be sent. 620 00:28:33,610 --> 00:28:35,910 C is going to find that there's a better route 621 00:28:35,910 --> 00:28:38,330 to go to D via this link as 0. 622 00:28:38,330 --> 00:28:40,590 It advertises D now at a cost of 4. 623 00:28:40,590 --> 00:28:42,720 And eventually all of the nodes figure it out. 624 00:28:42,720 --> 00:28:45,450 And they converge back to the right answer. 625 00:28:45,450 --> 00:28:46,333 OK. 626 00:28:46,333 --> 00:28:48,250 And you can see that the link state protocol-- 627 00:28:48,250 --> 00:28:50,208 the convergence is actually a little bit easier 628 00:28:50,208 --> 00:28:52,380 because again, there-- 629 00:28:52,380 --> 00:28:54,700 the nodes are periodically advertising these links. 630 00:28:54,700 --> 00:28:57,270 So what's going to happen in a link state protocol is 631 00:28:57,270 --> 00:28:58,730 if you take the same picture-- 632 00:28:58,730 --> 00:29:00,630 and previously the nodes all had routes. 633 00:29:00,630 --> 00:29:03,830 And many of those routes went through that link. 634 00:29:03,830 --> 00:29:07,050 You have to wait for the next link state advertisement, which 635 00:29:07,050 --> 00:29:10,350 would tell you after this hello protocol discovers that C 636 00:29:10,350 --> 00:29:11,970 discovers that this link has failed, 637 00:29:11,970 --> 00:29:15,210 it takes that next link state protocol advertised-- 638 00:29:15,210 --> 00:29:17,370 link state advertisement by which all 639 00:29:17,370 --> 00:29:19,290 of the nodes through the flooding process 640 00:29:19,290 --> 00:29:20,970 discover that this link has failed. 641 00:29:20,970 --> 00:29:23,430 And they all run Dijkstra's algorithm again. 642 00:29:23,430 --> 00:29:26,280 And they will find the correct new answer, 643 00:29:26,280 --> 00:29:27,720 which will take them through paths 644 00:29:27,720 --> 00:29:31,970 that bypass this failed link. 645 00:29:31,970 --> 00:29:34,115 Now, the same logic applies in both protocols 646 00:29:34,115 --> 00:29:34,990 to when a node fails. 647 00:29:34,990 --> 00:29:37,160 If this node were to fail, you can sort of 648 00:29:37,160 --> 00:29:39,377 think through-- the node failing is actually 649 00:29:39,377 --> 00:29:41,960 equivalent to all of the links coming out of the node failing. 650 00:29:41,960 --> 00:29:43,670 So it's a somewhat harder problem 651 00:29:43,670 --> 00:29:46,950 in terms of just making sure that you're able to find 652 00:29:46,950 --> 00:29:48,260 the routes correctly. 653 00:29:48,260 --> 00:29:50,660 But this node failing is really the same as all 654 00:29:50,660 --> 00:29:53,132 of the links attached to that node failing. 655 00:29:53,132 --> 00:29:54,590 And in a link state protocol, it'll 656 00:29:54,590 --> 00:29:56,007 eventually-- you'll discover that. 657 00:29:56,007 --> 00:29:58,190 And all of the nodes will compute routes this way. 658 00:29:58,190 --> 00:30:00,260 And similarly in a distance vector protocol 659 00:30:00,260 --> 00:30:02,485 that's what happens. 660 00:30:02,485 --> 00:30:03,860 Now, so far in this picture, I've 661 00:30:03,860 --> 00:30:08,620 assumed that once you have these failures and then you pause, 662 00:30:08,620 --> 00:30:10,220 nothing else happens. 663 00:30:10,220 --> 00:30:12,360 There's no more failures, no packets that are lost, 664 00:30:12,360 --> 00:30:12,980 and so on. 665 00:30:12,980 --> 00:30:15,080 But life's actually not so kind. 666 00:30:15,080 --> 00:30:19,605 What will happen in practice is that, first of all, 667 00:30:19,605 --> 00:30:21,980 before I get to why this stuff is a lot more complicated, 668 00:30:21,980 --> 00:30:24,110 does everyone understand how these things work 669 00:30:24,110 --> 00:30:27,020 and how they converge correctly to the right answer 670 00:30:27,020 --> 00:30:31,500 after failure and after recovery from failure? 671 00:30:31,500 --> 00:30:32,570 Any questions? 672 00:30:35,210 --> 00:30:35,800 OK. 673 00:30:35,800 --> 00:30:36,910 So now let me tell you all the ways 674 00:30:36,910 --> 00:30:38,380 in which this story goes wrong. 675 00:30:43,160 --> 00:30:45,748 The first way the story goes wrong is-- 676 00:30:45,748 --> 00:30:47,540 let me do it in the context of a link state 677 00:30:47,540 --> 00:30:50,090 protocol with a very, very simple picture. 678 00:30:50,090 --> 00:30:51,350 Let's say you have-- 679 00:30:51,350 --> 00:30:52,370 I think I have a slide. 680 00:30:55,820 --> 00:30:56,320 All right. 681 00:30:56,320 --> 00:31:00,630 Let's say you have the picture that I've shown up there, 682 00:31:00,630 --> 00:31:02,540 so very, very simple picture. 683 00:31:02,540 --> 00:31:05,110 There's A, B, and D. D is the destination. 684 00:31:05,110 --> 00:31:06,790 And this is some path. 685 00:31:06,790 --> 00:31:10,020 So let's say that what happens is that normally when 686 00:31:10,020 --> 00:31:13,770 there's no failures, the way to go from B to D is via A. 687 00:31:13,770 --> 00:31:17,560 So B, A, D. And A goes to D directly. 688 00:31:17,560 --> 00:31:20,610 Now, let's assume that this link fails. 689 00:31:20,610 --> 00:31:23,142 If that link fails and things work great, 690 00:31:23,142 --> 00:31:25,350 what's going to happen is that in the next link state 691 00:31:25,350 --> 00:31:30,450 advertisement, A tells B that AD no longer exists. 692 00:31:30,450 --> 00:31:33,570 A knows the correct link state from B. 693 00:31:33,570 --> 00:31:37,320 And so it computes its path via B, its route via B. 694 00:31:37,320 --> 00:31:41,310 And similarly, B realizes that AD doesn't exist anymore. 695 00:31:41,310 --> 00:31:45,000 And it computes an alternate route that way. 696 00:31:45,000 --> 00:31:47,730 But let's say what happens is that AD fails. 697 00:31:47,730 --> 00:31:52,660 And then in the next link state advertisement that A sends out, 698 00:31:52,660 --> 00:31:54,580 that packet is lost. 699 00:31:54,580 --> 00:31:56,760 Let's say that A's link state advertisement to B 700 00:31:56,760 --> 00:31:58,390 is just lost. 701 00:31:58,390 --> 00:32:00,150 Packets could get lost. 702 00:32:00,150 --> 00:32:05,280 Now we have a problem because A knows that this has failed. 703 00:32:05,280 --> 00:32:08,100 And therefore, when it computes its Dijkstra's algorithm 704 00:32:08,100 --> 00:32:10,740 or shortest path algorithm, it knows that what it wants 705 00:32:10,740 --> 00:32:12,990 is a route going like that. 706 00:32:12,990 --> 00:32:14,640 But B, on the other hand, doesn't 707 00:32:14,640 --> 00:32:16,920 know that link AD has failed, because it 708 00:32:16,920 --> 00:32:20,680 didn't see that link state advisement which was lost. 709 00:32:20,680 --> 00:32:23,140 So what B does is compute its routing table entry, 710 00:32:23,140 --> 00:32:26,070 which is the same as it was before, going 711 00:32:26,070 --> 00:32:27,960 through that link over here. 712 00:32:30,720 --> 00:32:32,530 Now you have a problem because when 713 00:32:32,530 --> 00:32:34,430 A gets a packet that it now-- a data 714 00:32:34,430 --> 00:32:37,137 packet that it wants to send to destination D, previously 715 00:32:37,137 --> 00:32:37,970 it sent it this way. 716 00:32:37,970 --> 00:32:39,620 But now it knows that link has failed. 717 00:32:39,620 --> 00:32:42,170 So it sends the packet to B, because its route for D 718 00:32:42,170 --> 00:32:45,200 is via B. Well, B gets that packet 719 00:32:45,200 --> 00:32:47,540 and looks it up in its routing table. 720 00:32:47,540 --> 00:32:50,390 And B believes that the way to get to D is via A. 721 00:32:50,390 --> 00:32:52,183 So it sends it back to A. 722 00:32:52,183 --> 00:32:54,350 Well, A gets that packet and says, oh, that's great. 723 00:32:54,350 --> 00:32:56,900 This is a packet for destination D. I look it up 724 00:32:56,900 --> 00:32:57,990 in my routing table. 725 00:32:57,990 --> 00:33:00,680 It goes via B. And this thing [INAUDIBLE] 726 00:33:00,680 --> 00:33:03,860 for pretty much as long as you want. 727 00:33:03,860 --> 00:33:07,430 This thing here is the simplest example of a general phenomenon 728 00:33:07,430 --> 00:33:09,750 called a routing loop. 729 00:33:09,750 --> 00:33:11,630 So the first thing that can happen when-- 730 00:33:11,630 --> 00:33:14,000 during the process of route convergence, 731 00:33:14,000 --> 00:33:16,640 various kinds of pathologies and problematic conditions 732 00:33:16,640 --> 00:33:17,353 could happen. 733 00:33:17,353 --> 00:33:18,770 And one of them is a routing loop. 734 00:33:22,310 --> 00:33:23,810 The second thing that could happen-- 735 00:33:23,810 --> 00:33:25,490 and I showed you that here-- 736 00:33:25,490 --> 00:33:28,460 where during the process of convergence, 737 00:33:28,460 --> 00:33:31,040 C does not have a route to this link-- 738 00:33:31,040 --> 00:33:32,810 to the destination D. But B thought 739 00:33:32,810 --> 00:33:35,750 it had a route going via C. But in fact, C just 740 00:33:35,750 --> 00:33:36,620 dropped that packet. 741 00:33:36,620 --> 00:33:38,180 That's the second condition that happens. 742 00:33:38,180 --> 00:33:38,847 It's a dead end. 743 00:33:41,522 --> 00:33:43,730 So both of these things can happen during the process 744 00:33:43,730 --> 00:33:44,355 of convergence. 745 00:33:44,355 --> 00:33:46,063 Now, these routing loops are particularly 746 00:33:46,063 --> 00:33:48,470 problematic because when you have a routing loop, 747 00:33:48,470 --> 00:33:51,440 this is an example of a two-hop routing loop. 748 00:33:51,440 --> 00:33:54,840 A goes to B. B goes to A goes to B. So it bounces twice. 749 00:33:54,840 --> 00:33:56,840 But you can have more complicated routing loops. 750 00:33:56,840 --> 00:34:00,110 You could have a routing loop with four hops that 751 00:34:00,110 --> 00:34:03,080 looks like-- or four nodes involved, as opposed 752 00:34:03,080 --> 00:34:06,410 to two nodes, where this is destination D. 753 00:34:06,410 --> 00:34:09,600 And this A thinks that you have to go that way. 754 00:34:09,600 --> 00:34:11,270 B thinks that you have to go this way. 755 00:34:11,270 --> 00:34:12,690 C thinks you have to go this way. 756 00:34:12,690 --> 00:34:15,380 And let's call this guy E. He thinks you have to go that way. 757 00:34:15,380 --> 00:34:16,949 And this could happen. 758 00:34:16,949 --> 00:34:19,679 So you end up with packets cycling around. 759 00:34:19,679 --> 00:34:22,260 Now, these packets cycling around-- 760 00:34:22,260 --> 00:34:24,110 you know, there's really no way to-- 761 00:34:24,110 --> 00:34:28,040 once you have routing table entries that have somehow 762 00:34:28,040 --> 00:34:31,040 converged, until it gets fixed, somehow if they've 763 00:34:31,040 --> 00:34:33,739 converged to routes that-- 764 00:34:33,739 --> 00:34:35,420 where for B, you have to use this link, 765 00:34:35,420 --> 00:34:37,489 and C has to use this link, and so forth, 766 00:34:37,489 --> 00:34:40,430 and you get a cycle, what ends up happening 767 00:34:40,430 --> 00:34:42,739 is these packets cycle forever. 768 00:34:42,739 --> 00:34:46,190 There's really no way to avoid the packets cycling forever. 769 00:34:48,830 --> 00:34:51,170 Now, this is, of course-- eventually this will be fixed. 770 00:34:51,170 --> 00:34:52,940 If the routing protocol eventually converges, 771 00:34:52,940 --> 00:34:54,860 it will eventually discover that this is wrong 772 00:34:54,860 --> 00:34:56,600 and find the correct answer. 773 00:34:56,600 --> 00:34:58,610 But during the process of convergence, 774 00:34:58,610 --> 00:35:00,170 bad things could happen like this. 775 00:35:00,170 --> 00:35:03,320 And that's why we have on packets in packet switch 776 00:35:03,320 --> 00:35:06,620 networks a field called the hop limit field. 777 00:35:06,620 --> 00:35:08,030 And that's on a data packet. 778 00:35:08,030 --> 00:35:10,880 So you have the source of the packet sets 779 00:35:10,880 --> 00:35:12,980 a hop limit-- let's say 32. 780 00:35:12,980 --> 00:35:15,230 It just says that I need to get to the destination 781 00:35:15,230 --> 00:35:17,120 and I know it shouldn't take more than 32 782 00:35:17,120 --> 00:35:19,070 hops, no matter what happens. 783 00:35:19,070 --> 00:35:22,100 And then every node that-- every switch that gets this packet 784 00:35:22,100 --> 00:35:25,340 reduces the hop limit by 1. 785 00:35:25,340 --> 00:35:28,010 And eventually when the hop limit gets to zero, 786 00:35:28,010 --> 00:35:29,052 the packet's discarded. 787 00:35:29,052 --> 00:35:31,260 So this is a way to flush packets out of the network. 788 00:35:31,260 --> 00:35:35,060 And usually you use this mechanism to handle the case 789 00:35:35,060 --> 00:35:37,963 when you get stuck in a routing loop, 790 00:35:37,963 --> 00:35:40,130 you don't want these packets to cycle around forever 791 00:35:40,130 --> 00:35:43,010 and ever and ever, because these packets move around the network 792 00:35:43,010 --> 00:35:44,510 in milliseconds. 793 00:35:44,510 --> 00:35:46,160 And the routing protocols take minutes 794 00:35:46,160 --> 00:35:48,260 to converge, or many, many seconds to converge. 795 00:35:48,260 --> 00:35:49,490 So that's many, many milliseconds. 796 00:35:49,490 --> 00:35:51,532 These packets could remain in the network forever 797 00:35:51,532 --> 00:35:54,080 and ever using the bandwidth and no one's getting any use out 798 00:35:54,080 --> 00:35:54,900 of it. 799 00:35:54,900 --> 00:35:57,200 So you have this hop limit field to flush packets out 800 00:35:57,200 --> 00:35:58,862 of the system. 801 00:35:58,862 --> 00:36:00,320 But of course, what we'd like to do 802 00:36:00,320 --> 00:36:03,470 is to design protocols with guaranteed no routing loops 803 00:36:03,470 --> 00:36:04,820 at all. 804 00:36:04,820 --> 00:36:07,320 Unfortunately, it's impossible to do that. 805 00:36:07,320 --> 00:36:09,740 But what we can try to do is to reduce and mitigate 806 00:36:09,740 --> 00:36:13,040 the effects of routing loops. 807 00:36:13,040 --> 00:36:16,190 Now, I want to go through a few more examples of routing loops 808 00:36:16,190 --> 00:36:17,060 in-- 809 00:36:17,060 --> 00:36:18,717 this is in the link state protocol. 810 00:36:18,717 --> 00:36:20,300 I want to actually now talk about what 811 00:36:20,300 --> 00:36:22,910 happens with a distance vector protocol 812 00:36:22,910 --> 00:36:26,047 and show you why this basic, simple distance vector 813 00:36:26,047 --> 00:36:28,130 protocol, which is the first routing protocol that 814 00:36:28,130 --> 00:36:31,253 was invented, has some problems and how we go about fixing it. 815 00:36:31,253 --> 00:36:33,170 And eventually I'll talk about how this is all 816 00:36:33,170 --> 00:36:36,720 used on the internet today. 817 00:36:36,720 --> 00:36:39,125 So here's how a distance protocol-- 818 00:36:39,125 --> 00:36:40,820 a distance vector protocol might get 819 00:36:40,820 --> 00:36:45,690 stuck in a weird kind of routing loop. 820 00:36:45,690 --> 00:36:49,310 So let's take this example here where you have five nodes 821 00:36:49,310 --> 00:36:52,310 and we're all interested in finding routes to destination 822 00:36:52,310 --> 00:36:55,160 E. And the general lesson I want to get at here 823 00:36:55,160 --> 00:36:58,080 is that a distance vector protocol is extremely simple, 824 00:36:58,080 --> 00:37:01,010 but it only works on small networks. 825 00:37:01,010 --> 00:37:03,950 And for bigger networks, we want something better. 826 00:37:03,950 --> 00:37:06,470 So that's where the story's going. 827 00:37:06,470 --> 00:37:09,200 So let me refresh where we are, all the discussion I 828 00:37:09,200 --> 00:37:09,980 had so far. 829 00:37:09,980 --> 00:37:14,558 So let's assume that link AC fails in this picture. 830 00:37:14,558 --> 00:37:16,975 So what you would like to-- and assume that all link costs 831 00:37:16,975 --> 00:37:17,540 are 1. 832 00:37:17,540 --> 00:37:20,300 So we don't worry about costs at this point. 833 00:37:20,300 --> 00:37:23,910 What you want to have happen is for A to discover that this-- 834 00:37:23,910 --> 00:37:25,220 A discovers that's failed. 835 00:37:25,220 --> 00:37:26,900 And when the routing converges, you 836 00:37:26,900 --> 00:37:30,890 would like A to use this link as its route to destination E. 837 00:37:30,890 --> 00:37:35,040 And the cost would be 1, 1, 1, which would be 3. 838 00:37:35,040 --> 00:37:35,540 All right. 839 00:37:35,540 --> 00:37:38,060 So when A discovers failure, it sends a cost of E 840 00:37:38,060 --> 00:37:42,770 is infinity to its neighbor-- in particular, to B. 841 00:37:42,770 --> 00:37:45,500 And then B, of course, has a route 842 00:37:45,500 --> 00:37:48,090 to destination E at cost 2. 843 00:37:48,090 --> 00:37:51,620 B advertises that to A. And then A says, now 844 00:37:51,620 --> 00:37:54,020 I have a route to destination E. And thus, this 845 00:37:54,020 --> 00:37:57,140 is an example of a good converging routing protocol. 846 00:37:57,140 --> 00:37:59,278 Everything's good. 847 00:37:59,278 --> 00:38:01,070 Now, let's assume I complicate the picture. 848 00:38:01,070 --> 00:38:04,820 Let's assume that link BD also fails. 849 00:38:04,820 --> 00:38:06,480 So now what's the correct answer? 850 00:38:06,480 --> 00:38:10,850 Well, these two guys have a route to E. 851 00:38:10,850 --> 00:38:12,883 But the network has become disconnected. 852 00:38:12,883 --> 00:38:15,050 So the correct answer, the correct convergent answer 853 00:38:15,050 --> 00:38:19,270 here is that A and B both discover and instantiate 854 00:38:19,270 --> 00:38:21,080 in the routing tables entries that 855 00:38:21,080 --> 00:38:23,510 say that E is at a cost of infinity 856 00:38:23,510 --> 00:38:25,010 because there's no path, which means 857 00:38:25,010 --> 00:38:27,270 that it's an infinite cost. 858 00:38:27,270 --> 00:38:30,800 So when a packet arrives at B for destination DE, 859 00:38:30,800 --> 00:38:33,230 you just drop the packet. 860 00:38:33,230 --> 00:38:34,830 But this could happen. 861 00:38:34,830 --> 00:38:37,020 So here's an example of how that happens. 862 00:38:37,020 --> 00:38:40,130 So let's say that this link fails. 863 00:38:40,130 --> 00:38:42,530 B discovers that through the hello protocol. 864 00:38:42,530 --> 00:38:46,500 And at this point, B changes its routing table entry 865 00:38:46,500 --> 00:38:49,190 so that E is at infinity. 866 00:38:49,190 --> 00:38:51,980 B had previously sent information to A saying 867 00:38:51,980 --> 00:38:53,240 that B was-- 868 00:38:53,240 --> 00:38:56,360 E was at distance 2 or cost 2. 869 00:38:56,360 --> 00:38:58,220 And now it says, well, I told you 870 00:38:58,220 --> 00:39:00,350 that E was at cost 2 before. 871 00:39:00,350 --> 00:39:01,520 But I'm changing my mind. 872 00:39:01,520 --> 00:39:02,890 It's at cost infinity. 873 00:39:02,890 --> 00:39:04,580 And A says, OK. 874 00:39:04,580 --> 00:39:08,630 My entry for E now has cost infinity and both of them 875 00:39:08,630 --> 00:39:12,245 have converged correctly to the right answer. 876 00:39:12,245 --> 00:39:14,120 Now, unfortunately, that's not the only thing 877 00:39:14,120 --> 00:39:15,560 that could happen. 878 00:39:15,560 --> 00:39:19,310 This was in the lucky situation when B discovered it had failed 879 00:39:19,310 --> 00:39:22,790 and immediately sent out its cost to A. 880 00:39:22,790 --> 00:39:25,530 But what could happen is a little different. 881 00:39:25,530 --> 00:39:27,560 What could happen is that B could 882 00:39:27,560 --> 00:39:33,380 discover that D has failed and change its routing table 883 00:39:33,380 --> 00:39:35,240 entry to infinity. 884 00:39:35,240 --> 00:39:38,080 But before it gets a chance to send out its advertisement 885 00:39:38,080 --> 00:39:39,140 to A-- 886 00:39:39,140 --> 00:39:41,250 or perhaps it sends out its advertisement 887 00:39:41,250 --> 00:39:44,368 with a cost of infinity to A, but it got lost-- 888 00:39:44,368 --> 00:39:46,160 in either of those cases, what could happen 889 00:39:46,160 --> 00:39:48,990 is A could send out its routing table 890 00:39:48,990 --> 00:39:53,780 cost to B for destination E, because that's what's 891 00:39:53,780 --> 00:39:55,190 happening periodically, right? 892 00:39:55,190 --> 00:39:56,630 Every node is periodically running this. 893 00:39:56,630 --> 00:39:58,088 And the times are all asynchronous. 894 00:39:58,088 --> 00:40:01,220 Every node has its own notion of when it should send out 895 00:40:01,220 --> 00:40:03,290 its advertisement. 896 00:40:03,290 --> 00:40:07,790 So what happens now is A sends out an advertisement to B 897 00:40:07,790 --> 00:40:12,810 saying it has a route to destination E at a cost of 3, 898 00:40:12,810 --> 00:40:14,120 which is very valid, right? 899 00:40:14,120 --> 00:40:18,580 After all, A does have a route in its routing table 900 00:40:18,580 --> 00:40:20,120 to E, whose cost is 3. 901 00:40:20,120 --> 00:40:22,670 It so happens it goes through B. But A doesn't yet 902 00:40:22,670 --> 00:40:25,040 know that that link BD has failed. 903 00:40:27,775 --> 00:40:29,150 Now we're a little bit in trouble 904 00:40:29,150 --> 00:40:32,960 because B now believes that its routing table entry for E 905 00:40:32,960 --> 00:40:37,700 is at cost of infinity because BD has failed that link. 906 00:40:37,700 --> 00:40:42,490 And now it sees an advertisement from A with a better cost. 907 00:40:42,490 --> 00:40:44,700 The route says, wow, this is cool. 908 00:40:44,700 --> 00:40:48,330 I now have a path of cost 3 via A 909 00:40:48,330 --> 00:40:52,380 to E, which is better than my cost of infinity. 910 00:40:52,380 --> 00:40:55,320 And so I'm going to assume that I have an entry 911 00:40:55,320 --> 00:40:58,080 to E at a cost of 4. 912 00:40:58,080 --> 00:41:00,120 So now you can see that this is actually 913 00:41:00,120 --> 00:41:03,350 not a valid route at all. 914 00:41:03,350 --> 00:41:05,150 Now, B actually, on the face of it, 915 00:41:05,150 --> 00:41:08,660 has no way of knowing if A is telling it a different route. 916 00:41:08,660 --> 00:41:10,280 So it could conceivably be the case 917 00:41:10,280 --> 00:41:16,640 that A has a different route going that way whose cost is 3. 918 00:41:16,640 --> 00:41:20,222 And A can legitimately have a cost of 3 to E 919 00:41:20,222 --> 00:41:23,060 that it could be telling B about. 920 00:41:23,060 --> 00:41:25,010 But in this protocol, there's no way for B 921 00:41:25,010 --> 00:41:28,670 to distinguish that case from the case where A is just 922 00:41:28,670 --> 00:41:31,520 repeating to B a route that it received via B. 923 00:41:31,520 --> 00:41:35,550 But it's just telling it that it has a route via B. 924 00:41:35,550 --> 00:41:39,710 Now, B, therefore, says that it has a cost of 4 to E. 925 00:41:39,710 --> 00:41:42,020 And it sends that to A. And A says, whoa. 926 00:41:42,020 --> 00:41:43,760 Previously, the cost was 3-- 927 00:41:43,760 --> 00:41:46,190 2 from B. And now B is telling me 928 00:41:46,190 --> 00:41:47,810 that the cost is 4, which means I 929 00:41:47,810 --> 00:41:51,460 need to make my cost equal to 4 plus 1, which is 5. 930 00:41:51,460 --> 00:41:53,570 And I'm going to send that back down. 931 00:41:53,570 --> 00:41:54,490 B says, all right. 932 00:41:54,490 --> 00:41:55,490 I've got a cost of 5. 933 00:41:55,490 --> 00:41:58,500 Previously, that same thing had a cost of 3. 934 00:41:58,500 --> 00:42:00,901 So now I'm going to make my cost 6. 935 00:42:00,901 --> 00:42:02,552 And this goes on forever. 936 00:42:02,552 --> 00:42:04,760 Now, in the meantime, if there are packets showing up 937 00:42:04,760 --> 00:42:06,895 at either A or B for destination E, 938 00:42:06,895 --> 00:42:09,020 they're just going to go bouncing between these two 939 00:42:09,020 --> 00:42:09,750 guys. 940 00:42:09,750 --> 00:42:12,530 This is a routing loop. 941 00:42:12,530 --> 00:42:14,880 Now, when does this stop? 942 00:42:14,880 --> 00:42:20,065 When do these guys stop sending these incrementing costs? 943 00:42:20,065 --> 00:42:20,991 Sorry? 944 00:42:20,991 --> 00:42:23,493 AUDIENCE: [INAUDIBLE]. 945 00:42:23,493 --> 00:42:24,160 PROFESSOR: Yeah. 946 00:42:24,160 --> 00:42:25,990 You need a value of infinity. 947 00:42:25,990 --> 00:42:27,610 You need to say that, at some point, 948 00:42:27,610 --> 00:42:30,050 they're going to reach infinity and we're going to stop. 949 00:42:30,050 --> 00:42:31,570 So in other words, for this protocol 950 00:42:31,570 --> 00:42:34,330 as it's presented to converge in a legitimate amount-- 951 00:42:34,330 --> 00:42:37,030 reasonable amount of time, your value of infinity 952 00:42:37,030 --> 00:42:39,940 should be small. 953 00:42:39,940 --> 00:42:41,470 So this thing has a colorful name. 954 00:42:41,470 --> 00:42:43,270 It's called counting to infinity. 955 00:42:43,270 --> 00:42:47,280 Now, in reality, in any network, the cost of infinity cannot be 956 00:42:47,280 --> 00:42:53,760 smaller than the minimum-- the maximum minimum cost path. 957 00:42:53,760 --> 00:42:56,970 If you have a minimum cost path that has a cost of 75, 958 00:42:56,970 --> 00:43:01,590 for whatever reason, infinity had better be bigger than 75. 959 00:43:01,590 --> 00:43:02,280 Right? 960 00:43:02,280 --> 00:43:04,080 So what it means is that you have 961 00:43:04,080 --> 00:43:06,440 a problem with this protocol. 962 00:43:06,440 --> 00:43:07,950 It works great on small networks. 963 00:43:07,950 --> 00:43:09,480 But it only works on small networks. 964 00:43:09,480 --> 00:43:12,220 And the reason for that is that it needs the value of infinity 965 00:43:12,220 --> 00:43:14,830 that's not very big. 966 00:43:14,830 --> 00:43:17,370 So this is why distance vector protocols are only 967 00:43:17,370 --> 00:43:19,800 used for really simple, small networks. 968 00:43:19,800 --> 00:43:22,170 And the moment the network becomes a certain size 969 00:43:22,170 --> 00:43:25,390 or when you want costs that are large values, 970 00:43:25,390 --> 00:43:27,788 you really can't use this protocol. 971 00:43:27,788 --> 00:43:29,080 So how do you fix this problem? 972 00:43:32,460 --> 00:43:35,580 Any ideas on how to solve this problem? 973 00:43:35,580 --> 00:43:38,710 Clearly the internet is pretty big. 974 00:43:38,710 --> 00:43:41,820 We're not counting to infinity throughout the whole internet. 975 00:43:41,820 --> 00:43:43,770 Or at least, we don't think we are. 976 00:43:43,770 --> 00:43:45,300 So how would you fix this problem? 977 00:43:45,300 --> 00:43:45,930 Any ideas? 978 00:43:51,370 --> 00:43:51,870 Yes? 979 00:43:51,870 --> 00:43:53,680 AUDIENCE: [INAUDIBLE]. 980 00:43:53,680 --> 00:43:55,680 PROFESSOR: So we do have a hop limit on packets. 981 00:43:55,680 --> 00:43:58,120 So all these packets might have a hop limit. 982 00:43:58,120 --> 00:44:01,020 So the packets don't remain in the network for a long time. 983 00:44:01,020 --> 00:44:03,930 But that doesn't solve the problem of the routing protocol 984 00:44:03,930 --> 00:44:10,625 to converge takes a time which is this counting 985 00:44:10,625 --> 00:44:12,130 to infinity problem. 986 00:44:12,130 --> 00:44:14,080 So you want a better solution in some way. 987 00:44:14,080 --> 00:44:15,344 Yes? 988 00:44:15,344 --> 00:44:16,805 AUDIENCE: [INAUDIBLE]. 989 00:44:24,997 --> 00:44:25,580 PROFESSOR: OK. 990 00:44:25,580 --> 00:44:27,655 So that's one good idea, which is-- 991 00:44:27,655 --> 00:44:29,280 in fact, that's how they started trying 992 00:44:29,280 --> 00:44:33,180 to solve this problem, which is, if you have 993 00:44:33,180 --> 00:44:37,740 a route to a destination coming from a neighbor, 994 00:44:37,740 --> 00:44:40,570 don't send back the same route to them. 995 00:44:40,570 --> 00:44:44,100 In other words, in this case, A's route to E 996 00:44:44,100 --> 00:44:49,320 was via B. So A should not advertise a route to E-- 997 00:44:49,320 --> 00:44:51,947 a route for destination E back to B. 998 00:44:51,947 --> 00:44:53,530 If you do that, there's a name for it. 999 00:44:53,530 --> 00:44:55,155 It's called split horizon and the notes 1000 00:44:55,155 --> 00:44:57,450 describe how this protocol works. 1001 00:44:57,450 --> 00:44:59,910 Or you could do even better. 1002 00:44:59,910 --> 00:45:03,660 A could advertise to B that its route to destination E 1003 00:45:03,660 --> 00:45:07,800 has a cost of infinity, forcing B to definitely 1004 00:45:07,800 --> 00:45:09,270 not use that route, no matter what 1005 00:45:09,270 --> 00:45:11,610 happens, because A perceived that route via B. 1006 00:45:11,610 --> 00:45:14,100 So A should tell B that the cost of that route 1007 00:45:14,100 --> 00:45:16,770 is infinity because under no circumstances does A 1008 00:45:16,770 --> 00:45:20,220 want B to use the same route that it received. 1009 00:45:20,220 --> 00:45:21,095 So you could do that. 1010 00:45:21,095 --> 00:45:23,303 The trouble with that is it doesn't-- it solves these 1011 00:45:23,303 --> 00:45:25,680 two-hop loop problems, but it doesn't solve four-hop loop 1012 00:45:25,680 --> 00:45:26,340 problems. 1013 00:45:26,340 --> 00:45:30,960 So you could have a situation where this link fails and C 1014 00:45:30,960 --> 00:45:32,010 discovers that. 1015 00:45:32,010 --> 00:45:34,140 But before C sends out its update, 1016 00:45:34,140 --> 00:45:38,805 B sends out its route to C. And so C thinks it can use B. 1017 00:45:38,805 --> 00:45:42,600 In the meantime, B thinks it has a route via A. 1018 00:45:42,600 --> 00:45:44,730 So you might end up with packets cycling around 1019 00:45:44,730 --> 00:45:45,900 in longer hop loops. 1020 00:45:45,900 --> 00:45:48,030 So that idea that you had doesn't actually 1021 00:45:48,030 --> 00:45:50,110 solve the more general problem. 1022 00:45:50,110 --> 00:45:51,765 So any other modification or idea 1023 00:45:51,765 --> 00:45:52,890 that can solve the problem? 1024 00:46:01,250 --> 00:46:03,260 So one thing you could do is something 1025 00:46:03,260 --> 00:46:05,870 called path vector, which is what you could do 1026 00:46:05,870 --> 00:46:09,080 is every node, rather than just sending the cost, 1027 00:46:09,080 --> 00:46:12,230 it could send the entire route, that is-- sorry. 1028 00:46:12,230 --> 00:46:13,910 It could send the entire path. 1029 00:46:13,910 --> 00:46:16,250 It could send the list of nodes that 1030 00:46:16,250 --> 00:46:19,417 corresponds to that particular route in its routing table 1031 00:46:19,417 --> 00:46:20,000 advertisement. 1032 00:46:20,000 --> 00:46:21,620 So I'll show that with a picture here. 1033 00:46:21,620 --> 00:46:25,910 So E could send out not just its destination 1034 00:46:25,910 --> 00:46:29,240 and a cost, which previously, it would say that to come to E, E 1035 00:46:29,240 --> 00:46:30,710 would say the cost is zero. 1036 00:46:30,710 --> 00:46:34,700 But it could now say the cost is zero and the path is E. 1037 00:46:34,700 --> 00:46:38,210 And then each of these other guys, C and D, 1038 00:46:38,210 --> 00:46:42,850 could send out their own advertisements 1039 00:46:42,850 --> 00:46:46,030 saying the cost is 2 or whatever-- the cost is 1. 1040 00:46:46,030 --> 00:46:48,970 But they could also say that the path is the DE. 1041 00:46:48,970 --> 00:46:53,560 So D says that my path to get to E is DE in its advertisement. 1042 00:46:53,560 --> 00:46:55,540 And B here, when it receives that, 1043 00:46:55,540 --> 00:46:59,120 could send out its own path vector, 1044 00:46:59,120 --> 00:47:05,270 which is the list of nodes or the list of switches 1045 00:47:05,270 --> 00:47:09,590 that corresponds to an actual path that's advertised. 1046 00:47:09,590 --> 00:47:11,630 And now the rule for how you integrate 1047 00:47:11,630 --> 00:47:15,180 a route into your routing table entries is very simple. 1048 00:47:15,180 --> 00:47:18,380 If you see an advertisement with your own identity 1049 00:47:18,380 --> 00:47:19,940 in that advertisement, then you know 1050 00:47:19,940 --> 00:47:22,455 that that's just a rumor that you started 1051 00:47:22,455 --> 00:47:24,830 or you were involved with, so you shouldn't integrate it. 1052 00:47:24,830 --> 00:47:27,020 So in particular, in this example here, 1053 00:47:27,020 --> 00:47:31,280 if B, for example, were to see an advertisement from A 1054 00:47:31,280 --> 00:47:36,568 with a path that was A, B, D, E, then B wouldn't integrate that. 1055 00:47:36,568 --> 00:47:38,860 So what would happen in the picture I showed you before 1056 00:47:38,860 --> 00:47:41,510 is if these two links were to fail, what would happen 1057 00:47:41,510 --> 00:47:44,510 is that B would have-- if that link failed, 1058 00:47:44,510 --> 00:47:47,780 B would have sent that BDE over here. 1059 00:47:47,780 --> 00:47:50,480 And when A advertises that back to B, 1060 00:47:50,480 --> 00:47:53,120 it would have ABDE show up. 1061 00:47:53,120 --> 00:47:55,880 And B now sees ABDE. 1062 00:47:55,880 --> 00:47:59,270 And B finds that its own name is in that vector 1063 00:47:59,270 --> 00:48:00,890 or in that advertisement and says, 1064 00:48:00,890 --> 00:48:03,550 I should pay no attention to that. 1065 00:48:03,550 --> 00:48:05,810 And as long as you find your own name somewhere 1066 00:48:05,810 --> 00:48:09,890 in that list of nodes that routing advertisement 1067 00:48:09,890 --> 00:48:12,500 went through, you know that you shouldn't pay any attention 1068 00:48:12,500 --> 00:48:16,190 to it because you were involved in creating that advertisement. 1069 00:48:16,190 --> 00:48:18,560 And so you shouldn't pay attention to it. 1070 00:48:18,560 --> 00:48:20,090 This protocol is called path vector. 1071 00:48:20,090 --> 00:48:21,872 It's used on the internet in something 1072 00:48:21,872 --> 00:48:23,330 called the Border Gateway Protocol, 1073 00:48:23,330 --> 00:48:25,310 which runs between autonomous systems. 1074 00:48:25,310 --> 00:48:30,050 And that's actually what makes the internet essentially 1075 00:48:30,050 --> 00:48:32,780 converge and not have these routing loops that 1076 00:48:32,780 --> 00:48:35,212 go between different internet service providers. 1077 00:48:38,590 --> 00:48:42,160 Any questions, comments so far about any of this stuff? 1078 00:48:45,950 --> 00:48:48,423 So let me summarize everything about routing protocols. 1079 00:48:48,423 --> 00:48:50,590 And we pick this up in recitation with some problems 1080 00:48:50,590 --> 00:48:51,400 tomorrow. 1081 00:48:51,400 --> 00:48:53,620 So the last two lectures in recitation, we've 1082 00:48:53,620 --> 00:48:55,490 spoken about the network layer. 1083 00:48:55,490 --> 00:48:58,420 And the main problem that's solved by the network layer 1084 00:48:58,420 --> 00:49:00,640 is how to get packet routing to work. 1085 00:49:00,640 --> 00:49:04,200 How do you find good paths between different nodes 1086 00:49:04,200 --> 00:49:05,950 in the network, between different switches 1087 00:49:05,950 --> 00:49:06,575 in the network? 1088 00:49:09,150 --> 00:49:10,850 Now, we've separated out the tasks 1089 00:49:10,850 --> 00:49:12,680 of routing from forwarding. 1090 00:49:12,680 --> 00:49:16,208 Forwarding is what happens when a packet arrives at a switch. 1091 00:49:16,208 --> 00:49:18,250 There's a lookup that happens in a routing table. 1092 00:49:18,250 --> 00:49:19,160 You take the destination. 1093 00:49:19,160 --> 00:49:20,660 You look it up in the table, find 1094 00:49:20,660 --> 00:49:24,000 the link in the routing table, and ship the packet. 1095 00:49:24,000 --> 00:49:25,630 So that's done-- usually you want 1096 00:49:25,630 --> 00:49:27,502 it to be done very, very fast. 1097 00:49:27,502 --> 00:49:29,210 Routing is the process by which the nodes 1098 00:49:29,210 --> 00:49:31,130 create routing table entries. 1099 00:49:31,130 --> 00:49:32,870 And that's a very distributed process. 1100 00:49:32,870 --> 00:49:35,240 It runs amongst all of the other-- all 1101 00:49:35,240 --> 00:49:37,092 of the switches in the network. 1102 00:49:37,092 --> 00:49:39,050 We looked at two routing protocols-- link state 1103 00:49:39,050 --> 00:49:41,190 and distance vector. 1104 00:49:41,190 --> 00:49:43,070 In distance vector, the computation 1105 00:49:43,070 --> 00:49:46,250 is distributed with these Bellman-Ford update steps. 1106 00:49:46,250 --> 00:49:48,560 And the distance vector protocol is 1107 00:49:48,560 --> 00:49:50,600 very beautiful in that it's very, very simple. 1108 00:49:50,600 --> 00:49:52,122 It works for small networks. 1109 00:49:52,122 --> 00:49:54,080 But to make the ideal work for bigger networks, 1110 00:49:54,080 --> 00:49:57,590 you have to enhance the distance with the actual path. 1111 00:49:57,590 --> 00:49:59,262 And if you enhance it with the path, 1112 00:49:59,262 --> 00:50:01,220 you actually avoid a lot of these routing loops 1113 00:50:01,220 --> 00:50:01,762 that show up. 1114 00:50:01,762 --> 00:50:02,780 You can't eliminate it. 1115 00:50:02,780 --> 00:50:06,330 But you can mitigate the effect of it. 1116 00:50:06,330 --> 00:50:07,918 In the link state protocol, there's 1117 00:50:07,918 --> 00:50:09,210 actually more work that's done. 1118 00:50:09,210 --> 00:50:12,480 There's a lot more information that's flooded between nodes. 1119 00:50:12,480 --> 00:50:14,400 But the protocol converges quicker 1120 00:50:14,400 --> 00:50:17,875 than these distance vector and path vector protocols usually. 1121 00:50:17,875 --> 00:50:20,250 Link state protocol, you flood this neighbor information. 1122 00:50:20,250 --> 00:50:21,375 You consume more bandwidth. 1123 00:50:21,375 --> 00:50:23,667 There's a lot more bandwidth that's used in the network 1124 00:50:23,667 --> 00:50:24,372 in flooding it. 1125 00:50:24,372 --> 00:50:25,830 And the computation is centralized. 1126 00:50:25,830 --> 00:50:27,560 You run Dijkstra's shortest path. 1127 00:50:27,560 --> 00:50:29,460 So what the internet does in general-- 1128 00:50:29,460 --> 00:50:31,170 I'll pick up on this two lecture-- or three lectures 1129 00:50:31,170 --> 00:50:33,295 from now, when I talk about how the internet really 1130 00:50:33,295 --> 00:50:35,730 works and applies the concepts we've studied. 1131 00:50:35,730 --> 00:50:38,460 What you'll find is that networks like MIT's network 1132 00:50:38,460 --> 00:50:40,740 will run a protocol like-- 1133 00:50:40,740 --> 00:50:43,530 a link state like protocol to achieve connectivity 1134 00:50:43,530 --> 00:50:45,300 between nodes inside MIT. 1135 00:50:45,300 --> 00:50:47,682 And then routers at the edge of MIT connecting 1136 00:50:47,682 --> 00:50:49,140 to other internet service providers 1137 00:50:49,140 --> 00:50:52,008 run a path vector protocol, like BGP. 1138 00:50:52,008 --> 00:50:53,550 And all of these things work together 1139 00:50:53,550 --> 00:50:55,830 and they work because ultimately, all of the switches 1140 00:50:55,830 --> 00:50:57,510 create these routing table entries 1141 00:50:57,510 --> 00:51:00,870 that have a mapping between destinations and routes 1142 00:51:00,870 --> 00:51:02,793 or links that have to be used. 1143 00:51:02,793 --> 00:51:03,960 So that's the routing story. 1144 00:51:03,960 --> 00:51:05,730 We'll pick it up in recitation tomorrow 1145 00:51:05,730 --> 00:51:09,140 and see you back on Wednesday.