Serval: an end-host stack for service-centric networking

NSDI, pp. 7-7, 2012.

Cited by: 150|Bibtex|Views51|Links
EI
Keywords:
online service provideruninterrupted service accessonline serviceservice-centric networkchange network addressMore(6+)
Weibo:
This paper presents a new end-host stack and layering model, and the larger Serval architecture for service discovery, that provides the right abstractions and protocols to more naturally support service-centric networking

Abstract:

Internet services run on multiple servers in different locations, serving clients that are often mobile and multihomed. This does not match well with today's network stack, designed for communication between fixed hosts with topology-dependent addresses. As a result, online service providers resort to clumsy and management-intensive work-...More

Code:

Data:

0
Introduction
  • The Internet is increasingly a platform for accessing services that run anywhere, from servers in the datacenter and computers at home, to the mobile phone in one’s pocket and a sensor in the field.
  • Serval provides a service-aware network stack, where applications communicate directly on service names instead of addresses and ports.
  • The SAL maps service names in packets to network addresses, based on rules in its service table.
Highlights
  • The Internet is increasingly a platform for accessing services that run anywhere, from servers in the datacenter and computers at home, to the mobile phone in one’s pocket and a sensor in the field
  • We present the Serval architecture that runs on top of an unmodified network layer
  • Previous works consider some of the problems we address, none provides a comprehensive solution for service access, control, dynamicity, and multiplicity
  • The stack offers a clean service-level control/data plane split: the user-space service controller can manage service resolution based on policies, listen for servicerelated events, monitor service performance, and communicate with other controllers; the Service Access Layer (SAL) provides a service-level data plane responsible for connecting to services through forwarding over service tables
  • This paper presents a new end-host stack and layering model, and the larger Serval architecture for service discovery, that provides the right abstractions and protocols to more naturally support service-centric networking
  • More information and source code are available at www.serval-arch.org
Results
  • By handling flow mobility and migration above the network layer, Serval allows addresses to change dynamically as hosts move.
  • The stack offers a clean service-level control/data plane split: the user-space service controller can manage service resolution based on policies, listen for servicerelated events, monitor service performance, and communicate with other controllers; the Service Access Layer (SAL) provides a service-level data plane responsible for connecting to services through forwarding over service tables.
  • Service-level anycast forwarding: Figure 5 shows a more elaborate connection establishment example that illustrates the SAL’s indirection support, allowing efficient, late-binding, and stateless load balancing, touching only the first packet of a connection.
  • The service-level control/data plane split is central to this ability; the controller disseminates serviceID prefixes to build service resolution networks, while the SAL applies rules to packets, sending them onward—if necessary, through service routers deeper in the network— to a remote service instance.
  • Including the SAL, service table, and control interface in the design allowed them to unify the implementations of service routers and end-hosts, with only the policy defining their distinct roles.
  • The section is organized around example systems the authors built for each of these tasks: a replicated front-end web service that provides dynamic load balancing between servers (§6.1), a back-end storage system that uses partitioning for scalability (§6.2), and servers that migrate individual connections between interfaces or entire virtual machines, to achieve higher utilization (§6.3).
  • The SAL maps the serviceID to a partition using LPM in the service table, and forwards the request to a responsible server that listens on the common prefix.
Conclusion
  • The application uses a standard PF INET socket, and the authors map legacy IP addresses and ports to serviceIDs and flowIDs. Supporting unmodified applications: If the end-host installs a Serval stack, translation between legacy and Serval packets can be done on-the-fly without terminating a connection: A virtual network interface can capture legacy packets to particular address blocks, translate the legacy IP addresses and ports to Serval identifiers.
  • This paper presents a new end-host stack and layering model, and the larger Serval architecture for service discovery, that provides the right abstractions and protocols to more naturally support service-centric networking.
  • More information and source code are available at www.serval-arch.org
