Understanding Internet Architecture and Networking Principles

The content explores the architecture and goals of the Internet, focusing on its original objectives, survivability in the face of failure, and evolving requirements. It delves into how networks function, describing behaviors and packet handling. Additionally, it discusses the framework for describing packet handling behavior in networks, emphasizing the alignment of interests between packet senders and implementers.

• Internet Architecture
• Networking Principles
• Packet Behavior
• Network Survivability
• Internet Requirements

ama_g Follow

Uploaded on Sep 15, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. The Architecture of the Internet 1 CLARK, David. Designing an Internet. MIT Press. 2018. Chapter 5 Arquiteturas de Redes de Computadores (2019.1)

2. Internet Architecture original goals 2 Internet communication must continue despite loss of networks or gateways. The Internet must support multiple types of communications service. The Internet architecture must accommodate a variety of networks. The Internet architecture must permit distributed management of its resources. The Internet architecture must be cost effective. The Internet architecture must permit host attachment with a low level of effort. The resources used in the Internet architecture must be accountable. 1. 2. 3. 4. 5. 6. 7. Arquiteturas de Redes de Computadores (2019.1)

3. Internet Architecture original goals 3 Survivability in the Face of Failure Types of service Varieties of networks Distributed management Cost effectiveness Cost of attaching a host Accountability 1. 2. 3. 4. 5. 6. 7. Arquiteturas de Redes de Computadores (2019.1)

4. Internet Architecture Requirements 4 1988 List 2008 List Robustness/Resilience Internetworking Heterogeneity Distributed management Cost Ease of Attachment Accountability Security Availability and resilience Economic viability Better management Better Meet society s needs Longevity Support for tomorrow s computing Exploit tomorrow s networking Support tomorrow s applications Fit for purpose (it works?) 1. 1. 2. 2. 3. 3. 4. 4. 5. 5. 6. 6. 7. 7. 8. 9. 10. Arquiteturas de Redes de Computadores (2019.1)

5. Architecture and Function 5 CLARK, David. Designing an Internet. MIT Press. 2018. Chapter 6 Arquiteturas de Redes de Computadores (2019.1)

6. What a Network Does? 6 How we describe, in architectural terms, what a network does? Range of behavior is defined by the expressive power of the packet header. Per-Hop Behavior (PHB) is not just forwarding. Arquiteturas de Redes de Computadores (2019.1)

7. Framework to describe PHB execution 7 Alignment of interests: aligned or adverse Relationship between the sender of the packet and the owner of the element that implements the PHB. Delivery: intentional, contingent, topological, or coerced How the packet arrives at the element that implements the PHB? Parametrization: explicit or implicit The packet triggers the execution of a PHB, and the data in the packet is the input to that PHB. Arquiteturas de Redes de Computadores (2019.1)

8. Pruning the Space of Options 8 Aligned If the sender wants the PHB to be executed, then intentional delivery and explicit arguments make sense. Contingent delivery may be suitable in some cases (e.g., the basic forwarding function), but explicit arguments (e.g., the address field) still make sense. Adverse If the sender does not want the PHB to be executed (it represents the interests of the receiver, not the sender), then the receiver cannot expect the sender to provide any explicit arguments to the PHB. In this case, the PHB must depend on implicit arguments. Also, the PHB cannot count on intentional delivery, so coerced delivery is the best option, with contingent or topological delivery as a fallback. Arquiteturas de Redes de Computadores (2019.1)

9. Example: NAT boxes 9 NAT boxes implement a PHB that is not simple forwarding but includes rewriting of the source or destination address field. Disrupted assumptions: Single, global address space No per-flow state in forwarding elements. NAT boxes are an example of intentional delivery with explicit parameters (the addresses and port numbers). If the interests of the end points are aligned, NATs are normally a small nuisance; if the interests are not aligned, they provide a measure of protection, and in that respect fall into the coerced category. Arquiteturas de Redes de Computadores (2019.1)

10. Example: Firewalls 10 Are an example of a PHB that is adverse to the interests of the hostile sender (potential attacker) and thus must depend on implicit information. The firewall has the poorly defined task of trying to distinguish good behavior from bad, based on whatever hints can be gleaned from the packets. Sometimes users want the blocking to succeed (when they are being attacked) and sometimes they want it to fail (when some third party, such as a conservative government, is trying to block their access to other sites on the Internet). Arquiteturas de Redes de Computadores (2019.1)

11. Example: Tunnels and overlay networks 11 This PHB causes the packet to be sent to the destination address in the outer packet, not the inner packet. When the packet reaches that destination, a PHB there must either remove the outer packet or reencapsulate the inner packet in a new outer packet. The encapsulated packet is the explicit information used as input to the end point of the tunnel. Sometimes the starting point of the tunnel is contingent or topological, sometimes it is coincident with the sender, and sometimes it is intentional. Arquiteturas de Redes de Computadores (2019.1)

12. Tussle and Regions 12 Different actors within the network (the sender, the receiver, the ISPs, other third-party participants) have the right to control certain parts of the network, and within each such region of the network, the PHBs found there will be used to further the intentions of that actor. The design of applications can also shift the balance of power among the various actors. but from the point of view of balance of control, I believe that a network operator should have to offer a very strong justification for inserting a service into a communication where neither end point requested or expected it to be there. Arquiteturas de Redes de Computadores (2019.1)

13. Generality 13 The taxonomy of delivery modes, alignment of interests, and parameter modes applies equally to both packet-level PHBs and higher-level services. One could use the term PHB generally to mean any service element that is inserted into a data flow or restrict the term to lower-level functions like firewalls or routers. Since my goal is to discuss the role of architecture, I am most concerned with cases where a PHB justifies adding to the expressive power of the packet. Arquiteturas de Redes de Computadores (2019.1)

14. Architectural Alternatives for Expressive Power 14 Addressing Increasing the Expressive Power of a Design Blank scratch pad in the packet Pushdown stack model A heap Active networks Per-Flow State Signaling and state setup State initiation bit Maintaining state in intermediate elements In-network state associated with receivers Arquiteturas de Redes de Computadores (2019.1)

15. Other issues 17 PHBs and Control of Network Resources Debugging Expressive Power and Evolvability PHBs and Layering Arquiteturas de Redes de Computadores (2019.1)