CN102315961B

CN102315961B - 执行路径导向的系统管理

Info

Publication number: CN102315961B
Application number: CN201010611936.XA
Authority: CN
Inventors: L·亚历山大·柯勒姆; 玉泉·江; 埃梅尔·阿克特; 史蒂夫·常; 希云·什兰·林
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2010-07-07
Filing date: 2010-12-17
Publication date: 2014-12-24
Anticipated expiration: 2030-12-17
Also published as: US20120008498A1; US8995266B2; US9787593B2; CN104468205B; CN104468205A; US20150207746A1; EP2405608B1; EP2405608A1; CN102315961A

Abstract

本发明涉及执行路径导向的系统管理。公开了一种用于利用诸如RSVP之类的网络控制协议沿着网络路径将系统管理请求发送给计算机系统的方法。例如，源发节点可以利用网络控制协议将单个系统管理请求沿着路径发送给目的地节点。沿着网络路径的每个计算机系统可以分析网络控制协议消息以判断该消息是否包含系统管理请求。如果在该消息中发现系统管理请求，则计算机系统可以执行请求中标识的系统管理功能并且对其作出响应。

Description

执行路径导向的系统管理

技术领域

本公开一般涉及网络管理。

背景技术

本节中描述的方案可以被实行，但不一定是先前已想出或实行过的方案。因此，除非在此另有指出，否则本节所描述的方案对本申请中的权利要求来说不是现有技术，并且并不因为包括在此节中而被承认为现有技术。

计算机网络管理协议使得管理员能够管理网络路径并且为联网计算机之间的通信分配资源。例如，ICMP路由追踪被用来发现沿着路径的系统上的接口的IP地址。多协议标签交换(MPLS)操作、管理和维护(OAM，MPLS-OAM)跟随MPLS标签交换路径(LSP)发现系统和沿着路径的MPLS标签。以太网OAM(E-OAM)类似于用于以太网域的MPLS-OAM。思科发现协议(CDP)和链路层发现协议(LLDP)可以发现与相连接的邻居有关的信息。资源预留协议(RSVP)允许消息沿着用于专用应用的路径穿越系统，该专用应用涉及为了服务质量(QoS)目的而进行的资源预留。

系统管理任务包括配置和数据收集。执行系统管理任务可能需要管理员或管理应用将多个消息发送给联网计算机。例如，去往目标计算机的路径发现消息可被用来确定去往目标的路径，并且多个分开的第二消息可以沿着该路径将管理请求载运至每个节点。该方案需要网络中的太多消息以及管理站处的太多处理。

发明内容

根据本发明第一方面，公开了一种方法，包括：在第一节点处从源发节点接收网络控制消息，其中，所述网络控制消息是从源发节点起在指定路径上被发送的；其中，所述网络控制消息包括系统管理请求和系统管理请求元数据，并且是在路径导向的网络控制协议的分组中被接收的；分析所述系统管理请求以确定要在所述第一节点处执行的特定系统管理功能；利用所述路径导向的网络控制协议将所述网络控制消息中继到第二节点；其中，所述方法由一个或多个处理器执行。

根据本发明另一方面，公开了一种装置，包括：用于在第一节点处从源发节点接收网络控制消息的装置，其中，所述网络控制消息是从源发节点起在指定路径上被发送的；其中，所述网络控制消息包括系统管理请求和系统管理请求元数据，并且是在路径导向的网络控制协议的分组中被接收的；用于分析所述系统管理请求以确定要在所述第一节点处执行的特定系统管理功能的装置；用于利用所述路径导向的网络控制协议将所述网络控制消息中继到第二节点的装置。

根据本发明又一方面，公开了一种装置，包括：一个或多个处理器；消息接收逻辑，被耦合到所述一个或多个处理器并且被配置来从源发节点获取网络控制消息，其中，所述网络控制消息是从源发节点起在指定路径上被发送的；其中，所述网络控制消息包括系统管理请求和系统管理请求元数据，并且是在路径导向的网络控制协议的分组中被接收的；消息协议逻辑，被配置来分析所述系统管理请求以确定要执行的特定系统管理功能；第一消息中继逻辑，被配置来将所述网络控制消息中继到另一节点。

附图说明

在附图中：

图1图示出了TCP/IP模型；

图2图示出了可以执行路径导向的系统管理的计算机系统；

图3图示出了用于路径导向的系统管理的示例处理；

图4A图示出了根据实施例的沿着外出(outbound)路径的管理请求处理，其中，响应有效载荷(payload)在各个响应消息中被发送给源发节点(originating node)；

图4B图示出了根据实施例的沿着进入(inbound)路径的管理请求处理，其中，响应有效载荷在各个响应消息中被发送给源发节点；

图4C图示出了沿着外出路径的管理请求处理，其中，响应有效载荷与其它响应有效载荷相连结(concatenate)并在响应消息中被发送给源发节点；

图5图示出了可以在其上实现实施例的计算机系统。

具体实施方式

描述了执行路径导向的系统管理。在下面的描述中，为了说明的目的，阐述了多个具体细节以提供对本发明的透彻理解。然而，本领域技术人员将清楚，可以不用这些具体细节来实施本发明。在其它实例中，公知的结构和设备以框图形式示出，以避免不必要地模糊本发明。

这里根据下面的大纲来描述实施例：

1.0总体概述

2.0结构和功能概述

3.0示例性路径导向的系统管理方案

3.1处理外出消息

3.2处理进入消息

4.0实现机制—硬件概述

5.0扩展和替代

1.0总体概述

在实施例中，第一节点接收从源发节点发送到目的地节点的网络控制消息。除了其它数据元素外，该网络控制消息可以包含并包括系统管理请求和系统管理请求元数据。该系统管理请求可以被分析以确定要在所述第一节点处执行的特定系统管理功能。所述网络控制消息可以被中继到第二节点。在其它实施例中，本发明包括被配置来执行前述步骤的计算机装置和计算机可读介质。

2.0结构和功能概述

实施例可以利用路径导向的网络控制协议来向沿着网络路径的节点传输系统管理请求和系统管理请求响应有效载荷。网络控制消息可以是用作传输工具的控制协议的消息。例如，在实施例中，RSVP以新的非预期的方式被扩展来利用RESV或PATH作为控制消息来载运系统管理请求和系统管理请求响应有效载荷。传统的RSVP是被设计来在沿着跨越网络的源发节点和目的地节点之间的路径的每个节点处预留资源的应用层协议，但不被用作传输工具来载运系统管理请求或响应。一个RSVP Path消息可以从源发节点被发送给目的地节点以在沿着网络路径的每个中间节点处为数据流预留资源。一旦RSVP Path消息到达目的地节点，则目的地节点就可以沿着网络路径将RSVP RESV消息发送回源发节点。RSVP RESV消息可以向沿着网络路径的每个节点指示出沿着该路径传送该流需要什么资源。

