CS 145A Case Study: Simplified BGP Finite State Machine - PowerPoint PPT Presentation

omer
cs 145a case study simplified bgp finite state machine l.
Skip this Video
Loading SlideShow in 5 Seconds..
CS 145A Case Study: Simplified BGP Finite State Machine PowerPoint Presentation
Download Presentation
CS 145A Case Study: Simplified BGP Finite State Machine

play fullscreen
1 / 28
Download Presentation
CS 145A Case Study: Simplified BGP Finite State Machine
404 Views
Download Presentation

CS 145A Case Study: Simplified BGP Finite State Machine

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. CS 145ACase Study: Simplified BGP Finite State Machine Netlab.caltech.edu/course

  2. Today • Brief Introduction of routing protocols • An example of Finite State Machine • Lab 3

  3. What does the Internet look like? • Example: (/sbin/traceroute) C:\>tracert cwis.usc.edu Tracing route to cwis.usc.edu [128.125.253.146] 1 <1 ms Jorgensen-RSM-44.caltech.edu [131.215.44.253] 2 <1 ms Booth-border.ilan.caltech.edu [131.215.254.254] 3 <1 ms CalREN-Caltech.caltech.edu [192.41.208.49] 4 <1 ms JPL--CIT.POS.calren2.net [198.32.248.5] 5 1 ms UCLA--JPL.POS.calren2.net [198.32.248.1] 6 1 ms ISI--UCLA.POS.calren2.net [198.32.248.29] 7 2 ms USC--ISI.POS.calren2.net [198.32.248.25] 8 3 ms rtr43-c2-gw.usc.edu [128.125.251.66] 9 2 ms rtr-gw-1.usc.edu [128.125.254.1] 10 2 ms cwis.usc.edu [128.125.253.146]

  4. Topology of the Network

  5. The Journey of a packet (1)131.215.44.214->131.215.44.253

  6. The Journey of a packet (2)131.215.44.253

  7. The Journey of a packet (2)131.215.44.253

  8. The Journey of a packet (2)131.215.44.253

  9. Necessary Information (1) • Where shall I pass the packet, for a given destination IP address? – Routing Table • Exmaple: [weixl@orchestra:~]> route

  10. How can the routers know the routing information?

  11. How? • Manually add/delete routing entries • Automatically exchange routing information between routers.

  12. Routing Protocol A: hi, are you there? B: yes. A: Can I tell you a piece of news? B: Sure. A: I have a way to get to www.usc.edu. B: ok. I will send you all the packets that are going to www.usc.edu. … B: Hi, Can I tell you some news, too? A: Yes! B: I can connect to all the machines in “cs.caltech.edu” A: ok. I will send you all the packets that are going to “cs.caltech.edu”. ……

  13. Routing Protocol A to C: hi, are you there? ... A to C: hi, are you there? … A to B: I think C is down. And from now on, I cannot contact USC. B: OK. I will try other paths when I get packets for USC. …

  14. Routing Protocol • Good: Efficiently broadcast up-to-date routing information • Bad: Rumor may be broadcast efficiently, too. • Argument: If the majority is good… • The algorithm should be correct in distributed environments.

  15. Routing Protocols • Autonomous System

  16. Routing Protocols • Inside Autonomous System: Embrace the Freedom! • RIP (Routing Information Protocol) • OSPF (Open Shortest Path First) • Between Autonomous System (Exterior Gateway Protocol): More consideration… • BGP (Border Gateway Protocol)

  17. Border Gateway Protocol-4 • Inter-Autonomous System Communication • Propagate Path Information • Support Policy • Incremental Updates • Assume reliable transmission (TCP) • http://www.ietf.org/rfc/rfc1771.txt

  18. Simplified BGP State Machine

  19. BGP Packets • Packets Format: • 0-15th Byte: FF (hexadecimal) • 16-17th Byte: Unsigned number, Length of the Packet (>=19) • 18th Byte: Packet Type: • 1 OPEN • 2 UPDATE • 3 NOTIFICATION • 4 KEEPALIVE • 19th Byte to the end of the Packet: Routing Data

  20. Detailed Specification • http://www.ietf.org/rfc/rfc1771.txt Appendix I (page 47)

  21. Lab 3

  22. Lab 3 - Task • Implement a (simplified) simplified BGP Finite State Machine: • Ignore the timers • Ignore the details of Routing Data

  23. Lab3 - Finite State Machine

  24. Lab 3 - Requirements • The implementation is based on TCP. • The implementation is able to actively connect to multiple machines and it is able to accept requests from multiple machines. • The implementation allows at most one connection from one machine (identified by IP / hostname). • For each connection, the implementation implements the Lab3 Finite State Machine.

  25. Lab 3 - Details • A program “server” • Read from a file called “server.conf”. Format of “server.conf”: • (1st line:) Listen_Port Connection_Num(N) • (2nd line:) IP_1 Port_1 • (…) • (N+1st line:) IP_N Port_N • The server should read from “server.conf”, listen to Listen_Port for new connection, at the same time, actively connect the specified machines (IP_1:Port_1, IP_2:Port_2, … IP_N:Port_N)

  26. Lab 3 - Possible Problems • Implementation of Finite State Machine • Check the errors (including operation errors and Packet errors) • Multiple connections from the same machine

  27. Lab 3 - Tips • Re-Use the codes in Lab 1 • How to implement the Finite State Machine? • “if … then…” • “State transition table” • How to test? • Incremental Development • DON’T START AT THE LAST MOMENT!

  28. Lab 3 • Due: Dec 1st (Sunday) 23:59:59 • Email: weixl@caltech.edu • Grading • TA hours: Tue / Thu (20:00 – 22:00) JRG 170 Except: Nov.19 / Nov.21