Interactive control of network devices

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0001] None.

REFERENCE TO APPENDIX

[0002] An Appendix is included with this Specification which describes the structure of invention control interface, the various formats for identifying and addressing networking device partners and message payload structures.

[0003] 1. Field of the Invention

[0004] The present invention relates to the field of networking devices, and to the control of one networking device by another. The invention addresses methods in which decisions are made by a first device affecting operational control of a second device. Alternatively, the invention pertains to methods in which a second device exerts control over the first—such as directing the flow of data through the first device for load-balancing or blocking “nefarious” viruses or intentional “denial of service” overloads.

[0005] More particularly, the invention provides a generalized interface architecture which is used for real time interactions between network switches and general purpose processors (GPP) for purposes of inspection and control of the flow of data to and from groups of GPP. The invention provides consistent, extensible, high-performance interfaces between groups of partnered processors, enabling the application of appropriate resources and providing a foundation for building network applications.

[0006] 2. Background of the Invention

[0007] Combining applications with the other functions of a networking switching device (network switch) has been tried with varying degrees of success. Nortel Networks™ has manufactured and experimented extensively with such devices. These devices are referred to in this Specification as Nortel™ Appliances/Switch Architecture or “NA/SA.”

[0008] Certain applications have never been delivered within the constraints of a custom network processor. For example, in the case of encryption, it has not been viable to integrate hardware within a network switch. While commercial, off-the-shelf electronics are available, integration in a network switch combined with hardware in a GPP interferes with other network switch applications. In other cases, it is possible to make a suitable solution for a user's needs by large customization of network switch software coupled with a GPP running the user's application. But such a solution is essentially unique to that user.

[0009] It would be a major technological advance to provide a consistent framework for interfacing future interactive networking devices such as switches and GPPs; one which would:

[0010] 1) be as efficient as possible, especially in terms of processing requirements and minimize the copying of Ethernet frames, allowing them to be processes “in-place;”

[0011] 2) implement one interface and reuse it for each type of GPP product, leveraging switch and GPP development efforts and enabling a broad spectrum of GPP applications; and

[0012] 3) reuse the same interface as network switches evolve.

[0013] Solving these problems would satisfy a long felt need of network user, network providers, and equipment manufacturers.

SUMMARY OF THE INVENTION

[0014] The present invention provides apparatus and methods which establish a set of interfaces between a first networking device, for example, a general purpose processor (GPP) and a second networking device, for example, a network switch. By means of these interfaces, one device can control the other and vice versa. The first networking device is directly in the path of data packets as they flow across a network. It is most often optimized for high-speed data transfer. The second networking device is attached to the first, and can access packets only if they flow through the first device. Similarly, the second device can only send packets to the network if they flow through the first device. In a preferred embodiment, the second device is optimized for data inspection, and associated data flow decision making. In a preferred embodiment, network processing occurs in the network switch, and application processing occurs in the GPP.

[0015] The first device and second device are logically coupled by interconnections, referred to in this Specification as “tunnels.” Tunnels carry related types of packets in one direction between “partnered” network devices. To accomplish bi-directional data flow, the first device and second device are connected by two “data tunnels.”

[0016] Data tunnels are used to pass network data packets between network devices that are typically client-server in nature.

[0017] A Control tunnel is a special form of a tunnel that is used to control the operation of a first device by a second device. Messages are sent by the first device to exert control over the operation of the second device. These messages may exert operational control (start, stop, boot, etc) or data flow control. The data flow control messages are used to direct the flow of data through the device as described in the section below.

[0018] Another special form of tunnel is the Broadcast tunnel. All of the NA/SA enabled network devices can interact through this tunnel. These interactions can be similar to Control tunnel interactions. A Control tunnel exists between two network devices and a Broadcast tunnel exists between all network devices. A first device is configured to direct certain data flows to a second device through a first data tunnel. As data packets are received from the network by the first device, they are passed to the second device. The second device contains logic, typically in the form of an application program, that receives the data packets, processes them and then sends them back to the first device via a second data tunnel.

[0019] The second device can process the data packets in a number of ways. One type of processing is data inspection. The packets are viewed by the application program and can be recorded on an attached device, such as a hard drive. More complex processing by the application program makes decisions based on the contents of the packets. One preferred embodiment of application program is a virus checker. When the packets pass through the first device and arrive at the second device, the contents of the packets are classified and certain classes of packets are compared with known patterns. If the packets contain a matching pattern, then that packet, as well as all associated packets, are not sent back to the first device.

[0020] The second device establishes a Control tunnel with the first device. This tunnel is used to send control messages from the second device to the first device. The reverse process may also take place. The Control tunnel is also used to send responses to control message or unsolicited status messages from the first device to the second device. Various types of control messages can be:

[0021] (1) messages carrying command interface data to simulate user interaction with the first device such as start, stop and reboot; and/or

[0022] (2) data flow control messages that exert control regarding the flow of data packets through the first device; these messages change the configuration of the first device in such a way that new data packets arriving at the first device are directed or handled in the directed way.

[0023] This new configuration persists until the second device alters it with another control message or the first device's internal logic has determined that the change is appropriate.

[0024] When Data tunnels are used in conjunction with Control tunnels, another form of processing uses the contents of the data packets received at the second device to condition decisions regarding the subsequent flow of data packets through the first device. The control exerted by the second device on the first device can vary from blocking the flow of related data packets to accelerating the flow of data packets through the first device.

[0025] For example, when a known virus pattern is detected, the second device may block the flow of related packets from the first device. This limits the impact of a nefarious virus to the “data entrance” portion of the first device and the first device can efficiently handle data packets without requiring further use of the data tunnel or the second device.

[0026] In another embodiment, the application program scans the data flow for particular files of copyrighted material, such as might be transferred in file-sharing services such as Napster™. Fees could be assessed or the data blocked. One practiced in the art will note that this function can include blocking of intentional “Denial Of Service” schemes.

[0027] The first packets of a data flow can be examined and should the application program running on the second device be configured to route the flow of subsequent data packets, based on their contents, a route is chosen. The routing decision is conveyed to the first device via the Control tunnel, and the rest of the related data packets will flow through the first device without involving the second device. This method is called “Data Flow Acceleration.”

[0028] An appreciation of other aims and objectives of the present invention may be achieved by studying the following description of preferred and alternate embodiments and by referring to the accompanying drawings.

A BRIEF DESCRIPTION OF THE DRAWINGS

[0029]
FIG. 1 is a schematic diagram of a network showing a group of general purpose processors connected to a server farm and the Internet through a network switch.

[0030]
FIG. 2 is a schematic of the internal structure of a general purpose processor.

[0031]
FIG. 3 depicts, in schematic view, the general arrangement of networking devices which are partnered by an interface according to the present invention.

[0032]
FIG. 4 is a schematic view showing the interactive logical connections or tunnels through which data and control signals are exchanged by partnered networking devices.

[0033]
FIG. 5 reveals a schematic diagram of one embodiment of tunnel interconnections in which functions of a first networking device are coupled to functions of a second, partnered networking device, in this case a general purpose processor and a network switch, respectively.

A DETAILED DESCRIPTION OF PREFERRED & ALTERNATIVE EMBODIMENTS

[0034] Introduction

[0035] The present invention provides an interface between networking devices such as an Alteon WebSystems™ Ethernet™ switch, and a general purpose processor (GPP) such as an Alteon WebSystems™ iSD (Integrated Service Director). Nortel Networks™ has manufactured and experimented extensively with such devices, and they are referred to in this Specification as Nortel™ Appliances/Switch Architecture or “NA/SA.” The architecture disclosed is intended to provide a consistent framework for future network switches and future GPPs.

[0036]
FIG. 1 shows schematically a typical network 10 in which a group 14 of general purpose processors (GPP) 16 & 18 which are connected 26 & 24 to a server farm 22, and coupled 28 to the Internet 20 through a network switch 12. Packet data flows between the networking devices 12, 16, 18, 22 and the Internet 20 through the network connections 26, 24 & 28.

[0037] In the present invention, a generalized interface is used to enable real-time interactions between the network switch 12 and GPPs 14. In some situations, the network switch 12 simply re-redirects the flow of data to the GPP group 14. In this situation, there is little need for control interactions between the network switch 12 and the GPP 16, 18. In other situations, the switch 12 is paired with a GPP 16 which views the initial portions of the flow of data. The GPP 16 then causes the network switch handle the rest of that particular connection. In this situation, the GPP 16 needs a control interface with the network switch 12 to change the future flow of data. The present invention addresses this need.

[0038] Interface Architecture

[0039] The foundation of the interface between a network switch 12 and a GPP 16, 18 is a message that contains an action or data. For switch control, the GPP 16, 18 sends control messages to a network switch management processor or one of the switch processors. For data control, the switch 12 encapsulates Ethernet frames and passes them to a GPP 16, 18. The GPP 16, 18 can send the updated encapsulated Ethernet frame back to the switch 12 for processing. Before exploring the details of these interactions, the following description of a GPP will be helpful to an understanding of the invention.

[0040] General Purpose Processor Structure

[0041] The internal structure 32 of the GPP is illustrated diagrammatically 30 in FIG. 2. Each different type of GPP used as an Integrated Service Director (iSD), is unique in only the iSD functionality area 34 containing vendor program products, custom integration logic and the command line interface. The iSD Functionality area 34 may contain vendor program products or application programs that implement custom logic. In either case, there will usually be some integration logic that couple it with the GPP environment. This logic will either call the GPP operating system or invoke the GPP Application Programming Interface (GPP API) 36. The GPP will also contain a System Management Interface component 38 that enables a systems management process to control the GPP.

[0042] The GPP API 36 is an application view of the GPP's partner, either another GPP 16, 18 or a network switch 12. For example, a function named “add13 user13 to13 video13 stream ( )” might be available. A set of control messages that are generated by the GPP Application Programming Interface would contain actions that would accomplish the desired function. This set of messages would be passed along to the appropriate driver. The driver would modify each message, if required, to suit the needs of the attached switch 12 or GPP 16, 18.

[0043] Preferred & Alternative Embodiments

