Messaging and presence protocol as a configuration and management bus for embedded devices

Techniques are provided herein for establishing at a network management server a presence on a network. A presence associated with one or more managed devices on the network is detected. An instant messaging (IM) session is established with the one or more managed devices. The IM session forms a virtual chat room for performing a management function on the one or more managed devices, and IM messages are sent that are configured to perform the management function on the one or more managed devices. Techniques are also provided herein for establishing on a network an enriched presence by a network management server that is configured to perform a management function via a presence function of a messaging and presence protocol.

TECHNICAL FIELD

The present disclosure relates to network management, and more specifically to managing network devices by leveraging the instant messaging and presence features of a messaging and presence protocol.

BACKGROUND

Instant messaging (IM) has grown from simple messaging in the 1960's, bulletin board systems of the 1980's, and messaging applications of the 1990's, into the field of unified communications, which provides real-time communications services such as unified messaging (integrated email, voicemail, fax, instant messaging, and presence information), telephony, and video conferencing. Enabling many of these IM features are a number of messaging and presence protocols, such as Instant Messaging and Presence Service (IMPS), Extensible Messaging and Presence Protocol (XMPP), and Session Initiation Protocol (SIP) with its extension SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), to name a few.

These protocols allow the establishment of an IM session that may include IM, file transfer, voice, and video. Underlying these protocols is the concept of “presence” which indicates a user's willingness, capacity, or ability to communicate. Before one can initiate an IM session with another, one must ascertain the status of the other, e.g., “off-line”, “busy”, or “do no disturb”. Presence information is periodically shared across the network, while IM is event driven, i.e., nothing happens until a user takes action. Both IM and presence can be leveraged to perform a variety of tasks.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Techniques are provided herein for establishing at a network management server a presence on a network. A presence associated with one or more managed devices on the network is detected. An IM session is established with the one or more managed devices. The IM session forms a virtual chat room for performing a management function on the one or more managed devices, and IM messages are sent that are configured to perform the management function on the one or more managed devices.

Techniques are also provided herein for establishing on a network an enriched presence by a network management server that is configured to perform a management function via a presence function of a messaging and presence protocol. The enriched presence allows the exchange of operational parameters of enriched presence capable endpoints and the operational parameters of any sub-entities associated with the enriched presence capable endpoints. An enriched presence associated with a managed device is detected on the network. In response to detecting the enriched presence associated with the managed device, an enriched presence message is sent to the managed device that is configured to allow the managed device to establish presence with the network management server. A registration message is received from the managed device that is configured to register the device and any sub-entities associated with the managed device. The managed device is managed based on a mutually correlated presence between the network management server and the managed device.

Example Embodiments

Referring first toFIG. 1, a diagram for a network100of virtual chat rooms110(1)-110(3) is shown. Each of the virtual chat rooms has one or more IM enabled endpoints or devices120(1)-120that are managed by one or more IM enabled network management systems, stations, or servers (NMSs)130(1)-130(3). The network100has an IM mediation server140and an optional software server150as shown by a dashed box. The IM enabled endpoints120(1)-120may be devices that have embedded system functions, e.g., network router, switches, or cellular base station that are usually managed from a remote location, i.e., their operating parameters may be changed or configured in response to network conditions, or new software or firmware images may be upgraded or downgraded remotely. Alternatively, IM enabled endpoints120(1)-120may be any device capable of establishing presence on a network and that has an IM capability, e.g., IM enabled endpoints120(1)-120could be mobile phones or personal computers.

Each virtual chat room110has at least one IM enabled network management server130for performing management functions for the IM enabled endpoints120(1)-120(m). In virtual chat room110(1) Joe in San Jose is managing a single IM enabled endpoint120(1) in San Jose using IM enabled NMS130(1) via IM, with IM mediation server140mediating the messaging and presence for virtual chat room110(1). Thus, virtual chat room110(1) forms a “management bus” in which one operator Joe is managing one device, i.e., IM enabled endpoint120(1), in a one-to-one correspondence.

