Packet assembly

BACKGROUND

0001Networks enable computers and other devices to communicate. For example, networks can carry data representing video, audio, e-mail, and so forth. Typically, data sent across a network is divided into smaller messages known as packets. By analogy, a packet is much like an envelope you drop in a mailbox. A packet typically includes “payload” and a “header”. The packet's “payload” is analogous to the letter inside the envelope. The packet's “header” is much like the information written on the envelope itself. The header can include information to help network devices handle the packet appropriately. For example, the header can include an address that identifies the packet's destination. Much like one envelope stuffed inside another, one or more packets may be stored within another packet. This is known as “encapsulation”.

0002Some packet processing systems use programmable devices known as network processors. Network processors enable software programmers to quickly reprogram network processor operations, for example, to adapt to changing protocols or provide new features. Some network processors feature multiple processing engines to share packet processing duties. For instance, while one engine determines how to forward one packet further toward its destination, a different engine determines how to forward another. This enables the network processors to achieve high packet processing speeds while remaining programmable.

BRIEF DESCRIPTION OF THE DRAWINGS

0003<figref idref="DRAWINGS">FIGS. 1–2</figref> and <b>4</b> are flow-diagrams.

0004<figref idref="DRAWINGS">FIGS. 3 and 5</figref> are flow-charts.

0005<figref idref="DRAWINGS">FIGS. 6–8</figref> are diagrams.

DETAILED DESCRIPTION

0006How data is arranged in memory can greatly affect performance of a system. For example, some arrangements of packet data in memory can reduce the number of memory read and write operations needed to process the packet. Packet data may also be arranged to place packet portions of interest in readily determined locations reducing the time required to search through the packet data in memory.

0007To illustrate the impact of data arrangement, <figref idref="DRAWINGS">FIG. 1A</figref> depicts the arrangement of a packet in memory <b>104</b>. The “H”-s represent the packet's header while the “P”-s represent the packet payload. The numbers in the upper left hand corner of each memory <b>104</b> location identify the memory <b>104</b> address of the location. For example, the first payload byte is stored in the location at address “2”.

0008The memory <b>104</b> is depicted as rows of bytes. The width (e.g., 8-bytes) of these rows corresponds to the amount of memory read or written at a time. For example, to access the value at byte-3, a read operation can be used to retrieve the entire row (i.e., byte-0 to byte-7).

0009As shown in <figref idref="DRAWINGS">FIG. 1A</figref>, the packet data may be moved from one memory <b>104</b> (“the source”) to another <b>106</b> (“the target”). As shown, the target memory <b>106</b> may have a different memory width than memory <b>104</b>. For example, instead of an 8-byte wide random access memory, memory <b>106</b> may be formed from an array of 4-byte registers.

0010The transfer illustrated in <figref idref="DRAWINGS">FIG. 1A</figref> copied each packet byte in memory <b>104</b> to a byte in memory <b>106</b>. The different memory widths, however, result in the different arrangement of the data within the memories <b>104</b>, <b>106</b>. The arrangement of the packet in memory <b>106</b>, however, may not be the best for a given packet processing operation. For example, a routing operation may need to access the first four bytes of the payload (e.g., the header bytes of an encapsulated packet). In <figref idref="DRAWINGS">FIG. 1A</figref>, the first four payload bytes could be accessed using two read operations of memory <b>106</b> (i.e., one read to access bytes <b>2</b> and <b>3</b> and a second read to access bytes <b>4</b> and <b>5</b>) and performing a subsequent shift operation.

0011<figref idref="DRAWINGS">FIG. 1B</figref> illustrates an alternate arrangement of the packet's data. As shown, the packet data is padded with garbage bytes (labeled “G”) that align the start of the payload along the boundary of memory <b>106</b>. For example, as shown, the addition of garbage bytes shifts the first payload byte, byte-2, in memory <b>104</b> to byte-4 in memory <b>106</b>. In addition to aligning the first byte of the payload within memory <b>106</b>, the first four bytes of payload (i.e., bytes 4–7 of memory <b>106</b>) may now be accessed with a single read operation instead of two reads and a shift as in <figref idref="DRAWINGS">FIG. 1A</figref>.