[0044]
FIGS. 3 and 4 depict, in schematic view, the general arrangement of networking devices 52 & 54 which are “partnered” by an interface according to the present invention. FIG. 3 describes the flow of data 60 through two partnered devices 52 & 54. FIG. 4 shows the interactive logical connections or “tunnels” 56, 58, 70 through which data and control signals are exchanged by the partnered networking devices 52 & 54. The first device 52 and second device 54 are logically coupled by these tunnels. Each data tunnel 56, 58 carries related types of packets in one direction between the partnered network devices 52 & 54 resulting in bi-directional data flow.

[0045] For convenience, the tunnels 56, 58, 70 have been divided into their special uses. Data tunnels 56, 58 are used to pass network data packets between network devices that are typically client-server in nature. Data tunnels are discussed in more detail in a section below.

[0046] A Control tunnel 70 is a special form of a tunnel that is used to control the operation of a first device 52 by a second device 54. Messages are sent by the first device 52 to exert control over the operation of the second device 54. These messages may exert operational control (start, stop, boot, etc) or data flow control. The data flow control messages are used to direct the flow of data 60 through the device as described below.

[0047] Another special form of tunnel is the Broadcast tunnel. All of the NA/SA enabled network devices can interact through this tunnel. These interactions are similar to Control tunnel 70 interactions. The primary difference between the Control and Broadcast tunnels is that a Control tunnel 70 exists between two network devices 52 & 54 and a Broadcast tunnel exists between all network devices 14.

[0048] Data Tunnel

[0049] A first device 52 is configured to direct certain data flows 60 to a second device 54 through a first data tunnel 56. As data packets are received from the network by the first device 52, they are passed to the second device 54. The second device 54 contains logic, typically in the form of an application program, that receives the data packets, processes them and then sends them back to the first device 52 via a second data tunnel 58.

[0050] The second device 54 can process the data packets in a number of ways. One type of processing is data inspection. In this form, the packets are viewed by the application program and can be recorded on an attached device, such as a hard drive. More complex processing by the application program makes decisions based on the contents of the packets. When the packets pass through the first device 52 and arrive at the second device 54, the contents of the packets are classified and certain classes of packets are compared with known patterns. If the packets contain an undesirable, matching pattern, then that packet, as well as all associated packets, are not sent back to the first device 52. These data packets are termed “dropped packets.” If the data packets are not blocked, they may be further processed in the first device 52 and sent back 62 to the network.

[0051] Control Tunnel

[0052] The second device 54 establishes a Control tunnel 70 with the first device 52. The Control tunnel 70 is used to send control messages from the second device 54 to the first device 52. The reverse process may also take place. The Control tunnel 70 is also used to send responses to control message or unsolicited status messages from the first device 52 to the second device 54. Various types of control messages are possible:

[0053] (1) messages carrying command interface data which simulate user interaction with the first device 52—these messages are typically used to exert operational control over the first device 52, such as start, stop and reboot; and/or

[0054] (2) data flow control messages that exert control regarding the flow of data packets through the first device—these messages change the configuration of the first device in such a way that new data packets arriving at the first device are directed or handled in the directed way. This new configuration persists until the second device alters it with another control message or the first device's internal logic has determined that the change is appropriate.

[0055] Data Flow Control

[0056] When Data tunnels 56 & 58 are used in conjunction with Control tunnels 70, then another form of processing can occur beyond that described above. This form of processing uses the contents of the data packets received at the second device to condition decisions regarding the subsequent flow of data packets through the first device. The control exerted by the second device on the first device can vary from blocking the flow of related data packets to accelerating the flow of data packets through the first device.

[0057] In a virus scanning application program, for example, when a known virus pattern is matched, the second device 54 may block the flow 60 of related packets from the first device 52. This has the advantage of limiting the impact of a nefarious virus to the “data entrance” portion of the first device and the first device can efficiently handle data packets without requiring further use of the data tunnel or the second device.

[0058] In another embodiment, the application program scans the data flow for particular files of copyrighted material, such as might be transferred in file-sharing services such as Napster™. Fees could be assessed or the data blocked. One practiced in the art will note that this function can include blocking of intentional “Denial Of Service” schemes.

[0059] The first packets of a data flow are examined. Should the application program running on the second device 54 be configured to route the flow of subsequent data packets, based on their contents, a route is chosen. The routing decision is conveyed to the first device 52 via the Control tunnel 70 and the rest of the related data packets will flow through the first device 52 without involving the second device 54. Logical View of a Network Switch/GPP System

[0060] Since the GPP 16, 18 and network switch 12 have a logical view, represented by their respective APIs, then the combination of network switch 54 (12) and GPP 52 (14) is properly considered a system. As seen in FIG. 5, the invention interface 80 allows the GPP-Switch API 100 to access functions 90 within the network switch 54 (12). Conversely, the network switch functions 90 can access GPP functions 100. For example, GPP function 1001 can be linked to Switch function 90A.

APPENDIX

[0061] NA/SA Tunnels

[0062] 1. Tunnel Concepts

[0063] Tunnels are logical conduits between two NA/SA partners (network switches or GPPs). A 16-bit tunnel ID is associated with each tunnel. Tunnels are unidirectional, since one partner writes to it and the other partner reads from it. In the case, where each partner reads from and writes to the same tunnel ID, there are logically two unidirectional tunnels. Thus, tunnels should always be considered unidirectional.

[0064] The eth13 type field of each Ethernet frame that traverses a given tunnel contains that tunnel's ID value. Tunnel IDs are assigned such that the eth13 type is symmetrically transformed. This means that the value of eth13 type at the entrance to the tunnel can be reconstructed at the exit end of the tunnel.1 As an example, an IP Ethernet frame could be sent through the IP13 DATAGRAM tunnel and transformed back into an IP frame at the other end. 1. As this architecture is incorporated in other network switches and Special Purpose Processors (SPPs), there may be changes. As an example, the implementation of a tunnel may not depend on Ethernet frames. In that situation, a suitable mechanism is substituted.

[0065] At the tunnel exit, the tunnel ID is the primary basis to determine the disposition of each Ethernet frame. The network switch and the GPP will provide a mechanism to associate an application with each of its supported tunnels. If Ethernet frames are received for a tunnel ID that is not supported, then the recipient will drop all of those frames.

[0066] Transmission of Ethernet frames through a tunnel is on a best effort basis, except for the control tunnel. If reliable transport is required by an application, then it is the application which will provide it. Since the very nature of the control tunnel makes each interaction critical, then special provisions are made for that tunnel as described below in paragraph 14.

[0067] 2. Frame Formats

[0068] In an Ethernet frame, the Ethernet header is followed by the payload, which is followed by the frame checksum (CRC). The Frame header is described in the next section. For Ethernet frames that traverse a NA/SA tunnel, the format of the payload is indicated in Table A. The details of these formats are:

[0069] a. NA/SA message header followed by the message body as described in paragraph 14.

[0070] b. The original payload is unchanged. Only the Ethernet header is changed.

[0071] 3. Frame Header

[0072] All Ethernet frames that traverse NA/SA tunnels have a frame header and payload. The frame header always has the same structure. The only difference, between the various tunnel s frame headers, is the value of the Eth13 type field. Every frame will specify the partner's destination address, the sender's address as the source address and one of the types specified in Table B. The structure of the frame header is as follows:

1TABLE AFrame Header StructureNA/SA HeaderField NameData TypeValueDestination MACU8 (6)NA/SA partners destination HardwareSource MACU8 (6)NA/SA source Hardware AddressEth_typeU16The NA/SA tunnel identifier-ties thisframe to a specific NA/SA tunnel.

[0073] 4. Addressing

[0074] All identification of NA/SA partners is accomplished by hardware addresses, which are commonly referred to as MAC addresses. The Source MAC address identifies the sender of an Ethernet frame and the Destination MAC address identifies the intended recipient. This applies to all NA/SA tunnels.

2TABLE BRecognized Tunnel ID'sTunnel IDFormatDescriptionNA/SA_TUNNEL_ARP_PACKET2Used to pass Address resolutionProtocol PacketsNA/SA_TUNNEL_BROADCAST1Used to pass NA/SA broadcastmessages. See para. 15.NA/SA_TUNNEL_CLIENT_REDIRECT2Used to pass an IP datagramthat contains an application-level redirect directive tothe indicated IP address.NA/SA_TUNNEL_CONTROL1Used for control interactionsbetween NA/SA partners.See para. 14.NA/SA_TUNNEL_FIREWALL2Used to pass IP datagramsamong firewall partners.NA/SA TUNNEL_IP_DATAGRAM2Used to pass IP datagrams2NA/SA_TUNNEL_IP_FRAGMENT2Used to pass IP datagramfragments between NA/SApartnersNA/SA_TUNNEL_IP_REDIRECT2Used to pass an IP datagramand to cause all subsequentassociated datagrams to flowto the indicated IP address,different than the originalIP address (or port).NA/SA_TUNNEL_MAC_FORWARD2Used to pass Ethernet frameswith the intent that the en-closed Ethernet frame be for-warded based on its MACinformation.2These diagrams are typically flowing between clients and servers, such as a web browser and web server. This tunnel is used to divert the data flow to facilitate one of the following; Data Transformation, Decision Export and Auxiliary Services. Examples include, content manipulation or insertion, server load balancing based on business logic and messaging services.

[0075] 5 ARP PACKET Tunnel

[0076] The ARP Packet Tunnel is used to pass Address Resolution Protocol packets between NA/SA partners. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 ARP13 PACKET

[0077] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table:

3TABLE CARP Packet Frame StructurePayload FieldNameData TypeValueARP PacketU8 (n)The ARP packet that is being passed

[0078] 6. BROADCAST Tunnel

[0079] The Broadcast Tunnel is used to pass broadcast messages amongst NA/SA partners. The details of the Broadcast Message field are provided in Chapter 5. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 BROADCAST.

[0080] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table:

4TABLE DBroadcast Message Frame StructurePayload FieldNameData TypeValueBroadcast MessageU8 (n)The message that is being broadcast asdescribed in section 15.

[0081] 7. CLIENT REDIRECT Tunnel

[0082] The Client Redirect Tunnel causes the network switch to send an IP datagram back to the client. The datagram contains a redirect directive that is appropriate for the specified IP protocol. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 CLIENT13 REDIRECT.

[0083] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

5TABLE EClient Redirect Directive Frame StructurePayload Field NameData TypeValueDatagramU8 (n)The IP datagram that is being passed

[0084] 8. CONTROL Tunnel

[0085] The Control Tunnel is used to influence the actions of a network switch or GPP. The details of the NA/SA Message field are provided in paragraph 14. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 CONTROL.

