1 / 28

CS 145A Case Study: Simplified BGP Finite State Machine

CS 145A Case Study: Simplified BGP Finite State Machine Netlab.caltech.edu/course Today Brief Introduction of routing protocols An example of Finite State Machine Lab 3 What does the Internet look like? Example: (/sbin/traceroute) C:>tracert cwis.usc.edu

omer
Download Presentation

CS 145A Case Study: Simplified BGP Finite State Machine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related