在实施例中，不是向沿着源发节点与目的地节点之间的网络路径的每个节点发送独有的管理请求消息，而是单个RSVP消息用作用于将管理请求载运到沿着网络路径的所有节点的传输工具。每个节点可以接收单个RSVP消息并且沿着路径中继它。RSVP消息还可以沿着该路径往回载运系统管理请求响应有效载荷。因此，克服了过去的方案具有的问题，源发节点处的系统管理员可以发送单个RSVP消息以将系统管理请求沿着网络路径发送给多个节点，从而减少网络上的流量。此外，与管理请求针对特定的、被指名的代理的传统方法相反，源发节点不需要指名、寻址或了解路径上的各个节点。

尽管参考RSVP讨论了这里公开的一些实施例，然而在其它实施例中，也可以使用其它协议来传输系统管理请求和系统管理请求响应有效载荷。例如，一些实施例可以使用UDP对网络地址转换的简单穿越(SimpleTraversal of UDP through Network Address Translation，STUN)或者网络层信令(Network Layer Signaling，NLS)协议消息。

图1图示出了用于各种实施例的TCP/IP模型。节点102、104、106和108可以经由硬件110连接到网络。节点102、104、106的每个可以是可包含网络基础设施元件(例如路由器、交换机、网关或集线器)的计算机。或者，节点可以是网络末端站，例如服务器、工作站、存储装置或打印机。

在实施例中，节点102、104、106容纳或运行被配置来执行组织在多个概念或逻辑层中的通信功能和应用功能的逻辑。在实施例中，节点102、104、106容纳或运行逻辑，该逻辑被配置用于因特网协议(IP)层112、容纳诸如RSVP之类的协议的传输层114、容纳代理间管理协议(IAMP)的中间层116、诸如Mediatrace应用118之类的第一应用，以及诸如视频监视应用120之类的第一应用118感兴趣的管理信息的源。

利用诸如IAMP之类的应用间通信机制来将管理信息从应用120传达给应用118。在实施例中，IAMP传达管理请求和响应，并且包含与请求有关的元数据，例如跳数、请求标识符、发起者标识符和各种标志，以及请求或响应及其各自的参数。因此，IAMP消息可以在为请求服务的应用与下层的传输工具之间提供绑定。

网络层112可以利用例如IP寻址来提供逻辑寻址和路由。网络层112还可以负责数据报封装等。传输层114可以负责主机到主机的数据传输。传输层114还可以负责可靠地或不可靠地将数据从主机传输到主机并且如果需要则重新发送数据。

这里描述的实施例可以在图1的示例性TCP/IP模型的层116处实现。因此，实施例可以在该TCP/IP模型的传输层与应用层之间操作。例如，在层116处，实施例可以提供用于管理沿着网络内的路径的系统的IAMP。在实施例中，IAMP可以使用如下逻辑来利用RSVP的一些方面：该逻辑确定何时处理所接收的管理请求、发送响应的方式以及何时向沿着网络路径的节点发送数据，如下面将进一步公开的。因此，在实施例中，诸如数据收集和配置命令之类的系统管理命令可在图1的TCP/IP模型的层116中从节点104传输到节点106。

此外，实现IAMP的诸如节点102、108之类的其它节点可能能够接收IAMP分组并且执行包含在其中的系统管理任务。然而，如果节点102、108不实现IAMP，或者如果节点上的进程尚未注册来截取包含有定义在其中的有效载荷的RSVP消息，则这些节点可能将IAMP分组当作RSVP分组那样来处理该IAMP分组，并且仅将分组传递给下一节点。因此，沿着路径的节点可以被透明地穿越，并且可以根据RSVP来处理IAMP分组。此外，如果节点不实现RSVP，则分组可以被透明地传递下去，而不进行为了这里描述的目的的截取或处理。

第一和第二应用层提供了可以使用这里描述的实施例的高级别处理。第一应用层的示例实现方式是来自加利福尼亚的圣何塞的思科系统的Mediatrace。诸如Mediatrace之类的应用可以依赖于这里描述的实施例来识别媒体流中的端到端的问题。作为另一示例，第二应用层处的视频监视软件应用可以使用Mediatrace来识别视频媒体流中的问题。

图2图示出了根据实施例的可以执行路径导向的系统管理的计算机系统。源发节点202可以容纳系统管理应用204、协议逻辑206、消息发送逻辑208和消息接收逻辑210。网络上的任何计算设备可以是源发节点。例如，源发节点202可以是互联网络设备，例如路由器、交换机或网关，或者可以是网络末端站设备，例如服务器、个人计算机或任何其它计算设备。

系统管理应用204可以是由系统管理员或其它用户使用的系统管理应用，用于执行诸如计算机系统202、212、214、216之类的网络内计算机系统上的系统管理任务。系统管理应用204可以指定针对其发出了系统管理请求的特定系统管理任务或者多个系统管理任务。系统管理请求可被插入到网络控制协议消息中，例如RSVP消息、STUN消息或NLS消息，以用于递送给沿着网络路径的节点。

根据实施例，协议逻辑206可以是被配置来将从系统管理应用204接收的系统管理请求插入到网络控制协议消息中的逻辑。系统管理请求可以是用于通过提供配置数据来配置沿着网络路径的系统的请求。或者，系统管理请求可以是针对数据收集的请求。例如，系统管理员可能希望从沿着网络路径的所有节点收集系统信息。可从沿着网络路径的节点收集的信息的示例是主机名、设备类型以及操作系统版本。可从沿着网络路径的节点收集的其它类型的信息包括与计算机系统的健康有关的信息以及关键性能指标，例如CPU利用率和存储器利用率。另外，系统管理请求可以请求特定流的路径上的每个系统上的流缓存的当前内容。

协议逻辑206还可以负责利用系统管理请求元数据来构建网络控制协议消息。系统管理请求元数据可以是这样的数据，该数据由源发节点202初始化并且由沿着网络路径的节点(例如中间节点212、214和目的地节点216)更新。在此上下文中，除了位于目的地位置的节点不将消息转发或中继给其它节点之外，目的地节点可以实现提供了与这里描述的中间节点212相同功能的操作逻辑。系统管理请求元数据可以包括：指示网络控制消息穿越了的节点的数量的节点计数、唯一地标识从源发节点发送系统管理请求的应用的类型的应用类型标识符、唯一地标识源发节点的节点标识符，以及唯一地标识该系统管理请求的请求标识符。另外，系统管理请求元数据可以包括唯一地标识用于路由网络控制协议消息的路径的路径标识符，以使得接收到该网络控制协议消息的节点可以沿着源发节点所指定的路径来中继该消息。例如，可以通过包括目的地IP地址、目的地IP端口、IP协议标识符、源IP地址和源端口的五元组来标识路径。

