Homework #18 - Architecture - Due Wednesday November 2, 11PM


Turn in this assignment via email (vern@berkeley.edu) by the due date, with the term Homework in the Subject.
In networking, the notion of "architecture" refers to the overall structure of how and where functionality is allocated/realized. This includes the abstractions that the structure aims to provide, and the related notion of what types of state exist, where they reside, and how they are managed. One of the abstractions often concerns the design of naming, which can govern what sort of relationships the architecture allows users to express.

For example, in the Internet's current architecture, the decision to divide functionality into particular layers (Physical/Link/Internet/Transport/Application) and the services those layers provide reflect architectural choices. So does its naming, such as the design of IP's addresses - what they mean (i.e., identifying a network interface) and how they are structured (prefix hierarchy to facilitate routing; multicast and broadcast functionality; blocks reserved for private networks; no enforcement of source address validity).

Architecture often has significant implications for how well the network can perform various tasks, including security considerations. As you do this assignment, keep this notion in mind; try not to overly focus on specific mechanisms used to achieve architectural functionality.

Read the paper Ethane: Taking Control of the Enterprise, Martin Casado et al., SIGCOMM 2007

  1. Briefly write up your views of:

    1. What are the main contributions of this paper?

    2. What parts of the paper do you find unclear? (optional)

    3. What parts of the paper are questionable? (That is, you think a conclusion may be wrong, an approach or evaluation technically flawed, or data ill-presented.)

  2. Devise and frame a particular architectural approach for addressing a specific network security issue. The issue you tackle needn't have anything to do with those explored in the paper, and can be narrow or broad in scope. However, try to be sure that your approach is architectural, rather than simply a particular mechanism. That is, it should concern underlying abstractions/abstract notions, and placement of functionality and state.

    Feel free to think boldly! In particular, you should not worry about ensuring backward compatibility or incremental deployment (though you should identify whether or not your scheme has these properties in part (7) below).

    1. Briefly describe your overall approach.
    2. What are the abstractions in your approach?
    3. Where sort of functionality and state does your approach use, and where do you place it?
    4. What are your approach's strengths and weaknesses?

    5. Be prepared to briefly talk about the approach in class.