FreshPatents.com Logo
stats FreshPatents Stats
3 views for this patent on FreshPatents.com
2014: 3 views
Updated: July 25 2014
newTOP 200 Companies filing patents this week


    Free Services  

  • MONITOR KEYWORDS
  • Enter keywords & we'll notify you when a new patent matches your request (weekly update).

  • ORGANIZER
  • Save & organize patents so you can view them later.

  • RSS rss
  • Create custom RSS feeds. Track keywords without receiving email.

  • ARCHIVE
  • View the last few months of your Keyword emails.

  • COMPANY DIRECTORY
  • Patents sorted by company.

Follow us on Twitter
twitter icon@FreshPatents

Generating packets to test fragmentation

last patentdownload pdfdownload imgimage previewnext patent


20140043981 patent thumbnailZoom

Generating packets to test fragmentation


Methods, apparatus and machine readable storage media for testing fragmentation of datagrams by a network under test. A traffic generator may generate a datagram including a header and a payload, the payload containing plural instrumentation blocks, each instrumentation block containing information identifying the datagram and information identifying the location of each instrumentation block within the datagram. The traffic generator may transmit the datagram over the network under test.
Related Terms: Datagram Fragmentation Machine Readable

Browse recent Ixia patents - Calabasas, CA, US
USPTO Applicaton #: #20140043981 - Class: 370241 (USPTO) -
Multiplex Communications > Diagnostic Testing (other Than Synchronization)

Inventors: Alon Regev

view organizer monitor keywords


The Patent Description & Claims data below is from USPTO Patent Application 20140043981, Generating packets to test fragmentation.

last patentpdficondownload pdfimage previewnext patent

RELATED APPLICATION INFORMATION

This application is a continuation of application Ser. No. 12/948, 567, filed Nov. 17, 2010, entitled TESTING PACKET FRAGMENTATION (to be issued on Oct. 29, 2013 as U.S. Pat. No. 8,571,032).

This application is related to application Ser. No. 12/948,582, filed Nov. 17, 2010, entitled TESTING PACKET REASSEMBLY, published as US 2012/0120820 A1.

NOTICE OF COPYRIGHTS AND TRADE DRESS

A portion of the disclosure of this patent document contains material which is subject to copyright protection. This patent document may show and/or describe matter which is or may become trade dress of the owner. The copyright and trade dress owner has no objection to the facsimile reproduction by anyone of the patent disclosure as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright and trade dress rights whatsoever.

BACKGROUND

1. Field

This disclosure relates to testing a network or network device.

2. Description of the Related Art

In many types of communications networks, each message to be sent is divided into portions of fixed or variable length. Each portion may be referred to as a packet, a frame, a cell, a datagram, a data unit, or other unit of information, all of which are referred to herein as packets.

Each packet contains a portion of an original message, commonly called the payload of the packet. The payload of a packet may contain data, or may contain voice or video information. The payload of a packet may also contain network management and control information. In addition, each packet contains identification and routing information, commonly called a packet header. The packets are sent individually over the network through multiple switches or nodes. The packets are reassembled into the message at a final or intermediate destination using the information contained in the packet headers, before the message is delivered to a target device or end user. At the receiving end, the reassembled message is passed to the end user in a format compatible with the user\'s equipment.

Communications networks that transmit messages as packets are called packet switched networks. Packet switched networks commonly contain a mesh of transmission paths which intersect at hubs or nodes. At least some of the nodes may include a switching device or router that receives packets arriving at the node and retransmits the packets along appropriate outgoing paths. Packet switched networks are governed by a layered structure of industry-standard protocols. Layers 1, 2, and 3 of the structure are the physical layer, the data link layer, and the network layer, respectively.

Layer 1 protocols define the physical (electrical, optical, or wireless) interface between nodes of the network. Layer 1 protocols include various Ethernet physical configurations, the Synchronous Optical Network (SONET) and other optical connection protocols, and various wireless protocols such as WiFi.

Layer 2 protocols govern how data is logically transferred between nodes of the network. Layer 2 protocols include the Ethernet, Asynchronous Transfer Mode (ATM), Frame Relay, and Point to Point Protocol (PPP).

Layer 3 protocols govern how packets are routed from a source to a destination along paths connecting multiple nodes of the network. The dominant layer 3 protocols are the well-known Internet Protocol version 4 (IPv4) and version 6 (IPv6). A packet switched network may need to route IP packets using a mixture of the Ethernet, ATM, FR, and/or PPP layer 2 protocols. At least some of the nodes of the network may include a router that extracts a destination address from a network layer header contained within each packet. The router then uses the destination address to determine the route or path along which the packet should be retransmitted. A typical packet may pass through a plurality of routers, each of which repeats the actions of extracting the destination address and determining the route or path along which the packet should be retransmitted.

The IPv4 and IPv6 layer 3 protocols also provide for packet fragmentation and reassembly. A network device may fragment an original packet into two or more shorter packets, which may be subsequently reassembled into the original packet by some other network device. Packet fragmentation and reassembly may be necessary, for example, if a device or path within a network has a maximum allowable packet length that is shorter than the original packet. Packet fragmentation and reassembly may also be used to divide a long data packet into fragments that can be transmitted between periodically scheduled voice or video packets. In keeping with the terminology of IPv4, an original packet to be fragmented will be referred to herein as a “datagram”. Each datagram may be divided into a plurality of “fragments”. Note that both datagrams and fragments are packets as previously defined.

In order to test a packet switched network or a device included in a packet switched communications network, test traffic comprising a large number of packets may be generated, transmitted into the network at one or more ports, and received at different ports. Each packet in the test traffic may be a unicast packet intended for reception at a specific destination port or a multicast packet, which may be intended for reception at one or more destination ports. In this context, the term “port” refers to a communications connection between the network and the equipment used to test the network. The term “port unit” refers to a module within the network test equipment that connects to the network at a port. The received test traffic may be analyzed to measure the performance of the network. Each port unit connected to the network may be both a source of test traffic and a destination for test traffic. Each port unit may emulate a plurality of logical source or destination addresses.

A series of packets originating from a single port unit and having a specific type of packet and a specific rate will be referred to herein as a “stream.” A source port unit may support multiple outgoing streams simultaneously and concurrently, for example to accommodate multiple packet types, rates, or destinations. “Simultaneously” means “at exactly the same time.” “Concurrently” means “within the same time.”

For the purpose of collecting test data, the test traffic may be organized into packet groups, where a “packet group” is any plurality of packets for which network traffic statistics are accumulated. The packets in a given packet group may be distinguished by a packet group identifier (PGID) contained in each packet. The PGID may be, for example, a dedicated identifier field or combination of two or more fields within each packet.

For the purpose of reporting network traffic data, the test traffic may be organized into flows, where a “flow” is any plurality of packets for which network traffic statistics are reported. Each flow may consist of a single packet group or a small plurality of packet groups. Each packet group may typically belong to a single flow.

Within this description, the term “engine” means a collection of hardware, which may be augmented by firmware and/or software, which performs the described functions. An engine may typically be designed using a hardware description language (HDL) that defines the engine primarily in functional terms. The HDL design may be verified using an HDL simulation tool. The verified HDL design may then be converted into a gate netlist or other physical description of the engine in a process commonly termed “synthesis”. The synthesis may be performed automatically using a synthesis tool. The gate netlist or other physical description may be further converted into programming code for implementing the engine in a programmable hardware device such as a field programmable gate array (FPGA), a programmable logic device (PLD), or a programmable logic arrays (PLA). The gate netlist or other physical description may be converted into process instructions and masks for fabricating the engine within an application specific integrated circuit (ASIC).

Within this description, the term “logic” also means a collection of hardware that performs a described function, which may be on a smaller scale than an “engine”. “Logic” encompasses combinatorial logic circuits; sequential logic circuits which may include flip-flops, registers and other data storage elements; and complex sequential logic circuits such as finite-state machines.

Within this description, a “unit” also means a collection of hardware, which may be augmented by firmware and/or software, which may be on a larger scale than an “engine”. For example, a unit may contain multiple engines, some of which may perform similar functions in parallel. The terms “logic”, “engine”, and “unit” do not imply any physical separation or demarcation. All or portions of one or more units and/or engines may be collocated on a common card, such as a network card or blade, or within a common FPGA, ASIC, or other circuit device.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a network environment.

FIG. 2 is a block diagram of a network card.

FIG. 3 is a graphical depiction of packet fragmentation.

FIG. 4 is a flow chart of a method for testing packet fragmentation.

FIG. 5 is a graphical depiction of packet fragmentation.

FIG. 6 is a graphical depiction of packet fragmentation.

FIG. 7 is a graphic depiction of an instrumentation block.

FIG. 8 is a flow chart of a method for testing packet reassembly.

FIG. 9 is a graphic depiction of an instrumentation block.

Throughout this description, elements appearing in block diagrams are assigned three-digit reference designators, where the most significant digit is the figure number where the element is introduced and the two least significant digits are specific to the element. An element that is not described in conjunction with a block diagram may be presumed to have the same characteristics and function as a previously-described element having the same reference designator.

In block diagrams, arrow-terminated lines may indicate data paths rather than signals. Each data path may be multiple bits in width. For example, each data path may consist of 4, 8, 16, 64, 256, or more parallel connections.

DETAILED DESCRIPTION

Description of Apparatus

FIG. 1 shows a block diagram of a network environment. The environment may include network test equipment 100, and a network 190 including one or more network devices 192.

The network test equipment 100 may be a network testing device, performance analyzer, conformance validation system, network analyzer, or network management system. The network test equipment 100 may include one or more network cards 106 and a backplane 104 contained or enclosed within a chassis 102. The chassis 102 may be a fixed or portable chassis, cabinet, or enclosure suitable to contain the network test equipment. The network test equipment 100 may be an integrated unit, as shown in FIG. 1. Alternatively, the network test equipment 100 may comprise a number of separate units cooperative to provide traffic generation and/or analysis. The network test equipment 100 and the network cards 106 may support one or more well known standards or protocols such as the various Ethernet and Fibre Channel standards, and may support proprietary protocols as well.

The network cards 106 may include one or more application specific integrated circuits (ASICs), processors, and other kinds of devices. The network cards 106 may include one or more programmable hardware devices such as field programmable gate arrays (FPGAs), programmable logic devices (PLDs), programmable logic arrays (PLAs). In addition, the network cards 106 may include software and/or firmware. The term network card encompasses line cards, test cards, analysis cards, network line cards, load modules, interface cards, network interface cards, data interface cards, packet engine cards, service cards, smart cards, switch cards, relay access cards, and the like. The term network card also encompasses modules, units, and assemblies that may include multiple printed circuit boards. Each network card 106 may contain one or more port unit 110. Each port unit 110 may connect to the network 190 through one or more ports. The port units 110 may be connected to the network 190 through a communication medium 195, which may be a wire, an optical fiber, a wireless link, or other communication medium. Each network card 106 may support a single communications protocol, may support a number of related protocols, or may support a number of unrelated protocols. The network cards 106 may be permanently installed in the network test equipment 100 or may be removable.

The backplane 104 may serve as a bus or communications medium for the network cards 106. The backplane 104 may also provide power to the network cards 106.

The network devices 192 may be any devices capable of communicating over the network 190. The network devices 192 may be computing devices such as workstations, personal computers, servers, portable computers, personal digital assistants (PDAs), computing tablets, cellular/mobile telephones, e-mail appliances, and the like; peripheral devices such as printers, scanners, facsimile machines and the like; network capable storage devices including disk drives such as network attached storage (NAS) and storage area network (SAN) devices; networking devices such as routers, relays, hubs, switches, bridges, and multiplexers. In addition, the network devices 192 may include appliances, alarm systems, and any other device or system capable of communicating over a network.

The network 190 may be a Local Area Network (LAN), a Wide Area Network (WAN), a Storage Area Network (SAN), wired, wireless, or a combination of these, and may include or be the Internet. Communications on the network 190 may take various forms, including frames, cells, datagrams, packets or other units of information, all of which are referred to herein as packets. The network test equipment 100 and the network devices 192 may communicate simultaneously with one another, and there may be plural logical communications paths between the network test equipment 100 and a given network device 192. The network itself may be comprised of numerous nodes providing numerous physical and logical paths for data to travel. Each port unit 110 may be connected, via a specific communication medium 195, to a corresponding port on a network device 192.

Referring now to FIG. 2, an exemplary port unit 210 may include a port processor 212, a traffic generator unit 220, a traffic receiver unit 280, and a network interface unit 270 which couples the port unit 210 to a network under test 290. The port unit 210 may be all or part of a network card such as the network cards 106. The network under test 290 may be one or more network devices such as the network device 194, and/or all or portion of a network such as the network 190.

The port processor 212 may include a processor, a memory coupled to the processor, and various specialized units, circuits, software and interfaces for providing the functionality and features described here. The processes, functionality and features may be embodied in whole or in part in software which operates on the processor and may be in the form of firmware, an application program, an applet (e.g., a Java applet), a browser plug-in, a COM object, a dynamic linked library (DLL), a script, one or more subroutines, or an operating system component or service. The hardware and software and their functions may be distributed such that some functions are performed by the processor and others by other devices.

The port processor 212 may communicate with a test administrator 205 which may be coupled to an operator interface 207. The test administrator 205 may be a computing device contained within, or external to, the network test equipment 100. The test administrator 205 may provide the port processor 212 with instructions and data required for the port unit to participate in testing the network 290. The instructions and data received from the test administrator 205 may include, for example, definitions of packet streams to be generated by the port unit 210 and definitions of performance statistics that may be accumulated and reported by the port unit 210.

The port processor 212 may provide the traffic generator unit 220 with stream forming data 214 to form a plurality of streams. The stream forming data 214 may include, for example, the type of packet, the frequency of transmission, definitions of fixed and variable-content fields within the packet and other information for each packet stream. The traffic generator unit 220 may then generate the plurality of streams in accordance with the stream forming data 214. The plurality of streams may be interleaved to form outgoing test traffic 235. Each of the streams may include a sequence of packets. The packets within each stream may be of the same general type but may vary in length and content.

The network interface unit 270 may convert the outgoing test traffic 235 from the traffic generator unit 220 into the electrical, optical, or wireless signal format required to transmit the test traffic to the network under test 290 via a link 295, which may be a wire, an optical fiber, a wireless link, or other communication link. Similarly, the network interface unit 270 may receive electrical, optical, or wireless signals from the network over the link 295 and may convert the received signals into incoming test traffic 275 in a format usable to the traffic receiver unit 280.

The traffic receiver unit 280 may receive the incoming test traffic 275 from the network interface unit 270. The traffic receiver unit 280 may determine if each received packet is a member of a specific flow, and may accumulate test statistics for each flow in accordance with test instructions 218 provided by the port processor 212. The accumulated test statistics may include, for example, a total number of received packets, a number of packets received out-of-sequence, a number of received packets with errors, a maximum, average, and minimum propagation delay, and other statistics for each flow. The traffic receiver unit 280 may also capture and store specific packets in accordance with capture criteria included in the test instructions 218. The traffic receiver unit 280 may provide test statistics and/or captured packets 284 to the port processor 212, in accordance with the test instructions 218, for additional analysis during, or subsequent to, the test session.

The outgoing test traffic 235 and the incoming test traffic 275 may be primarily stateless, which is to say that the outgoing test traffic 235 may be generated without expectation of any response and the incoming test traffic 275 may be received without any intention of responding. However, some amount of stateful, or interactive, communications may be required or desired between the port unit 210 and the network 290 during a test session. For example, the traffic receiver unit 280 may receive control packets, which are packets containing data necessary to control the test session, that require the port unit 210 to send an acknowledgement or response.



Download full PDF for full patent description/claims.

Advertise on FreshPatents.com - Rates & Info


You can also Monitor Keywords and Search for tracking patents relating to this Generating packets to test fragmentation patent application.
###
monitor keywords



Keyword Monitor How KEYWORD MONITOR works... a FREE service from FreshPatents
1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored.
3. Each week you receive an email with patent applications related to your keywords.  
Start now! - Receive info on patent apps like Generating packets to test fragmentation or other areas of interest.
###


Previous Patent Application:
Opportunistic carrier aggregation for dynamic flow switching between radio access technologies
Next Patent Application:
Lawful interception in a mobile data network with data offload at the basestation
Industry Class:
Multiplex communications
Thank you for viewing the Generating packets to test fragmentation patent info.
- - - Apple patents, Boeing patents, Google patents, IBM patents, Jabil patents, Coca Cola patents, Motorola patents

Results in 0.57093 seconds


Other interesting Freshpatents.com categories:
Novartis , Pfizer , Philips , Procter & Gamble ,

###

All patent applications have been filed with the United States Patent Office (USPTO) and are published as made available for research, educational and public information purposes. FreshPatents is not affiliated with the USPTO, assignee companies, inventors, law firms or other assignees. Patent applications, documents and images may contain trademarks of the respective companies/authors. FreshPatents is not affiliated with the authors/assignees, and is not responsible for the accuracy, validity or otherwise contents of these public document patent application filings. When possible a complete PDF is provided, however, in some cases the presented document/images is an abstract or sampling of the full patent application. FreshPatents.com Terms/Support
-g2-0.2597
     SHARE
  
           

FreshNews promo


stats Patent Info
Application #
US 20140043981 A1
Publish Date
02/13/2014
Document #
14055579
File Date
10/16/2013
USPTO Class
370241
Other USPTO Classes
370474
International Class
04L12/26
Drawings
10


Datagram
Fragmentation
Machine Readable


Follow us on Twitter
twitter icon@FreshPatents