The operations of the management bus from the perspective of the network management station will be described generally in connection withFIGS. 1,2, and3, and described more specifically in connection withFIG. 5. The operations of the management bus from the perspective of the IM enabled endpoint will be described generally in connection withFIGS. 1,2, and4, and also described more specifically in connection withFIG. 5. Network device management using the enriched presence features of a messaging and presence protocol will be described in connection withFIGS. 6-10.

In virtual chat room110(2), Joe in San Jose and Nelly in New York are collaboratively managing IM enabled endpoint120(2) in Texas, and IM enabled endpoint120(3) in Italy. In one example, Joe is an expert in the operation of IM enabled endpoints120(2) and120(3) and Nelly is a novice. By virtue of the virtual chat room120(2) Joe can train Nelly in the operation and configuration of IM enabled endpoints120(2) and120(3) because Nelly can both see what Joe is doing and hear what Joe is saying. In another example, Nelly sends a single IM with an embedded command to both IM enabled endpoints120(2) and120(3) simultaneously commanding both devices to perform a function substantially at the same time, e.g., Nelly may have commanded both IM enabled endpoints120(2) and120(3) to reboot using the single command.

Absent the techniques described herein, devices with embedded systems would normally be managed individually using Simple Network Management Protocol (SNMP) or through a command line interface (CLI), e.g., through a Telnet or Secure Shell (SSH). However, by virtue of the virtual chat room110(2) a management bus is formed in which either operator, Joe or Nelly, may managing two IM enabled endpoints120(1) and120(2) in a two-to-two correspondence. This example is extensible to any number of users N and any number of devices or endpoints M to form an N:M correspondence. Any number of the M devices may be grouped to receive a single command or a series of commands.

In virtual chat room110(3) Sam in San Jose is managing a cluster of IM enabled endpoints120(4)-102in New York. In one example, Sam needs to upgrade software on IM enabled endpoints120(4)-102. Sam sends a single IM with an embedded command to IM enabled endpoints120(4)-120. In this example, the software may be sent to the devices from, e.g., software server150, using a file transfer capability of the messaging and presence protocol in use. In another example, IM enabled endpoints120(4)-120have a File Transfer Protocol (FTP) client and software server150has an FTP server, and the IM command sent by Sam tells the IM enabled endpoints120(4)-120to retrieve their new software image from the FTP server. The IM command may optionally contain login parameters for logging in to the FTP server. Communications security may be provided through an inherent mechanism of the messaging and presence protocol in use. Virtual chat room110(3) forms a management bus in which Sam manages many IM enabled endpoints120(4)-120in a one-to-many scheme.

It should be noted that the IM enabled endpoints or devices or the enriched presence capable endpoints referred to herein may establish an IM session or enriched presence without human intervention and may communicate amongst themselves using IM or enriched presence. For example, traditional presence conveys endpoint state, e.g., the endpoint is “up” and running, while enriched presence may convey endpoint attributes such as endpoint configuration, software load, inventory, neighboring devices/sub-entities, alarm conditions, etc. In one example, devices may communicate status to each other. The status may indicate a system failure or traffic congestion at a network node. On the basis of the status information the network may perform a self-healing function or reroute network traffic automatically and without human intervention. Network management is also informed, whereby repairs can be made or new equipment installed to reduce network congestion.

Many of the examples are described herein using generic terms, e.g., using an “IM protocol” or via a protocol that enables “presence” or “enriched presence”, while some examples may be described according to a specific protocol, e.g., XMPP. These examples are not meant to be limited to any particular protocol. Any protocol that provides IM features may be used with the IM techniques described herein and any protocol that provides presence features may be used with the presence enabled techniques described herein. Examples protocols include open protocols, such as IMPS, XMPP, or SIP/SIMPLE as mentioned above, or proprietary protocols such as Skype or IBM Lotus Sametime, to name a few.