Summary
  • The Internet is increasingly a platform for accessing services that run anywhere, from servers in the datacenter and computers at home, to the mobile phone in one’s pocket and a sensor in the field.
  • Serval provides a service-aware network stack, where applications communicate directly on service names instead of addresses and ports.
  • The SAL maps service names in packets to network addresses, based on rules in its service table.
  • By handling flow mobility and migration above the network layer, Serval allows addresses to change dynamically as hosts move.
  • The stack offers a clean service-level control/data plane split: the user-space service controller can manage service resolution based on policies, listen for servicerelated events, monitor service performance, and communicate with other controllers; the Service Access Layer (SAL) provides a service-level data plane responsible for connecting to services through forwarding over service tables.
  • Service-level anycast forwarding: Figure 5 shows a more elaborate connection establishment example that illustrates the SAL’s indirection support, allowing efficient, late-binding, and stateless load balancing, touching only the first packet of a connection.
  • The service-level control/data plane split is central to this ability; the controller disseminates serviceID prefixes to build service resolution networks, while the SAL applies rules to packets, sending them onward—if necessary, through service routers deeper in the network— to a remote service instance.
  • Including the SAL, service table, and control interface in the design allowed them to unify the implementations of service routers and end-hosts, with only the policy defining their distinct roles.
  • The section is organized around example systems the authors built for each of these tasks: a replicated front-end web service that provides dynamic load balancing between servers (§6.1), a back-end storage system that uses partitioning for scalability (§6.2), and servers that migrate individual connections between interfaces or entire virtual machines, to achieve higher utilization (§6.3).
  • The SAL maps the serviceID to a partition using LPM in the service table, and forwards the request to a responsible server that listens on the common prefix.
  • The application uses a standard PF INET socket, and the authors map legacy IP addresses and ports to serviceIDs and flowIDs. Supporting unmodified applications: If the end-host installs a Serval stack, translation between legacy and Serval packets can be done on-the-fly without terminating a connection: A virtual network interface can capture legacy packets to particular address blocks, translate the legacy IP addresses and ports to Serval identifiers.
  • This paper presents a new end-host stack and layering model, and the larger Serval architecture for service discovery, that provides the right abstractions and protocols to more naturally support service-centric networking.
  • More information and source code are available at www.serval-arch.org
Tables
  • Table1: Comparison of BSD socket protocol families: INET sockets (e.g., TCP/IP) use both IP address and port number, while Serval simply uses a serviceID
  • Table2: TCP throughput of the native TCP/IP stack, the Serval stack, and the two stacks connected through a translator. UDP routing throughput of native IP forwarding and the Serval stack
  • Table3: Applications currently ported to Serval