根据一些实施例，消息发送逻辑208可被配置来发送被协议逻辑206配置为包含系统管理请求的网络控制协议消息。消息发送逻辑208可以沿着如上所述由系统管理请求元数据指定的且已在网络内建立的路径来发送网络控制协议消息。或者，可以根据由网络控制协议本身所确定的路径来路由网络控制协议消息。例如，如果RSVP被用作网络控制协议的话，则可以基于用于路由RSVP Path和RESV消息的路由协议来确定路径。

计算机系统214可能能够处理在网络控制协议消息中发送的系统管理请求。计算机系统214可以是沿着路径的中间节点，例如中间节点206、208，或者是目的地节点，例如目的地节点210。计算机系统214可以是沿着源发节点202与目的地节点216之间的网络路径的、能够处理在网络控制协议分组中发送的系统管理请求的系统，例如路由器、集线器、交换机、个人计算机或其它计算设备。

计算机系统214可以包括消息接收逻辑218、消息协议逻辑220、管理请求处理逻辑222、管理代理224、消息中继逻辑226、消息接收逻辑228以及消息中继逻辑230。在此上下文中，中继可以包括向原始接收的消息添加响应有效载荷，或者发起新的消息，如将在这里进一步描述的。消息接收逻辑218可以接收从源发节点202沿着网络路径去往目的地节点216的外出消息。

消息协议逻辑220分析由消息接收逻辑218接收的网络控制协议消息以判断所接收的网络控制协议消息是否包含系统管理请求。例如，消息协议逻辑220被配置来接收利用RSVP作为传输工具的RSVP分组，并且判断RSVP分组是否包含表示管理请求和相关元数据的IAMP字段。

消息协议逻辑220可以确定网络控制协议消息包含这样的元数据，该元数据指明应当在从目的地节点216到源发节点202的进入路径上处理系统管理请求。例如，系统管理请求元数据可以包含指明应当何时处理系统管理请求的标志。该标志可以指明应当在从源发节点起的外出路径上在到达目的地节点之前接收到系统管理请求时或者在从目的地节点到源发节点的进入路径上接收到系统管理请求时，执行该系统管理请求。如果标志指示外出路径处理，则消息协议逻辑220可以将系统管理请求发送给管理请求处理逻辑222。

或者，标志可以指明应当在从目的地节点216到源发节点202的进入路径上处理该系统管理请求。如果消息协议逻辑220确定系统管理请求应当在进入路径上被处理，则消息协议逻辑可以将网络控制协议消息发送给消息中继逻辑226以转发给目的地节点，而不将系统管理请求发送给管理请求处理逻辑222。

如果系统管理请求将在进入路径上被处理，则一旦在消息接收逻辑228处接收到来自目的地节点216的网络控制协议消息，就可以处理该系统管理请求。消息接收逻辑228可以从目的地节点216接收网络控制协议消息。消息协议逻辑220可以分析网络控制协议消息以判断该网络控制协议消息是否包含系统管理请求。如果找到系统管理请求，则消息协议逻辑220可以将该系统管理请求递送给管理请求处理逻辑222供进一步处理。

应注意，如果接收到包含系统管理请求的网络控制协议消息的节点是目的地节点，例如目的地节点216，则当系统管理请求在目的地节点处被接收到时就可以被处理，而不管该请求是否被设置有关于进入或外出处理的标志。取决于模式，目的地节点将简单地发送回响应，或者除了响应之外，其还“反射”回请求，用于在该请求在进入方向上朝着源发者往回穿越节点时被处理。

消息协议逻辑220可以从管理请求处理逻辑222接收用于插入网络控制协议消息中的响应数据，以将响应数据发送给源发节点202。响应数据可以从计算机系统214上的消息中继逻辑230沿着进入路径被发送到源发节点。响应数据可包括IAMP消息中的数据。响应数据还可以在经由接收逻辑228和消息中继逻辑230沿着进入路径被发送到源发节点202之前，沿着外出路径从消息中继逻辑226被发送到目的地逻辑216。

此外，消息协议逻辑220可被配置成为基于系统管理请求生成的响应数据发送独立的网络控制协议消息。或者，消息协议逻辑220可被配置为通过将在系统214处生成的响应数据连结到或附加到由沿着源发节点202与目的地节点216之间的路径的其它节点生成的响应数据，来将响应数据添加到现有响应消息中，例如现有的IAMP消息中。中间节点可以发送若干个不同形式的消息。中间节点可以进一步沿着朝向目的地的同一路径来中继带有原始请求的消息，以使得该消息到达路径上的下一节点。在连结模式中，中间节点可以将其自己的响应数据捎带在该消息上。另外，中间节点可以源发具有响应数据的另一消息并且将其发送回发起者。在单独响应模式中，或者在连结响应模式中(在否则消息有效载荷将会太大的情况下)，则响应数据可以是中间节点自己处理管理请求的响应。

这里将进一步描述用于处理系统管理请求和发送系统管理响应数据的替代方法。

管理请求处理逻辑222可以执行在网络控制协议消息中接收的系统管理请求。例如，系统管理请求可以包含执行特定系统管理功能的请求，该特定系统管理功能可以使管理请求处理逻辑222执行计算机系统214上的系统功能，例如系统配置功能或系统状态检索功能。系统功能还可以是执行一个或多个应用的系统命令，例如执行命令行实用工具或计算机系统214上可用的另一软件应用。

管理请求处理逻辑222还可以响应于接收到系统管理请求来改变计算机系统214的配置或者从计算机系统214收集信息。或者，管理请求处理逻辑222可以经由进程间通信过程调用来与运行在计算机系统214上的另一应用交互。例如，管理请求处理逻辑222可以将系统管理请求传达给运行在计算机系统214上的管理代理224。管理代理224可以执行系统管理请求并且向管理请求处理逻辑222提供回指示系统管理请求的结果的响应数据。

管理请求处理逻辑222可以基于对系统管理请求的执行来生成响应数据。响应数据可以指示管理请求成功。例如，如果系统管理请求包括配置系统214的请求，则响应数据可以指示配置请求成功或失败。另外，响应数据可以包括响应于系统管理请求而收集的系统数据，例如主机系统的名称、设备类型、操作系统版本、健康信息、关键性能指示符或流缓存的当前内容。

