Aaron Gember, Robert Grandl, Junaid Khalid, Aditya Akella
{"title":"软件定义的中间件网络框架的设计与实现","authors":"Aaron Gember, Robert Grandl, Junaid Khalid, Aditya Akella","doi":"10.1145/2486001.2491686","DOIUrl":null,"url":null,"abstract":"Middleboxes (MBs) are used widely to ensure security (e.g., intrusion detection systems), improve performance (e.g., WAN optimizers), and provide other novel network functionality [4, 6]. Recently, researchers have proposed several new architectures for MB deployment, including Stratos [2], CoMb [4], and APLOMB [6]. These frameworks all advocate dynamic deployment of software-based MBs with the goal of increasing flexibility, improving efficiency, and reducing management overhead. However, approaches for controlling the behavior of MBs (i.e., how MBs examine and modify network traffic) remain limited. Today, configuration policies and parameters are manipulated using narrow, MB-specific configuration interfaces, while internal algorithms and state are completely inaccessible and unmodifiable. This apparent lack of finegrained control over MBs and their state precludes correct and performant implementation of control scenarios that involve re-allocating live flows across MBs: e.g., server migration, scale up/down of MBs to meet cost-performance trade-offs, recovery from network or MB failures, etc. Several key requirements must be satisfied to effectively support the above scenarios. To illustrate these requirements, we consider a scenario where MB instances are added and removed based on current network load [2] (Figure 1). When scaling up, some in-progress flows may need to be moved to a new MB instance to reduce the load on the original instance. To preserve the correctness and fidelity of MB operations, the new instance must receive the internal MB state associated with the moved flows, while the old instance still has the internal state associated with the remaining flows. For some MBs (e.g., an intrusion prevention","PeriodicalId":159374,"journal":{"name":"Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM","volume":"197 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2013-08-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"35","resultStr":"{\"title\":\"Design and implementation of a framework for software-defined middlebox networking\",\"authors\":\"Aaron Gember, Robert Grandl, Junaid Khalid, Aditya Akella\",\"doi\":\"10.1145/2486001.2491686\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"Middleboxes (MBs) are used widely to ensure security (e.g., intrusion detection systems), improve performance (e.g., WAN optimizers), and provide other novel network functionality [4, 6]. Recently, researchers have proposed several new architectures for MB deployment, including Stratos [2], CoMb [4], and APLOMB [6]. These frameworks all advocate dynamic deployment of software-based MBs with the goal of increasing flexibility, improving efficiency, and reducing management overhead. However, approaches for controlling the behavior of MBs (i.e., how MBs examine and modify network traffic) remain limited. Today, configuration policies and parameters are manipulated using narrow, MB-specific configuration interfaces, while internal algorithms and state are completely inaccessible and unmodifiable. This apparent lack of finegrained control over MBs and their state precludes correct and performant implementation of control scenarios that involve re-allocating live flows across MBs: e.g., server migration, scale up/down of MBs to meet cost-performance trade-offs, recovery from network or MB failures, etc. Several key requirements must be satisfied to effectively support the above scenarios. To illustrate these requirements, we consider a scenario where MB instances are added and removed based on current network load [2] (Figure 1). When scaling up, some in-progress flows may need to be moved to a new MB instance to reduce the load on the original instance. To preserve the correctness and fidelity of MB operations, the new instance must receive the internal MB state associated with the moved flows, while the old instance still has the internal state associated with the remaining flows. For some MBs (e.g., an intrusion prevention\",\"PeriodicalId\":159374,\"journal\":{\"name\":\"Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM\",\"volume\":\"197 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2013-08-12\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"35\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/2486001.2491686\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/2486001.2491686","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Design and implementation of a framework for software-defined middlebox networking
Middleboxes (MBs) are used widely to ensure security (e.g., intrusion detection systems), improve performance (e.g., WAN optimizers), and provide other novel network functionality [4, 6]. Recently, researchers have proposed several new architectures for MB deployment, including Stratos [2], CoMb [4], and APLOMB [6]. These frameworks all advocate dynamic deployment of software-based MBs with the goal of increasing flexibility, improving efficiency, and reducing management overhead. However, approaches for controlling the behavior of MBs (i.e., how MBs examine and modify network traffic) remain limited. Today, configuration policies and parameters are manipulated using narrow, MB-specific configuration interfaces, while internal algorithms and state are completely inaccessible and unmodifiable. This apparent lack of finegrained control over MBs and their state precludes correct and performant implementation of control scenarios that involve re-allocating live flows across MBs: e.g., server migration, scale up/down of MBs to meet cost-performance trade-offs, recovery from network or MB failures, etc. Several key requirements must be satisfied to effectively support the above scenarios. To illustrate these requirements, we consider a scenario where MB instances are added and removed based on current network load [2] (Figure 1). When scaling up, some in-progress flows may need to be moved to a new MB instance to reduce the load on the original instance. To preserve the correctness and fidelity of MB operations, the new instance must receive the internal MB state associated with the moved flows, while the old instance still has the internal state associated with the remaining flows. For some MBs (e.g., an intrusion prevention