[0086] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

6TABLE FNA/SA Message Frame StructurePayload Field NameData TypeValueNA/SA MessageU8 (n)This field contains NA/SA messagesas described in section 14.

[0087] 9. FIREWALL Tunnel

[0088] The Firewall Tunnel is used to pass IP datagrams and related switch internal information between NA/SA partners. The information regarding the internal switch element, such as Switch Port or IP Interface, is passed in an encoded form of the Source MAC address (SMAC). The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 FIREWALL

[0089] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

7TABLE GSource MAC Address Frame StructurePayload Field NameData TypeValueDatagramU8 (n)The IP datagram that is being passed

[0090] 10. IP DATAGRAM Tunnel

[0091] The IP Datagram Tunnel is used to pass IP datagrams between NA/SA partners. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 IP13 DATAGRAM.

[0092] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

8TABLE HIP Datagram Frame StructurePayload Field NameData TypeValueDatagramU8 (n)The IP datagram that is being passed

[0093] Example of usage: re-direct filter on network switch sends an Ethernet frame to a GPP via the IP Datagram Tunnel

[0094] a. The network switch receives an Ethernet frame that matches the filter criteria and updates the Ethernet header as described above.

[0095] b. The SP sends the message via the IP Datagram Tunnel.

[0096] c. The GPP receives the Ethernet frame via the IP Datagram Tunnel and passes it to the Request consumer.

[0097] d. The Request consumer transforms the contents of the IP datagram.

[0098] e. The GPP sends the IP datagram to the IP Datagram Tunnel handler. The IP datagram is sent to the network switch via the IP Datagram Tunnel.

[0099] f. The SP receives the IP Datagram frame, which passes it to the Request consumer.

[0100] g. The Request consumer queries the IP datagram and forwards it to the updated IP Address.

[0101] 11. IP FRAGMENT Tunnel

[0102] The IP Fragment Tunnel is used to pass IP datagrams, which contain IP fragments, between NA/SA partners.

[0103] The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 IP13 FRAGMENT.

[0104] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

9TABLE IIP Fragment Datagram Frame StructurePayload Field NameData TypeValueDatagramU8 (n)The IP datagram that is being passed

[0105] 12. IP REDIRECT Tunnel

[0106] The IP Redirect Tunnel causes the network switch to update associated tables with new values from the IP datagram (update IP address, or the TCP/UDP port, or both) and then sends the IP datagram to the specified destination. All subsequent frames for this session will also flow to this destination. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 IP13 REDIRECT.

[0107] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table:

10TABLE JIP Redirect Frame StructurePayload Field NameData Type-ValueDatagramU8 (n)The IP datagram that is being passed

[0108] 13. MAC FORWARD Tunnel

[0109] The Forward to MAC Tunnel causes the network switch to forward an Ethernet frame to the destination MAC address of the enclosed frame. Note that the Destination MAC address of this Ethernet frame can be used to address a specific element within a network switch. Additionally, the Source MAC address of the frame to be forwarded can be used to indicate the desired routing within the network switch. The NA/SA header must have:

Eth13 type=NA/SA13 TUNNEL13 MAC13 FORWARD.

[0110] The structure of the payload of Ethernet frames traversing this tunnel is described in the following table.

11TABLE KMAC Forward Frame StructurePayload Field NameData TypeValueEthernet FrameU8 (n)The Ethernet frame to be forwarded

[0111] 14. NA/SA CONTROL Tunnel

[0112] The NA/SA control tunnel is used to pass NA/SA messages between partners. NA/SA messages can be broken down into two classes of functions; System-level Control and Table Manipulation. In most cases, invoking one of these functions will cause an Ethernet frame to flow between the GPP and its partner, either a network switch or a GPP. A message will flow and data may be returned. In rare cases, invoking one of these functions will simply reference information that was previously cached in the GPP.

[0113] A NA/SA message is comprised of sections. The Link Layer section is required to be the first section of every NA/SA message. The message Header section follows the Link Layer section and is required in every NA/SA message. The message body follows the Header section. The contents of the message body are dependent on the value of the Type and Modifier fields of the message Header. Some message types do not have a message body.

[0114] 14.1 Link Layer Section

[0115] The first section of each NA/SA message is the Link Layer Section. This section is required in every message. It must be the first section of the message and is built by the NA/SA message transport functions (described in paragraph 19).

12TABLE LLink Layer Frame StructureDataField NameTypeValueVersionU8NA/SA_VERSION 1PadU8Reserved for future use. This field must be 0ACK RequiredU1Indicates that the message sender requires alink-level ACK message from the messagerecipient.LL FlagsU15Reserved for future use. These bits must bezero.Sequence NumberU16If ACK Required is TRUE, then this fieldcontains an ever-increasing number thatindicates the ordering and sequencing ofNA/SA messages. This number is echoed backin the link-level ACK message. If ACKRequired is FALSE, then this field mustcontain zeros.Message LengthU16The length of the payload. This value doesNOT include the length of the Link LayersectionChecksumU16The 16 bit one's complement of the one'scomplement sum of all 16-bit words in thepayload. If the Message Length contains anodd value, then zeroes will be padded to theend of the payload for this calculation. The padis not transmitted as part of the payload. Thisalgorithm is specified in RFC1071.

[0116] 14.2 Message Header Section

[0117] The second section of each NA/SA message is the message Header Section. This section is required in every message. It must immediately follow the Link Layer Section and identifies the purpose of the message. The structure of this section is described in the following table.

13TABLE MMessage Header Frame StructureField NameData TypeValueHeaderU8NA/SA_HEADER_VERSION1Security TypeU8Indicates the security algorithm that wasused to encrypt the rest of the message fromthis point on. The message Header fields thatprecede this field are not subject toService UnitsU1Indicates that the Service Units Used fieldcontainsRequestU1Indicates that the application considers thisMessagemessage to be a request. If TRUE, theapplication requires a response message inwhich the Message Identifier field containsthe same value as this Request Message.ResponseU1Indicates that the application considers thismessage toHeader FlagsU12Reserved. This field must contain zeros.TypeU8This field contains a value, which may beconditioned by the Modifier field thatindicates the format of the message body andthe purpose of the message.ModifierU8This field can be used to indicate a modifica-tion of the Type field. If the Type field is notbeing modified, then this field shall containzero.ResponseU16This field shall contain zero in all requestCodemessages. If, during the processing of arequest, an error was encountered then thisfield of the response message will containthe error indicator (one of the NA/SA—ERROR_xxxxx values) as defined inAppendix B. If there was an exceptioncondition encountered during the deliveryof a NA/SA message, then a NA/SA—EXCEPTION message is formed with thisfield set with an exception indicator (one ofthe NA/SA_EXCEPTION_xxxx values)as defined in Exception Numbers paragraphbelowMessageU32A number assigned by the requestor andIdentifierechoed back in a response messageService UnitsU32If the Service Units Reported flag is true,Usedthen this field used to report the currentutilization of a GPP. A network switch canbase its load balancing decisions on thisfield. If the Service Units Reported flag isnot true, then this field shall contain zeros.

[0118] 14.3 Message Exception Handling

[0119] There are two defined classes of NA/SA message exceptions: Type and Data. A Type exception is indicated when the Message Header Type field contains a value that is not supported. A Data exception is indicated when a field contains illogical data, such as all fields of a Session Create message body contains zeros or all bits in an Applicable field are 0.

[0120] As the network switch (or GPP) is processing a request message, it is possible to have an error. In the general case, the error is logged via an appropriate mechanism for that device. If there is a response message defined for this request message, then the request message is converted into a Response Message by recording an error code in the Response Code field of the message header and sending the message back to the message originator. The message originator is responsible for undoing any damage that the exception may have caused, such as inconsistent data in switch tables.

[0121] For certain exception circumstances (usually related to message reception), it is useful to provide an indication to another NA/SA entity. In these cases, a NA/SA13 EXCEPTION message is formed. The Header Type field is set to NA/SA13 EXCEPTION, the Response Code field is assigned a relevant value, and the message body is comprised of the offending message (message Header and message body). Then the message is sent as an unacknowledged message. It is expected (but not required) that all NA/SA exception routines reference Houston, as in “Houston, we have a problem.”

[0122] 14.4 Applicable Field

[0123] Some of the fields contained within a Control message aren't always relevant. The technique that is used to determine when a field is relevant is to associate a validity bit with each field in a frame. The validity bits are accumulated into a U16 field named Applicable. This implies that, while processing a Control message that contains an Applicable field, the process should test the associated bit before using the data values provided in the message body.

[0124] Throughout this document, whenever a Control message contains an Applicable field, the definition of each field will have an associated applicable bit number. There are a set of defined symbols of the form NA/SA13 APPLICABLE13 BITn, where n ranges from 0 to 15. These defined symbols should be used to perform the field validity test described above.

[0125] 14.5 Control Message Transport

[0126] The NA/SA Link Layer section determines the manner in which message delivery is handled. The control tunnel uses a best-efforts approach to message delivery, unless the ACK Required flag in the Link Layer section is true. When ACK Required is true, then the application has requested reliable message delivery. Using the Sequence Number field of the Link Layer section and the use of link-level ACK messages assure reliable delivery. The details of reliable message delivery are provided in the next sections.

[0127] 14.6 Link-level ACK Message

[0128] The reliable message delivery process requires the transmission of a link-level ACK message. When the NA/SA transport layer of a NA/SA partner receives a message that has the ACK Required flag set to true, then a link-level ACK message must be generated. A single ACK message can acknowledge multiple messages. Thus, if an ACK message is dropped, then a subsequent ACK message will acknowledge more than one message.

[0129] A link-level ACK message is comprised of only a Link Layer section. The Link Layer section contains the following:

14a.The Version field is set to NA/SA_VERSION1.b.The Pad field is set to zero.c.The ACK Required flag is false.d.Set the Sequence Number field to the Sequence Number that is beingacknowledged.e.The Message Length field is set to 0.f.The Checksum field is set to x ‘FFFF’.

[0130] 14.7 Message Transmission

[0131] The following three processes are used to deliver NA/SA control messages. The first process describes best effort transmission. The second and third processes are used for providing reliable delivery of NA/SA control messages:

[0132] a. NA/SA13 MSG13 SEND

[0133] The ACK Required field is set false, Sequence Number is set to 0, and Checksum is calculated.