中间节点212可以是网络路径上位于源发节点202和目的地节点216之间的节点。中间节点212可能能够处理由源发节点202发送的管理请求。或者，中间节点212可以是不能够处理系统管理请求的节点。如果中间节点212不能处理由源发节点202发送的管理请求，则中间节点212可以透明地或者根据消息的网络控制协议以其他方式处理或向前传递消息。在一个实施例中，中间节点212可以不包括RSVP的客户端层，例如不包括IAMP层；在此情况中，不存在截取消息的客户端，并且节点是“透明的”。在另一实施例中，中间节点212具有诸如IAMP之类的客户端层，但是没有诸如Mediatrace之类的应用。在此情况中，IAMP层像通常那样处理消息，但取而代之的是针对管理请求的响应指示在该节点上不存在客户端应用。在此情况中，中间节点212不是透明的，因为发起者节点将得知在路途中存在未处理目标应用的IAMP节点。在另一实施例中，IAMP层和诸如Mediatrace之类的应用位于中间节点212中，但存在内部处理差错；例如，管理请求或对视频监视数据的请求返回差错。中间节点212将该情况作为将包含有差错代码或差错数据的常规响应来处理。

因此，不能处理系统管理请求的中间节点可以被透明地穿越。

此外，源发节点可能能够基于包括在响应有效载荷中的IP TTL来识别出沿着路径存在不能处理系统管理请求的节点。例如，如果中间节点不能处理系统管理请求，则源发节点可能不会接收到包括针对该中间节点的IP TTL的响应有效载荷，并且通过接收在其IP TTL值中具有间隙的响应有效载荷而判断出这些间隙表示无能力的节点。源发节点可能能够基于丢失的响应有效载荷以及IP TTL来确定哪个节点不能处理系统管理请求。

除了目的地节点不向更下游节点转发或中继消息以外，目的地节点216可以实现与这里描述的中间节点212类似的逻辑，以使得元件226、228是适用的。在实施例中，中继逻辑230、226可以在同一逻辑单元中实现，并且接收逻辑218、228可以形成同一逻辑单元。因此，不需要多个实例，但是在图2中被提供用于清楚地指示数据流的目的。

3.0示例性的路径导向的系统管理方案

图3图示出了路径导向的系统管理的示例。在步骤302处，从源发节点接收消息。例如，可以从源发节点接收诸如RSVP、STUN或NLS消息之类的网络控制协议消息。网络控制协议消息可以被沿着从源发节点到目的地节点的网络路径的任何节点(包括目的地节点)接收。

在步骤304，消息被分析以判断是否存在系统管理请求以及该系统管理请求应当沿着从源发节点起的外出路径被处理还是应当沿着从目的地节点到源发节点的进入路径被处理。例如，不是所有的网络控制协议消息都包含系统管理请求，并且不具有系统管理请求的网络控制协议消息可以该消息的特定协议(例如RSVP)被处理。

包含系统管理请求的网络控制协议消息还可以根据包含在系统管理请求中的标志被处理。系统管理请求可以包含指明该系统管理请求应当沿着进入路径还是外出路径被处理的标志，如上所述。例如，RSVP标志字段或IAMP字段中的值可以指示进入或外出处理。如果标志指示外出路径处理，则图3的处理沿着外出处理流306继续。例如，如果标志指示了外出路径处理，则当从源发节点接收到系统管理请求时并且在该请求被转发给目的地节点之前来处理该请求。如果标志指示了进入路径处理，则图3的处理沿着进入处理流308继续。例如，如果标志指示了进入路径处理，则在在回到源发节点的路途上从目的地节点接收到系统管理请求之前，系统管理请求不被处理。

外出处理流306例示出了根据实施例的外出系统管理器请求处理。在步骤310，在步骤302接收的网络控制协议消息可被分析以确定系统管理请求。例如，网络控制协议消息可以包含系统管理请求。该系统管理请求可以是许多不同的系统管理请求中可以被沿着从源发节点到目的地节点的网络路径的计算机系统处理的系统管理请求。系统管理请求可以是执行系统配置功能、系统数据收集功能或用于管理计算机系统的任何其它系统功能的请求。在步骤310，系统管理请求可被分析以确定接收到了哪种类型的管理请求。除了处理连结响应的情况外，步骤310可以与步骤318并行地进行，如下面将描述的。

在步骤312，通过步骤310确定的管理功能可以被执行。在网络控制协议消息中接收的管理功能可以由图2的管理请求处理逻辑222或者运行在计算机系统上的系统管理代理224来执行。例如，计算机系统可以具有运行在该系统上的执行系统管理任务的各种应用。系统管理请求可以包含执行存在于计算机系统上的应用或实用工具的命令。或者，系统管理请求可以指示管理处理逻辑222请求已经运行在计算机系统上的应用(例如管理代理224)执行系统管理功能。

在步骤314，基于在步骤312执行的系统管理请求中所指定的管理功能的执行来生成响应有效载荷。例如，如果系统管理功能是系统配置功能，则响应有效载荷可被生成来指示执行系统配置功能的成功或失败。例如，如果发出系统配置请求的系统管理员或系统管理应用不具有配置沿着网络路径的特定系统的权限，则可以生成指示请求失败的响应有效载荷，表明该系统管理员或系统管理应用不具有配置系统的权限。或者，如果系统管理请求是执行数据收集功能的请求，则包含所请求的数据的响应有效载荷可被生成。

在步骤316，在步骤314处生成的响应有效载荷可以被发送给源发节点。例如，响应有效载荷可以被包括在这样的网络控制协议消息中，该消息关联于与在步骤302中接收的网络控制协议消息相同的协议。

作为特定示例，如果RSVP被用来传输系统管理请求，则响应有效载荷可以在RSVP Notify消息中被发送或者响应有效载荷可以在RSVPReservation(RESV)消息中被发送。此外，响应有效载荷可以在为了发送响应有效载荷的目的而生成的新消息(例如上面的RSVP Notify消息)中被发送给源发节点。或者，响应有效载荷可以被连结到或附加到包含有来自沿着源发节点与目的地节点之间的网络路径的其它节点的响应有效载荷的现有消息中，例如RSVP RESV消息中。在一些实施例中，经连结的消息可能达到施加给某些协议的消息的大小限制。

如果对于特定消息，达到了大小限制，则可以生成新的消息用于为网络路径上尚未抵达的节点发送响应有效载荷。在实施例中，生成一单独的响应消息用于向发起者发送已经累积或连结的响应有效载荷。这样的响应有效载荷具有已经被穿越的系统的响应；没有了被剥掉的响应的原始请求消息沿着路径被进一步向目的地中继。

