updating 311 stuff for now

cst311/lec/lec15.md

@@ -0,0 +1,66 @@
+# lec15
+
+## DHCP 
+
+For a client to setup a connection with a server using DHCP we must (as a clien) send out:
+
+```
+source addres: 0.0.0.68
+dest: 255.255.255.255,67
+yiaddr: 0.0.0.0
+transaction ID: 654
+```
+
+This is broadcasted out so that nearby serer can "hear" this request and send back some pertinent information for the client's new address on the network:
+
+```
+src: somthing
+dest: ff.ff.ff.ff,44
+yiaddr: something else
+transactioni ID: sumting
+lifetime: long time
+```
+The client then responds using its _previous_ information because we must first acknoledge to the server that we are going to use that new information.
+
+## From subnet to Internet
+
+A given machine's network address must be routed through some interface(modem) to reach the rest of the internet. 
+This modem is the part between us and the internet which translates our local address to an address that is recognizable to the rest of the internet.
+
+## Network address translation
+
+3 things our NAT router must do:
+
+1. Replace outgoing message addresses/port with NAT address/port
+
+2. Remember all the ingoing and outgoing addresses and port.
+
+3. Incoming datagrams must have their target address/ports changed to relevant local network address/ports.
+
+Basically the NAT must translate things going in and out to the proper direction.
+
+## ICMP
+
+> Internet Control Message Protocol
+
+## IPv6 
+
+> Initially, because 32-bits is almost not enough these days.
+
+This is becoming increasingly true as the IoT industry grows.
+
+> No more checksums
+
+Because we want to reduce the processing load on 
+
+> Options
+
+Specified in a seperate header from the top header using a flag
+
+> ICMPv6
+
+New stuff like _packet too big_ messages whch can be sent upstream to tell a host to reduce packet size.
+
+The whol point of this new protocol is to primarily simplify the implementation at an atomic level, and to also reduce the strain on routers to improve quality of service.
+
+To move towards IPv6 we can use tunneling which basically means we wrap our IPv6 datagram with an IPv4 header.

cst311/lec/lec16.md

@@ -0,0 +1,25 @@
+# lec16
+
+Now we'll look at an introduction to how routing (sort of) works, with a few constraints.
+
+## Constraints for Routing
+
+We know that no router can have a link to every other router in the world so we know that most data will have to hop over a few routers at least to get pretty much anywhere(welcome to heuristics).
+To add onto this constraint, each router will only have knowledge of the routers directly around it.
+This means we have a small, easy to update catalog of nearby routers, which hopefully small enough where searching it doesn't take too long.
+
+Further more each router must have some kind of "_length_" concept to determine how "_far away_" nearby routers are.
+This could be a ping time to send data to those nodes, or maybe a physical distance.
+Whatever the case may be, we have a _length_ or _distance_ to the surrounding nodes.
+
+In essence, these are the only constraints we have to build a routing algorithm.
+We know that we have tools like Dijkstra's algorithm but the problem is that with a huge network, say the size of the whole internet we will waste countless amounts of time.
+For this reason we have to come up with some kind of _good enough, nice one bro_ algorithm.
+
+## Routing Algorithm Goals
+
+1. Finish Fast
+	* graph traversal is cool and all but people have things to do. So we want to reach the end as fast as possible
+
+2. Easy Execution
+	* Individual nodes might be comprised of old hardware, slow and sluggish, so give them something easy to compute

cst311/lec/lec17.md

@@ -0,0 +1,14 @@
+# lec17
+
+## Distance Vector Algorithm 
+
+Properties of this algorithm include:
+
+* Nodes are self updating 
+	* This means that each node updates its distance table with all of its neighbors.
+
+The main advantage of this is that we don't need a knowledge of the whole map and we can have dynamic maps that change over time.
+
+Compared to Dijktra's algorihtm we are able to establish a much more realistic scenario, akin to how routers actually figure out how to route packets.
+We're able to to do this because we don't worry about mapping out the _entire_ network which, if you sending data across countries, would be monumental in size to map out.
+This is isn't even mentioning the amount of time and effort it would take to process the shortest path cost, assuming that giant network doesn't change because someone plugged in a router.

cst311/lec/lec18.md

@@ -0,0 +1,39 @@
+# lec18
+
+## Heirarchical Routing
+
+So far we've looked at routing from a very simple point of view.
+To better model reality we'll assume a new constraint: that being the internet as a network of networks.
+This means that the actual routers within each network must maintain multiple forwarding tables.
+One for intra-net routing, and another for inter-net routing.
+
+## Intra-AS Routing
+
+### RIP
+	
+Popular because it was included with BSD/unix back in 82.
+Uses simple distance vectoralgoritm for evaluating cost.
+
+1. Maximum distance of 15 hops
+2. Distance vectors exchanged every 30 seconds
+
+### OSPF
+
+> Open Shortest Path First
+
+Uses a link state algorithm.
+* LS pcket dissemination
+* Topology map at each node
+
+Security is built into the protocol itself.
+We allow for multiple _same-cost paths_ 
+
+Also uni- multi-casting 
+
+## Inter-AS Routing
+
+### BGP 
+
+> Border Gateway Protocol
+
+* Allows subnet to advertise its existent 

cst311/lec/lec19.md

@@ -0,0 +1,14 @@
+# lec19
+
+## Broadcast Routing
+
+We allow multiple identical streams to follow a _trunk_ structure wherein we only branch to a client when needed.
+This keeps bandwidth usage down on a network's links.
+
+## Multicast Problem
+
+Take the concept from the previous section, where we have a tree structure spread across a network.
+
+Our goal here would be to create some tree where all the _members_ for the data share the same tree.
+_Also multicast groups get their own subnet class_.
+This is to distinguish regular traffic from this multicast traffic[224.0.0.0].