[0134] The message is sent and control returns to caller.

[0135] b. NA/SA13 MSG13 SEND13 WITH13 ACK

[0136] The next sequential Sequence Number value is generated and set in the Link Layer section. The ACK Required field is set true and Checksum is calculated.

[0137] If there are messages on the deferred queue or there is more than the predefined OUTSTANDING13 WINDOW number of messages on the outstanding queue, then add this message to the end of the deferred message queue and return to caller.

[0138] Else send the message. Then add it to the end of the outstanding queue and return to caller.

[0139] c. NA/SA13 MSG13 SEND13 REDRIVE (periodically invoked and explicitly invoked by NA/SA13 MSG13 RECEIVE process).

[0140] Send the messages that are on the deferred queue. This must be done in order by Sequence Number field of the message header.

[0141] If there is more than the predefined OUTSTANDING13 WINDOW number of messages on the outstanding queue, then exit.

[0142] 14.8 Message Reception

[0143] Ethernet frames with an Eth13 type of NA/SA13 TUNNEL13 CONTROL are received at the exit of the NA/SA control tunnel. If reliable message delivery is indicated (by ACK Required being set true), then the NA/SA13 MSG13 RECEIVE process generates a link-level ACK as described in section 14.6 The higher-level NA/SA functions only allow one Request message consumer to be identified. Thus, NA/SA13 MSG13 RECEIVE simply passes Requests along to that consumer. The algorithm for handling message reception is:

[0144] A. NA/SA13 MSG13 RECEIVE

[0145] 1. Receive a message.

[0146] 2. Calculate the checksum of the message and compare to Checksum field of Link Layer section. If they differ, increment a counter and free the message.

[0147] 3. If the Message Length is zero (this is a link-level ACK),

[0148] a. If the Sequence Number of the link-level ACK message is less than the Sequence Number of the first message on the outstanding queue, free the link-level ACK message and no further action will be taken.

[0149] b. For each message on the outstanding queue whose Sequence Number is less than or equal to the Sequence Number of the link-level ‘ACK message’,

[0150] i. De-queue the message from the outstanding queue.

[0151] ii. Free the message.

[0152] c. Free the link-level ACK message.

[0153] d. If there are any messages on the deferred queue, invoke the NA/SA13 SEND13 MSG13 REDRIVE process.

[0154] e. No further action will be taken.

[0155] 4. If the message has the ACK Required flag set,

[0156] a. If there are not sufficient resources to allow the message to be retained, then increment a counter and free the message. No further action will be taken.

[0157] b. If the Sequence Number of the message does not contain the Link Layer Expected Value,

[0158] i. If the Sequence Number of the message is less than the Expected Value, then generate and send a link-level ACK message as described in section 14.20 with a Sequence Number of the Expected Value minus one.

[0159] ii. Increment a counter and free the message.

[0160] iii. No further action will be taken.

[0161] c. Generate a link-level ACK message as described in paragraph 14.6 with a Sequence Number of the Expected Value.

[0162] d. Increment the Link Layer Expected Value.

[0163] e. Send the ACK message via NA/SA13 MSG13 SEND.

[0164] f. Continue with message processing.

[0165] 5. If a Request consumer has not been identified,

[0166] a. Form a NA/SA13 EXCEPTION message and send it via NA/SA13 MSG13 SEND.

[0167] b. Increment a counter and free the message.

[0168] 6. If the Request consumer is not prepared to receive the message, retain the message are indicate to the consumer that messages are available.

[0169] 7. When the Request consumer is prepared to receive a message, then pass along the oldest message.

[0170] 14.9 Structure of a Control Message

[0171] An NA/SA control message is comprised of a Link Layer section, Message Header section and (optionally, depending on the message Type and Modifier) the message body with one request or response. Each message body contains data fields as required. The data field contents vary based on the message type. All data contained in a message are in network byte order.

[0172] An example of a message that would add a session table entry could contain the following (details will be explained later in this Appendix):

[0173] 14.10 Response Messages

[0174] This class of messages is used to pass data among network switches and GPPs. This data is primarily of a control nature, such as the values that comprise a session table entry.

[0175] All response messages have the same structure: Link Layer section, message Header section followed by the relevant message body. The Request Message flag is always FALSE and the Response Message is always TRUE for a response message. The supported message types are summarized in the following table and details are provided in subsequent sections.

15TABLE NMessage Header Frame StructureMessage TypeMessage ModifierDescriptionNA/SA_CMD_RESULTSNA/SA_LOCK_OWNED orContains the results of aNA/SA_LOCK_NOT_OWNEDCLI requestNA/SA_HEARTBEAT0Provides feedbackregarding a heartbeatrequest.NA/SECESSIONNA/SA_CHARACTERISTICSCharacteristics of thesession tableNA/SECESSIONNA/SA_ENTRYSession table entry valuesfor a given session,typically between a clientand serverNA/SECESSIONNA/SA_FEEDBACKOptional Session tablemanipulation responsemessage

[0176] 4.11 Command Results

[0177] The Command Results response message is used to return the results of a CLI request. The following message Header fields must have the following values:

[0178] Request Message=FALSE

[0179] Response Message=TRUE

[0180] Type=NA/SA13 CMD13 RESULTS

[0181] Modifier=NA/SA13 LOCK13 OWNED or NA/SA13 LOCK13 NOT13 OWNED indicating the current status of the command lock

[0182] Message Identifier=Message Identifier value from request message The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

[0183] A series of messages with Response Code of NA/SA13 CLI13 STATUS will always be followed by a message with a Response Code of NA/SA13 ERROR13 CLI13 FAIL to allow detailed error messages to be passed between NA/SA entities. If this is a multi-message successful response, then the sender can indicate message order by the Sequence Number field. The first through the next-to-last message will have Response Code=NA/SA13 SUCCESS and the last message is indicated by Response Code=NA/SA13 SUCCESS13 LAST.

16TABLE OCommand Results Response Message Frame StructureMessage Body Field NameData TypeValueSequence NumberU32A field that allows a CLI handlerto indicate the order of CLIresults to the requestor so thatthe requestor can re-constructthe entire command result.Command Result TextU8 (n)The text results of a CLIcommand

[0184] Example of usage: Network switch sends a CLI command to a GPP

[0185] 1. The Message Processor identifies that the user has entered a command that is to be handled by a GPP.

[0186] 2. The Message Processor forms a message with Request Message=TRUE, Response Message=FALSE, a Type=Command and Modifier=0

[0187] 3. The MP sends the message via NA/SA13 MSG13 SEND13 WITH13 ACK.

[0188] 4. The GPP receives the message via NA/SA13 MSG13 RECEIVE and passes it to the Request consumer.

[0189] 5. The GPP Request consumer calls the CLI command handler with the command.

[0190] 6. The GPP forms a message with Request Message=FALSE, Response Message=TRUE, Type=Command Results, Modifier=NA/SA13 LOCK13 NOT13 OWNED -and Message Identifier field equal to the Message Identifier in the Request message.

[0191] 7. The GPP sends the Command Results message via NA/SA13 MSG13 SEND13 WITH13 ACK.

[0192] 8. The MP receives the Command Results message via NA/SA13 MSG13 RECEIVE.

[0193] 9. The results of the command are displayed to the user.

[0194] In Unusual Conditions:

[0195] a) The command is not recognized by the GPP: The normal processing is followed with the exception that the Command Results message contains text that describes the error and provides user help for valid commands.

[0196] b) A command is passed that requires that the command lock be owned: The Command message is not executed, a Command Results response message is formed with the Response Code set to:

NA/SA13 ERROR13 CMD13 LOCK13 NOT13 OWNED.

[0197] 14.12 Heartbeat Response

[0198] The Heartbeat Response message is used to acknowledge a Heartbeat Request message. The following message Header fields must have the following values:

17Request Message =FALSEResponse Message =TRUEType =NA/SA_HEARTBEATModifier =0

[0199] There is no message body for a Heartbeat Response message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0200] NA/SA Heartbeat Response messages are always sent best effort.

[0201] 14.13 Session Characteristics

[0202] The Session Characteristics response message is used to return characteristics of the session table to the requester. The following message Header fields must have the following values:

18Request Message =FALSEResponse Message =TRUEType =NA/SECESSIONModifier =NA/SA_CHARACTERISTICS

[0203] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer paragraph.

19TABLE PSession Characteristics Response Frame StructureMessage BodyDataValueValid SessionU16The number of valid session entries in theEntriessession tableSession Entry SizeU16The number of bytes in a session entrySession Table SizeU32The number of bytes in the session table

[0204] Example of usage: GPP needs the characteristics of the session table that resides in an associated network switch:

[0205] 1. The GPP forms a message with Request Message=TRUE, Response Message FALSE, Type=Session and Modifier=Characteristics.

[0206] 2. The GPP sends the Request message via NA/SA13 MSG13 SEND13 WITH13 ACK

[0207] 3. An SP receives the Request message via NA/SA13 MSG13 RECEIVE, which passes it to the Request consumer.

[0208] 4. The Request consumer counts the number of valid entries in the session table.

[0209] 5. The Request consumer forms an Session Characteristics Response message with the Valid Session Entries field equal to the count from step 4, the Session Table Size field is set to a constant, and the Session Entry Size field is also set to a constant. The Message Identifier in the header of the Response message must equal the Message Identifier in the Request message. The Request Message flag is set FALSE and the Response Message flag is set TRUE.

[0210] 6. The SP sends the Response message via NA/SA13 MSG13 SEND13 WITH13 ACK.

[0211] 7. The GPP receives the Response message, via NA/SA13 MSG13 RECEIVE, which notifies the NA/SA higher-level function of success.

[0212] 8. The requestor is returned a Session Characteristics Response message.

[0213] 14.14 Session Entry

[0214] The Session Entry response message is used to return the values from a session entry to the requester. The following message Header fields must have the following values:

20Request Message =FALSEResponse Message =TRUEType =NA/SECESSIONModifier =NA/SA_ENTRYMessage Identifier =Message Identifier value from request message

[0215] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