0012The number of garbage bytes used to pad the packet data may vary. For example, the length of a header may vary across protocols or even across packets. Thus, the payload may start at different positions within different packets. Software control of the alignment, however, permits flexible adaptation to different packet structures. For instance, the payload of a packet having a two-byte header (as shown) can be aligned by padding the packet data with two beginning garbage bytes. A packet having a three-byte header (not shown) would only need a single garbage byte of padding.

0013The data configuration shown in <figref idref="DRAWINGS">FIG. 1B</figref> may be controlled by a software instruction that specifies how to align the data in memory <b>106</b>. For example, an instruction may result in a memory command (1) that identifies an offset of two-bytes. In response, to this command, a component (e.g., a memory controller <b>100</b>) can (2) shift the retrieved data by padding the data with an appropriate number of “garbage” bytes. As shown, the component may also pad the end of the data such that the padded data completely occupies a row or register of a target memory <b>106</b>. Alignment of data by software controlled hardware can provide fast but flexible alignment of data.

0014A similar approach may be used when writing data to memory <b>104</b>. For example, an instruction may result in a memory command that reverses the previous shifting operation by stripping the previously added garbage bytes before writing the data. By over-writing memory with the stripped data, read-modify-write operations may be reduced.

0015<figref idref="DRAWINGS">FIGS. 2A–2E</figref> illustrate sample operation of a processor using techniques described above. The processor shown in <figref idref="DRAWINGS">FIG. 2A</figref> includes multiple programmable engines <b>102</b><i>a</i>–<b>102</b><i>n </i>that execute instructions (not shown) in parallel. The engines <b>102</b> include local storage <b>106</b><i>a </i>(e.g., local random access memory and/or an array of registers) of their own, but also share access to memory <b>104</b>. In the example shown, memory <b>104</b> stores 16-bytes of a packet.

0016To read or write data to memory <b>104</b>, the engines send commands to memory controller <b>100</b>. The controller <b>100</b> can queue or arbitrate between commands received from the engines <b>102</b>. As shown, engine <b>102</b><i>a </i>may send a command requesting a read of 16-bytes of memory <b>104</b> into local memory <b>106</b><i>a</i>. The command specifies an offset (e.g., 2) identifying which byte should be aligned in the local memory <b>106</b>. In response to the command, read-align logic (e.g., hardware to shift data) is configured to shift the retrieved 16-bytes by 2-bytes. This amount to shift can be computed as: <br />(shift amount)=(target memory width)−(offset).

0017The memory controller <b>100</b> initiates read operations to retrieve the data. As shown in <figref idref="DRAWINGS">FIG. 2B</figref>, after retrieving the 16-bytes, the read align logic pads the retrieved data with a two garbage byte prefix (G<b>0</b>, G<b>1</b>) to shift the data by the requested amount. The logic also pads the data with a two garbage byte suffix (G<b>18</b>, G<b>19</b>) so that the padded data completely fills rows of memory <b>106</b> instead of having a final “partially” filled row. As shown, the padded data aligns the payload as desired within memory <b>106</b><i>a. </i>

0018In the course of processing the packet, engine <b>102</b><i>a </i>may alter some of the packet's payload. For example, in <figref idref="DRAWINGS">FIG. 2C</figref>, byte-9, byte-10, and byte-17 (identified by deltas) were altered. For instance, the engine <b>102</b><i>a </i>may reroute a web-request to a different server by altering a Universal Resource Locator (URL) included in the packet, change a Transmission Control Protocol (TCP) checksum, or alter the destination address of a packet.

0019As shown in <figref idref="DRAWINGS">FIG. 2D</figref>, after modifying the packet, the engine <b>102</b><i>a </i>executes an instruction to write the packet data back to memory <b>104</b>. As shown, the instruction causes the engine <b>102</b><i>a </i>to issue a command to write 16-bytes of local storage to memory <b>104</b> address <b>0</b>. The command also instructs write align logic to perform a reverse shift of two-bytes. That is, by specifying an offset of “2”, the write align logic can determine that a “2” garbage byte prefix and suffix were previously added to the data and that the garbage data should be stripped before writing.

0020As shown in <figref idref="DRAWINGS">FIG. 2E</figref>, the write align logic strips the garbage bytes previously added to pad the data. The controller <b>100</b> then over-writes memory <b>104</b> with the stripped data, altering the modified bytes without performing a “read-modify-write” at the controller <b>100</b>.