在步骤318，在步骤302处接收到的响应被中继到目的地节点。例如，如果响应有效载荷是通过将响应有效载荷连结到在步骤302处接收的消息而被发送给源发节点的，则一旦系统管理请求的处理完成并且响应有效载荷被生成，就可以将在步骤302处接收的网络控制协议消息中继到目的地节点。或者，如果生成了用于将响应有效载荷发送给源发节点的新消息，则该消息可以在网络控制协议消息被分析以确定是否包含系统管理请求之后的任何时间被中继到目的地节点。当不使用连结响应处理时，步骤318可以与步骤310并行地执行。

进入处理流308例示了根据实施例的进入系统管理请求处理。当包含系统管理请求的网络控制协议消息从目的地节点被发送到源发节点时，可以执行系统管理请求的进入处理。

在步骤320，从源发节点接收的网络控制协议消息可被中继到目的地节点。例如，在步骤302处接收的网络控制协议消息可以包含指示进入处理的系统管理请求。因此，取代在步骤320处理系统管理请求，步骤320中继该网络控制消息而不对系统管理请求进行处理。

在步骤322处，从目的地节点接收由源发节点发送的网络控制消息。例如，发送到目的地节点的RSVP消息可以包含系统管理请求。该RSVP消息可以沿着网络路径被发送到目的地节点。一旦RSVP消息到达目的地节点，RSVP消息就可以沿着该网络路径被发送回源发节点。当该消息从目的地节点穿越路径回到源发节点时，沿着网络路径的每个计算机系统可以接收网络控制协议消息，如步骤322所示。

在步骤324，网络控制协议消息可以被分析以确定系统管理请求。步骤324处的处理对应于针对步骤310公开的处理。

在步骤326，管理请求中指示的管理功能可以被执行。步骤326处的处理对应于针对步骤312公开的处理。

在步骤328，可以基于在步骤326中描述的执行管理功能的结果来生成响应有效载荷。步骤328处的处理对应于针对步骤314公开的处理。

在步骤330，在步骤328中生成的响应有效载荷可以被发送给源发节点。例如，响应有效载荷可以被连结或附加到在步骤302处接收的网络控制协议消息中，在所生成的用于单独发送响应有效载荷的消息中发送，或者被连结到在其它节点处生成的其它响应有效载荷，这些其它响应有效载荷被累积地发送并且是在诸如RSVP Notify消息或RSVP RESV消息之类的单个消息中发送的。

3.1路径导向的系统管理消息

图4A图示出了根据实施例的沿着外出路径的管理请求处理，其中，响应有效载荷在单独的响应消息中被发送给源发节点。图4B图示出了根据实施例的沿着进入路径的管理请求处理，其中，响应有效载荷在单独的响应消息中被发送给源发节点。图4C图示出了沿着外出路径的管理请求处理，其中，响应有效载荷与其它响应有效载荷连结在一起并且在响应消息中被发送给源发节点。

3.2外出系统管理请求处理

首先参考图4A，图示出了根据实施例的发送路径导向的系统管理消息。当诸如RSVP消息之类的网络控制协议消息在从源发节点402到目的地节点404的外出路径上被发送时，包含在该网络控制协议消息中的系统管理请求可以在沿着源发节点402与目的地节点404之间的网络路径的节点处被处理。节点404、406、408可以是能够处理包含在源发节点402所发送的网络控制协议消息中的系统管理请求的沿着网络路径的节点。

源发节点402可以生成包含有系统管理请求412和系统管理请求元数据414的网络控制协议消息410。例如，网络控制协议消息410可以是被扩展来将系统管理请求412和系统管理请求元数据414传输给节点404、406、408的RSVP Path消息。系统管理请求412可以是任何系统管理请求，例如配置请求或数据收集请求。

系统管理请求412可以被沿着网络路径的能够处理包含在RSVP Path消息中的系统管理请求的所有节点所处理。如果沿着源发节点402和目的地节点404之间的网络路径的节点不能处理系统管理请求412，则该节点可以根据RSVP来处理RSVP Path消息，并且在不处理系统管理请求的情况下将该消息中继到下一节点。因此，不能处理系统管理请求的节点被透明地穿越。

系统管理请求元数据414a包含有允许源发节点402确定源发节点402和目的地节点404之间的路径的特性的数据。系统管理请求元数据414a还可以允许源发节点402识别哪个响应有效载荷与特定节点相关联。例如，系统管理请求元数据414a可以包括：指示网络控制协议消息已经穿越的节点的数量(跳数)的节点计数、唯一地标识作出系统管理请求的应用的类型的应用标识符、唯一地标识发起了请求的节点的节点标识符、以及唯一地标识系统管理请求的请求标识符。

在实施例中，元数据414a可以包括指示节点如何分别处理消息以编排成整个流的信息。例如，元数据414a可以指明是连结响应还是直接发送单独的响应，以及是在外出还是进入时处理请求。

另外，系统管理请求元数据414a可以包括流标识符或路径标识符以向下层的网络控制协议实现指示出网络控制协议消息应当跟随哪条流路径。例如，如果网络控制协议消息是RSVP Path消息，则路径标识符可以向RSVP实现指示出包含系统管理请求的RSVP Path消息应当跟随与该路径标识符相对应的特定路径。如果未提供任何路径标识符，则RSVP Path消息可以沿着根据RSVP选择的路径被发送。

如图4A所示，消息410可被节点406接收。当接收到消息410时，节点406可以处理系统管理请求412并且生成包含响应有效载荷418的回复消息416。例如，回复消息416可以是具有与消息410相同的协议的网络控制协议消息。在实施例中，回复消息416可以是RSVP Notify消息。例如，RSVP Notify消息可被扩展为包括指示在节点406处处理系统管理请求412的结果的响应有效载荷418。

例如，响应有效载荷可以包含指示系统管理请求的成功或失败或者响应于系统管理请求收集的系统数据的信息。响应有效载荷还可以包含辅助源发节点识别网络路径的特性的数据，例如识别哪个节点发送了响应有效载荷的数据。例如，响应有效载荷可以包括指示网络控制协议消息已经穿越的节点的数量的节点计数(跳数)。跳数可以指示路径上的对系统管理请求作出响应的节点相对于源发节点的位置，以使得源发节点可以重现节点被穿越的顺序。响应有效载荷还可以包括唯一地标识发送响应的节点的节点标识符以及在发送响应的节点处请求的IP存活时间(TTL)。IP TTL可被用于识别是否穿越了不能处理系统管理请求的任何节点。响应有效载荷还可以包括唯一地标识该系统管理请求的系统管理请求标识符，以及通过处理请求而生成的差错响应状态。包含响应有效载荷的RSVP Notify消息然后可以被发送给源发节点供进一步处理。

另外，在接收到网络控制协议消息410后，节点406可以在向目的地节点404中继消息410之前更新系统管理请求元数据。例如，诸如跳数之类的响应有效载荷数据中的一些可以被从系统管理请求元数据中拷贝。元数据中的跳数可以被每个节点更新或递增，以使得该元数据中的跳数可以指示已经穿越了多少跳。因此，系统管理请求元数据414a在穿越节点406和408时可被更新为系统管理请求元数据414b和414c。

与节点406处对系统管理请求412的处理类似地，节点408可以响应于节点406向目的地节点404中继消息410而处理系统管理请求412。因此，根据实施例，节点408可以响应于在从源发节点402到目的地节点404的外出路径上接收到网络控制协议消息410中的系统管理请求412，来生成包含响应有效载荷422的回复消息420。节点404可以以类似方式生成包含响应有效载荷426的回复消息424。

3.3进入系统管理请求处理

图4B图示出了根据实施例的发送路径导向的系统管理消息。类似于图4A，图4B图示出了源发节点402与目的地节点404之间的、具有中间节点406、408的网络路径。源发节点402可以发送包含有系统管理请求412和系统管理请求元数据414a的、诸如RSVP Path消息之类的网络控制协议消息。

然而，与参考图4A描述的实施例不同，系统管理请求412在从源发节点402到目的地节点404的外出路径上被节点406接收到时不能被处理。例如，系统管理请求元数据414a可以包含向节点406指示系统管理请求412应当在从目的地节点404到源发节点402的进入路径上而不是从源发节点到目的地节点的外出路径上被处理的标志。因此，当节点406接收到包含系统管理请求412的网络控制协议消息410时，节点406可以沿着网络路径将消息410朝着目的地节点404中继，而不处理系统管理请求412。然而，节点404可以更新系统管理请求元数据414a内包含的信息，如上所述。

一旦网络控制协议消息410到达目的地节点404，网络控制协议消息428就沿着该网络路径被发送回源发节点402。例如，如果网络控制协议消息410是RSVP消息，则RSVP RESV消息可以被生成并沿着网络路径被发送回源发节点。新的RSVP RESV消息可以包含系统管理请求412和系统管理请求元数据414d，以使得当网络控制协议消息428被节点408、406接收到时，这些节点可以处理系统管理请求并更新系统管理请求元数据。

当在去往源发节点402的进入路径上接收到网络控制协议消息428时，节点408可以处理系统管理请求412并且生成包含响应有效载荷436的回复消息434。例如，如果消息428是包含有系统管理请求412和系统管理请求元数据414b的RSVP Path消息，则回复消息434可以是被配置来传输响应有效载荷436的RSVP Notify消息或RSVP RESV消息。在一些实施例中，回复消息434可以传输单个节点的响应有效载荷。例如，在图4B中，节点404、408、406各自生成传输响应有效载荷432、436、440的对应回复消息430、434、438。在其它实施例中，回复消息434可以传输多个节点的响应有效载荷，如将在下面参考图4C进一步讨论的。

3.4连结响应有效载荷

图4C图示出了根据实施例的发送路径导向的系统管理消息。图4C图示出了沿着从目的地节点404到源发节点402的进入路径处理系统管理请求并且连结响应有效载荷以用于发送给源发节点。例如，网络控制协议消息410可以从源发节点402被发送给目的地节点404。在实施例中，网络控制协议消息410可以是RSVP消息、STUN消息、NLS消息或者任何其它路径导向的系统控制协议消息。如果网络控制协议消息410是RSVPPath消息，则一旦该消息到达目的地节点404，则目的地节点404就可以生成包含系统管理请求412和系统管理请求元数据414d的RSVP RESV消息，并将该RSVP RESV消息发送回源发节点402。

另外，目的地节点404可以在网络控制协议消息428中发送响应有效载荷402a。例如，目的地节点404可以处理系统管理请求412并且基于该系统管理请求生成响应有效载荷402a，如上面讨论的。然而，取代发送包含有目的地节点404的响应有效载荷的单独消息(例如RSVP Notify消息)，目的地节点可以将响应有效载荷402a包括在包含有系统管理请求412和系统管理请求元数据414d的RSVP RESV消息中，并且将该RSVPRESV消息中继给源发节点402。

当节点408接收到网络控制协议消息428时，该节点可以处理系统管理请求412并生成响应有效载荷402b。然而，取代将包含响应有效载荷402b的单独消息发送给源发节点402，节点408可以将响应有效载荷402b连结到包含在网络控制协议消息428内的响应有效载荷402a，并将网络控制协议消息428中继给源发节点402。

在一些实施例中，经连结的响应有效载荷402a和402b可能达到施加给某些协议的消息上的大小限制。例如，RSVP消息长度可被限制为64K总大小。如果达到大小限制，则可以生成新的RSVP消息来传输尚未处理系统管理请求的节点的响应有效载荷。例如，网络控制协议消息442可以包含系统管理请求412、系统管理请求元数据414f以及由节点404、408生成的经连结的响应有效载荷402a、402b。如果网络控制协议消息已经达到了由网络控制协议施加的大小限制，或者如果额外的响应有效载荷被连结到响应有效载荷402a、402b使得网络控制协议消息将超过该大小限制，则新的网络控制协议消息444可被生成来传输节点406的响应有效载荷402c，并且新消息中的有效载荷被从原始消息中移除，以使得每个消息符合可适用的大小约束。因此，沿着网络路径的另外的节点的响应有效载荷可以被附加到包含在网络控制协议消息444内的响应有效载荷402c，而不将额外的响应有效载荷附加到包含在网络控制协议消息442内的响应有效载荷402a和402b。因此，网络控制协议消息内的响应有效载荷的连结可以提供用于向源发节点提供响应数据的更高效方法，因为可以不必为每个响应有效载荷生成和发送新的网络控制协议消息。

因此，已公开了允许网络中的一系统在沿着路径的所有系统处将管理请求引导向另一系统。管理请求跟随沿着路径的IP流，从请求的源发者起穿越网络去往请求的目的地，并且被沿着该路径的、支持这里的技术的每个系统截取并对其作出响应；不支持这些技术的系统被透明地穿越。此外，可能发现不支持的系统和支持的系统存在于该路径中。

本公开的方案可以允许系统管理员或系统管理应用发出到达路径上的所有系统的单个系统管理请求，而不是必须向沿着网络路径的每个系统发送独有的系统管理请求。相比之下，诸如公共开放策略服务协议(COPS)之类的协议在策略决定点(PDP)和策略实施点(PEP)之间每次传达一个策略信息，从而需要针对网络上的每个PEP从PDP向PEP发送一消息。

此外，实施例可以提供诸如RSVP之类的下层网络控制协议所支持的自治系统管理，而无需来自外部管理应用的帮助。相比之下，诸如COPS-RSVP之类的协议仅提供了帮助建立并控制通过路径的流量的机制。具体地，COPS-RSVP请求针对的是路径本身以及在路径上移动的网络流量，而不是碰巧被该路径穿越的系统。此外，诸如RSVP-TE之类的协议表示将RSVP专门化用于流量工程(TE)，其被用来发信号通知用于经流量工程的隧道的资源预留，而非提供系统管理机制。

这里公开的实施例还可以取消如下需要：在向系统发送管理请求之前，发现并预先识别出应当向其引导管理请求的这些系统。此外，这里公开的实施例可以提供容易支持的分散化系统管理机制，并且具有支持任何类型的系统管理请求的灵活性，同时在每个系统处保留了限制哪些请求被服务的能力。

例如，实施例对于发现哪些系统当前位于沿着特定流的路径上以便找出诸如主机名称、设备类型、OS版本之类的系统信息是有用的。实施例可被用来获取路径上的这些系统的健康信息或性能指示符，例如CPU利用率或存储器利用率。实施例可被用来获取特定流的路径中的每个系统上的流缓存中的当前内容。

4.0实现机制—硬件概述

图5是示出本发明的实施例可在其上实现的计算机系统500的框图。计算机系统500包括用于传送信息的总线502或其他通信机构以及与总线502相耦合用于处理信息的处理器504。计算机系统500还包括诸如随机访问存储器(RAM)或其他动态存储设备之类的主存储器506，其耦合到总线502，用于存储信息和处理器504要执行的指令。主存储器506还可用于存储在处理器504执行指令期间的临时变量或其他中间信息。计算机系统500还包括只读存储器(ROM)508或其他静态存储设备，其耦合到总线502，用于存储静态信息和处理器504的指令。提供了诸如磁盘或光盘之类的存储设备510，其耦合到总线502，用于存储信息和指令。

计算机系统500可以经由总线502耦合到显示器512，例如阴极射线管(CRT)，用于向计算机用户显示信息。包括字母数字和其他键的输入设备514被耦合到总线502，用于向处理器504传送信息和命令选择。另一类用户输入设备是光标控制装置516，例如鼠标、轨迹球或光标方向键，用于向处理器504传送方向信息和命令选择，并用于控制显示器512上的光标移动。该输入设备一般具有两个轴(第一轴(例如x)和第二轴(例如y))上的两个自由度，其允许设备指定平面中的位置。

本发明涉及使用计算机系统500来实现这里描述的技术。根据本发明的一个实施例，这些技术由计算机系统500响应于处理器504执行包含在主存储器506中的一条或多条指令的一个或多个序列而执行。这种指令可以被从另一计算机可读介质(如存储设备510)读取到主存储器506中。对包含在主存储器506中的指令序列的执行使得处理器504执行这里描述的过程步骤。在替换实施例中，可以使用硬线电路来替代软件指令或与软件指令相组合以实现本发明。因此，本发明的实施例并不限于硬件电路和软件的任何特定组合。

这里所用的术语“机器可读介质”指参与提供使得机器以特定方式工作的数据的任何介质。在利用计算机系统500实现的实施例中，例如，在向处理器504提供指令以供执行时，涉及了各种机器可读介质。这种介质可以采取许多形式，包括但不限于存储介质和传送介质。存储介质包括非易失性介质和易失性介质。非易失性介质例如包括光盘或磁盘，如存储设备510。易失性介质包括动态存储器，如主存储器506。传送介质包括同轴电缆、铜线和光纤，包括构成总线502的线路。传送介质也可以采取声波或光波的形式，例如在无线电波和红外数据通信期间生成的声波或光波。所有这种介质都必须是有形的，以使得介质所承载的指令能够被物理机构检测到，该物理机构将指令读取到机器中。

机器可读介质的常见形式例如包括软盘、柔性盘、硬盘、磁带或任何其他磁介质，CD-ROM、任何其他光介质，穿孔卡、纸带、任何其他具有孔图案的物理介质，RAM、PROM和EPROM、FLASH-EPROM、任何其他存储器芯片或卡盘，下文中描述的载波，或者计算机可以读取的任何其他介质。

各种形式的机器可读介质可用于将一条或多条指令的一个或多个序列传送到处理器504以供执行。例如，指令可以首先承载在远程计算机的磁盘上。远程计算机可以将指令加载到其动态存储器中，并利用调制解调器经由电话线发送指令。计算机系统500本地的调制解调器可以接收电话线上的数据，并使用红外发送器来将数据转换为红外信号。红外检测器可以接收在红外信号中携带的数据，并且适当的电路可以将数据置于总线502上。总线502将数据传送到主存储器506，处理器504从主存储器506取得指令并执行指令。主存储器506接收的指令可以可选地在处理器504执行之前或之后存储在存储设备510上。

计算机系统500还包括耦合到总线502的通信接口518。通信接口518提供到与本地网络522相连接的网络链路520的双向数据通信耦合。例如，通信接口518可以是综合业务数字网络(ISDN)卡或调制解调器，以提供与相应类型电话线的数据通信连接。又例如，通信接口518可以是局域网(LAN)卡，以提供与兼容LAN的数据通信连接。也可以实现无线链路。在任何这种实现方式中，通信接口518发送并接收电的、电磁的或光的信号，这些信号携带了表示各种类型信息的数字数据流。

网络链路520通常通过一个或多个网络提供到其他数据设备的数据通信。例如，网络链路520可以通过本地网络522提供与主机计算机524或由因特网服务供应商(ISP)526操作的数据设备的连接。ISP 526进而通过全球分组数据通信网络(现在通常称为“因特网”)528提供数据通信服务。本地网络522和因特网528都使用携带数字数据流的电的、电磁的或光的信号。经过各种网络的信号和在网络链路520上并经过通信接口518的信号(这些信号携带去往和来自计算机系统500的数字数据)是传输信息的载波的示例性形式。

计算机系统500可以通过(一个或多个)网络、网络链路520和通信接口518发送消息并接收数据，其中包括程序代码。在因特网示例中，服务器530可以通过因特网528、ISP 526、本地网络522和通信接口518发送针对应用程序的请求代码。

接收到的代码可以在接收时被处理器504执行，和/或被存储在存储设备510或其他非易失性存储装置中以供以后执行。这样，计算机系统500可以获得载波形式的应用代码。

5.0扩展和替代

在前述说明书中，参考依实现方式而不同的多个具体细节描述了本发明的实施例。因此，说明书和附图应被认为是例示性的而不是限制性的。

Claims

1.一种用于网络管理的方法，包括由一个或多个处理器执行以下操作：

在第一节点处从源发节点接收网络控制消息，其中，所述网络控制消息是从源发节点起在指定路径上被发送的；其中，所述网络控制消息包括系统管理请求和系统管理请求元数据，并且是在路径导向的网络控制协议的分组中被接收的；

分析所述系统管理请求以确定要在所述第一节点处执行的特定系统管理功能；

在所述第一节点处执行所述特定系统管理功能；

生成指示出通过使得执行所述特定系统管理功能而生成的结果的响应有效载荷；

利用所述路径导向的网络控制协议，将所述响应有效载荷连结到所述网络控制消息或包含有来自所述指定路径的其他节点的响应有效载荷的现有消息中，并发送给所述源发节点；以及

利用所述路径导向的网络控制协议将所述网络控制消息中继到第二节点。

2.如权利要求1所述的方法，其中，所述网络控制消息是从所述源发节点起在所述指定路径上被发送的并且没有指定目的地节点。

3.如权利要求1所述的方法，还包括：从目的地节点接收所述网络控制消息并且利用路径导向的网络控制协议将所述网络控制消息中继到所述源发节点，其中，执行、生成和发送是在所述系统管理请求被从所述源发节点传送到所述目的地节点之后，响应于从所述目的地节点接收到所述系统管理请求而执行的。

4.如权利要求1所述的方法，其中，将所述响应有效载荷发送给所述源发节点包括：将所述响应有效载荷连结到来自一个或多个其他节点的一个或多个其它响应有效载荷并且利用所述路径导向的网络控制协议来发送经连结的响应有效载荷。

5.如权利要求1所述的方法，其中，所述系统管理请求元数据包括从由以下项目构成的组中选择的项目：指示所述网络控制消息已经穿越的节点的数量的节点计数；唯一地标识所述请求所针对的应用或客户端的类型的应用类型标识符；唯一地标识所述源发节点的节点标识符；以及唯一地标识所述系统管理请求的请求标识符。

6.如权利要求1所述的方法，其中，所述系统管理请求元数据包括：唯一地标识用于路由所述网络控制消息的路径的路径标识符；其中，将所述网络控制消息中继到第二节点包括：沿着由所述路径标识符所标识的路径来中继所述网络控制消息。

7.如权利要求1所述的方法，其中，所述响应有效载荷包括从由以下项目构成的组中选择的项目：指示所述网络控制消息已经穿越的节点的数量的节点计数；唯一地标识所述第一节点的节点标识符；所述网络控制消息在所述第一节点处的IP存活时间TTL；唯一地标识所述系统管理请求的请求标识符；以及通过处理所述系统管理请求而生成的差错响应状态。

8.如权利要求1所述的方法，其中，所述网络控制消息是如下消息中的一者：资源预留协议RSVP消息、用户数据报协议对网络地址转换器的简单穿越STUN消息、或者网络层信令NLS消息。

9.如权利要求1所述的方法，其中，所述特定系统管理功能包括如下中的一者：系统配置功能、系统状态检索功能、执行所述第一节点上的一个或多个应用的系统命令、以及对运行在所述第一节点上的应用所提供的功能的调用。

10.一种用于网络管理的装置，包括：

用于在第一节点处从源发节点接收网络控制消息的装置，其中，所述网络控制消息是从源发节点起在指定路径上被发送的；其中，所述网络控制消息包括系统管理请求和系统管理请求元数据，并且是在路径导向的网络控制协议的分组中被接收的；

用于分析所述系统管理请求以确定要在所述第一节点处执行的特定系统管理功能的装置；

用于利用所述路径导向的网络控制协议将所述网络控制消息中继到第二节点的装置；

用于在所述第一节点处执行所述特定系统管理功能的装置；

用于生成指示出通过使得执行所述特定系统管理功能而生成的结果的响应有效载荷的装置；

用于利用所述路径导向的网络控制协议，将所述响应有效载荷连结到所述网络控制消息或包含有来自所述指定路径的其他节点的响应有效载荷的现有消息中，并发送给所述源发节点的装置。

11.如权利要求10所述的装置，所述网络控制消息是从所述源发节点起在所述指定路径上被发送的并且没有指定目的地节点。

12.如权利要求10所述的装置，还包括：

用于从目的地节点接收所述网络控制消息的装置；

用于将所述网络控制消息中继到所述源发节点的装置；

其中，所述用于在所述第一节点处执行所述特定系统管理功能的装置、所述用于生成指示出通过使得执行所述特定系统管理功能而生成的结果的响应有效载荷的装置和所述用于利用所述路径导向的网络控制协议，将所述响应有效载荷连结到所述网络控制消息或包含有来自所述指定路径的其他节点的响应有效载荷的现有消息中，并发送给所述源发节点的装置是响应于从所述目的地节点接收到所述系统管理请求而工作的。

13.如权利要求10所述的装置，其中，用于利用所述路径导向的网络控制协议，将所述响应有效载荷连结到所述网络控制消息或包含有来自所述指定路径的其他节点的响应有效载荷的现有消息中，并将所述响应有效载荷发送给所述源发节点的装置包括：用于将所述响应有效载荷连结到来自一个或多个其他节点的一个或多个其它响应有效载荷并且发送经连结的响应有效载荷的装置。

14.如权利要求10所述的装置，其中，所述系统管理请求元数据包括从由以下项目构成的组中选择的项目：指示所述网络控制消息已经穿越的节点的数量的节点计数；唯一地标识所述请求所针对的应用或客户端的类型的应用类型标识符；唯一地标识所述源发节点的节点标识符；以及唯一地标识所述系统管理请求的请求标识符。

15.如权利要求10所述的装置，其中，所述系统管理请求元数据包括：唯一地标识用于路由所述网络控制消息的路径的路径标识符；其中，用于利用所述路径导向的网络控制协议将所述网络控制消息中继到第二节点的装置包括：用于沿着由所述路径标识符所标识的路径来中继所述网络控制消息的装置。

16.如权利要求10所述的装置，其中，所述响应有效载荷包括从由以下项目构成的组中选择的项目：指示所述网络控制消息已经穿越的节点的数量的节点计数；唯一地标识所述第一节点的节点标识符；所述网络控制消息在所述第一节点处的IP存活时间TTL；唯一地标识所述系统管理请求的请求标识符；以及通过处理所述系统管理请求而生成的差错响应状态。

17.如权利要求10所述的装置，其中，所述网络控制消息是如下消息中的一者：资源预留协议RSVP消息、用户数据报协议对网络地址转换器的简单穿越STUN消息、或者网络层信令NLS消息。

18.如权利要求10所述的装置，其中，所述特定系统管理功能包括如下中的一者：系统配置功能、系统状态检索功能、执行所述第一节点上的一个或多个应用的系统命令、以及对运行在所述第一节点上的应用所提供的功能的调用。