Referring toFIG. 2, a user interface screen, e.g., a graphical user interface (GUI)200is shown for an IM enabled NMS. The GUI200may also be referred to as a Messaging User Interface (MUI) or a Messaging and Presence User Interface (MPUI). The GUI200has a menu210, a tabbed display area220with Instant Messaging tab230for exchanging instant messages, File Transfer tab240for performing a file transfer function as described above, and Enriched Presence tab250which will be described in connection withFIG. 7. The user interface screen is used by operators, e.g., Joe, Nelly, and Sam, for managing devices. Thus, the user interface screen may be part of an application that is “launched” by an operator. It could optionally be launched when a first operator sends a second operator and invitation to join a chat room. The user interface screen may also be launched on a managed device, e.g., for an end user to watch a maintenance or repair operation.

In display area270, chat room activity is displayed. In this example, at272, operator1has joined or entered the chat room at 12:08 in the afternoon. At274, operator1has started a chat with device1. In response, device1has sent a status message indicating central processing unit usage at 10% and free memory of 13,567,421 bytes. At276, operator1has entered a series of commands via the text entry area280to configure device1. The commands are entered in a similar fashion as CLI commands are entered. In this example, operator1has sent an “edit-config” command to place device1in the edit configuration mode. Operator1next configures device1's interface to be fast Ethernet, with an IP address to 10.1.1.1 and a mask of 255.255.255.0. Operator1takes device1out of the edit configuration mode by sending and “end” command. At278, device1responds with an edit configuration “ok” message indicating that device1accepted the configuration changes from operator1.

There are several advantages when using this form of GUI in the context of an IM protocol like XMPP. First, devices can “message” to each other either in a 1:1 fashion for private messaging or 1: M fashion in which case the users “see” and log this communication. Multiple users, e.g., a support expert engineer or a customer representative, can join the “troubleshooting chat room” and see each other, natively and naturally. The GUI allows for a logical merge point for all sessions in a “System” or “Solution”, in a way that when information is needed from multiple devices, it can be gathered and compared on the same “space”. The GUI allows devices, e.g., a root port, a processor in a linecard, a phone, a set-top-box, to have “presence” and show “how they feel” (e.g., a phone being busy, a processor being idle, a set-top-box being “I am upgrading” or “in a meeting”). It allows for a central place to perform tasks that need to poll a sequence of devices, embedded or not, from a single place. For example, the GUI allows one to perform a type of “traceroute” by asking sequentially different devices by means of messaging. Lastly, the GUI provides a way of privately operating on one device at a time as XMPP provides a way of sending unicast messages to one party while still being subscribed to a multi-party chat room.

In other examples, XMPP is extensible such that the managed device could set an attribute (or a tag) in the XMPP response packet to indicate that a command failed, and how. This offloads intelligence from the NMS, reduces false positives, and adds robustness to device management. Given the Extensible Markup Language (XML) nature of XMPP, it would also be possible to incorporate the Network Configuration Protocol (NETCONF) standard to leverage its existing network management schema and error control features. The NETCONF standard includes a definition for passing error information between the agent (device) and the management station. Because of the high-level nature of the NETCONF specification, it can be implemented over a variety of protocols. Currently, NETCONF has been implemented over, e.g., Secure Shell Version 2 and the Block Extensible Exchange Protocol. NETCONF may also be implemented over XMPP.

Turning now toFIG. 3, an example block diagram of a management device, e.g., IM enabled NMS130, is shown. The NMS130comprises a data processing device310, a network interface unit320, a user interface device330, and a memory340. Resident in the memory340is an IM client350and software configured to execute management server IM management bus process logic500. Briefly, process logic500configures NMS130to manage devices on network100via IM client350as generally described above. The details of the process logic500will be described in connection withFIG. 5.