0021As illustrated, the memory controller <b>100</b> circuitry handled the low-level tasks of padding and stripping while engine <b>102</b><i>a </i>software controlled these operations such that the controller <b>100</b> shift logic added and removed garbage bytes. This decoupling of operations enables the controller <b>100</b> to be simply constructed while saving software execution cycles that would have otherwise be used to manipulate the data.

0022<figref idref="DRAWINGS">FIGS. 2B and 2D</figref> both depicted commands issued in response to engine instructions. The instructions can be included in source code for assembly and/or compilation into target code executable by an engine. The source code instructions may have a variety of syntaxes and parameters. For example, the read instruction may have a syntax of:

0023memory_identifier [read_align, $xfer, addr1, addr2, ref cnt], opt_tok

0024where the “memory_identifier” identifies a memory (e.g., external SRAM or DRAM) and the “read_align” parameter distinguishes the command from conventional read instructions. The “$xfer” (transfer register) parameter identifies the starting register of register array <b>106</b><i>a </i>to store the aligned data. Briefly, a transfer register is a register within an engine that buffers data exchanged with the memory controller <b>100</b>. The addresses specified by “addr1” and “addr2” are added to determine the offset. The first six bits of the sum identify a memory row, while the last two identify the offset. The identified offset results in a “rightward” shift of (target memory width)−(offset). The “ref_cnt” parameter identifies how many longwords to retrieve from memory. Finally, the “opt_tok” (optional token) has a syntax of:

0025[ctx_swap[signal],][sig_done[signal]].

0026The ctx_swap parameter instructs an engine <b>102</b> to swap to another engine thread of execution until a signal indicates completion of the read operation. This enables other threads to perform operations while the read proceeds. The sig_done parameter also identifies a status signal to be set upon completion of the fetch, but does not instruct the engine <b>102</b> to swap contexts.

0027The write align instruction may have a similar syntax. For example, the write align instruction may have a syntax of:

0028memory reference[write_align, $xfer, addr1, addr2, ref_cnt], opt_tok

0029where the parameters represent the same values as the read align command. For example, the offset identified by the last two bits of the sum of addr1 and addr2 yields a reverse shift of (transfer memory width)−(offset) bytes before writing the contents of the specified transfer registers into the controlled memory.

0030Again, the syntaxes described above are merely examples and other implementations may feature different keywords, parameters, options, and so forth. Additionally, the instruction may exist at different levels of code. For example, the instruction may be part of the instruction set of an engine. Alternately, the instruction may be processed by a compiler or assembler to generate target instructions (e.g., engine executable instructions) corresponding to the source code alignment instruction.

0031<figref idref="DRAWINGS">FIG. 3</figref> is a flow-chart illustrating the sample sequence shown in <figref idref="DRAWINGS">FIG. 2</figref>. As shown, a software instruction (e.g., an instruction of an engine thread), causes an engine to issue <b>160</b> a read align command requesting data and identifying the desired alignment. The memory controller receives the command, then retrieves <b>162</b> and pads <b>164</b> the requested data. The software continues operations <b>166</b> (e.g., packet processing) and potentially modifies the read data.

0032As shown, software subsequently encounters an instruction that causes the engine to issue <b>168</b> a write align command to the memory controller <b>100</b>. In response to the command, the controller <b>100</b> strips <b>170</b> the identified data of previously added padding and writes <b>172</b> the data to memory.

0033Techniques described above can be used to enhance performance in a wide variety of environments. For example, the techniques can be used to align packet data based on the structure of the memory rather than an alignment dictated by the packet structure. For example, most of the link layer protocols (layer 2) used in the Internet today (Ethernet, Packet-Over-Sonet (POS)) have headers that are aligned on a 2-byte boundary. However, many computer systems that typically form the end-point of the network often feature 4-byte boundaries. This can create a mismatch between the alignment of the packet data 2-byte) and the natural alignment of the end-system (4-byte). Thus, an encapsulated packet (e.g., an Internet Protocol (IP) datagram or Transmission Control Protocol (TCP) segment) is unlikely to be aligned along a memory boundary. Techniques described above, however, can be used to speed packet processing operations. These savings can become considerable, particularly, in high-speed packet processing where memory bandwidth and compute cycles become critical resources.

0034<figref idref="DRAWINGS">FIGS. 4A to 4F</figref> illustrate operation of a computer program <b>122</b> using the alignment techniques described above to align a packet <b>128</b> in memory <b>104</b>. In the scheme illustrated by <figref idref="DRAWINGS">FIGS. 4A–4F</figref>, packets arrives piecemeal as a series of packet segments in receive buffer <b>120</b>. This packet segmentation may be due, for example, to a component, such as a framer, that breaks-up different packets received over different ports into uniform portions (e.g., 64-bytes). This enables more uniform servicing of the ports despite the potentially varying sizes of packets being received.

0035In <figref idref="DRAWINGS">FIGS. 4A–4F</figref>, a packet is divided into segments that include a “start of packet” segment <b>128</b><i>a </i>and, potentially, one or more “middle of packet” segments, and an “end of packet” segment. These labels are not necessarily exclusive. That is, if a packet is small enough, a segment may be labeled as both the starting and ending segment of a packet.

0036The different packet segments are processed by instructions <b>122</b> executed by engine <b>102</b><i>a</i>. These instructions reconstruct a packet by accumulating the different packet segments in consecutive bytes in memory <b>104</b>. To align the packet within memory <b>104</b>, the instructions <b>122</b> can use the memory controller shifting capabilities described above. The alignment capabilities can, however, potentially introduce stretches of garbage bytes within the accumulating packet. That is, a command to write-align an entire packet segment in memory <b>104</b> could result in appendage of garbage bytes to the end of the segment in memory <b>104</b>. If subsequent packet segments were appended immediately after the inserted garbage bytes, the resulting packet could include multiple stretches of garbage bytes separating the segments. To avoid these garbage “holes”, <figref idref="DRAWINGS">FIGS. 4A to 4F</figref> illustrate an approach that temporarily buffers the ending portion of a segment that would otherwise cause garbage padding. That is, the last “L” segment bytes that would occupy only a portion of a memory row are buffered as “residue” instead of being padded with a garbage suffix and written along with the rest of the segment data. The residue is saved until the following packet arrives with sufficient data to fill a row in memory <b>104</b>. When an end of packet segment arrives, remaining residue is flushed to memory.

0037In greater detail, as shown in <figref idref="DRAWINGS">FIG. 4B</figref>, a read instruction <b>142</b> reads data in a “start of packet” segment. A following write-align instruction <b>144</b> writes a subset of the data to memory <b>104</b>. To align the packet payload in memory <b>104</b>, the instruction <b>144</b> identifies an offset of “2”, causing the memory controller (not shown in <figref idref="DRAWINGS">FIG. 4</figref>) to shift the data by 6-bytes (i.e., 6-bytes=(memory width of 8-bytes)−(offset of 2-bytes)). The shift will align the packet's payload along the quadword (8-byte) boundary of memory <b>104</b>. The segment subset write aligned excludes “L” trailing residue bytes where L is determined as the memory width)−(offset). Thus, write-aligning the data does not cause inserting of a garbage suffix.

0038As shown in <figref idref="DRAWINGS">FIG. 4C</figref>, the residue <b>128</b><i>b </i>is stored by engine <b>102</b><i>a</i>. The residue <b>128</b><i>b </i>may be saved in local memory of the engine or in another memory such as external SRAM. Since segments from many different packets may be interleaved as they arrive in receive buffer <b>120</b>, the engine <b>102</b><i>a </i>may buffer many packet residues at a time. This residue may form part of a packet context that includes other packet data such as the location in memory <b>104</b> to continue writing segments of a given packet.

0039As shown in <figref idref="DRAWINGS">FIG. 4D</figref>, after another segment <b>130</b> for the packet arrives in receive buffer <b>120</b>, the engine instructions <b>122</b><i>b </i>read H <b>148</b> starting bytes of the segment <b>130</b> to completely fill a row of memory <b>104</b> when combined <b>150</b> with the previous residue <b>128</b><i>b </i>bytes. For example, as shown, the first two bytes of segment <b>130</b> are added to the previously stored 6-byte residue and written to memory <b>104</b>. As shown, in <figref idref="DRAWINGS">FIG. 4E</figref>, the process then continues accumulation of the packet in memory <b>104</b> for the remaining bytes in the segment. That is the remaining bytes, excluding the last “L” bytes that would cause garbage “holes”, are written <b>152</b> to memory. For example, a write align operation may write segment data excluding the already written H bytes and the ending L bytes. As shown, an instruction may be provided that causes direct transfer of bytes from the receive buffer <b>120</b> to memory <b>104</b> without traveling through engine <b>102</b><i>a. </i>

0040As shown in <figref idref="DRAWINGS">FIG. 4F</figref>, the remaining bytes are saved as residue. The operations illustrated in <figref idref="DRAWINGS">FIGS. 4D–4F</figref> repeat as additional segments arrive. After an end of packet segment is processed, any remaining residue is flushed to the memory.

0041Many variations of the above possible. For example, for packets that fit in entirely within one segment, alignment may be performed completely in hardware since no software action is required to fill in the holes. Additionally, residue bytes of an end of packet segment need not be handled separately from other bytes in the segment. Further, in many cases it is not necessary to write the initial (e.g., link layer header) bytes from a start of packet segment.

0042In the scheme above, the engine software handles the task of maintaining contexts for different packets instead of burdening the memory controller <b>100</b> with this task. Thus, scalability is provided by the engines instead of the controller <b>100</b>.

0043<figref idref="DRAWINGS">FIG. 5</figref> depicts a flowchart of a process implementing the scheme illustrated above. As shown, the process identifies <b>180</b> the type of segment. For “start of packet” segments, the segment is read <b>182</b> from the receive buffer. The bytes of segment, other than the L-bytes of the residue, are write aligned <b>184</b> to memory. The remaining L bytes are saved <b>186</b> as residue. For other segments, the residue is combined <b>188</b> with the first [(target memory width)−L] bytes read <b>186</b> from the segment and written <b>190</b> to memory. The next remaining bytes of the segment, other than the last L bytes, are write aligned <b>192</b> to memory. The residue is then updated <b>194</b> with the ending L bytes of the segment. For “end of segment” packets <b>196</b>, the residue is flushed <b>198</b> to memory.

0044The techniques described above may be implemented in a variety of systems. For example, <figref idref="DRAWINGS">FIG. 6</figref> depicts an example of network processor <b>200</b>. The network processor <b>200</b> shown is an Intel® Internet eXchange network Processor (IXP). Other network processors feature different designs.

0045The network processor <b>200</b> shown features a collection of packet processing engines <b>102</b> on a single integrated semiconductor chip. Individual engines <b>102</b> may provide multiple threads of execution. As shown, the processor <b>200</b> may also include a core processor <b>210</b> (e.g., a StrongARM® XScale®) that is often programmed to perform “control plane” tasks involved in network operations. The core processor <b>210</b>, however, may also handle “data plane” tasks.

0046As shown, the network processor <b>200</b> also features at least one interface <b>202</b> that can carry packets between the processor <b>200</b> and other network components. This interface <b>202</b> can include the receive buffer shown in <figref idref="DRAWINGS">FIGS. 4A–4F</figref>. For example, the processor <b>200</b> can feature a switch fabric interface <b>202</b> (e.g., a Common Switch Interface (CSIX)) that enables the processor <b>200</b> to transmit a packet to other processor(s) or circuitry connected to the fabric. The processor <b>200</b> can also feature an interface <b>202</b> (e.g., a System Packet Interface (SPI) interface) that enables the processor <b>200</b> to communicate with physical layer (PHY) and/or link layer devices (e.g., MAC or framer devices). The processor <b>200</b> also includes an interface <b>208</b> (e.g., a Peripheral Component Interconnect (PCI) bus interface) for communicating, for example, with a host or other network processors.

0047As shown, the processor <b>200</b> also includes other components shared by the engines <b>102</b> such as a hash engine, internal scratchpad memory shared by the engines, and memory controllers <b>206</b>, <b>212</b> that provide access to external memory shared by the engines. The controllers <b>206</b>, <b>212</b> and/or scratchpad can feature the read and write alignment circuitry described above

0048<figref idref="DRAWINGS">FIG. 7</figref> illustrates a sample engine <b>102</b> architecture. The engine <b>102</b> may be a Reduced Instruction Set Computing (RISC) processor tailored for packet processing. For example, the engines <b>102</b> may not provide floating point or integer division instructions commonly provided by the instruction sets of general purpose processors.

0049The engine <b>102</b> may communicate with other network processor components (e.g., shared memory) via transfer registers <b>232</b><i>a</i>, <b>232</b><i>b </i>that buffer data to send to/received from the other components. The engine <b>102</b> may also communicate with other engines <b>102</b> via neighbor registers <b>234</b><i>a</i>, <b>234</b><i>b </i>wired to adjacent engine(s).

0050The sample engine <b>102</b> shown provides multiple threads of execution. To support the multiple threads, the engine <b>102</b> stores program counters <b>222</b> for each thread. A thread arbiter <b>222</b> selects the program counter for a thread to execute. This program counter is fed to an instruction store <b>224</b> that outputs the instruction identified by the program counter to an instruction decode <b>226</b> unit. The instruction decode <b>226</b> unit may feed the instruction to an execution unit (e.g., an Arithmetic Logic Unit (ALU)) <b>230</b> for processing or may initiate a request to another network processor component (e.g., a memory controller) via command queue <b>228</b>. The decoder <b>226</b> and execution unit <b>230</b> may implement an instruction processing pipeline. That is, an instruction may be output from the instruction store <b>224</b> in a first cycle, decoded <b>226</b> in the second, instruction operands loaded (e.g., from general purpose registers <b>236</b>, next neighbor registers <b>234</b><i>a</i>, transfer registers <b>232</b><i>a</i>, and/or local memory <b>238</b>) in the third, and executed by the execution data path <b>230</b> in the fourth. Finally, the results of the operation may be written (e.g., to general purpose registers <b>236</b>, local memory <b>238</b>, next neighbor registers <b>234</b><i>b</i>, or transfer registers <b>232</b><i>b</i>) in the fifth cycle. Many instructions may be in the pipeline at the same time. That is, while one is being decoded <b>226</b> another is being loaded from the instruction store <b>104</b>. The engine <b>102</b> components may be clocked by a common clock input.

0051<figref idref="DRAWINGS">FIG. 8</figref> depicts a network device <b>312</b> incorporating techniques described above. As shown, the device features a collection of line cards <b>300</b> (“blades”) interconnected by a switch fabric <b>310</b> (e.g., a crossbar or shared memory switch fabric). The switch fabric, for example, may conform to CSIX or other fabric technologies such as HyperTransport, Infiniband, PCI, Packet-Over-SONET, RapidIO, and/or UTOPIA (Universal Test and Operations PHY Interface for ATM).

0052Individual line cards (e.g., <b>300</b><i>a</i>) may include one or more physical layer (PHY) devices <b>302</b> (e.g., optic, wire, and wireless PHYs) that handle communication over network connections. The PHYs translate between the physical signals carried by different network mediums and the bits (e.g., “0”-s and “1”-s) used by digital systems. The line cards <b>300</b> may also include framer devices (e.g., Ethernet, Synchronous Optic Network (SONET), High-Level Data Link (HDLC) framers or other “layer 2” devices) <b>304</b> that can perform operations on frames such as error detection and/or correction. The line cards <b>300</b> shown may also include one or more network processors <b>306</b> that perform packet processing operations for packets received via the PHY(s) <b>302</b> and direct the packets, via the switch fabric <b>310</b>, to a line card providing an egress interface to forward the packet. Potentially, the network processor(s) <b>306</b> may perform “layer 2” duties instead of the framer devices <b>304</b>.

0053While <figref idref="DRAWINGS">FIGS. 6–8</figref> described specific examples of a network processor, engine, and a device incorporating network processors, the techniques may be implemented in a variety of hardware, firmware, and/or software architectures including network processors, engines, and network devices having designs other than those shown. Additionally, the techniques may be used in a wide variety of network devices (e.g., a router, switch, bridge, hub, traffic generator, and so forth).

0054The term packet was sometimes used in the above description to refer to a frame. However, the term packet also refers to a TCP segment, fragment, Asynchronous Transfer Mode (ATM) cell, and so forth, depending on the network technology being used.

0055The term circuitry as used herein includes hardwired circuitry, digital circuitry, analog circuitry, programmable circuitry, and so forth. The programmable circuitry may operate on computer programs. Such computer programs may be coded in a high level procedural or object oriented programming language. However, the program(s) can be implemented in assembly or machine language if desired. The language may be compiled or interpreted. Additionally, these techniques may be used in a wide variety of networking environments.

0056Other embodiments are within the scope of the following claims.