1. David Clark, Robert Braden, Aaron Falk, Venkata Pingali ACM SIGCOMM 2003 Workshops August 25&27, 2003 2005.09.07 Jongsoo Lee (jslee@mmlab.snu.ac.kr)jslee@mmlab.snu.ac.kr FARA: Reorganizing the Addressing Architecture

2. 2/14 Content Introduction Abstraction, Modularity and Simplicity FARA M-FARA Conclusion

3. 3/14 147.46.114.112 mmlab.snu.ac.kr Seoul University Abstraction, Modularity and Simplicity Abstraction Modularity Simplicity Node Identity ↕ Network Location

4. 4/14 Content Introduction FARA Components Functions The System Model M-FARA Conclusion

5. 5/14 Components Entity Generalization of an application Maintain application state & communication state Association Logical communication link Combination of communication state & flowing data Communication Substrate Deliver data on behalf of associations Using Forwarding Directive (FD) a E2 E1 Communication substrate API The smallest mobility unit & no global set of names No global namespace No single global address space Assumptions a No new global namespace of entity name! How do associations get established when there is no global namespace for entities? How are packet delivery paths maintained as entities move?

6. 6/14 Functions Creating an Association Rendezvous Mechanism ־Not dest AId, Rendezvous information (RI) in initial packet ־Discovery & Initiation FARA Directory Service (fDS) ־Single generic directory service ־RI → FD End-to-End Security Support a range of source verification mechanisms, ranging from nothing to high security Assurance level ↑ → overhead, complexity and latency ↑

7. 7/14 Functions Communication Substrate Mechanisms Packet Delivery ־Connectionless best-effor packet delivery is basic ־allow wide range architecture FD Management ־use API for manipulation and signaling ־Mobility support Network-Layer Security ־Use own notion of identity (different from identity of upper-layer) Delivery Failure Notification Resource Control

8. 8/14 Functions Forwarding Directive Uniform and well-defined syntax Derived from the network topology Network part + local-delivery (slot ID) part → FD May contain identifiers drawn from a global address space May be reversible May be transformed in route Slots A logical point of attachment of the entity to the network topology The place to which an FD directs packet delivery and in which an entity is located

9. 9/14 The System Model ENTITY... AId 1 AId 2 AId 3 AId n Slot FD1 FD2 Association State OS level User level You can use another model! Entity Start up Request slot Get own FD If the entity provides a service, Register a (service → FD) with the fDs Communication Substrate

10. 10/14 Content Introduction FARA M-FARA Overview Implementation Conclusion

11. 11/14 Overview Network Addressing Destination FD is independent of the topological location. 2-level domain hierarchy – (FDup, FDdown) ־FDup : from source to global routable domain ־FDdown : from global domain to destination FD Maintenance Using Mobility Agents (M-agents) Indirection or Redirect message Associations Simple (similar with UDP) + authorization (similar with DCCP) → Connected + mobility → Mobile + reliability & ordering → Reliable (similar with TCP) M agent

12. 12/14 Implementation Low-level end-system : UNIX processes using UNIX IPC Communication via Internet overlays with UDP Routing Hop-by-hop forwarding & Source Routing FD form ־(HopFD1, HopFD2, …, SlotID) ־HopFD : IPv4 or IPv6 address

13. 13/14 Content Introduction Abstraction, Modularity and Simplicity FARA Components Functions The System Model M-FARA Overview Implementation Conclusion

14. 14/14 Although concepts are not new, assembly into a general model is new! Modularized 2-level architecture Upper-level : abstractions of entities and associations Lower-level : communication substrate Separation location from identity Provide support for general mobility Independent evolution of mechanisms at the two level FARA is a work in progress Conclusion