The data processing device310may be a microprocessor, a microcontroller, systems on a chip (SOCs), or other fixed or programmable logic. The memory340may be any form of random access memory (RAM) or other data storage block that stores data used for the techniques described herein. The memory340may be separate or part of the processor310. Instructions for performing the process logic500may be stored in the memory340for execution by the processor310such that when executed by the processor, causes the processor to perform the functions describe herein in connection withFIG. 3. The network interface unit320enables communication over network100. The user interface device330comprises a display and keyboard for viewing and entering data, and may optionally comprise other input devices such a computer mouse and a camera for the chat room. It should be understood that any of the devices in system100may be configured with a similar hardware or software configuration as NMS130.

The functions of the processor310may be implemented by a processor readable tangible medium encoded with instructions or by logic encoded in one or more tangible media (e.g., embedded logic such as an application specific integrated circuit (ASIC), digital signal processor (DSP) instructions, software that is executed by a processor, etc.), wherein the memory340stores data used for the computations or functions described herein (and/or to store software or processor instructions that are executed to carry out the computations or functions described herein). Thus, functions of the process logic500may be implemented with fixed logic or programmable logic (e.g., software or computer instructions executed by a processor or field programmable gate array (FPGA)).

Referring toFIG. 4, an example block diagram of a managed device, e.g., IM enabled endpoint120, is shown. The IM enabled endpoint120comprises a data processing device410, a network interface unit420, an optional user interface device430, and a memory440. Resident in the memory440is an IM client450and software configured to execute managed device IM management bus process logic550. Briefly, process logic550configures IM enabled endpoint120to receive instant messages over network100comprising management commands, and respond accordingly, as generally described above. The details of the process logic550will be described in connection withFIG. 5.

The functions of the various components for IM enabled endpoint120operate essentially the same way as the components of NMS130, as described in connection withFIG. 3. The optional user interface device430is optional, as shown by the dashed box, because it may not be required for a remote or embedded system. The IM enabled endpoint120may instead have a serial port for connecting to a dumb terminal, or provide a terminal connection or web interface via the network interface unit420.

Turning now toFIG. 5, the management server IM management bus process logic500and the managed device IM management bus process logic550will now be described in conjunction with each other. InFIG. 5devices fromFIG. 1, e.g., one or more IM enabled NMS(s)130and one or more IM enabled endpoint(s)120form a virtual chat room management bus mediated by IM mediation server140. The steps associated with management process logic500are framed with a dashed line and comprise steps505-535, while steps associated with managed process logic550are also framed with a dashed line and comprise steps555-585.

Starting with management process logic500, at505, IM enabled NMS130registers with the IM mediation server140. At510, IM enabled NMS130performs a stream authentication. The stream authentication provides a means of ensuring communications security. The streams may be verified by contacting a certificate authority, e.g., for an X.509 certificate. At this point, IM enabled NMS130has established a presence on the network. After stream authentication, at515, IM enabled NMS130receives an advertisement from the IM mediation server140indicating that sessions may now be established between devices. On the IM enabled endpoint side, managed process logic550performs similar steps at555,560, and565for IM enabled endpoint120.

At520, IM enabled NMS130requests a session with IM enabled endpoint120. In one example, an XMPP Session Initiate message may be sent. At570, the session request is received by the IM enabled endpoint120. At575, the IM enabled endpoint120accepts the session and sends a session accept message, e.g., using an XMPP Session Accept message. Sessions may also be rejected for a variety of reason by any party to the chat room. At525, IM enabled NMS130receives the session accept message, thereby establishing the session/virtual chat room between IM enabled NMS130and IM enabled endpoint120.

Once the virtual chat room is established, at530, IM enabled NMS130can send instant messages comprising various commands to IM enabled endpoint120in order to perform various management functions. At585, the IM enabled endpoint120responds to commands sent by IM enabled NMS130using instant messages. Some IM enabled NMS130commands may not require a response. Commands sent from IM enabled NMS130may be multicast to a plurality of devices or unicast to a single device, and used for device identification and device configuration.

