i3:互联网中介基础设施的研究与应用
需积分: 9 18 浏览量
更新于2024-12-23
收藏 306KB PDF 举报
互联网指示基础设施 (I3) 是一种由麻省理工学院(MIT)提出的概念，旨在解决在移动网络环境中实现诸如多播、任意播等高级通信服务所面临的挑战。传统的点对点通信模型难以扩展以支持这些复杂的服务需求，因此I3论文提出了一个基于overlay的解决方案。
I3的核心理念是通过引入一种间接的通信方式来提供一种 rendezvous-based（会合基础）的通信抽象层。在这个模型中，数据包不再直接发送到特定目的地，而是与一个标识符关联起来。发送方将这个标识符附在数据包上，接收方则通过这个标识符找到并接收数据，实现了发送和接收的解耦。这种设计极大地提高了灵活性，使得I3能够有效地支持多种基础通信服务，如跨网络的数据交换、设备发现以及动态路由等。
为了验证这一理念的可行性，论文的作者们参考了Chord查找协议构建了一个原型系统。Chord是一种分布式哈希表协议，其环状结构和节点间的逻辑链接使得查找过程高效且易于扩展，这对于I3的寻址和路由机制具有重要意义。通过Chord的原理，I3能够在无需对底层网络进行大规模改动的情况下，提供一种适应性强、易于部署的互联网服务架构。
此外，论文还关注了I3在H.4.3类别中的应用，这是关于“信息系统的”分类，可能涉及到网络体系结构、服务质量(QoS)管理、路由算法等相关技术。I3的设计目标不仅限于理论研究，它旨在降低新服务部署的复杂性，提高网络的可扩展性和可靠性，这对于现代互联网的演进和发展具有深远的影响。
I3作为一项创新的互联网基础设施构想，通过引入间接标识和会合机制，成功地将传统的点对点通信模式扩展到了支持多播、任意播和移动性等高级服务。其基于Chord协议的实现原型展示了其技术可行性和实用性，预示着未来互联网架构演进的一个重要方向。
s1p
(id |id , R1)
s2p
(id |id , R2)
s3p
(id |id , R3)
(id |id , data)
p s
(a) Mobility
receiver (R2)
receiver (R1)
receiver (R3)
(b) Multicast
(id, R2)
sender (S)
(R2, data)
(id, R1)
(id, R3)
receiver (R2)
(R3, data)
receiver (R1)
(R1, data)
(id, data)
receiver (R3)
(c) Anycast
(R2, data)
sender (S)
(id, data)
sender (S)
receiver (R’)
(id, R)
(id, data)
sender (S)
receiver (R)
(R, data) (R’, data)(id, R’)
Figure 2: Communication abstractions provided by
. (a) Mobility: The change of the receiver’s address from
1
to
1
is transparent
to the sender. (b) Multicast: Every packet
2
!34398;:<8=6
is forwarded to each receiver
1
that inserts the trigger
2
@341
6
. (c) Anycast:
The packet matches the trigger of receiver
17L
.
@3
!
@3
#"
denotes an identifier of size
B
, where
@3
$
represents the prefix of the
D
most
significant bits, and
!3
"
represents the suffix of the
B
&%
D
least significant bits.
periodic refreshing to maintain their triggers in
. Hosts contact an
node when sending
packets or inserting triggers. This
node
then forwards these packets or triggers to the
node responsible
for the associated identifiers. Thus, hosts need only know one
node in order to use the
infrastructure.
2.4 Communication Primitives Provided by
>?
We now describe how
can be used by applications to achieve
the more general communication abstractions of mobility, multi-
cast, and anycast.
2.4.1 Mobility
The form of mobility addressed here is when a host (e.g., a lap-
top) is assigned a new address when it moves from one location to
another. A mobile host that changes its address from
1
to
1
'
as a
result of moving from one subnet to another can preserve the end-
to-end connectivity by simply updating each of its existing triggers
from
2
@34176
to
2
@341
6
, as shown in Figure 2(a). The sending host
needs not be aware of the mobile host’s current location or address.
Furthermore, since each packet is routed based on its identifier to
the server that stores its trigger, no additional operation needs to be
invoked when the sender moves. Thus,
can maintain end-to-end
connectivity even when both end-points move simultaneously.
With any scheme that supports mobility, efficiency is a major
concern [25]. With
, applications can use two techniques to
achieve efficiency. First, the address of the server storing the trigger
is cached at the sender, and thus subsequent packets are forwarded
directly to that server via IP. This way, most packets are forwarded
through only one
server in the overlay network. Second, to al-
leviate the triangle routing problem due to the trigger being stored
at a server far away, end-hosts can use off-line heuristics to choose
triggers that are stored at
servers close to themselves (see Sec-
tion 4.5 for details).
2.4.2 Multicast
Creating a multicast group is equivalent to having all members of
the group register triggers with the same identifier
!3
. As a result,
any packet that matches
@3
is forwarded to all members of the group
as shown in Figure 2(b). We discuss how to make this approach
scalable in Section 3.4.
Note that unlike IP multicast, with
there is no difference be-
tween unicast or multicast packets, in either sending or receiving.
Such an interface gives maximum flexibility to the application. An
application can switch on-the-fly from unicast to multicast by sim-
ply having more hosts maintain triggers with the same identifier.
For example, in a telephony application this would allow multiple
parties to seamlessly join a two-party conversation. In contrast,
with IP, an application has to at least change the IP destination ad-
dress in order to switch from unicast to multicast.
2.4.3 Anycast
Anycast ensures that a packet is delivered to exactly one receiver
in a group, if any. Anycast enables server selection, a basic building
block for many of today’s applications. To achieve this with
, all
hosts in an anycast group maintain triggers which are identical in
the
D
most significant bits. These
D
bits play the role of the anycast
group identifier. To send a packet to an anycast group, a sender uses
an identifier whose
D
-bit prefix matches the anycast group identi-
fier. The packet is then delivered to the member of the group whose
trigger identifier best matches the packet identifier according to the
longest prefix matching rule (see Figure 2(c)). Section 3.3 gives
two examples of how end-hosts can use the last
B
(%
D
bits of the
identifier to encode their preferences.
2.5 Stack of Identifiers
In this section, we describe a second generalization of
, which
replaces identifiers with identifier stacks. An identifier stack is a
list of identifiers that takes the form
2
!3
I
4
@3
*)
4
@3
#+
'4
-,.,-,
4
@3
*/
6
where
@3
#
is either an identifier or an address. Packets
0
and triggers
:
are
thus of the form:
1
Packet
0
J 2
@3
"
H
3254
/
453989:8=6
1
Trigger
:J 2
@34
@3
*"
<H
32-4
/
6
剩余13页未读，继续阅读
2021-02-08 上传
188 浏览量
2008-06-26 上传
2023-02-27 上传
2023-12-14 上传
2023-05-27 上传
2023-06-01 上传
2023-06-10 上传
2023-05-03 上传
guang2601312009
- 粉丝: 2
- 资源: 36
我的内容管理
展开
