4WARD项目：未来互联网的场景与用例定义

需积分: 3 166 浏览量更新于2024-08-01 收藏 1.09MB PDF 举报

"4WARD项目中的场景与用例定义文档" 4WARD，全称为"Architecture and Design for the Future Internet"（未来互联网的架构与设计），是欧盟资助的ICT-2007.1.1项目，旨在研究和开发未来网络的架构。该项目由 Henrik Abramowicz 作为项目协调人，由Ericsson AB领导，并包含多个合作伙伴机构，如Fraunhofer、EAB、KTH、NEC、NSND、PTIN、Siemens ROM、TUCN、Technion和DT等。 D-4.1文档是该项目的一个关键部分，主要关注"场景与用例定义"。这个阶段的工作目标是明确未来互联网可能的应用场景和具体使用情况，以便为项目的后续研发提供清晰的方向和基础。在定义这些场景和用例时，项目团队成员，包括编辑Rudolf Roth、Fabian Wolff、Tanja Zseby（来自Fraunhofer）以及来自其他合作机构的专家，共同参与了文档的编写工作。场景和用例的定义在任何技术或系统设计中都是至关重要的，因为它们帮助确定需求、预期的行为以及系统应如何响应特定用户或环境的交互。在4WARD项目中，这些场景可能是针对未来网络技术的创新应用，如高速数据传输、智能物联网、安全通信、分布式计算等。用例则会详细描述每个场景下的具体操作步骤、参与者、目标和预期结果，以确保项目成果能够满足实际的业务和用户需求。例如，一个可能的场景是大规模的物联网环境，其中数以亿计的设备需要高效、可靠地交换数据。对应的用例可能包括设备自动报告状态、远程控制和故障检测等功能。另一个场景可能涉及到未来的移动通信，比如5G网络，其中高速视频流、虚拟现实应用和自动驾驶汽车的实时通信是核心需求。通过这些场景和用例，4WARD项目团队可以预见未来互联网可能面临的技术挑战，如数据处理能力、网络延迟、安全性及隐私保护等，并据此进行技术创新和架构设计。此文档的最终版本2.0，表明经过多轮修订和完善，确保了对这些场景和用例的详尽理解和准确描述。总结来说，4WARD项目通过D-4.1文档深入探讨了未来互联网的多种应用场景和具体使用情况，为项目的创新研发提供了坚实的基础，同时也展示了项目团队在协同工作和专业知识上的深度与广度。这份工作对于理解未来网络技术的发展趋势和可能面临的挑战具有重要意义。

Document:

FP7-ICT-2007-1-216041-4WARD/D-4.1

Date:

2009-04-02

Security:

Public

Status:

Final

Version:

2.0

4WARD PUBLIC INFORMATION 12(78)

Chapter 3 4WARD Vision and Key Idea of In-Network Management

In order to overcome the limitations of current management technologies discussed in the

previous chapter, we envision a new paradigm for network management, which we call In-

Network Management. Its key idea is that management stations outside the network delegate

management tasks to a self-organizing management plane inside the network.

The goal of In-Network Management is to achieve scalable, robust management systems with

low complexity for large-scale, dynamic network environments. The guiding principles to

achieve this goal are decentralisation and self-organisation.

The realisation of the In-Network Management paradigm includes developing a network

management plane that self-configures and dynamically adapts to changes in networking

conditions. The plane provides communication and coordination primitives for a range of

distributed management functions.

The In-Network Management paradigm can be interpreted as pushing management

intelligence into the network, and, as a consequence, making the network more intelligent.

The network, which now includes the management plane as a part, can execute end-to-end

management functions on its own and perform, for instance, reconfigurations in an

autonomous fashion. It reports results of management actions to an external management

system, and it triggers alarms if intervention from outside is needed.

Figure 1 shows the main difference between In-Network Management (right side) and

traditional approaches (left side) regarding the components and their interactions.

In-network Management

Traditional Network Management

Analysis and

action

Network

element

Management

command

Notification

Network element

with embedded

management

processes

Peer-to-peer

interaction

Managed

domain

Managed

domain

Figure 1 Comparing traditional network Management (left) with In-Network

Management (right).

In traditional management approaches, the external management system interacts with each

managed device individually. First, it polls the devices for learning their states. Then, it

analyses the states and determines the actions to execute, taking into account business

policies. Finally, it executes these actions in a per-device fashion, e.g., through remote CLI

commands. This control loop is generally initiated and supervised by a human administrator.

Document:

FP7-ICT-2007-1-216041-4WARD/D-4.1

Date:

2009-04-02

Security:

Public

Status:

Final

Version:

2.0

4WARD PUBLIC INFORMATION 13(78)

In contrast, with In-Network Management, external management entities do not interact with

each managed device individually. Instead, they interact with access points of the

management plane (Figure 2), which provides network-wide management functionality. To

provide this functionality, the management plane executes a set of distributed, self-stabilising

protocols for monitoring and control.

Figure 2 shows a possible realisation of the management plane. It includes management

processes that are associated with network devices and communicate with neighbouring

processes through an overlay. Every process serves as an access point for In-Network