Referring now toFIG. 6, a block diagram shows an example network600in which one or more devices with enriched presence are managed by an enriched presence enabled NMS. The network600may be the same as network100and is described here inFIG. 6in the context of an enriched presence leveraged from an existing messaging and presence protocol. Network600has a service discovery server610, an enriched presence aware NMS620, a presence server630, and a plurality of devices with enriched presence640(1)-640.

The service discovery server610is a server that provides a multicast service used by a host to advertise or publish the details of offered services, e.g., service instance name, service type, domain name, and configuration parameters. One example discovery service is multicast Domain Name Server (mDNS) which used for DNS based service discovery. Thus, service discovery server610may be in the form of a server that may reside anywhere in network600. Other examples of service discovery mechanisms include Simple Service Discovery Protocol or Service Location Protocol. In this example, enriched presence aware NMS620registers with service discovery server610to advertise the service instance name and associated information for presence-driven network management services. The devices with enriched presence640(1)-640may then query the service discovery server610to “discover” their NMS, e.g., enriched presence aware NMS620. The devices with enriched presence640(1)-640then establish an enriched presence with enriched presence aware NMS620.

Once the enriched presence is established, the devices with enriched presence640(1)-640periodically send presence “heartbeats” or status messages to the enriched presence aware NMS620. The heartbeats contain a set of parameters or other information about the individual devices. Example parameters include device name, configuration, inventory, IP address, location, software version, and the like, as described above. Enriched presence aware NMS620uses the information in the heartbeat to generate a network map and to provide presence-driven network management services using the presence capabilities of a messaging and presence protocol. Additional details of presence-driven network management services will generally be described in connection withFIGS. 7-9, and in greater detail in connection withFIG. 10.

Turning toFIG. 7, the example GUI fromFIG. 2is shown with the “Enriched Presence” tab250selected. Within the display area700is a topographical map705of the network600fromFIG. 6. The map shows devices with enriched presence640(1)-640(5) and their associated connections, and a series of pop-up windows710(1),710(2),720(1), and720(2). In this example map, the service discovery server610, enriched presence aware NMS620, and presence server630are omitted for ease of illustration.

Devices with enriched presence640(1) and640(2) are switches as indicated by their associated icons, while devices with enriched presence640(3),640(4), and640(5) are routers as indicated by router icons. The various connection types are illustrated by solid or dashed lines. Pop-up windows710(1) and710(2) are associated with devices with enriched presence640(4) and640(5), respectively, and pop-up windows720(1) and720(2) are associated with connections730(1) and730(2), respectively. Included within device pop-ups710(1) and710(2) are buttons configured to activate a management function, e.g., to update a software image or initiate a configuration change as shown. These management functions are examples only and other functions may be added as needed. The pop-up windows also show sub-entities or sub-buddies, as described above. These sub-entities may also be managed by “clicking” on one of the buttons.

In one example, a cursor740is used to mouse over the various devices and connections. By pausing the cursor740over a device or connection, a pop-up window will appear. Removing the cursor from the device or connection will cause the pop-up window to disappear, unless the pushpin is selected. The cursor740is currently positioned over device with enriched presence640(4). The associated pop-up window710(1) is not pinned as indicated by the horizontal pushpin, while pop-up windows710(2),720(1), and720(2) are pinned to the display as indicated by the vertical pushpin.

Each pop-up window displays information received through presence heartbeats according to the associated object. For example, pop-ups710(1) and710(2) display router information including hostname, IP address, status, image or software version, and location or address. Pop-ups720(1) and720(2) display connection information such as media type, status, etc. Pop-up720(1) indicates that the media type is 10 Gigabit Ethernet. This is shown on the map as a solid line between devices with enriched presence640(1) and640(3). Pop-up720(2) indicates that the media type is frame-relay. This is shown on the map as a dashed line between the network cloud750and device with enriched presence640(5). The map may be further enhanced through the use of various colors, line types, icons, etc. Thus, the map may be generated based the locations and attributes of the various objects in the network based in the information received through the presence heartbeats.