21TABLE QSession Entry Response Frame StructureMessage BodyDataValueApplicableU16Bit field-each indicated field in the pay-load area is related to a bit. If a bit is 1,then the sender has a meaningful valuein the related field.ApplicationU16/0Well known application port numberProtocol(e.g., HTTP = 80)Source IP AddressU32/1IP Address of sourceDestination IPU32/2IP Address of destinationAddressReal IP AddressU32/3IP Address of real serverSource PortU16/4Port of sourceDestination PortU16/5Port of destinationReal PortU16/6Port of real serverIP ProtocolUS/7Well known protocol number (e.g.,tcp = 6, udp = 17)TypeU8/8Used to identify the contents of theOpaque fieldOpaqueU8 (64)/Field available to application level9to define additional data

[0216] Example of usage: GPP reads a session table entry from an associated network switch

[0217] 1. The GPP forms a message with Request Message=TRUE, Response Message=FALSE, Type=Session and Modifier=Read.

[0218] 2. The GPP sends the request message via NA/SA13 MSG13 SEND13 WITH13 ACK.

[0219] 3. An SP receives the request message via NA/SA13 MSG13 RECEIVE, which passes it to the Request consumer.

[0220] 4. The Request consumer reads the entry from the session table.

[0221] 5. The Request consumer forms a message with Request Message=FALSE, Response Message=TRUE, Type=Session and Modifier=Entry. The Message Identifier in the header of the Response message must equal the Message Identifier in the Request message.

[0222] 6. The SP sends the Response message via NA/SA13 MSG13 SEND13 WITH13 ACK

[0223] 7. The GPP receives the Response message via NA/SA13 MSG13 RECEIVE, which notifies the NA/SA higher-level function of success.

[0224] 14.15 Session Response

[0225] The Session Response message is optionally used to acknowledge a Session Create/Update/Delete Request message. If the application requires a response message, then the Request Message flag should be set TRUE in the Session Request message. If the application sets the Request Message flag=FALSE, then the Session Response message is not returned. The following message Header fields must have the following values:

22Request Message =FALSEResponse Message =TRUEType =NA/SECESSIONModifier =NA/SA_FEEDBACKMessage Identifier =Message Identifier value from request message

[0226] There is no message body for a Session Response message, therefore the Message Length field of the Link Layer section is always set to length of the message Header.

[0227] 14.16 System Level Control Messages

[0228] This class of interactions deals with messages passed between the network switch and GPP units or between two GPP units. They are operational in nature, enabling the control and setup of each unit. The intent of these interactions is to allow external control of the respective unit, either network switch or GPP. The following subsections will provide details of each interaction.

[0229] All System Level Control messages have the same structure; Link Layer section, message Header section followed by the relevant message body. The supported message types are summarized in the following table and details are provided in subsequent sections.

23TABLE RSystem-Level Control MessagesMessage TypeMessage ModifierDescriptionNA/SA_EXCEPTION0Used to share exceptiondetails amongst NA/SApartners.NA/SA_COMMAND0,Passes a command to aNA/SA_LOCK_FORCE,NA/SA partner's CLI.NA/SA_LOCK_GET,NA/SA_LOCK_REL orNA/SA_LOCK_QUERYNA/SA_HEARTBEAT0Used to determine thehealth of a NA/SA partnerNA/SA_REGISTERNA/SA_GPP orUsed by a GPP to establishNA/SA_SWITCHits type, capabilities andfacilities. The modifiervalue identifies the type ofNA/SA partner that is expected to respond.NA/SA_CAPABILITIES0This is the response to aNA/SA_REGISTER re-quest message. It is used toestablish the sender's type,capabilities and facilities.NA/SA_CONFIRM_REGISTRATION0Used to affirm the com-pletion of the registrationprocess. This message de-clares the facilities, cap-abilities and applicationsthat will be active through aNA/SA tunnel.NA/SA_UNREGISTER0Used to notify anotherNA/SA entity that thesender is disabling thepreviously registered NA/SA functionalityNA/SA_CONFIRM_UNREGISTER0The Unregister Confirmmessage indicates thesender has terminated allfacilities, capabilities andapplications that hadpreviously been registered.

[0230] 14.17 NA/SA Exception

[0231] The NA/SA Exception message allows NA/SA partners to share details regarding exceptional conditions. The normal handling of this message simply involves the recipient logging the exception in an appropriate manner. The following message Header fields must have the following values:

24Request Message =FALSEResponse Message =FALSEType =NA/SA_EXCEPTIONModifier =0

[0232] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

25TABLE SNA/SA Exception Message Frame StructureMessage BodyDataValueException MessageU8 (12)The 12-byte NA/SA message Header ofHeaderthe message that generated the exceptionalconditionException MessageU8 (n)The NA/SA message Body of the messageBodythat generated the exceptional condition. Ifthe message Body is greater than 256bytes in length, then this field will containonly the first 256 bytes of that message.

[0233] 14.18 Command Line Interface

[0234] The command message allows a CLI command to be passed to either a network switch or GPP. To address the security concerns regarding this capability, then each unit (network switch or GPP) can be configured to disallow this interaction. If this interaction is allowed, then the command results are passed back to the caller. The following message Header fields must have the following values:

26Request Message =TRUEResponse Message =FALSEType =NA/SA_COMMANDModifier =0, NA/SA_LOCK_FORCE,NA/SA_LOCK_GET,NA/SA_LOCK_REL orNA/SA_LOCK_QUERYas described in section 14.19

[0235] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer section and is used by the recipient to determine the length of the command. The recipient will convert the command to the required format for internal processing, such as appending null or newline characters at the end of the array.

27TABLE TCommand Message Frame StructureMessage BodyDataValueCommandU8 (n)The command(s) to be executed

[0236] The results of a command message are returned in a message with a Type of command results. Refer to section 14.11 for an example of the usage of this message.

[0237] 14.19 Command Lock

[0238] There is one NA/SA command lock associated with each NA/SA partner that allows another partner to execute a modifying command(s). A partner must own the lock to execute a modifying command message. The methods for determining which commands are modifying commands are left to the implementation. The Command handler logic will implement the NA/SA command lock.

[0239] The NA/SA command lock shall have two states; Owned and Not13 Owned. When the state of the command lock is Owned, then the following information is saved to identify the lock owner:

[0240] MAC Address

[0241] IP Address

[0242] Hold Time

[0243] Login Name

[0244] When a modifying command message is received, the state of the NA/SA command lock is checked. If the state is Owned and the sender's MAC address matches that of the lock owner, then the command message is executed. If the state of the command lock is not Owned or the sender's MAC address does not match that of the lock owner, then the command message will not be executed and a message with Request Message=FALSE, Response Message=TRUE, Type=command results, Modifier=LOCK13 NOT13 OWNED, Response Code=NA/SA13 ERROR13 CMD13 LOCK13 NOT13 OWNED and a message body as described for Query Command Lock (section 14.22) shall be returned.

[0245] 14.20 Force Command Lock

[0246] The Force Command Lock message requests that the sender be given the recipient's command lock regardless of the current state of the command lock (as long as the Lock IP Address, Lock MAC Address and Lock Login fields of this message match the current values of the command lock). Thus, one GPP can ‘take’ ownership of a network switch's command lock even though another GPP currently is the lock owner. The following message Header fields must have the following values:

28Request Message =TRUEResponse Message =FALSEType =NA/SA_COMMANDModifier =NA/SA_LOCK_FORCE

[0247] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

29TABLE UForce Command Lock Message Frame StructureMessage BodyDataValueLock IP AddressU32IP address of the current lock ownerLock MAC AddressU8 (6)MAC address of the current lock ownerLock Login LengthU16Length of the login name in the LockLogin fieldLock LoginU8 (64)Current login name of the user that will beentering modifying commandsNew IP AddressU32IP address of the senderNew Hold TimeU16New number of seconds that the senderexpects to hold the command lockNew Login LengthU16Length of the login name in the NewLogin fieldNew LoginU8 (64)New login name of the user that will beentering modifying commands

[0248] The results of a Force Command Lock message are returned in a message with Request Message=FALSE, Response Message=TRUE, Type=command results, Modifier=NA/SA13 LOCK13 OWNED and a message body as described for Query Command Lock (section 14.22) shall be returned.

[0249] 14.21 Get Command Lock

[0250] A NA/SA partner's command lock must be owned before that partner can execute a modifying command message. The Get Command Lock message requests that the sender be given the recipient's command lock. The following message Header fields must have the following values:

30Request Message =TRUEResponse Message =FALSEType =NA/SA_COMMANDModifier =NA/SA_LOCK_GET

[0251] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer section.

31TABLE VGet Command Lock Message Frame StructureMessage BodyDataValueIP AddressU32IP address of the senderHold TimeU16Number of seconds that the sender expectsto hold the command lockLogin LengthU16Length of the login name in the Login fieldLoginU8 (64)Login name of the user that will be enteringmodifying commands

[0252] The results of a Get Command Lock message are returned in a message with Request Message=FALSE, Response Message=TRUE, Type=command results and a message body as described for Query Command Lock (section 14.22). The values of the Modifier and Response Code fields depend on the success of the request. If successful, Modifier=NA/SA13 LOCK13 OWNED and Response Code=NA/SA13 SUCCESS. If failure, Modifier=NA/SA13 LOCK13 NOT13 OWNED and Response Code=NA/SA13 ERROR13 CMD13 LOCK13 NOT13 OWNED.

[0253] 14.22 Query Command Lock

[0254] The Query Command Lock message requests the NA/SA command lock owner information. The following message Header fields must have the following values:

32Request Message =TRUEResponse Message =FALSEType =NA/SA_COMMANDModifier =NA/SA_LOCK_QUERY

[0255] There is no message body for a Query Command Lock message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0256] The results of a Query Command Lock message are returned in a message with Request Message=FALSE, Response Message=TRUE and Type=command results. The value of the Modifier field depends on the current state of the command lock. The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

33TABLE WQuery Command Lock Message Frame StructureMessage BodyDataValueIP AddressU32IP address of the ownerMAC AddressU8 (6)MAC address of the ownerHold TimeU16Number of seconds that the owner expectedto hold the command lockHeld TimeU16Number of seconds that the owner has heldthe command lockLogin LengthU16Length of the login name in the Login fieldLoginU8 (64)Login name of the user that will be enteringmodifying commands

[0257] 14.23 Release Command Lock

[0258] The Release Command Lock message indicates that the NA/SA command lock owner wants to change the state of the command lock to Not13 Owned. The following message Header fields must have the following values:

34Request Message =TRUEResponse Message =FALSEType =NA/SA_COMMANDModifier =NA/SA_LOCK_REL