Download tables as Excel
Reference
  • BGPSEC protocol specification, draft-lepinski-bgpsec-protocol02, 2012.
    Google ScholarFindings
  • IETF TRILL working group. http://www.ietf.org/html.charters/trill-charter.html.
    Findings
  • M. Al-Fares, S. Radhakrishnan, B. Raghavan N. Huang, and A. Vahdat. Hedera: Dynamic flow scheduling for data center networks. In NSDI, Apr. 2010.
    Google ScholarLocate open access versionFindings
  • M. Arye. FlexMove: A protocol for flexible addressing on mobile devices. Technical Report TR-900-11, Princeton CS, June 2011.
    Google ScholarFindings
  • H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish. A layered naming architecture for the Internet. In SIGCOMM, Aug. 2004.
    Google ScholarLocate open access versionFindings
  • D. Clark, J. Wroclawski, K. Sollins, and R. Braden. Tussle in Cyberspace: Defining tomorrow’s Internet. In SIGCOMM, Aug. 2002.
    Google ScholarLocate open access versionFindings
  • J. Day, I. Matta, and K. Mattar. Networking is IPC: A guiding principle to a better Internet. In ReArch, Dec. 2008.
    Google ScholarLocate open access versionFindings
  • D. Farinacci, V. Fuller, D. Meyer, and D. Lewis. Locator/ID separation protocol (LISP), draft-ietf-lisp-22, Feb. 2012.
    Google ScholarFindings
  • A. Feldmann, L. Cittadini, W. Muhlbauer, R. Bush, and O. Maennel. HAIR: Hierarchical architecture for Internet routing. In ReArch, Dec. 2009.
    Google ScholarLocate open access versionFindings
  • A. Ford, C. Raiciu, M. Handley, S. Barre, and J. Iyengar. Architectural Guidelines for Multipath TCP Development, Mar. 2011. RFC 6182.
    Google ScholarFindings
  • B. Ford and J. Iyengar. Breaking up the transport logjam. In HotNets, Oct. 2008.
    Google ScholarLocate open access versionFindings
  • V. Fuller, D. Farinacci, D. Meyer, and D. Lewis. LISP alternative topology (LISP+ALT), draft-ietf-lisp-alt-10, Dec. 2011.
    Google ScholarLocate open access versionFindings
  • A. Greenberg, N. Jain, S. Kandula, C. Kim, P. Lahiri, D. Maltz, P. Patel, and S. Sengupta. VL2: A scalable and flexible data center network. In SIGCOMM, Aug. 2009.
    Google ScholarLocate open access versionFindings
  • C. Kim, M. Caesar, and J. Rexford. Floodless in SEATTLE: A scalable Ethernet architecture for large enterprises. In SIGCOMM, Aug. 2008.
    Google ScholarLocate open access versionFindings
  • T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica. A data-oriented (and beyond) network architecture. In SIGCOMM, Aug. 2007.
    Google ScholarLocate open access versionFindings
  • D. Mazieres, M. Kaminsky, M. F. Kaashoek, and E. Witchel. Separating key management from file system security. In SOSP, Dec. 1999.
    Google ScholarLocate open access versionFindings
  • memcached. http://memcached.org/, 2012.
    Findings
  • J. Mudigonda, P. Yalagandula, M. Al-Fares, and J. C. Mogul. SPAIN: COTS data-center Ethernet for multipathing over arbitrary topologies. In NSDI, Apr. 2010.
    Google ScholarLocate open access versionFindings
  • R. N. Mysore, A. Pamboris, N. Farrington, N. Huang, P. Miri, S. Radhakrishnan, V. Subramanya, and A. Vahdat. PortLand: A scalable fault-tolerant layer 2 data center network fabric. In SIGCOMM, Aug. 2009.
    Google ScholarLocate open access versionFindings
  • P. Natarajan, F. Baker, P. D. Amer, and J. T. Leighton. SCTP: What, why, and how. Internet Comp., 13(5):81–85, 2009.
    Google ScholarLocate open access versionFindings
  • P. Nikander, A. Gurtov, and T. R. Henderson. Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks. IEEE Comm. Surveys, 12 (2), Apr. 2010.
    Google ScholarLocate open access versionFindings
  • C. E. Perkins. IP mobility support for IPv4, RFC3344, Aug. 2002.
    Google ScholarFindings
  • R. Perlman. Rbridges: Transparent routing. In INFOCOM, Mar. 2004.
    Google ScholarLocate open access versionFindings
  • B. Podmayersky. An incremental deployment strategy for Serval. Technical Report TR-903-11, Princeton CS, June 2011.
    Google ScholarFindings
  • U. Saif and J. M. Paluska. Service-oriented network sockets. In MobiSys, May 2003.
    Google ScholarFindings
  • A. C. Snoeren and H. Balakrishnan. An end-to-end approach to host mobility. In MOBICOM, Aug. 2000.
    Google ScholarLocate open access versionFindings
  • I. Stoica, D. Adkins, S. Zhuang, S. Shenker, and S. Surana. Internet indirection infrastructure. Trans. Networking, 12(2), Apr. 2004.
    Google ScholarLocate open access versionFindings
  • P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. RFC 2136: Dynamic Updates in the Domain Name System, Apr. 1997.
    Google ScholarFindings
  • M. Walfish, H. Balakrishnan, and S. Shenker. Untangling the Web from DNS. In NSDI, Mar. 2004.
    Google ScholarLocate open access versionFindings
  • M. Walfish, J. Stribling, M. Krohn, H. Balakrishnan, R. Morris, and S. Shenker. Middleboxes no longer considered harmful. In OSDI, Dec. 2004.
    Google ScholarLocate open access versionFindings
  • D. Wischik, C. Raiciu, A. Greenhalgh, and M. Handley. Design, implementation and evaluation of congestion control for multipath TCP. In NSDI, Mar. 2011.
    Google ScholarLocate open access versionFindings
  • S. Zhuang, K. Lai, I. Stoica, R. Katz, and S. Shenker. Host mobility using an Internet indirection infrastructure. In MobiSys, May 2003.
    Google ScholarFindings
Your rating :
0

 

Tags
Comments