Referring toFIG. 8, an example block diagram of an enriched presence aware NMS, e.g., enriched presence aware NMS620, is shown. The NMS620comprises a data processing device810, a network interface unit820, a user interface device830, and a memory840. Resident in the memory840is an IM client850and software configured to execute NMS enriched presence messaging process logic1000. Briefly, process logic1000configures NMS620to monitor and manage devices on network600via a presence capability of a messaging and presence protocol associated with IM client850, as generally described above. The details of the process logic1000will be described in connection withFIG. 10. The functions of the various components for enriched presence aware NMS620operate in substantially the same way as the components of NMS130as described in connection withFIG. 3.

Referring theFIG. 9, an example block diagram of a managed device, e.g., a device with enriched presence generally depicted at reference numeral640, is shown. The block diagram ofFIG. 9is representative of the make-up of any or all of the devices640(1)-640shown inFIG. 6. The device with enriched presence640comprises entities with enriched presence including a data processing device910, a network interface unit920, an optional user interface device930, and a memory940. Resident in the memory940is an IM client950and software configured to execute enriched presence messaging process logic1050. Briefly, process logic1050configures device with enriched presence640to generate presence heartbeats, and respond to any presence messages received from enriched presence aware NMS620, as generally described above. The details of the process logic1050will be described in connection withFIG. 10.

Coupled to the device with enriched presence640are a plurality of additional sub-entities960(1)-960. The additional sub-entities may be line cards in a chassis, peripherals, additional interfaces, or any other entity with presence capability. In this example, each entity is equipped with an IM client950and enriched presence messaging process logic1050, thereby enabling each entity to report its own status to enriched presence aware NMS620. For example, the memory930may report memory utilization and sub-entity960(1) may be an optical interface for a router that reports wavelength utilization or bit error rates. In another example, each entity need not have its own IM client950and an IM client950residing on any entity, e.g., processor910, may act as a proxy for any other entity or sub-entity.

Turning now toFIG. 10, the NMS enriched presence messaging process logic1000and the enriched presence messaging process logic1050will now be described. InFIG. 10, devices fromFIG. 6, e.g., the service discovery server610, the enriched presence aware NMS620, the presence server630, and a device with enriched presence640are shown in a ladder diagram. The steps associated with NMS enriched presence messaging process logic1000are framed with a dashed line and comprise steps1005-1030, while steps associated with the enriched presence messaging process logic1050are also framed with a dashed line and comprise steps1055-1085.

Starting with NMS enriched presence messaging process logic1000, at1005, enriched presence aware NMS620registers with the service discovery server610. Referring to the enriched presence messaging process logic1050, at1055, the device with enriched presence640queries the service discovery server610for the locations NMSs with enriched presence-driven network management services. In this example, at1060, the device with enriched presence640receives a response from the service discovery server610indicating that enriched presence aware NMS620can provide the necessary enriched presence-driven network management services.

At1065, device with enriched presence640sends a presence probe message to enriched presence aware NMS620via the presence server630to determine the state of presence of enriched presence aware NMS620. The presence probe also informs enriched presence aware NMS620that a device to be managed, i.e., device with enriched presence640has presence on the network. At1015, enriched presence aware NMS620sends a presence message to device with enriched presence640. In this example, an XML message or an XML message with an embedded bit-mapped message is sent using, e.g., XMPP.

Listing 1 shows an example presence message in XML format that is sent from the enriched presence aware NMS620.

Listing 1. Sample XML Message Sent from an Enriched Presence Aware NMS.

Listing 2 shows an example presence message in bit-mapped format that is sent from the enriched presence aware NMS620.

16-bit operational status presence Protocol Data Unit:The 24-bit status field applies to the management station.The values of the status field bit-mask are as follows:Bits 0, 1 and 2: Operational state: In-service, active (000), In-service, standby (001), Out of service, boot/initialization in progress (010), Out of service, boot/initialization complete (011), Out of service, administrative shutdown (100), Out of service, graceful shutdown in progress (101), Out of service, failed (110).Bit 3: Booted since last heartbeatBits 4 and 5: Utilization: Free (00), light work (01), busy (10), overloaded (11).Bit 6: Minor faultBit 7: Major faultBit 8: Performance degradationBit 9: Software version changeBit 10: Request refresh of capabilities/featuresBit 11: Request refresh of virtual overlay associationsBits 12-15: Other uses, TBD

Listing 2. SAMPLE Bit-Mapped Message Sent from an Enriched Presence Aware NMS.

At1070, device with enriched presence640receives the XML message. At1075, the device with enriched presence640registers itself, its entities, and any sub-entities, e.g., network interface920and additional sub-entities906(1)-960. At this point presence is established between the device with enriched presence640and the enriched presence aware NMS620.

Listing 3 shows an example XML presence registration message that is sent from the device with enriched presence640.

Listing 3. Sample XML Registration Message Sent from a Device with Enriched Presence.

At1080, the device with enriched presence640and any presence configured entities or sub-entities send periodic presence updates or heartbeats to the enriched presence aware NMS620. In this example, an XML message or an XML message with an embedded bit-mapped message is sent using, e.g., XMPP. The heartbeats contain a set of parameters or other information about the individual devices. Example parameters include device name, IP address, location, software version, etc.

Listing 4 shows an example bit-mapped presence message that is sent from the device with enriched presence640.

32-bit operational status presence PDU:The 16-bit status field applies to the sub-entity. A sub-entity field of all-zeros identifies the ‘device proper’. Other sub-entities may be sub-components, resources, interfaces and neighbors.A value of 1 in the ‘M’ or ‘more’ field indicates that there are additional presence vectors that are stacked after this PDU.The values of the 16-bit status field bit-mask for the device proper and its sub-components, resources, interfaces and neighbors are as follows (definitions adapted to the semantics of the particular sub-entity):Bits 0, 1 and 2: Operational state: In-service, active (000), In-service, standby (001), Out of service, boot/initialization in progress (010), Out of service, boot/initialization complete (011), Out of service, administrative shutdown (100), Out of service, graceful shutdown in progress (101), Out of service, failed (110).Bit 3: Booted since last heartbeatBits 4 and 5: Utilization: Free (00), light work (01), busy (10), overloaded (11).Bit 6: Minor faultBit 7: Major faultBit 8: Performance degradationBit 9: Configuration changeBit 10: Inventory change (including software changes such as version upgrades)Bit 11: Change in capabilities/featuresBit 12: Change in virtual overlay associationBit 13: Any reload will use a different code imageBits 14-15: Other uses, TBDThe values of the status field bit-mask for neighbors are:Bit 0: Reachable/Not reachableBit 1: Reachable intermittentlyBit 2: Degraded/lossy communicationsBit 3 Round trip response time above thresholdBit 4: Jitter above thresholdBit 5: Remote fault indication from neighbor that is specific to the neighborBit 6: Remote fault indication from neighbor that is points to an upstream faultBit 7-15: Other uses, TBD

Listing 4. Sample Bit-Mapped Presence Message Sent from a Device with Enriched Presence.

Listing 5 shows an example XML presence message that is sent from a device with enriched presence that also has an associated Optical Carrier (OC)-3 interface.

Listing 5. Sample XML Enriched Presence Message Sent from a Device with Enriched Presence that has an OC-3 Interface.

Referring again toFIG. 10, at1030, from the set of parameters in the enriched presence message sent from the device with enriched presence640, the enriched presence aware NMS620can perform target management functions on any entities or sub-entities associated with the device with enriched presence640, and generates the network topology map as described above. In one example, the application hosting the GUI or managing the managed devices may set off an audible alarm or visual indication when operational parameter associated with the managed devices change.