[0259] There is no message body for a Release Command Lock message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0260] The results of a Release Command Lock message are returned in a message with Request Message=FALSE, Response Message=TRUE, Type=command results and Modifier=NA/SA13 LOCK13 NOT13 OWNED shall be returned.

[0261] 14.24 Heartbeat Request

[0262] The Heartbeat Request message allows a partner to determine the operational status of its partner. It is possible for a GPP to extend its processing of a heartbeat into its application level by passing this message to the application. In that case, the application is expected to form a Heartbeat Response message to be passed back to the Heartbeat Request sender. This allows a network switch to determine the operational status of a GPP based application. If there is not an application to handle the Heartbeat Request message, then the upper NA/SA layer should generate the Heartbeat Response message. The following message Header fields must have the following values:

35Request Message =TRUEResponse Message =FALSEType =NA/SA_HEARTBEATModifier =0

[0263] There is no message body for a Heartbeat Request message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header. A Heartbeat Request message is confirmed by a message with a Type of Heartbeat Response.

[0264] NA/SA Heartbeat Request messages are always sent best effort.

[0265] 14.25 NA/SA Registration

[0266] NA/SA Registration accomplishes the following functions:

[0267] 1. Automating the network switch configuration of the GPP. The GPP describes itself in terms of function and capacity. The GPP always initiates the registration process. If two GPPs are registering with each other, then the controlled GPP is responsible for initiating the process.

[0268] 2. Maximizing the efficiency of the load balancing of each individual GPP. The GPP describes its capacity in terms called capacity units (CU). The switch will subsequently manage the GPP's workload in terms called service units (SU). The capacity metric is used to determine SUs. When the SUs sent to the GPP matches the CU for that GPP, the network switch will consider the GPP to be ‘maxed out.’

[0269] 3. Allows the network switch (or controlling GPP) to understand the GPP's capabilities. These are functions that can be enabled/disabled on that GPP.

[0270] 4. Allows the network switch (or controlling GPP) to understand the GPP's facilities. These are functions that are always available on that GPP (those that can't be enabled/disabled).

[0271] The following message Header fields must have the following values:

36Request Message =TRUEResponse Message =FALSEType =NA/SA_REGISTERModifier =0

[0272] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer section.

[0273] NA/SA Registration messages are always sent best effort.

37TABLE XNA/SA Registration Message Frame StructureMessageBody FieldDataNameTypeValueRequestedU32Bit indicating the originator's capabilities (A 1 inCapabilitythe bit position indicates that the capability isVectorpresent and is accessible via this API)0-Encryption1-Command Line InterfaceRequestedU32Bit indicating the originator's facilities (A 1 in theFacilitiesbit position indicates that the facility is presentand is accessible via this API)0-Session Table1-31 TBD (These bits must be zero)RequestedU32Bit mask indicating which applications are beingApplicationsregistered for in this NA/SA message:0-RURL1-Firewall2-SSL3-Akamizer4-30 TBD (These bits must be zero)31-User Defined ApplicationOperationalU8 (6)The MAC address to send operational messagesMACAddressInitialU16This field contains the initial sequence number,Sequencewhich is used to initialize the NA/SA LinkNumberLayer's Expected Value field. The firstacknowledged NA/SA control message from thesender will use this sequence number.CapacityU16This represents the maximum load that the GPPUnitscan reliably handleCapacityU16A value that indicates the unit of measure for GPPMetriccapacity. Defined values are:NA/SA_CAP_NUM_CONNECTIONS,NA/SA_CAP_NUM_PROCESSESHardwareU8 (32)Text string containing the model typeIdentifierCLI formatU8 (16)Text string indicating what format CLI commandshould be issuedIP AddressU32IP address of senderNetmaskU32Network Mask of sender

[0274] 14.26 NA/SA Capabilities Response

[0275] The following message Header fields must have the following values:

38Request Message =FALSEResponse Message =TRUEType =NA/SA_CAPABILITIESModifier =0Message Identifier =Message Identifier valuefrom Registration message

[0276] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

[0277] NA/SA Capabilities Response messages are always sent best effort.

39TABLE YNA/SA Capabilities Response Frame StructureMessageBody FieldDataNameTypeValueCapabilityU32Indicating which requested capabilities thisBit MaskNA/SA entity can support. Note thatcapabilities that were not requested will notappear in this message.0-Encryption1-Command Line Interface2-31 TBD (These bits must be zero)FacilitiesU32Indicating which requested facilities thisBit MaskNA/SA entity can support. Note that facilitiesthat were not requested will not appear in thismessage.0-Session Table1-31 TBD (These bits must be zero)ApplicationsU32Indicating which requested applications thisBit MaskNA/SA entity can support. Note thatapplications that were not requested will notappear in this message.0-RURL1-Firewall2-SSL3-Akamizer4-30 TBD (These bits must be zero)31 ? User Defined ApplicationOperationalU8 (6)The MAC address to send operational messagesMACAddressInitialU16This field contains the initial sequence number,Sequencewhich is used to initialize the NA/SA LinkNumberLayer's Expected Value field. The firstacknowledged NA/SA control message fromthe sender will use this sequence number.CapacityU16This represents the maximum load that the GPPUnitscan reliably handleCapacityU16A value that indicates the unit of measure forMetricGPP capacity. Defined values are:NASA_CAP_NUM_CONNECTIONS,NASA_CAP_NUM_PROCESSESHardwareU8 (32)Text string containing the model typeIdentifierCLI formatU8 (16)Text string indicating what format CLIClockU32Current time in absolute ticksTicks perU32Clock ticks per secondsecond

[0278] 14.27 NA/SA Registration Confirm

[0279] The following message Header fields must have the following values:

40Request Message =FALSEResponse Message =FALSEType =NA/SA_CONFIRM_REGISTRATIONModifier =0

[0280] The structure of this message body is described below. The length of the message is set in the Message Length field of the Link-Layer section. NA/SA Confirm Registration messages are always sent “Ack required.”

[0281] The Confirm Register message has no message body; therefore the Message Length field of the Link-Layer section is always set to the length of the message Header.

[0282] The registration of a GPP to a Switch proceeds in the following series of events from the GPP's perspective:

[0283] 1. If the GPP sends a NA/SA13 BCAST13 PING message to discover the MAC addresses of NA/SA capable switches.

[0284] 2. GPP receives a ping response. GPP sends a best effort NA/SA13 REGISTER message out to the source MAC address of the ping response.

[0285] a. Event 1 will be repeated if event 2a does not occur within the pre-defined GPP Registration wait period.

[0286] 3. GPP receives a NA/SA13 CAPABILITIES message from a switch

[0287] a. If Capabilities, Facilities and Applications are sufficient to run desired NA/SA application, proceed to event 3.

[0288] b. If Capabilities, Facilities and Applications are not sufficient to run desired NA/SA application, take no action (wait period in event 1a will handle re-transmit)

[0289] 4. GPP sets up to receive acknowledged messages by using the Initial Sequence Number of the NA/SA13 CAPABILITIES message to initialize the NA/SA Link Layer's Expected Value field.

[0290] 5. GPP sends an “Ack required” NA/SA13 CONFIRM13 REGISTRATION message to the source MAC address of the NA/SA13 CAPABILITIES message received in event 2. The contents of the Capability Bit Mask, Facilities Bit Mask, and Applications Bit Mask fields of the NA/SA13 CONFIRM13 REGISTRATION shall be the same as the NA/SA13 CAPABILITIES. NA/SA13 CONFIRM13 REGISTRATION messages require acknowledgments.

[0291] 6. The GPP is now registered to the switch

[0292] Note that the same events occur for a GPP registering with another GPP.

[0293] From the switch's perspective:

[0294] 1. Switch receives a NA/SA13 REGISTER message.

[0295] a. If port allows NA/SA messages and the message is sent to a broadcast address (or the switch's MAC address), the switch sends a ‘best effort’ NA/SA13 CAPABILITIES message containing the capabilities of this switch. The message is sent to source MAC address of the NA/SA13 REGISTER message in event 1. The values set in the NA/SA13 CAPABILITIES will be stored in the switch. These values will indicate which capabilities, facilities, and applications need to launch when the NA/SA13 CONFIRM13 REGISTER message is received. Proceed to event 2.

[0296] b. If the port does not allow NA/SA messages or the destination MAC address is non-broadcast and is not that of the switch, process the frame as a non-NA/SA frame. Take no further action

[0297] 2. Switch sets up to receive acknowledged messages from the GPP by using the Initial Sequence Number of the NA/SA13 REGISTER message to initialize the NA/SA Link Layer's Expected Value field.

[0298] a. If event 3 does not occur within the pre-defined time out period, undo the acknowledged message setup from event 2. Take no further action.

[0299] b. If the switch receives another NA/SA13 REGISTER message from the same GPP before event 3 occurs, undo the acknowledged message setup from event 2. Handle the new NA/SA13 REGISTER message again in event 1.

[0300] 3. Switch receives a NA/SA13 CONFIRM13 REGISTRATION message from the GPP.

[0301] a. If the NA/SA13 CONFIRM13 REGISTRATION message is not received within the pre-defined timeout period, the registration information received in event 1 will be discarded. Take no further action.

[0302] 4. The GPP is now registered to the switch. Any subsequent NA/SA13 REGISTER messages received during the registration process or after the GPP has registered with the switch shall result in the previous registration being undone (including shutting down any applications related to the previous registration) and event 1 of the switch's registration process will handle the new NA/SA13 REGISTER.

[0303] Note, that then same events occur for a GPP registering with another GPP. GPP's always initiate the NA/SA registration process. NA/SA registration can operate in 1 of 2 modes: ‘Plug and Play’ and Configured. ‘Plug and Play’ allows a customer to have a NA/SA application function simply by connecting a factory default, NA/SA capable switch and a GPP together. ‘Plug and Play’ has the following restrictions:

[0304] The GPP only accepts the first NA/SA13 CAPABILITIES message. Any subsequent NA/SA capabilities frames from other switches will be ignored.

[0305] ‘Plug and Play’ only works for one switch to many GPP applications. Configured registration allows a customer to configure multi switch to multi GPP applications. For configured registrations, the GPP has the option to send NA/SA13 REGISTER to a user defined MAC address or to a broadcast MAC address (the GPP does not use NA/SA13 BCAST13 PING messages to discover NA/SA switches in configured registrations). The needs of the NA/SA application dictate this decision.

[0306] 14.28 NA/SA Unregistration

[0307] The unregister request message informs the recipient to remove all information about the sender as well as disabling capabilities, facilities, and applications the sender had previously registered for. The following message Header fields must have the following values:

41Request Message =TRUE or FALSEResponse Message =FALSEType =NA/SA_UNREGISTERModifier =0

[0308] There is no message body for an unregister request message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0309] Unregister messages can be sent in 1 of 2 ways:

[0310] 1. “Best effort” and Request Message=FALSE. This is used by NA/SA entities that are shutting down immediately (e.g. due to a panic).

[0311] 2. “Ack required” and Request Message=TRUE. This is used by NA/SA entities that want to cleanly terminate NA/SA activities with another NA/SA entity. This allows the message queue from the sender to the recipient to be completely flushed. This also allows the sender to know when the recipient has completed all appropriate NA/SA unregister activities (e.g. an application encounters an unexpected condition and needs to start over from ground zero).

[0312] 14.29 NA/SA Unregister Response

[0313] The unregister response message is an optional message used to inform the recipient that the sender has completed shutdown of all capabilities, facilities, and applications the recipient had previously registered for. If the Request Message flag=FALSE, then there is no response required for the unregister request message. If the Request Message flag=TRUE, then the unregister response message is generated. The following message Header fields must have the following values:

42Request Message=FALSEResponse Message =TRUEType =NA/SA_UNREGISTERModifier =0Message Identifier =Message Identifier value from unregister requestmessage

[0314] The unregister response message has no message body, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0315] 14.30 Table Manipulation

[0316] This class of interactions allows external control of data structures within the network switch or GPP. The intent of these interactions is to allow a controller process to anticipate the flow of data and to control that flow when it occurs. The following sections will provide details of each interaction.

[0317] 14.31 Session Table Manipulation

[0318] Clients and servers establish a session (or one is implied) before they communicate. Each session is represented by a row in a session table. This set of messages (create, read, update, or delete session) controls the rows of a session table. The session table normally resides within a network switch, but a similar table can exist within a GPP. These messages can be used to control the contents in either case.

[0319] 14.32 Session Create

[0320] The Create modifier is used to add new entries to the session table. If the Request Message flag=TRUE, then the session response message is returned. If the Request Message flag=FALSE, then there is no response to this message. The following message Header fields must have the following values:

43Request Message =TRUE or FALSEResponse Message =FALSEType =NA/SECESSIONModifier =NA/SA_CREATE

[0321] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

44TABLE ZCreate Modifier Message Frame StructureMessage BodyData Type/ValueApplicableU16Bit field-each indicated field in thepayload area is related to a bit. If a bit is1, then the sender has a meaningfulvalue in the related field.ApplicationU16/0Well known application port numberProtocol(e.g., HTTP = 80)Source IPU32/1IP Address of sourceAddressDestination IPU32/2IP Address of destinationAddressReal IP AddressU32/3IP Address of real serverSource PortU16/4Port of sourceDestination PortU16/5Port of destinationReal PortU16/6Port of real serverIP ProtocolU8/7Well known protocol number (e.g.,tcp = 6, udp = 17)TypeU8/8Used to identify the contents of theOpaque fieldOpaqueU8 (64)/9Field available to application levelto define additional data

[0322] 14.33 Session Read

[0323] The Read modifier is used to read rows from the session table. The results of a Read Session request message are returned in a message with a Type of Session Entry. Refer to section 4.6.4 for an example of reading a session entry.

[0324] The following message Header fields must have the following values:

45Request Message =TRUEResponse Message =FALSEType =NA/SECESSIONModifier =NA/SA_READ

[0325] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer section.

46TABLE AARead Modifier Frame StructureDataType/Message BodyApplicableField NamebitValueApplicableU16Bit field-each indicated field in the pay-load area is related to a bit. If a bit is 1,then the sender has a meaningful valuein the related field.ApplicationU16/0Well known application port numberProtocol(e.g., HTTP = 80)Source IP AddressU32/1IP Address of sourceDestination IPU32/2IP Address of destinationAddressReal IP AddressU32/3IP Address of real serverSource PortU16/4Port of sourceDestination PortU16/5Port of destinationReal PortU16/6Port of real serverIP ProtocolU8/7Well known protocol number (e.g.,tcp = 6, udp = 17)TypeU8/8Used to identify the contents of theOpaque fieldOpaqueU8 (64)/9Field available to application level todefine additional data

[0326] 14.34 Session Update

[0327] The Update modifier uses the values in the Tbl fields to identify the session being referenced for update. Once the session has been identified, then it is updated with the values from the New fields. The Applicable bit field conditions the handling of both the Tbl and New fields. If the Request Message flag=TRUE, then the session response message is returned. If the Request Message flag=FALSE, then there is no response to this message. The following message Header fields must have the following values:

47Request Message =TRUE or FALSEResponse Message =FALSEType =NA/SECESSIONModifier =NA/SA_UPDATE

[0328] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

48TABLE BBSession Update Modifier Frame StructureData Type/Message BodyApplicableField NamebitValueApplicableU16Bit field-each indicated field in the pay-load area is related to a bit. If a bit is 1,then the sender has a meaningful valuein the related field.Tbl ApplicationU16/0Session Table-Well known applicationProtocolport number (e.g., HTTP = 80)Tbl Source IPU32/1Session Table-IP Address of sourceAddressTbl DestinationU32/2Session Table-IP Address of destinationIP AddressTbl Source PortU16/3Session Table-Port of sourceTbl DestinationU16/4Session Table-Port of destinationPortTbl IP ProtocolU8/5Session Table-Well known protocolnumber (e.g., tcp = 6, udp = 17)New IP ProtocolU8 6Well known protocol number (e.g.,tcp = 6, udp = 17)New ApplicationU16/7Well known application port numberProtocol(e.g., HTTP = 80)New. Source IPU32/8IP Address of sourceAddressNew DestinationU32/9IP Address of destinationIP AddressNew Source PortU16/10Port of sourceNew DestinationU16/11Port of destinationPortTypeU8/12Used to identify the contents of theOpaque fieldOpaqueU8 (64)/13Field available to application level todefine additional data

[0329] 14.35 Session Delete

[0330] The Delete modifier is used to delete entries from the session table. The values in the Applicable fields identify the session to be deleted. If the Request Message flag=TRUE, then the session response message is returned. If the Request Message flag=FALSE, then there is no response to this message. The following message Header fields must have the following values:

49Request Message =TRUE or FALSEResponse Message =FALSEType =NA/SECESSIONModifier =NA/SA_DELETE

[0331] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

50TABLE CCSession Delete Modifier Frame StructureData Type/Message BodyApplicableField NamebitValueApplicableU16Bit field-each indicated field in the pay-load area is related to a bit. If a bit is 1,then the sender has a meaningful valuein the related field.ApplicationU16/0Well known application port numberProtocol(e.g., HTTP = 80)Source IPU32/1IP Address of sourceAddressDestination IPU32/2IP Address of destinationAddressReal IP AddressU32/3IP Address of real serverSource PortU16/4Port of sourceDestination PortU16/5Port of destinationReal PortU16/6Port of real serverIP ProtocolU8/7Well known protocol number (e.g.,tcp = 6, udp = 17)TypeU8/8Used to identify the contents of theOpaque fieldOpaqueU8 (64)/9Field available to application level todefine additional data

[0332] 14.36 Session Characteristics Request

[0333] The Session Characteristics Request message is used to determine a number of attributes of the session table. Refer to section 14.13 for an example of using the Session Characteristics message. The following message Header fields must have the following values:

51Request Message =TRUEResponse Message =FALSEType =NA/SECESSIONModifier =NA/SA_CHARACTERISTICS

[0334] There is no message body for a Session Characteristics Request message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header. A Session Characteristics Request message is confirmed by a message with Request Message=FALSE, Response Message=TRUE, Type=NA/SECESSION and Modifier of Session Characteristics

[0335] 15. NA/SA Broadcast Tunnel

[0336] The NA/SA broadcast tunnel is used to pass NA/SA messages amongst partners. This tunnel is used in conjunction with the NA/SA control tunnel. These two tunnels have the same structure for messages, Link Layer and Header sections followed by the message body. They also share the same message transport except that the broadcast tunnel only uses NA/SA13 MSG13 SEND since all messages sent over the broadcast tunnel are sent best effort.

[0337] A NA/SA message is comprised of sections. The Link Layer section is required to be the first section of every NA/SA message. The message Header section follows the Link Layer section and is required in every NA/SA message. The message body follows the Header section. The contents of the message body are dependent on the value of the Type field of the message Header. Some message types do not have a message body.

52TABLE DDNA/SA Broadcast MessagesMessage TypeMessage ModifierDescriptionNA/SA_BCAST_GENERAL0, NA/SA_GPP orUsed to send broadcastNA/SA_SWITCHmessages to the targetedclasses of partners(GPP or network switch)NA/SA_BCAST_IP_ADDRESS0Used by GPP to re-quest that an IPaddress be assigned to itNA/SA_BCAST_PING0, NA/SA_GPP orUsed to determineNA/SA_SWITCHwhether NA/SApartners are availableNA/SA_UCAST_GENERAL0Used to send a message inresponse to a broadcastrequest messageNA/SA_UCAST_IP_ADDRESS0Provides an IP addressto the requestorNA/SA_UCAST_PING_ANSWER0Provides feedbackregarding a pingrequest.

[0338] 15.1 Broadcast General

[0339] The NA/SA Broadcast General message allows one partner to send messages to the rest of the accessible NA/SA partners. The Request Message flag indicates the sender's expectation regarding a response message. If Request Message=TRUE, then at least one General Response messages is expected. If Request Message=FALSE, then no response messages are expected. The Modifier value indicates the target class. Zero indicates all NA/SA partners. NA/SA13 GPP indicates that all GPPs are the intended target. NA/SA13 SWITCH indicates that all network switches are the intended target. The following message Header fields must have the following values:

53Request Message =TRUE or FALSEResponse Message =FALSEType =NA/SA_BCAST_GENERALModifier =0, NA/SA_GPP or NA/SA_SWITCH indicatingthe type of partner that the sender is intending toreceive this message

[0340] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link-Layer section.

54TABLE EEBroadcast General Message Frame StructureMessage Body FieldNameData TypeValueTypeU32Used to identify the contents of theOpaque fieldOpaqueU8 (n)An opaque field that is generated by thesender and that may be understood byeach recipient.

