KR20080092332A - Method and system for light-weight soap transport for web services based management - Google Patents

Abstract

Certain aspects of a method and system for light-weight simple object access protocol (SOAP) transport for web services based management are disclosed. Aspects of a method may include managing a system using a simple object access protocol (SOAP) message that is mapped over one or both of: a remote management and control protocol (RMCP) and a RMCP security extensions protocol (RSP) to enable remote management of systems using Web services in out-of-band (OOB) management devices.

Description

METHOD AND SYSTEM FOR LIGHT-WEIGHT SOAP TRANSPORT FOR WEB SERVICES BASED MANAGEMENT}

Certain embodiments of the present invention relate to network communication. In particular, certain embodiments of the present invention relate to methods and systems for light-weight simple object access protocol (SOAP) transport for web service based management.

The web services architecture is based on a suite of details that define rich web-based functions and can be configured to meet various service needs. The web services architecture can be used in the area of system management to promote interoperability between management applications and managed resources. The web services architecture may be capable of identifying a central set of web service details and usage needs to show a common set of operations that may be central to system management. For example, the details can discover the existence of management resources and become operable between them. Individual management resources may be created, renamed, or deleted by coordination.

Web service details may specify minimum implementation requirements for conformant web service implementations. Implementation of the web service details may be free to extend beyond this set of operations, or may be chosen not to support one or more areas of this function if the function is not suitable for the target device or system.

Web services can be self-contained and self-describing modular applications that can be published, located, and cited over the web. A web services definition language (WSDL) may enable service providers to describe the basic format of web service requests on various protocols or encodings. Web services may be a collection of network endpoints or ports. In WSDL, abstract definitions of endpoints and messages are specific network layout or data of endpoints and messages to allow reuse of messages that are abstract descriptions of the data being exchanged, and port types that are abstract sets of operations. Can be separated from formal combinations. Data format details and specific protocols for a particular port type may constitute a reusable combination. Ports can be defined by associating network addresses with reusable bonds, and a collection of ports can define a service.

The term “system manageability” may represent a wide range of technologies that enable remote system access and control in both OS-existent and OS-absent. These technologies include minimizing on-site information technology (IT) related to maintenance, maximizing system availability and performance for local users, and localization by IT administrators. The primary focus is on maximizing remote visibility and connectivity to systems, and minimizing system power consumption required to maintain this connection robustly.

Web service based management of computer systems has been increasing in popularity. Remote management of a system using web services in an out-of-band (OOB) or OS-free environment is an OOB that resides in a system such as a network controller or baseboard management controllers (BMCs). Making significant changes for management devices.

The limitations and disadvantages of additional conventional and traditional approaches will become apparent to those skilled in the art in comparison with some aspects of the invention, such as the accompanying drawings and the rest of the invention described later.

As substantially shown in connection with at least one of the figures, a method and / or system for lightweight simple object access protocol (SOAP) transport for web service based management is more fully described in the claims. .

Other advantages, aspects, and progressive forms of the present invention, as well as the described embodiments, can be understood in more detail from the appended drawings, which will be described later.

1A is a block diagram of an exemplary architecture with SOAP on RMCP / RSP mapping in accordance with an embodiment of the invention.

1B is a block diagram illustrating a host with network interface hardware in accordance with an embodiment of the invention.

1C is a block diagram of an example client server architecture that may be used in connection with an embodiment of the present invention.

2 is a block diagram illustrating a WS-MAN stack with various SOAP transports, in accordance with various embodiments of the present invention.

3 is a block diagram illustrating a WS-MAN stack that can coexist with an ASF stack with a movement path from the ASF stack to the WS-MAN stack in accordance with an embodiment of the present invention.

4 is a flowchart illustrating exemplary steps for processing an outgoing message of an RMCP packet for web service based management, in accordance with various embodiments of the present invention.

5 is a flowchart illustrating exemplary steps for processing an incoming message of an RMCP packet for web service based management according to various embodiments of the present disclosure.

Certain embodiments of the present invention may be found in a method and system for lightweight SOAP transport for web service based management. One or both of the remote management and control protocol (RMCP), and the RMCP security extensions protocol (RSP), which enables remote management of systems using web services in OOB management devices. It may include managing the system using SOAP messages mapped over the web.

1A is a block diagram of an exemplary architecture with SOAP on RMCP / RSP mapping in accordance with an embodiment of the invention. Referring to FIG. 1A, a SOAP block 102, an RMCP block 104, an RSP block 106, a user datagram protocol (UDP) block 108, an Internet protocol (IP) block ( 110, and a medium access control (MAC) layer and a physical (PHY) layer (MAC / PHY) block 112 are shown.

The MAC / PHY layer block 112 may include suitable logic, circuitry, and / or code that may enable control of a connection to a medium that may be shared between two or more entities. The MAC / PHY layer block 112 may include a MAC address unique to each network interface controller (NIC). The MAC / PHY layer block 112 may enable encoding and decoding the data packet into bits. The MAC / PHY layer block 112 may provide transport protocol knowledge and management and may handle errors in the physical layer, flow control, and frame synchronization. The MAC / PHY layer block 112 may control how a computer on the network accesses the data and how to obtain permission to send the data. The MAC / PHY layer block 112 transmits a bit stream, such as electrical impulse, light, or wireless signals, over a network at electrical and mechanical levels, for example, to provide information on a physical medium that connects two devices. Can provide transmission. MAC / PHY layer block 112 provides hardware for transmitting and receiving data on a carrier such as, for example, a cable. The MAC / PHY layer 112 may correspond to the lowest layer of the network standard model, for example.

The Ethernet frame may include an Ethernet header 134, an Ethernet payload 136, and a cyclic redundancy check (CRC) field 138 associated with the MAC / PHY layer block 112. Ethernet header field 134 may include, for example, an Ethernet destination address and an Ethernet source address, and a frame type. Ethernet payload 136 may comprise a portion of an Ethernet packet that may be used to transmit user information. CRC field 138 may include data associated with CRC data validity calculation. CRC field 138 may be used for data transmission errors.

IP block 110 may correspond to a network layer. The network layer may define how network functions are interconnected and may enable receiving data from one computer to another, even in a remote network. The IP datagram may include an IP header 130 and an IP payload 132 associated with the IP block 110. IP header 130 includes a version and header length field, a service type field, a total length field, an identification field, a flag field, a time-to-live field, a protocol field, a header checksum field, a source. IP address field, and destination IP address field.

UDP block 108 may be layered on IP block 110. UDP block 108 may correspond to a transport layer. The transport layer can keep track of data from each application and combine it into a single flow of data to transfer the data to lower layers. The transport layer may also be responsible for defining the means by which potentially large amounts of application data are split for transmission. UDP block 108 excludes some of the flow management types and reliability of TCP, but can be used to transmit data between application processes with greater efficiency. The UDP datagram can include a UDP header 126 associated with the UDP block 108, and a UDP payload 128. The UDP header 126 may include a source port field, a destination port field, a UDP length field, and a UDP checksum field.

The RSP block 106 may enable to provide integrity and anti-replay services for RMCP messages. The RSP message may include an RSP header 120, an RSP payload 122, and an RSP trailer 124. When an RSP is used, the overall RMCP message may be sealed in the RSP header 120 and the RSP trailer 124. The RSP header 120 may be inserted between the UDP header 126 and the RMCP header 116. RSP trailer 124 may be located at the end of the data block of the RMCP message, and security extensions may be applied on the UDP layer.

The RSP header 120 may include two fields, for example, a session ID and a sequence number. The session ID can be any number selected by each entity and exchanged using RSP session protocol (RSP) open session request / response messages. Session IDs may be used to identify a particular session state that may be used to process a particular message. The sequential numbers may be used with a sliding receiving window to provide a redo prevention service for messages. The sequence number may be a unique monotonically increasing number inserted into the header by the sender. When a session is created, the sequence number can be initialized to zero and incremented to one at the beginning of the origination process for a given message. A new session may be created prior to the sequence number again surrounded by zero.

The RSP trailer 124 may include four fields, for example, a pad field, a pad length field, a next header field, and a maintenance data field. The pad field may provide data word alignment for the integrity data field in the protected RMCP message. The pad length field may specify the number of pad bytes present in the message. The next header field may indicate the type of message sealed between the RSP header 120 and the RSP trailer 124. The conservation data field may be used to maintain the results of conservation algorithms such as, for example, a keyed hash function performed on certain fields of the RSP header 120, the RMCP message, and the RSP trailer 124. Can be.

The RMCP block 104 can be used for client control functions when the managed client is in an OS-absent state. In an OS-free environment, RMCP messages can be exchanged between a management console and a managed client. Client control functions may include operations such as reset, power up, and power down. The protocols may activate firmware of alert-sending devices to analyze information in the absence of OS-existent drivers.

The RMCP message may be independent of the media, and, depending on the media, the associated header fields may be different. The RMCP message may include an RMCP header 116 and an RMCP payload 118. The RMCP header 116 may include a version field, a reserved field, a sequential number field, and a class field of a message. The version field may identify a version of the RMCP header. The sequence number field may indicate a sequence number associated with the RMCP message. Sequential numbers can be used to ensure reliability on UDP and to facilitate message ordering and recognition of identical messages. The sequence number may be incremented each time a unique message is sent from the same source, such as, for example, a management console or client system. When a message initiator retries a message due to a missing RMCP response, the message initiator initiates the exact message of the original transmission with the same sequence number that allows the message initiator to match the RMCP message to the associated response. Can be sent.

The RMCP payload 118 may include an Internet assigned number authority (IANA) enterprise number field, message type field, message tag field, spare field, data length field, and data field. The IANA Business Number field may indicate an iana business number associated with the entity that defines the message type values and data field format for the message. The message type field may be defined by an entity associated with the value of the previous field. The message tag field can be used to match the request-response pair. The data length field may indicate the number of bytes representing the data field. The data field may represent data associated with a specific company number and message type.

The current ping sent from the management console may request that the client respond to the current pong. A capability request from the management console may request that the client respond with a performance response. The system status request from the management console may request that the client respond with a system status response. The message tag field of the RMCP payload 118 may provide a method for combining the response with the associated request. For example, the management console can send a managed client a current ping with a set of message tag fields set to 12h. The alert-sending device at the client may copy the message tag field value from the received message in the associated current Pong response prior to sending the message. When the management console receives the current pong, the management console may map the message to the associated current ping by matching the message tag fields.

1B is a block diagram illustrating a host with network interface hardware in accordance with an embodiment of the invention. 1B, a networking system 150 is shown, such as a server, client, or similar network machine that may include, for example, a host 152 and network interface hardware (NIHW) device 154. do. The host 152 may include a central processing unit (CPU) 156, a memory 158, and a chipset 160. CPU 156, memory 158, and chipset 160 may be communicatively coupled, for example, via bus 162.

Networking system 150 may enable operation or provision of various networking protocols. For example, networking system 150 may enable provision of a TCP / IP connection. In this regard, the networking system 150 may be, for example, Internet control message protocol (ICMP), SOAP, RMCP, RSP, UDP, IP, address resolution protocol (ARP), streams. It may enable the provision of a stream control transmission protocol (SCTP), and / or a path maximum transmission unit (PMTU) discovery protocol. The ICMP protocol may, for example, allow routers to send error and / or control messages regarding packet processing in an IP network. The ARP protocol may refer to a low-level protocol within a TCP / IP pair that can map IP addresses to corresponding Ethernet addresses. SCTP may provide for the transmission of public switched telephone networks (PSTNs) for signaling messages on a connectionless packet network, for example an IP network. The PMTU may refer to the maximum unit of data that can be transmitted on a given physical network medium. In other embodiments, SCTP may be used as the transport protocol rather than TCP.

The host 152 may enable setting parameters for network connection. For example, host 152 may use time stamping, window scaling, delayed acknowledgment policies, flow control schemes used, handling, selective acknowledgment (SACK), and use. Buffers, and / or other transmission related parameters. The host 152 may also set network layer parameters including information supporting IPv4 or IPv6, for example, and choices such as no fragments and / or hop restriction. The host 152 may also set data link layer parameters including information providing, for example, a virtual local area network (VLAN) and a source address used.

CPU 156 may include suitable logic, circuitry, and / or code that may enable the provision of performance and / or management of networking operations associated with remote users or clients on a network. The CPU 156 may also be configured to provide performance and / or management of service applications that may be provided to remote clients on the network.

Memory 158 may include suitable logic, circuitry, and / or code that may enable storage of information regarding service applications and / or networking operations provided by CPU 156. Chipset 160 may include, for example, suitable logic to enable memory management, PCI master and arbitrator, graphical interface, I / O master for USB, audio, and / or parallel devices, Circuitry, and / or code. In this regard, chipset 160 may include at least one integrated circuit (IC) that provides a service of provision of CPU 156 operations. In some cases, services provided by chipset 160 may be implemented in separate ICs. The selection of one or more ICs for implementing chipset 160 may be based on the number and / or type of services provided. The NIHW device 154 may include suitable logic, circuitry, and / or code that may enable communication with the host 152. In this regard, NIHW device 154 may enable communication with CPU 156, memory 158, and / or chipset 160.

1C is a block diagram of an example client server architecture that may be used in connection with an embodiment of the present invention. Referring to FIG. 1C, a system 170 is shown that includes a host 171 and a plurality of clients 173, 175, 177, 179. The host 171 enables remote management of OOB management devices or clients, for example, systems using web services at client 173, client 175, client 177, and client 179. To this end, it may be possible to manage the system 170 using SOAP messages mapped over one or both of remote management and control protocol (RMCP), and RMCP Security Extension Protocol (RSP). Appropriate logic, circuitry, and / or code.

System 170 may include a management console that may use RMCP to manage a plurality of clients 173, 175, 177, 179. The management console can power down or reset the managed client using the OS-existing method as the primary method, in order to allow any shutdown operation to operate in the normal manner. The management console may use RMCP if the managed client fails to respond to OS-existing methods.

2 is a block diagram illustrating a Web services management (WS-MAN) stack with various SOAP transports in accordance with various embodiments of the present invention. 2, a WS-MAN stack 200 with various SOAP transports is shown. WS-MAN stack 200 includes MAC / PHY layer block 240, IP block 238, UDP block 234, transmission control protocol (TCP) block 236, RMCP / RSP block ( 222, a hyper text transfer protocol (HTTP) block 220, a secure HTTP (HTTPS) block 216, a transport layer security protocol (TLS) block 218, a SOAP block ( 212, description block 210, security profile block 208, data transfer block 206, WS-MAN block 204, and remote management application block 202. .

The MAC / PHY layer block 240 may include suitable logic, circuitry, and / or code that may enable control of a connection to a medium that may be shared between two or more entities. The MAC / PHY layer block 240 may include a MAC address that may be unique to each network interface controller (NIC). MAC / PHY layer block 240 may provide transport protocol knowledge and may control errors in physical layer, flow control, and frame synchronization. MAC / PHY layer block 240 provides hardware for transmitting and receiving data on a carrier such as, for example, cables. The MAC / PHY layer block 240 may correspond to a physical layer. IP block 238 may correspond to a network layer. The network layer may define how network functions are connected and may enable receiving data from one computer to another computer, even if it may be on a remote network.

UDP block 234 and TCP block 236 may be layered on IP block 238. UDP block 234 and TCP block 236 may correspond to the transport layer. The transport layer can enable tracking of data from each application and can combine the data into a single flow of data to send the data to the lower layers. The transport layer may also be responsible for defining the means by which potentially large amounts of application data are split for transmission. UDP block 108 excludes some of the flow management types and reliability of TCP block 236, but can be used to transmit data between application processes with greater efficiency.

The RMCP / RSP block 222 may enable providing integrity and anti-replay services for RMCP messages. When an RSP is used, the entire RMCP message can be sealed in the RSP header and the RSP trailer. RMCP / RSP block 222 may be used for client control functions when the managed client is in an OS-absent state. In an OS-free environment, RMCP messages can be exchanged between the management console and the managed client. Client control functions may include operations such as reset, power-up, and power-drop. The protocols may enable the firmware of the alert-transmitting devices to analyze the information in the absence of OS-existent drivers.

HTTP block 220 may enable the transfer of hypertext documents and other files between the client and server to enable the web. The HTTPS block 216 can enable the use of secure sockets layer (SSL) or transport layer security (TLS) algorithms to ensure the privacy of HTTP connections. TLS protocol block 218 may allow for providing secure communications on the Internet for various applications, such as, for example, web browsing, email, Internet fax, and other data transmissions. The various SOAP transports in the WS-MAN stack 200 are UDP block 234, TCP block 236, RMCP / RSP block 222, HTTP block 220, and HTTPS block 216 and TLS block 218. It may include.

SOAP block 212 may allow for the exchange of markup language messages, such as XML-based messages, on a computer network using, for example, HTTP. SOAP block 212 can form the foundation layer of WS-MAN stack 200 by providing a basic messaging framework in which more abstract layers can be created. The SOAP block 212 may be a remote procedure call where, for example, one network node, such as a client, may send a request message to another node, such as a server, and the server may send a response message to the client. procedure call (RPC). SOAP block 212 may be a light-weight protocol intended for the exchange of structured information in a distributed and distributed environment.

SOAP binding details can declare the types provided by the binding. SOAP binding details indicate how the services of the underlying protocol are used to transmit SOAP message information sets, and the services of the underlying protocol are used to fulfill the contract formed by the forms provided by the association. How it can be done. SOAP binding details may indicate how to deal with potential failures that may participate in the binding, and may specify requirements for building a conformant implementation of the specified binding.

In accordance with an embodiment of the present invention, the generation, transmission, and processing of a SOAP message via one or more intermediaries may be specified in terms of a distributed state machine. The state may include information known to the SOAP node at a given point in time, including without restricting the content of the messages collected for transmission or received for processing. The status at each node may be updated by either local processing or information received from adjacent nodes. The purpose of the join details may be to increase the central SOAP rules with additional processing that may be specific to the join, and to specify in such a way that the underlying protocol can be used to transfer information between adjacent nodes in the message path. have.

The distributed state machine that manages the transmission of a given SOAP message through the message path may be a combination of SOAP processing central to each node associated with the binding details connecting each pair of nodes. The minimum obligation of combining message transmissions is to specify the means by which a set of SOAP message information can be transmitted and reconstructed by combining at the receiving SOAP node and that the transmission of envelopes can be affected using the facilities of the underlying protocol. It may be to embody the manner.

Description block 210 may allow a programming model, transmission, or protocol for communicating between users. The description block 210 may represent messages received and generated by the WS-MAN stack 200 and may indicate application level error messages generated by the WS-MAN stack 200. Security profile block 208 may include a plurality of security profiles to protect management operations and responses against attacks such as snooping, interception, replay, and correction during transmission. The transport layer may be responsible for message integrity, protection, authentication, and / or security. Security profiles may be used for descriptive and metadata purposes and may not be visible in SOAP traffic.

The data transfer block 206 may include a plurality of resource access operations, for example, to obtain, set, and calculate values. For example, WS-transmission details can be used as the basis for a single resource access. WS-calculated messages can be used for multi-case retrieval. WS-eventing messages can be used to send and notify events by allowing the client to accept and receive event messages.

The WS-Management Block 204 may include a generic SOAP based protocol for managing systems such as PCs, servers, devices, web services, and other manageable entities. WS-management block 204 can be designed to meet a plurality of requirements to limit web service protocols so that web services can be implemented in management services of both hardware and software. The WS-Management Block 204 can ensure compatibility with other web service details. WS-management block 204 allows IT administrators to remotely access devices on networks, whether the systems are out of the box, low power consumption, or otherwise unavailable. can do. The remote management application block 202 may enable out of band remote management capability with systems such as PC desktop systems and / or servers.

According to an exemplary embodiment of the present invention, SOAP on RMCP may comprise a mapping of SOAP messages on RMCP / RSP transport. RMCP / RSP is a layered message based protocol over UDP. RMCP / RSP can be used as a transport in ASF and Intelligent Platform Management Interface (IPMI) based on OOB management solutions in client and server systems. RMCP may provide reliability over UDP with respect to sequencing, message level acknowledgments, and limited retansmissions. The RSP may provide sufficient security over UDP in the form of message integrity and data based authentication. According to an embodiment of the present invention, additional encryption services may be provided by encrypting portions of SOAP messages or by adding a cryptographic provision using RMCP +.

3 is a block diagram illustrating a WS-MAN stack that can coexist with an ASF stack with a movement path from an ASF stack to a WS-MAN stack, in accordance with an embodiment of the invention. Referring to FIG. 3, a WS-MAN with various SOAP transports is shown. The WS-MAN stack 300 includes a MAC / PHY layer block 340, an IP block 338, a UDP block 334, a TCP block 336, a platform event trap (PET) block 322, and a simple network (SNMP). Management protocol (block) 324, RSSP block 326, and RSPP (RSSP Authentication and Key Generation Protocol) block 328. WS-MAN stack 300 also includes RSP block 330, RMCP block 332, HTTP block 320, HTTPS block 316, TLS block 318, ASF block 314, SOAP block 312. , Description block 310, security profile block 308, data transfer block 306, WS-management block 304, and remote management application block 302. . The various protocols and SOAP transports of FIG. 3 will be substantially as shown in FIG. 2.

The RSP block 330 may enable providing preservation and redo prevention services for RMCP messages. When an RSP is used, the entire RMCP message can be sealed in the RSP header and the RSP trailer. The RMCP block 332 can be used for client control functions when the managed client is in an OS-absent state. In an OS-free environment, RMCP messages can be exchanged between the management console and the managed client. Client control functions may include operations such as reset, power up, power down. The protocols may enable the firmware of alert sending devices to parse the information in the absence of OS-existent drivers.

In operation for outgoing message processing, when the RMCP request initiator generates a message, its RMCP protocol engine may access a device security policy to determine if the RMCP security extension has been activated. If the function is activated, the RMCP block 332 can determine if an appropriate RSP session exists for the message. If no suitable session exists, the RMCP block 332 can use the RSSP block 326 to create a session. If the session exists but does not exist at the time of message transmission, the RMCP block 332 will wait until the session arrives, which is when the RMCP message is sent. If the session exists and this session exists at the time of message transmission, the RMCP block 332 will forward the session ID, RMCP message, and RMCP message length to the next lower layer for further processing.

When the sending device's RSP protocol engine receives a message from the RMCP block 332, the RSP block 330 can insert an RSP header at the beginning of the message and copy the session ID value into the session ID field of the header. Can be. The RSP block 330 may use the session ID for the session state, increment the sequence number of the session, and then insert this value into the sequence number field of the RSP header. The RSP block 330 may cause the RSP trailer to be created at the end of the data block of the message. The RSP block 330 may calculate the amount of padding required to align the integrity data fields of the protected message on the data word area. The RSP block 330 can use the RMCP message length passed from the RMCP block 332 to locate at the end of the data block of the message, and the pad bytes and value for the pad length of the RSP trailers and the next header fields. You can insert a modified number of them.

The RSP block 330 can use the session ID to access the session state, determine the particular conservation algorithm used with the message, and calculate the conservation data on the sealed message. The calculated value can be inserted into the conservation data field of the RSP trailer to generate a protected RMCP message. The RSP block 330 can cause the length of the message that causes the addition to be updated to be responsible for the addition of the RSP header and the RSP trailer, and the next subordinate, for example the UDP block 334, for further processing. The layer protocol can convey UDP source and destination port values, protected RMCP message length, and protected RMCP message.

When the UDP block 334 receives the message from the RSP block 330, the UDP protocol engine of the transmitting device may insert the header at the beginning of the protected RMCP message. The UDP block 334 can cause the port values delivered from the RSP block 330 to be copied into the source port and destination port fields of the UDP header. The UDP block 334 can calculate the UDP packet length and checksum and insert these values into the UDP length and checksum fields. The resulting UDP packet may be forwarded to other lower layer protocols such as, for example, IP block 338, and MAC / PHY layer block 340 for further processing and finally forwarding to the destination.

In operation for incoming message processing, when a frame containing a protected RMCP message arrives at the destination, lower layer protocols such as MAC / PHY layer block 340 and IP block 338 of the receiving device are further processed. For example, the resulting packet may be forwarded to the next higher layer protocol such as, for example, UDP block 334. The UDP block 334 of the receiving device can verify the checksum field of the UDP header. If the checksum field is invalid, the UDP block 334 may discard the packet. If the checksum field is valid, the UDP block 334 can verify that it provides a higher layer protocol specified by the value of the destination port field. If no higher layer protocol is provided, the UDP block 334 may discard the packet. If a higher layer protocol is provided, the UDP block 334 removes its header, updates the protected RMCP message length, and processes the protected RMCP message and its length with, for example, the RSP block 330 for further processing. It can be passed to the same next higher layer protocol.

When the RSP block 330 receives a protected RMCP message from the UDP block 334, the RSP block 330 may access a device security policy to determine if the RMCP security extension has been activated. If the function is disabled, the RSP block 330 may discard the message. If the function is activated, the RSP block 330 can use the session ID value of the RSP header to detect the session state for this message. If no session state is found for this message, the RSP block 330 may discard this message. If the session exists but does not allow to accept protected RMCP messages, the RSP block 330 may discard the message. If it is time for the session to exist and allow to accept a protected RMCP message, then the RSP block 330 detects the protected data field of the RSP trailer and validates the protected RMCP message length and session state passed from the UDP block 334. The conservation algorithm specified in. If the integrity data field is invalid, the RSP block 330 may discard this message. If the preservation data field is valid, the RSP block 330 uses the sequential number field of the RSP header and checks if this message is new and has not replicated the position of the message relative to the previously received message and the sliding receive window. The sliding reception window information of the session state may be used to determine.

The received message may be new and may be inside the sliding receive window or to the right of the sliding receive window. If the received message is not new, the RSP block 330 may discard this message. If the received message is on the right side of the sliding receive window, the sliding receive window may proceed to the right to process the message. In accordance with an embodiment of the present invention, the message may be inappropriately received and properly processed. If sequential number processing is successfully completed, RSP block 330 stores the sequential number value in the next header field and uses the value of the pad length field to calculate the number of pad bytes that can be removed at the end of the message. Can be. The RSP block 330 may remove the RSP header and the RSP trailer and update the length value of the RMCP message. The RSP block 330 may forward the RMCP message and its corresponding length to the next higher layer protocol such as, for example, the RMCP block 332 for further processing.

The RSSP block 326 may be configured to establish an association between the management console and the corresponding clients. The association may keep track of state information that defines a relationship, such as, for example, a keying material, and the particular algorithms used for the sequence numbers. An association may be established via a session protocol with a set of messages that may be sent to establish and release an association. The RSSP block 326 may allow the session to be divided into four periods, for example, discovery, generation, message transmission, and message destruction. The session may be further divided into one or more types based on the administrative console user role used to create the session, such as, for example, operator sessions and administrator sessions. In accordance with an embodiment of the present invention, a managed client may simultaneously provide at least two types of two sessions.

During the retrieval time, the management console and managed client can use the RMCP current ping / pong messages to determine if a particular managed client provides RMCP security extensions. If a managed client provides an RMCP security extension and a management console attempts to establish an association with the managed client, the management console may switch to the creation of a session protocol for the managed client. During generation, the management console and managed client can use RSSP open session request / response messages to exchange session IDs, the RSP integrity algorithm for the session, and the RSSP authentication and key generation protocol. RAKP) can be determined. The management console can initialize the selected authentication and key generation protocol and generate the required keying material required for the RSP conservation algorithm. If the RSSP is successful, an association between the management console and the managed client may be established and may transition to the message transmission time of the session protocol. If the RSSP is not successful due to missing messages, both entities can re-initialize their protocol state. If the management console detects a missing message, you can restart the protocol at the beginning.

During the message transmission period, the management console and the managed client can exchange the desired messages needed to manage the client. Each of these messages may be sealed in an RSP header and RSP trailer with integrity protection provided by the RSP conservation algorithm determined during generation. If the management console attempts to close the session, it can switch to the destruction time. During the disruption period, the management console and the managed client may exchange RSSP closed session request / response messages and terminate the session. At the end of the creation time a plurality of messages sent to the RMCP Secure Extended UDP port may be sealed in an RSP header that may use a bypass session ID prior to the establishment of the session.

RAKP block 328 mutually authenticates the management console with a given managed client and generates a pair-wise unique symmetric key material that can be used with multiple conservation algorithms to provide protection for RMCP messages. To do this, pre-shared keys and keyed-hashed message authentication code (HMAC) based preservation algorithms can be used. PET block 322 may enable the use of SNMP trap protocol data units (PDUs) to send alerts. The SNMP block 324 can be used by network management applications to query the management agent using the provided management information base. The SNMP block 324 may enable sending SNMP trap PDUs.

The PET block 322 can send alerts from the managed client to the management console. The SNMP block 324 can be used by the network management application to query the management agent using the provided management information base.

The management console can use RMCP to manage client systems. The management console may use OS-existent methods as the primary way to power down or reset the managed client so that any shutdown operation can be operated in the normal manner. If the managed client fails to respond to OS-existing methods, the management consoles can apply RMCP.

Alert standard format (ASF) block 314 may include a set of security extensions that provide authentication and preservation services for RMCP messages. The RMCP-aware management console can determine the RMCP capabilities of the managed client, for example by issuing any subsequent messages. The management console may issue an RMCP current ping message directed to the managed client. The RMCP-aware client may respond to receipt of an RMCP message as long as the RMCP version of the RMCP header 116 is the version provided by the client. The client may respond with an RMCP current pong message and may set the field of entities provided to indicate its ASF version. The management console can cause the managed client to issue RMCP capability request messages. The client may respond to receipt of the RMCP message as long as the RMCP version of the RMCP header 116 is the version provided by the client. The client may respond with an RMCP Performance Response message by returning to preconfigured system capabilities into non-volatile storage of the alert sending device.

Web services may use SOAP block 312 or XML-based messaging, and HTTP block 320 or HTTPS 320 as the SOAP transport for communication. The use of SOAP over HTTP / HTTPS may require implementation of the HTTP / TLS / TCP stack. HTTP / TLS / TCP stack implementations can be complex for embedded devices, and large HTTP (S) / TLS / TCP code footprints may not be cost effective for devices with limited memory resources. Can be. In addition, the processing power required for transport protocol processing can lead to unacceptable response time, or power consumption. Thus, light-weight transport for SOAP can be used in an OOB management environment.

ASF details are specified for remote management of computer systems in an OOB managed environment. RMCP block 332 and RSP block 330 are part of a pair of protocols defined by ASF details. In accordance with an embodiment of the present invention, a web service interface may be provided for remote management of systems.

According to an embodiment of the present invention, the use of SOAP over RMCP / RSP can have a number of benefits. For example, RMCP / RSP block 222 may be less complex than a combination of HTTP block 220, HTTPS block 216, TLS block 218, and TCP block 236. The RMCP / RSP block 222 may be a lightweight transmission with messaging semantics, reliability provision, authentication provision, and provision for multicast. The RMCP / RSP block 222 may be more suitable for an OOB management environment in terms of power, memory, and processing limitations. The use of SOAP over RMCP / RSP can affect the existing ASF / IPMI architecture and enable WS-MAN management solutions for the OOB management environment. The use of SOAP over RMCP / RSP can provide a better migration path from ASF to WS-MAN based management solutions.

The use of SOAP on RMCP / RSP can be referred to as a lightweight SOAP transport, for example. Lightweight SOAP transport may be suitable for smaller code footprints and may be easier to implement. Lightweight SOAP transport may require fewer processing cycles compared to HTTP block 220 or HTTPS block 216. Lightweight SOAP transport can provide security and reliability for OOB operations. Lightweight SOAP transport can provide multicasting, message-exchange-pattern (MEP), and request-response MEP of SOAP messages.

The RMCP message may be media independent and, if dependent on the media, the associated header fields may be different. The RMCP message may include an RMCP header 116, and an RMCP payload 118. The RMCP header 116 may include a version field, a spare field, a sequence number field, and a message class field. A new message class called Web Services can be used for SOAP over RMCP mapping. The version field may identify a version of the RMCP header. The sequence number field may identify a sequence number associated with the RMCP message. Sequential numbers can be used to ensure reliability on UDP and to facilitate message ordering and recognition of identical messages. The sequence number may be incremented each time a unique message is sent from the same source, such as, for example, a management console or client system. When a message initiator attempts to retry a message due to a loss of an RMCP response, the message initiator may send the exact message of the original transmission with the same sequence number that allows the message initiator to match the RMCP message with the associated response.

The RMCP payload 118 may include an Internet assigned numbers authority (IANA) enterprise number field, message type field, message tag field, spare field, data length field, and data field. The IANA enterprise number field may indicate an IANA enterprise number associated with the entity that defines the message type values and data field format for the message. A new IANA enterprise number can be assigned for SOAP over RMCP. The message type field may be defined by an entity associated with the value of the previous field. For example, for SOAP over RMCP, the value of the message type field may be equal to O for a unicast unidirectional SOAP message. The value of the message type field may be equal to 1 for a multicast unidirectional SOAP message. The value of the message type field may be equal to 2 for a unicast SOAP request. The value of the message type field may be equal to 3 for a unicast response. The value of the message type field may be equal to 4 for a multicast SOAP request.

The message tag field can be used to match request-response pairs. The data length field may indicate the number of bytes representing the data field. The data field may represent data associated with a particular business number and message type. The data length field for SOAP on RMCP can be extended to, for example, 2 bytes using a spare field, so that the SOAP message can be up to 65535 bytes in length. Sequencing, message acknowledgments, and retransmission schemes as defined in the ASF details may be used without any change to provide better reliability over UDP.

Uniform resource identifier (URI) scheme for lightweight transmission may be defined according to the following syntax.

soap.rmcp: // <host> [: <port>] [/ <rel_path>] [? <query>]

Semantics for the URI scheme may include a plurality of base port numbers, such as 0x026F for RMCP or 0x0298 for RMCP / RSP for OOB management services. If a port is specified, the corresponding port number can be used. If no port number is specified, a default port number may be used. The host can be determined by an IP address. The IP address, and port number can be used to send the message.

4 is a flowchart illustrating exemplary steps for processing an outgoing message of an RMCP packet for web service based management in accordance with various embodiments of the present invention. Referring to FIG. 4, example steps may begin at step 402. In step 404, the RMCP request initiator can receive a SOAP message. In step 405, the RMCP header may be inserted into the SOAP message. In step 406, the RMCP protocol engine may access the device security policy to determine if the RMCP security extension has been activated. If the RMCP security extension has not been activated, control passes to step 407. In step 407, it may be determined whether security is required. If security is required, control passes to step 408. At step 408, the message may be discarded. If no security is required, control may move to step 409. In step 409, the RSP block 330 can cause the message length to be updated to account for the addition of the RSP header, and the RSP trailer, adding UDP source and destination port values, RMCP message length, and RMCP message. For processing, it may pass to the next lower layer protocol, such as, for example, UDP block 334. In step 411, the UDP block 334 can receive the message from the RSP block 330, and the UDP protocol engine of the transmitting device can insert the header at the beginning of the RMCP message. Control then passes to step 430.

If the RMCP security extension is activated, control may move to step 410. In step 410, it may be determined whether an appropriate RSP session exists for the SOAP message. If no appropriate RSP session exists for the SOAP message, control passes to step 418. In step 418, the RSSP block 326 can cause the session to be created. Thereafter, control may move to step 416. If an appropriate RSP session exists for the SOAP message, control passes to step 412. In step 412, it may be determined whether the RSP session of the message is a switch time. If the RSP session is not at the message transition time, control passes to step 414. In step 414, the system may wait for a certain period of time until the session reaches a time before an RMCP message is sent and returns control to step 412. If the RSP session is at the message transition time, control passes to step 416. In step 416, the RMCP block 332 may forward the session ID, RMCP message, and RMCP message length to the next lower layer protocol for further processing.

In step 420, the RSP protocol engine of the transmitting device may receive a SOAP message from the RMCP block 332, the RSP block 330 may insert an RSP header at the beginning of the message, and set the session ID value. Can be copied to the session ID field of the RSP header. In step 422, the RSP block 330 may use the session ID to access the session state, increase the sequence number of the session, and then, replace the session sequence number value with the sequence number field of the RSP header. Can be inserted. In step 424, the RSP block 330 may cause the RSP trailer to be created at the end of the data block of the message. The RSP block 330 may calculate the amount of padding required to align the integrity data fields of the protected message on the data word boundary. The RSP block 330 can use the RMCP message length passed from the RMCP block 332 to find the end of the data block of the message, the pad bytes, and the value for the pad length and the next header fields of the RSP trailer. Can be used to insert a correction number. The RSP block 330 can use the session ID to access the session state, determine the particular conservation algorithm used with the message, and calculate the conservation data on the sealed message. The calculated value can be inserted into the maintenance data field of the RSP trailer to generate a protected RMCP message.

In step 426, the RSP block 330 can cause the message length to be updated to confirm the addition of the RSP header and the RSP trailer, the UDP source and destination port values, the protected RMCP message length, and the protected RMCP message. May be forwarded to the next lower layer protocol such as, for example, UDP block 334 for further processing. At step 428, the UDP block 334 can receive the message from the RSP block 330, and the UDP protocol engine of the transmitting device can insert a header at the beginning of the protected RMCP message. At step 430, the UDP block 334 can copy the port values delivered from the RSP block 330 to the source port and destination port fields of the UDP header. In step 432, the UDP block 334 can cause the UDP packet length and checksum to be calculated and insert these values into the UDP length and checksum fields. In step 434, the resulting UDP packet is forwarded to other lower layer protocols such as, for example, IP block 338, and MAC / PHY layer block 340 for further processing and consequently transmission to the destination. Can be.

5 is a flowchart illustrating exemplary steps for processing an incoming message of an RMCP packet for web service based management according to various embodiments of the present disclosure. Referring to FIG. 5, example steps may begin at step 502. In step 504, lower layer protocols such as the MAC / PHY layer block 340, and the IP block 338, of the receiving device may be added to the next higher layer such as the UDP block 334 for further processing. It can forward protected RMCP messages received by the protocol. In step 506, the UDP block 334 of the receiving device can cause the checksum field of the UDP header to be verified. At step 508, it may be determined whether the checksum field is valid. If the checksum field is invalid, control moves to step 510. At step 510, UDP block 334 may discard the packet. If the checksum field is valid, control passes to step 512. In step 512, it may be determined whether the received message supports the higher layer protocol specified by the value of the destination port field. If the received message does not support the higher layer protocol, control passes to step 510. At step 510, UDP block 334 may discard the packet. If higher layer protocols are supported, control passes to step 516. In step 516, the UDP block 334 can remove the header, update the protected RMCP message length, and protect it with the next higher layer protocol such as, for example, the RSP block 330 for further processing. RMCP message and its length can be passed.

In step 518, the RSP block 330 may receive the RMCP message protected from the UDP block 334, and the RSP block 330 may access the device security policy to determine if the RMCP security extension is enabled. have. If the RMCP security extension has been disabled, control passes to step 519. In step 519, it may be determined whether security is required. If security is required, control passes to step 510. In step 510, the RSP block 330 may discard the message. If no security is required, control passes to step 534.

If the RMCP security extension has been activated, control passes to step 520. In step 520, it may be determined whether the RSP block 330 can use the session ID value of the RSP header to discover the session state for this message. If no session state is found for this message, control passes to step 510. In step 510, the RSP block 330 may discard this message. If session state is found for this message, control passes to step 522.

In step 522, it may be determined whether the session is at a message acceptance time. If the session is not in message acceptance time, control passes to step 510. In step 510, the RSP block 330 may discard the message. If the session is at message accept time, control passes to step 524. In step 524, the RSR block 330 may use a protected RMCP message length passed from the UDP block 334 and a conservation algorithm specific to the session state to discover and verify the conservation data fields of the RSP trailer. . In step 526, it may be determined whether the integrity data field is valid. If the maintenance data field is invalid, control moves to step 510. In step 510, the RSP block 330 may discard the message. If the maintenance data field is valid, control passes to step 528. In step 528, the RSP block 330 is configured to determine whether the received message is a new and previously received message, and the location of the message relative to the sliding receive window is not a duplicate of the sliding receive window information, and the RSP header. You can use the sequence number field. If the received message is not new, control passes to step 510. In step 510, the RSP block 330 may discard the message.

If the received message is a new message, control moves to step 530. In step 530, the received message may be new, inside the sliding receive window, or on the right side of the sliding receive window. If the received message is on the right side of the sliding receive window, the sliding receive window can be advanced to the right to process the message. In accordance with an embodiment of the present invention, messages may be received irregularly and processed appropriately. In step 530, if sequential number processing is successfully completed, RSP block 330 may store the sequential number value in the next header field and calculate the number of pad bytes that may be removed at the end of the message. You can use the value in the Pad Length field for this purpose. In step 532, the RSP block 330 may remove the RSP block and the RSP trailer and update the length value of the RMCP message. In step 534, the RSP block 330 may forward the RMCP message and the corresponding length to the next higher layer protocol such as, for example, the RMCP block 332 for further processing. After this, control passes to step 536.

In accordance with an embodiment of the present invention, lightweight simple object access protocol (SOAP) transport for web services based management may include managing system 150 using SOAP 312 messages mapped over the lightweight transport protocol. . The lightweight transport protocol is one of the RMCP 332 and the RSP 330 to enable remote management of the system using web services, for example, in OOB management devices such as clients 173, 175, 177, 179. It can be one or all. System 150 may be managed using a mapped SOAP message and one or more web services. The lightweight transport protocol may provide security and reliability for OOB operation. The lightweight transport protocol may enable to support unidirectional MEP, request-response MEP, and multicasting of SOAP messages. The lightweight transport protocol may allow to provide a response of retransmission and receipt of a SOAP message. System 150 may be protected by message authentication and / or may be protected by checking the integrity of the mapped SOAP message. The lightweight transport protocol may provide for redo protection of SOAP messages.

Another embodiment of the present invention may provide machine-readable storage in which a computer program having at least one code portion executable by a machine is stored, whereby the machine provides a lightweight SOAP transport for web service based management. To perform the same steps as described above.

Applicant suggests that no claims or statements herein should be construed as an admission or representation that would result in an implementation of the Applicant's claims that would necessarily result in an operation that is not compliant with ASF details. On the contrary, the Applicant suggests that the implementation of the Applicant's claims may still result in an operation that is actually compliant with the ASF details.

Thus, the present invention can be implemented in hardware, software, or a combination of hardware and software. The invention may be implemented in a centralized manner in at least one computer system, or in a distributed manner in which other components are distributed across several connected computer systems. Any kind of computer system, or other apparatus, adapted for carrying out the methods described herein is matched. A typical combination of hardware and software may be a general purpose computer system with a computer program that, when read and executed, controls the computer system performing the methods described herein.

The invention may also be embedded in a computer program product. At this point, the computer program product includes all the features that enable the implementation of the methods described herein, and may be implemented when mounted on a computer system. By computer program in the context of the present invention is meant any kind of expression with respect to a set of instructions, expressed in any kind of language, code or notation. In this case, the set of instructions means that a system having an information processing capability converts a particular function directly or to (a) another programming language, code or notation, or (b) a different material form. Refers to those intended to be performed after each reproduction or both.

While the invention has been described with respect to specific embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the spirit of the invention. In addition, various modifications may be made to adapt a particular situation or material requirement to the teachings of the present invention without departing from its spirit. Accordingly, the invention is not to be limited to the specific embodiments disclosed and it is intended that the invention include all embodiments falling within the spirit of the appended claims.

Claims (36)

In the method for processing network information, Simple object access protocol (MAP) mapped onto one or both of remote management and control protocol (RMCP) and RMCP security extensions protocol (RSP) Managing the system using &lt; RTI ID = 0.0 &gt;). &Lt; / RTI &gt; The method of claim 1, comprising managing the system using the mapped SOAP message and one or more web services. 3. The method of claim 2, comprising remotely managing the system by the one or more web services, via out-of-band (OBB) management. 4. The method of claim 3, comprising securing the system via the OOB management. The method of claim 1, wherein the mapping provides one-way message exchange of the SOAP messages. The method of claim 1, wherein the mapping provides for a request-response message exchange of the SOAP messages. The method of claim 1, wherein the mapping provides for multicasting of the SOAP messages. The method of claim 1, comprising retransmitting the mapped SOAP message. The method of claim 1, comprising responding to a receipt of the mapped SOAP message. The method of claim 1, comprising securing the system by authenticating the mapped SOAP message. The method of claim 1, comprising securing the system by checking the integrity of the mapped SOAP message. The method of claim 1, wherein the mapping provides anti-replay protection of the SOAP messages. In the system for processing network information, Simple object access protocol (mapped) mapped onto one or both of remote management and control protocol (RMCP) and RMCP security extensions protocol (RSP) System for processing network information comprising one or more circuits that enable management of the system using &lt; RTI ID = 0.0 &gt; The method according to claim 13, The one or more circuits are for processing network information that enables management of the system using the mapped SOAP message and one or more web services. The method according to claim 14, The one or more circuits are for processing network information that enables remote management of the system by the one or more web services, through out-of-band (OOB) management. The method according to claim 15, Wherein the one or more circuits are capable of securing the system via the OOB management. The method according to claim 13, Wherein said mapping provides network information for providing one-way message exchange of said SOAP messages. The method according to claim 13, And the mapping provides network information for providing a request-response message exchange of the SOAP messages. The method according to claim 13, And the mapping is for processing network information that provides multicasting of the SOAP messages. The method according to claim 13, The one or more circuits are for processing network information that enables retransmission of the mapped SOAP message. The method according to claim 13, The one or more circuits are systems for processing network information that enable a response of a receipt of the mapped SOAP message. The method according to claim 13, The one or more circuits are configured to process network information enabling to secure the system by authenticating the mapped SOAP message. The method according to claim 13, The one or more circuits are configured to process network information making it possible to secure the system by checking the integrity of the mapped SOAP message. The method according to claim 13, Wherein said mapping provides network information for providing anti-replay protection of said SOAP messages. A machine-readable storage in which a computer program having at least one code section for processing network information is stored, The at least one code portion is a simple object access protocol (mapped) on one or both of a remote management and control protocol (RMCP), and an RMCP security extensions protocol (RSP). Machine-readable storage executable by the machine to operate the machine to perform the steps comprising managing the system using a simple object access protocol (SOAP). The method according to claim 25, And the at least one code portion comprises code for managing the system using the mapped SOAP message and one or more web services. The method of claim 26, And the at least one code portion comprises code for remotely managing the system by the one or more web services, through out-of-band (OBB) management. The method of claim 27, And the at least one code portion comprises code for securing the system through the OOB management. The method according to claim 25, And the mapping provides a one-way message exchange of the SOAP messages. The method according to claim 25, And the mapping provides a request-response message exchange of the SOAP messages. The method according to claim 25, And the mapping provides multicasting of the SOAP messages. The method according to claim 25, And the at least one code portion comprises code for retransmitting the mapped SOAP message. The method according to claim 25, And the at least one code portion comprises code for acknowledging the receipt of the mapped SOAP message. The method according to claim 25, And the at least one code portion comprises code for securing the system by authenticating the mapped SOAP message. The method according to claim 25, And the at least one code portion comprises code for securing the system by checking the integrity of the mapped SOAP message. The method according to claim 25, And the mapping provides anti-replay protection of the SOAP messages.

Images