In summary, the techniques described herein provide for establishing at a network management server a presence on a network. A presence associated with one or more managed devices on the network is detected. An instant messaging (IM) session is established with the one or more managed devices. The IM session forms a virtual chat room for performing a management function on the one or more managed devices, and IM messages are sent that are configured to perform the management function on the one or more managed devices.

In another example, establishing the presence comprises registering with an IM mediation server on the network. The IM mediation server mediates presence on the network, and advertises to the one or more managed devices the session establishment capabilities of the network management server.

In one example, a user interface screen is provided. A contact list associated with the virtual chat room comprising the one or more managed devices and a first user operating the network management server is displayed in a first display area of the user interface screen. The contact list indicates one or more of contact name, presence status, and device type. A messaging area is displayed in a second display area of the user interface screen that is configured for displaying incoming IM messages and for enabling the first user to configure an outgoing IM message for performing the management function, and for displaying other parameters or events associated with the virtual chat room. Operational parameters associated with the one or more managed devices contained in the incoming IM messages are also displayed. A second user may join the virtual chat room, and the first and second users may perform the management function collaboratively.

In another example, the first user is enable to configure an outgoing IM message to perform the management function such that the first user may modify the operational parameters associated with the one or more managed devices, and perform a file transfer function among the one or more managed devices and between the one or more managed devices and the network management server. The management function may be performed on individual ones of the one or more managed devices, or substantially simultaneously on groups of the one or more managed devices.

Techniques are also provided herein for establishing on a network an enriched presence by a network management server that is configured to perform a management function via a presence function of a messaging and presence protocol. An enriched presence associated with a managed device is detected on the network. In response to detecting the enriched presence associated with the managed device, an enriched presence message is sent to the managed device that is configured to allow the managed device to establish presence with the network management server. A registration message is received from the managed device that is configured to register the device and any sub-entities associated with the managed device. The managed device or endpoint is managed based on a correlated presence between the network management server and the managed device.

In one example, the network management server or device establishes enriched presence by registering an enriched presence driven network management service with a discovery service such that the managed device is able to discover the network management server. The managed device and the network management server maintain a mutually correlated presence by exchanging periodic enriched presence messages between the managed device and the network management server. The enriched presence messages sent by the managed device comprise one or more operational parameters associated with the managed device. Determining which management function to perform may be based on the one or more operational parameters contained in the enriched presence messages. A network topology map may be generated for the network comprising at least one of the one or more managed devices and the communications pathways between the one or more managed devices based on the enriched presence messages, or the one or more operational parameters contained therein.

In another example, the network topology map is displayed on a user interface screen configured to present the operational parameters to a user and present communications parameters associated with the communications pathways to the user. An alarm may be generated in response to a change in the one or more operational parameters sent by the managed device. The alarm may be a visual indication shown on the network topology map.

In another example, the user interface screen is configured to receive inputs from the user such that the user may modify the operational parameters, modify the communications parameters, and perform a file transfer function among the one or more managed devices and between the one or more managed devices and the network management server.

Techniques are also provided herein for managed devices. At a network device, a presence is established on a network. A presence associated with a management device is detected on the network. An invitation message to join an instant messaging (IM) session is received from the management device and an acceptance message is sent to the management device such that the IM session is established. The IM session forms a virtual chat room for performing a management function on the network device. An IM message comprising a management function command is received from the management device. An IM message comprising a response to the management function command is sent to the management device.

In another example, an enriched presence is established by a managed device, enriched presence being configured to perform a management function via a presence function of a messaging and presence protocol. An enriched presence is detected that is associated with a network management server on the network. In response to detecting the enriched presence associated with the network management server, an enriched presence message is sent to the network management server configured to allow the network management server to establish presence with the managed device, and an enriched presence message is received from the network management server configured to change the operation of the managed device. The managed device may query a service discovery server to discover the network management server associated with an enriched presence driven network management service and then send an enriched presence message to the network management server.

The above description is intended by way of example only.