[0341] Note that the NA/SA Broadcast General message is sent to the broadcast address. There is no acknowledgment available for this message. This message is always sent best effort.

[0342] 15.2 IP Address Request

[0343] The IP Address Request message is used by a GPP to request that an IP address be assigned to it. It is expected that the user when installing the first GPP can assign a block of IP addresses. This message is used by subsequent GPPs to request an IP address from that block of addresses. It is the responsibility of the GPP application that receives this message to generate the IP Address Response message. The following message Header fields must have the following values:

55Request Message =TRUEResponse Message =FALSEType =NA/SA_BCAST_IP_ADDRESSModifier =0

[0344] There is no message body for an IP Address Request message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header. The results of an IP Address Request message are returned in a message with a Type of IP Address Response.

[0345] NA/SA IP Address Request messages are always sent best effort and are always addressed to the broadcast destination.

[0346] 15.3 Ping Broadcast

[0347] The Ping Broadcast message is used to locate NA/SA partners. The following message Header fields must have the following values:

56Request Message =TRUEResponse Message =FALSEType =NA/SA_BCAST_PINGModifier =0, NA/SA_GPP or NA/SA_SWITCH indicatingthe type of partner that the sender is looking for.

[0348] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section. The recipient will compare its MAC address with the Ignore List to determine if a response is required.

57TABLE FFPing Broadcast Message Frame StructureMessage Body FieldDataNameTypeValueList LengthU16The number of elements in the Ignore ListIgnore ListU6 (n)The MAC addresses of NA/SA partnersthat should not respond to this request

[0349] The results of a Ping Broadcast message are returned in a message with a Type of Ping Answer. NA/SA Ping Broadcast messages are always sent best effort and are always addressed to the broadcast destination.

[0350] 15.4 General Response

[0351] The NA/SA General Response message allows a partner to response to a General Request message. The following message Header fields must have the following values:

58Request Message =FALSEResponse Message =TRUEType =NA/SA_UCAST_GENERALModifier =0Message Identifier =Message Identifier value from General Requestmessage

[0352] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

59TABLE GGGeneral Response Message Frame StructureMessage Body FieldDataNameTypeValueSequence NumberU32A field that allows an application toindicate the order of a multi-messageresponse to the requestor so that therequestor can re-construct the entireresponse.TypeU32Used to identify the contents of theOpaque fieldOpaqueU8 (n)An opaque field that is generated by thesender and that may be understood byeach recipient.

[0353] Note that the NA/SA General Response message is sent to a specific MAC address. There is no acknowledgment available for the General Response message. This message is always sent best effort. If this is a multi-message response, then the sender can indicate message order by the Sequence Number field and the last message is indicated by Response Code=NA/SA13 SUCCESS13 LAST.

[0354] 15.5 IP Address Response

[0355] The IP Address Response message is used to assign an IP address to a GPP that requested one. A GPP requests an IP address by sending an IP Address Request broadcast message. The GPP application that receives the IP Address Request message is responsible for generating the IP Address Response message. The following message Header fields must have the following values:

60Request Message =FALSEResponse Message =TRUEType =NA/SA_UCAST_IP_ADDRESSModifier =0Message Identifier =Message Identifier value from IP Address Requestmessage

[0356] The structure of this message body is described in the following table. The length of the message is set in the Message Length field of the Link Layer section.

61TABLE HHIP Address Response Message Frame StructureMessage Body FieldDataNameTypeValueIP AddressU32IP address that is assigned to the requestor

[0357] NA/SA IP Address Response messages are always sent best effort and are always addressed to the MAC address of the sender of the IP Address Request message.

[0358] 15.6 Ping Answer

[0359] The Ping Answer message is used to return the results of a Ping Broadcast message. The following message Header fields must have the following values:

62Request Message =FALSEResponse Message =TRUEType =NA/SA_UCAST_PING_ANSWERModifier =0Message Identifier =Message Identifier value from Ping Broadcastmessage

[0360] There is no message body for a Ping Answer message, therefore the Message Length field of the Link Layer section is always set to the length of the message Header.

[0361] NA/SA Ping Answer messages are always sent best effort and are always addressed to the MAC address of the sender of the Ping Broadcast message.

SUMMARIES

[0362]

63

TABLE II

Message Type Summary

Message Type
Message Modifier
Description

NA/SA_BCAST
0, NA/SA_GPP or
Used to send each

GENERAL
NA/SA_SWITCH
NA/SA partner a

message.

NA/SA_BCAST_IP
0
Used by GPP tp request an IP

ADDRESS

address be assigned to it.

NA/SA_BCAST_PING
0, NA/SA_GPP or
Used to determine if

NA/SA_SWITCH
NA/SA partners are available.

NA/SA_CAPABILITIES
0
Response to a regis-

tration request. De-

scribes the respondents

processing capabilities.

NA/SA_CMD_RESULTS
NA/SA_LOCK_OWNED or
Used to return the re-

NA/SA_LOCK_NOT_OWNED
suits of a CLI command.

NA/SA_COMMAND
0, NA/SA_LOCK_FORCE,
Used to pass CLI com-

hands to another unit.

NA/SA_LOCK_GET
Response message is

returned that contains

the command response

text.

NA/SA_CONFIRM_REGISTRATION
0
Ends the registration

process between NA/SA

partners.

NA/SA_EXCEPTION
0
Used to convey details

of exceptions among

NA/SA partners.

NA/SA_HEARTBEAT
0
Identifies operational

status of sender.

NA/SA_HEARTBEAT
0
Heartbeat Response

acknowledges Heartbeat

Message

NA/SA_REGISTER
0
Identifies a GPP or

switch and its

capabilities. Starts

negotiations of the

manner in which

subsequent processing

will occur.

NA/SECESSION
NA/SA_CHARACTERISTICS
Used to request

attributes of the session

table.

NA/SECESSION
NA/SA_CHARACTERISTICS
Returns attributes of the

session table.

NA/SA_SESSION
NA/SA_CREATE
Adds entry to the

sessikons table.

NA/SA_SESSION
NA/SA_DELETE
Deletes an entry from

the sessions table.

NA/SA_SESSION
NA/SA_ENTRY
Returns values for a

specific session entry.

NA/SA_SESSION
NA/SA_FEEDBACK
Optionally provides a

response message to

create/delete/update

messages.

NA/SA_SESSION
NA/SA_READ
Reads an entry from the

sessions trable.

NA/SA_SESSION
NA/SA_UPDATE
Updates an entry in the

sessions table.

NA/SA_UCAST_GENERAL
0
Responds to a Broadcast

General message.

NA/SA_UCST_IP_ADDRESS
0
Provides an IP address

to a requestor.

NA/SA_UCAST_PING_ANSWR
0
Provides feedback to a

Ping request.

NA/SA_UNREGISTER
0
Notifies another NA/SA

entity the sender is

disabling the previous

NA/SA functionality.

NA/SA_UNREGISTER_CONFIRM
0
Indicates the sender has

terminated all facilities,

capabilities previously

registered.

Error Numbers

[0363] The following table lists the valid error numbers that can be used to report problems that occur during the processing of a NA/SA control message. The Response Code field of the message header section provides feedback to the requestor when an error is encountered. This table listed the valid values that the Response Code field can contain.

64TABLE JJError NumbersLabelDescriptionNASA_ERROR_CLI_DISABLEDA Command message has failed since theCLI interface is not enabled.NASA_ERROR_CLI_FAILA command message has failed duringcommand processing.NASA_ERROR_CMD_LOCK_NOT_OWNEDA modifying Command message has beenreceived, but the sender does not hold thecommand lock.NASA_ERROR_INVALID_APPL_PROTOCOLA message refers to an application protocol,but the value provided is not valid.NASA_ERROR_INVALID_IP_PROTOCOLA message refers to an IP protocol, but thevalue provided is not valid.NASA_ERROR_INVALID_MESSAGE_MODIFIERA message header section Modifier fieldcontains an unsupported value or contains asupported value that is not defined to be usedwith the value specified in the Type field.NASA_ERROR_INVALID_MESSAGE_TYPEA message header section type field containsan unsupported value.NASA_ERROR_MISSING_IP_ADDRESSA message header section Type field impliesthe presence of an IP address, but it has notbeen provided or has a value of zero.NASA_ERROR_MISSING_PORT_NUMBERA message header section Type field impliesthe presence of a Port Number, but it has notbeen provided or has a value of zero.NASA_ERROR_SESSION_NOT_UNIQUEA message header section Type field refersto a session but the values provided do notresolve to a unique session entry.

Exception Numbers

[0364] The following table lists the valid exception numbers that can be used to report problems that occur during the delivery of a NA/SA control message. In these situations, a NASA_EXCEPTION message is formed with the Response Code field of the message header section providing feedback. This table listed the valid values that the Response Code field can contain.

65TABLE KKException NumbersLabelDescriptionNASA_EXCEPTION_SEQUENCEA message has been received withACK Required set true and theSequence Number field does notcontain the expected value.NASA_EXCEPTION_UNEXPECTED_HEADER_VERSIONA message header section HeaderVersion field contains a value thatis not supported.NASA_EXCEPTION_UNSUPPORTED_ENCRYPTIONA message header section SecurityType field contains a value that isnot supported.

Success Numbers

[0365] The following table lists the numbers that can be used to report success of a NA/SA control message The Response Code field of the message header section provides feedback to the requester when message processing has completed. This table listed the valid values that the Response Code field can contain.

66TABLE LLSuccess NumbersLabelDescriptionNASA SUCCESSA message has successfullycompleted.NASA SUCCESS LASTThis is the last response message fora multi-message response.NASA CLI STATUSThe CLI command completed withunusual conditions.

Conclusion

[0366] Although the present invention has been described in detail with reference to particular preferred and alternate embodiments, persons possessing ordinary skill in the art to which this invention pertains will appreciate that various modifications and enhancements maybe made without departing from the spirit and scope of the claims that follow. The various configurations that have been disclosed above are intended to educate the reader about preferred and alternative embodiments, and are not intended to constrain the limits of the invention or the scope of the claims. The list of Reference Characters which follows is intended to provide the reader with a convenient means of identifying elements of the invention in the Specification and Drawings. This list is not intended to delineate or narrow the scope of the claims.

Interactive control of network devices

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims