The original paper is in English. Non-English content has been machine-translated and may contain typographical errors or mistranslations. ex. Some numerals are expressed as "XNUMX".
Copyrights notice
The original paper is in English. Non-English content has been machine-translated and may contain typographical errors or mistranslations. Copyrights notice
Recentemente, as demandas de aplicativos colocadas na rede tornaram-se mais multifacetadas. Serviços de comunicação aplicativo a aplicativo altamente funcionais, como agregação de largura de banda, comunicação tolerante a falhas e redes tolerantes a atrasos/interrupções (DTN), foram desenvolvidos independentemente na camada de rede, na camada de transporte e na camada de aplicação. Como resultado, as camadas de protocolo tornaram-se complicadas. Este artigo propõe inserir a Camada 5 (L5) entre a camada de aplicação e a camada de transporte para separar as políticas de comunicação e os mecanismos de comunicação para tornar a camada de protocolo mais clara. A camada de transporte (L4) fornece mecanismos de comunicação ponta a ponta, como fluxo de bytes confiável, enquanto L5 realiza políticas de comunicação, como agregação de largura de banda, combinando os mecanismos de comunicação em L4. Este artigo propõe cinco tipos de caminhos L5 como políticas de comunicação: (1) o caminho agrupado L5 para agregação de largura de banda ou comunicação tolerante a falhas, (2) o caminho L5 emendado espacialmente para comunicação com middleboxes, (3) o caminho L5 emendado temporalmente. caminho para DTN, (4) o caminho L5 agrupado e (5) o L5 agrupado sobre o caminho espacialmente emendado. Um aplicativo pode selecionar e usar um caminho L5 apropriado dependendo das circunstâncias da rede por meio de uma API comum. Um protótipo do L5 é implementado no espaço do usuário Linux como uma biblioteca para facilitar a implantação e manutenção. Uma avaliação mostra que o tempo de estabelecimento dos caminhos L5 é suficientemente curto e o desempenho dos caminhos L5 é comparável ou superior ao das tecnologias existentes.
Hiroki WATANABE
Keio University
Takao KONDO
Keio University
Kunitake KANEKO
Keio University
Fumio TERAOKA
Keio University
The copyright of the original papers published on this site belongs to IEICE. Unauthorized use of the original or translated papers is prohibited. See IEICE Provisions on Copyright for details.
Copiar
Hiroki WATANABE, Takao KONDO, Kunitake KANEKO, Fumio TERAOKA, "Inserting Layer-5 to Provide Applications with Richer Functions through Common API" in IEICE TRANSACTIONS on Communications,
vol. E101-B, no. 9, pp. 1967-1981, September 2018, doi: 10.1587/transcom.2017EBP3390.
Abstract: Recently, application demands placed on the network have become more multifaceted. Highly functional application-to-application communication services such as bandwidth aggregation, fault tolerant communication, and delay/disruption tolerant networking (DTN) were developed independently in the network layer, the transport layer, and the application layer. As a result, protocol layering has become complicated. This paper proposes to insert Layer-5 (L5) between the application layer and the transport layer to separate communication policies and communication mechanisms to make protocol layering clearer. The transport layer (L4) provides end-to-end communication mechanisms such as reliable byte stream while L5 realizes communication policies such as bandwidth aggregation by combining the communication mechanisms in L4. This paper proposes five types of L5-paths as communication policies: (1) the L5 bundled path for bandwidth aggregation or fault tolerant communication, (2) the L5 spatially-spliced path for communication with middleboxes, (3) the L5 temporally-spliced path for DTN, (4) the L5 spliced-bundled path, and (5) the L5 bundled over spatially-spliced path. An application can select and use an appropriate L5-path depending on the network circumstances through a common API. A prototype of L5 is implemented in the Linux user space as a library to make deployment and maintenance easier. An evaluation shows that establishment time of L5-paths is short enough and performance of L5-paths is comparable or superior to existing technologies.
URL: https://global.ieice.org/en_transactions/communications/10.1587/transcom.2017EBP3390/_p
Copiar
@ARTICLE{e101-b_9_1967,
author={Hiroki WATANABE, Takao KONDO, Kunitake KANEKO, Fumio TERAOKA, },
journal={IEICE TRANSACTIONS on Communications},
title={Inserting Layer-5 to Provide Applications with Richer Functions through Common API},
year={2018},
volume={E101-B},
number={9},
pages={1967-1981},
abstract={Recently, application demands placed on the network have become more multifaceted. Highly functional application-to-application communication services such as bandwidth aggregation, fault tolerant communication, and delay/disruption tolerant networking (DTN) were developed independently in the network layer, the transport layer, and the application layer. As a result, protocol layering has become complicated. This paper proposes to insert Layer-5 (L5) between the application layer and the transport layer to separate communication policies and communication mechanisms to make protocol layering clearer. The transport layer (L4) provides end-to-end communication mechanisms such as reliable byte stream while L5 realizes communication policies such as bandwidth aggregation by combining the communication mechanisms in L4. This paper proposes five types of L5-paths as communication policies: (1) the L5 bundled path for bandwidth aggregation or fault tolerant communication, (2) the L5 spatially-spliced path for communication with middleboxes, (3) the L5 temporally-spliced path for DTN, (4) the L5 spliced-bundled path, and (5) the L5 bundled over spatially-spliced path. An application can select and use an appropriate L5-path depending on the network circumstances through a common API. A prototype of L5 is implemented in the Linux user space as a library to make deployment and maintenance easier. An evaluation shows that establishment time of L5-paths is short enough and performance of L5-paths is comparable or superior to existing technologies.},
keywords={},
doi={10.1587/transcom.2017EBP3390},
ISSN={1745-1345},
month={September},}
Copiar
TY - JOUR
TI - Inserting Layer-5 to Provide Applications with Richer Functions through Common API
T2 - IEICE TRANSACTIONS on Communications
SP - 1967
EP - 1981
AU - Hiroki WATANABE
AU - Takao KONDO
AU - Kunitake KANEKO
AU - Fumio TERAOKA
PY - 2018
DO - 10.1587/transcom.2017EBP3390
JO - IEICE TRANSACTIONS on Communications
SN - 1745-1345
VL - E101-B
IS - 9
JA - IEICE TRANSACTIONS on Communications
Y1 - September 2018
AB - Recently, application demands placed on the network have become more multifaceted. Highly functional application-to-application communication services such as bandwidth aggregation, fault tolerant communication, and delay/disruption tolerant networking (DTN) were developed independently in the network layer, the transport layer, and the application layer. As a result, protocol layering has become complicated. This paper proposes to insert Layer-5 (L5) between the application layer and the transport layer to separate communication policies and communication mechanisms to make protocol layering clearer. The transport layer (L4) provides end-to-end communication mechanisms such as reliable byte stream while L5 realizes communication policies such as bandwidth aggregation by combining the communication mechanisms in L4. This paper proposes five types of L5-paths as communication policies: (1) the L5 bundled path for bandwidth aggregation or fault tolerant communication, (2) the L5 spatially-spliced path for communication with middleboxes, (3) the L5 temporally-spliced path for DTN, (4) the L5 spliced-bundled path, and (5) the L5 bundled over spatially-spliced path. An application can select and use an appropriate L5-path depending on the network circumstances through a common API. A prototype of L5 is implemented in the Linux user space as a library to make deployment and maintenance easier. An evaluation shows that establishment time of L5-paths is short enough and performance of L5-paths is comparable or superior to existing technologies.
ER -