Management operations.

Notification

Management

command

Management

process

Managed domain

Management

plane

Figure 2 Management plane for In-Network Management.

In-Network Management calls for a device to have embedded "default-on" management

capabilities, consisting of several autonomous components which interact with each other in

the same device and with components in neighbouring devices. The architecture of In-

Network management first of all models how management capabilities are embedded inside

the services of a node. On this basis, it is then possible to compose them, in such a way that

the embedded functions are coordinated with each other. Out of smaller autonomous

components, more complex management functions can be constructed in the management

plane. Additionally, Figure 2 shows that communication between network elements is based

on peer-to-peer paradigms: In-Network management relies on different propagation schemes

to enforce management processes in the network.

In-Network Management relates to autonomic management in two ways. First, the

management plane inside the network is self-organizing and exhibits autonomic behaviour.

Second, the functions that the management plane offers are either autonomic themselves, for

instance distributed fault diagnosis and self-healing, or they are building blocks for autonomic

management functions. For example, many autonomic functions require the availability of

real-time network-wide state information.

In the 4WARD project, we will develop and evaluate the above described idea for In-Network

Management. Specifically, we will develop a framework that identifies the components and

their interactions. We will provide descriptions of how functions in the management plane can

Document:

FP7-ICT-2007-1-216041-4WARD/D-4.1

Date:

2009-04-02

Security:

Public

Status:

Final

Version:

2.0

4WARD PUBLIC INFORMATION 15(78)

Chapter 4 Key Issues for In-Network Management

We have identified the following set of general key requirements that a holistic INM

architecture should take into account. Of course, due to time constraints within the project it

might be not possible to address all of them, thus the main part of the work will rather deeply

focus on a set of key requirements than trying to plainly touch all of them. While this

compilation is not exhaustive, it may be used as a background for assessing existing work

related to INM in

Chapter 5 and the scenario descriptions in Chapter 6 as well as a guideline

in the design of the INM framework and algorithms that follow in subsequent deliverables of

Work Package 4.

Scalability: INM must support scalability in terms of network size (i.e. the number of network

components to be managed) and in terms of the number of management tasks, which also

grows with the network size.

Heterogeneity: INM must support heterogeneity on different dimensions, such as

heterogeneous devices (different manufacturers and vendors, proprietary network

components and functionality), heterogeneous network structures (MANETs, WSNs, WMNs,

wireless access networks, hybrid network structures, etc.), and heterogeneous environments

(homes, cars, offices, open country).

Interoperability: INM relies on interoperability between different devices to support

management operations. The coexistence of different interfaces and information models

should be avoided, because it poses a serious limitation to the degree of automation in the

network.

Real-Time-Support: INM should support management operations within limited time

constraints, i.e. real time. The limits of these time constraints may be specific to every

application and refer in general to the absence of mistakes in that application due to delays in

the management operations.

Robustness: INM must be robust with respect to failures in components and subsystems,

with respect to potential attacks (security), and with respect to incomplete or inaccurate

information that is available (data collection).

Small Footprint: INM must have a small footprint with respect to storage space, bandwidth

consumption, energy consumption, and other resources, in order to impact the network to the

least extend possible and avoid side-effects.

Level of Localisation: The localisation of management tasks / control loops to a small subset

of components is a prerequisite for scalability and a small footprint. In other words, the more

localised a management application can be executed, the larger the number of management

tasks that can be executed at the same level of resource utilisation.

Level of Integration: Management tasks need to be tightly integrated within network

components and subsystems (compare to external, partially embedded (e.g. only monitoring),

and fully embedded (inseparable management capabilities in network components)).

Comprehensiveness of Management Information Model: The Information model of INM

must be comprehensive in the sense that it must provide sufficient expressiveness (to capture

various types of management tasks), extensibility with respect to future requirements (e.g.

energy management), and flexibility (e.g. only partial implementations for lightweight

management tasks).

Functional Comprehensiveness: INM must provide functional richness to support a variety

of essential management tasks (e.g. fault detection and remedy), it must be possible to

specify tasks on different levels of abstraction (Æ degree of specification of a task, see

[MartinFlatinEtAl1999a]), and allow tasks to be translated to concrete implementations in

different environments (e.g. WSNs, WMNs).

剩余78页未读，继续阅读

cjbupt

粉丝: 1
资源: 7

4WARD项目：未来互联网的场景与用例定义

4.1.1.11 Packet Tracer - Configuring Extended ACLs Scenario 2.pka

Onto2OpenSCENARIO_Scenario-_22_6_7.xosc

parser.add_argument("--scenario-name", type=str, default="pursuit", help="name of the scenario script") parser.add_argument("--algo_name", type=str, default="ddpg", help="") parser.add_argument("--max-episode-len", type=int, default=350, help="max

docker-compose ceph分布式存储部署

Can't find file: './metersphere/test_case_review_scenario.frm' (errno: 13 - Permission denied)

生成matlab和STK互联的代码

pytest-bdd environment.py怎么写

unity Agora SDK 中有内置的声音消除功能 代码

最新资源

unity Agora SDK 中有内置的声音消除功能代码