U.S. patent application number 13/846838 was filed with the patent office on 2013-08-29 for large frame path mtu discovery and communication for fcoe devices.
This patent application is currently assigned to Emulex Design & Manufacturing Corporation. The applicant listed for this patent is Emulex Design & Manufacturing Corporation. Invention is credited to Parav Kanaiyalal PANDIT.
Application Number | 20130223281 13/846838 |
Document ID | / |
Family ID | 42165131 |
Filed Date | 2013-08-29 |
United States Patent
Application |
20130223281 |
Kind Code |
A1 |
PANDIT; Parav Kanaiyalal |
August 29, 2013 |
LARGE FRAME PATH MTU DISCOVERY AND COMMUNICATION FOR FCOE
DEVICES
Abstract
Embodiments of the invention relate to performing network
communications according to an existing protocol by using frames
that are larger than those usually allowed by the existing
protocol. Thus, embodiments of the present invention provide for an
extension of the existing protocol which allows for the use of
larger frames. Embodiments provide for use of various negotiation
and initialization mechanisms of the existing protocol with
additional modifications to allow for the negotiation of the use of
larger frames. Some embodiments ensure that the negotiations are
performed in such a manner that devices that feature the
improvements of the present invention can communicate with devices
that do not feature these improvements.
Inventors: |
PANDIT; Parav Kanaiyalal;
(Bangalore, IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Emulex Design & Manufacturing Corporation; |
|
|
US |
|
|
Assignee: |
Emulex Design & Manufacturing
Corporation
Costa Mesa
CA
|
Family ID: |
42165131 |
Appl. No.: |
13/846838 |
Filed: |
March 18, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12269716 |
Nov 12, 2008 |
8400942 |
|
|
13846838 |
|
|
|
|
Current U.S.
Class: |
370/254 |
Current CPC
Class: |
H04L 41/0803 20130101;
H04L 12/433 20130101; H04L 12/462 20130101 |
Class at
Publication: |
370/254 |
International
Class: |
H04L 12/24 20060101
H04L012/24 |
Claims
1. A system comprising: a network comprising a fabric; a first
device connected to the network; and a second device connected to
the network, wherein the first device, the second device and the
fabric are configured to negotiate a frame size larger than allowed
by standards, and the first and second devices are configured to
communicate through the network using frames of the negotiated
frame size.
2. The system of claim 1, wherein negotiating a frame size larger
than allowed by standards is defined by negotiating a payload size
larger than allowed by standards.
3. The system of claim 1, further including a legacy device,
wherein the legacy device is incapable of handling frames of size
larger than allowed by standards, the first device, the legacy
device and the fabric being configured to negotiate a frame size in
accordance with standards for communications between the first
device and the legacy device.
4. The system of claim 1, wherein the first device, the second
device and the fabric are configured to negotiate a frame size
larger than allowed by standards while they perform connection
initialization operations specified by standards.
5. The system of claim 4, wherein the connection initialization
operations specified by standards include FIP advertisement, FIP
solicitation, fabric login (FLOGI) and port login (PLOGI)
operations.
6. A method for operating a networked system including at least a
first and second device connected to a network including a fabric,
the method comprising: negotiating a frame size between the first
device, the second device and the fabric, the negotiated frame size
being larger than allowed by standards; and communicating between
the first and second devices through the network using frames of
the negotiated frame size.
7. The method of claim 6, wherein negotiating a frame size larger
than allowed by standards is defined by negotiating a payload size
larger than allowed by standards.
8. The method of claim 6, wherein the network further includes a
legacy device incapable of handling frames of size larger than
allowed by standards, the method further including negotiating a
second frame size for communication between the first device and
the legacy device by the first device, the second device and the
fabric, the second frame size being in accordance with standards;
communicating between the first and legacy devices through the
network using the second frame size.
9. The method of claim 6 further including performing connection
initialization operations specified by standards by the first
device, the second device and the fabric, said connection
initialization operations taking place while the first device, the
second device, and the fabric are negotiating a frame size larger
than allowed by standards.
10. The method of claim 9, wherein the connection initialization
operations specified by standards include FIP advertisement, FIP
solicitation, fabric login (FLOGI) and port login (PLOGI)
operations.
11. The method of claim 10, wherein the performance of connection
initialization operations specified by standards and the
negotiation of the frame size larger than allowed by standards
include sending one or more initialization frames specified by the
standards as being part of the connection initialization
operations, said frames including an additional field that is not
specified by standards, said additional field at least partially
defining a suggested frame size that is larger than allowed by
standards.
12. The method of claim 11, wherein the one or more initialization
frames include at least one of the group consisting of: an FIP
frame, a frame including a PLOGI request and a frame including a
PLOGI response.
13. The method of claim 11, wherein the suggested frame size that
is larger than allowed by standards is defined by defining a
suggested payload size larger than allowed by standards.
14. The method of claim 13, wherein the suggested payload size that
is larger than allowed by standards is defined by the use of the
additional field in conjunction with a conventional field that is
part of the frame, the conventional field storing a payload size
that is allowed by standards.
15. The method of claim 14, wherein the suggested payload size that
is larger than allowed by standards is defined in terms of a
predefined mathematical formula based on the values held in the
additional field and the conventional field.
16. The method of claim 15, wherein the additional field is
associated with a default value, the default value being a value
usually placed in that field by conventional devices, the
predefined mathematical formula being such that if the default
value is stored in the additional field, the predefined formula
results in a payload size that is equal to the payload size stored
by the conventional field.
17. A method performed by a device connected to a network including
a fabric the method comprising: negotiating a frame size with a
second device and the fabric, the negotiated frame size being
larger than allowed by standards; and communicating with the second
device through the network using frames of the negotiated frame
size.
18. The method of claim 17, wherein negotiating a frame size larger
than allowed by standards is defined by negotiating a payload size
larger than allowed by standards.
19. The method of claim 17, wherein the network further includes a
legacy device incapable of handling frames of size larger than
allowed by standards, the method further including negotiating a
second frame size with the legacy device and the fabric for
communication with the legacy device, the second frame size being
in accordance with standards; communicating with the legacy devices
through the network using the second frame size.
20. The method of claim 17 further including performing connection
initialization operations specified by standards, said connection
initialization operations taking place while negotiating a frame
size larger than allowed by standards.
21. The method of claim 20, wherein the connection initialization
operations specified by standards include FIP advertisement, FIP
solicitation, fabric login (FLOGI) and port login (PLOGI)
operations.
22. The method of claim 21, wherein the performance of connection
initialization operations specified by standards and the
negotiation of the frame size larger than allowed by standards
include sending one or more initialization frames specified by the
standards as being part of the connection initialization
operations, said frames including an additional field that is not
specified by standards, said additional field at least partially
defining a suggested frame size that is larger than allowed by
standards.
23. The method of claim 22, wherein the one or more initialization
frames include at least one of the group consisting of: an FIP
frame, a frame including a PLOGI request and a frame including a
PLOGI response.
24. The method of claim 22, wherein the suggested frame size that
is larger than allowed by standards is defined by defining a
suggested payload size larger than allowed by standards.
25. The method of claim 24, wherein the suggested payload size that
is larger than allowed by standards is defined by the use of the
additional field in conjunction with a conventional field, the
conventional field that is part of the frame, the conventional
field storing a payload size that is allowed by standards.
26. The method of claim 25, wherein the suggested payload size that
is larger than allowed by standards is defined in terms of a
predefined mathematical formula based on the values held in the
additional field and the conventional field.
27. The method of claim 26, wherein the additional field is
associated with a default value, the default value being a value
usually placed in that field by conventional devices, the
predefined mathematical formula being such that if the default
value is stored in the additional field, the predefined formula
results in a payload size that is equal to the payload size stored
by the conventional field.
28. A device connected to a network including a fabric, the device
including circuitry configured to: negotiate a frame size with a
second device and the fabric, the negotiated frame size being
larger than allowed by standards; and communicate with the second
device through the network using frames of the negotiated frame
size.
29. The device of claim 28, wherein the circuitry includes
application specific circuitry configured to perform the
negotiating and communicating steps.
30. The device of claim 28, wherein the device includes a generally
programmable processor and a memory including a plurality of
instructions, the instructions being executable at the processor
and configured to cause the processor to perform the negotiating
and communicating steps.
31. A device connected to a network including a fabric and
including: a processor; a memory connected to the processor and
including a plurality of computer executable instructions that are
executable at the processor; and a networking interface connected
to the processor and the network, wherein the computer executable
instructions, when executed at the processor, cause the processor
to negotiate a frame size with a second device and the fabric, the
negotiated frame size being larger than allowed by standards, and
communicate with the second device through the network using frames
of the negotiated frame size.
32. The device of claim 31, wherein the device is a computer.
33. The device of claim 31, wherein the device is a storage
device.
34. The storage device of claim 33, wherein the storage device is a
RAID array.
35. A network switch connected to a network and to first and second
devices through the network, the network switch being configured
to: negotiate a frame size with the first and second devices, the
negotiated frame size being larger than allowed by standards; and
forward communications between the first and second devices, the
communications including frames of the negotiated frame size.
36. A network switch connected to a network and to a first and
second devices through the network, the network switch including: a
processor; a memory connected to the processor and including a
plurality of computer executable instructions that are executable
at the processor; and a networking interface connected to the
processor and the network, wherein the computer executable
instructions, when executed at the processor, cause the processor
to negotiate a frame size with the first and second devices, the
negotiated frame size being larger than allowed by standards; and
forward communications between the first and second devices, the
communications including frames of the negotiated frame size.
37. A computer readable medium comprising a plurality of
instructions, the instructions being configured for execution at a
device connected to a network including a fabric, the instructions
being further configured to cause the device to perform a method
when executed at the device, the method comprising: negotiating a
frame size with a second device and the fabric, the negotiated
frame size being larger than allowed by standards; and
communicating with the second device through the network using
frames of the negotiated frame size.
38. A computer readable medium comprising a plurality of
instructions, the instructions being configured for execution at a
network switch connected to a network and to a first and second
devices through the network, the instructions being further
configured to cause the network switch to perform the following as
a result of execution of the instructions thereon: negotiate a
frame size with the first and second devices, the negotiated frame
size being larger than allowed by standards; and forward
communications between the first and second devices, the
communications including frames of the negotiated frame size.
39. The system of claim 1, wherein the network, the fabric, and the
standards are respectively a Fibre Channel over Ethernet (FCoE)
network, an FCoE fabric, and FCoE standards.
40. The system of claim 1, wherein the negotiated frame size is
larger than allowed by FC-BB-5 or comprises a payload size larger
than 2112 bytes.
41. The method of claim 6, wherein the network, the fabric, and the
standards are respectively a Fibre Channel over Ethernet (FCoE)
network, an FCoE fabric, and FCoE standards.
42. The method of claim 6, wherein the negotiated frame size is
larger than allowed by FC-BB-5 or comprises a payload size larger
than 2112 bytes.
43. The method of claim 17, wherein the network, the fabric, and
the standards are respectively a Fibre Channel over Ethernet (FCoE)
network, an FCoE fabric, and FCoE standards.
44. The method of claim 17, wherein the negotiated frame size is
larger than allowed by FC-BB-5 or comprises a payload size larger
than 2112 bytes.
45. The device of claim 28, wherein the network, the fabric, and
the standards are respectively a Fibre Channel over Ethernet (FCoE)
network, an FCoE fabric, and FCoE standards.
46. The device of claim 28, wherein the negotiated frame size is
larger than allowed by FC-BB-5 or comprises a payload size larger
than 2112 bytes.
47. The device of claim 31, wherein the network, the fabric, and
the standards are respectively a Fibre Channel over Ethernet (FCoE)
network, an FCoE fabric, and FCoE standards.
48. The device of claim 31, wherein the negotiated frame size is
larger than allowed by FC-BB-5 or comprises a payload size larger
than 2112 bytes.
49. The network switch of claim 35, wherein the network, the
fabric, and the standards are respectively a Fibre Channel over
Ethernet (FCoE) network, an FCoE fabric, and FCoE standards.
50. The network switch of claim 35, wherein the negotiated frame
size is larger than allowed by FC-BB-5 or comprises a payload size
larger than 2112 bytes.
51. The network switch of claim 36, wherein the network, the
fabric, and the standards are respectively a Fibre Channel over
Ethernet (FCoE) network, an FCoE fabric, and FCoE standards.
52. The network switch of claim 36, wherein the negotiated frame
size is larger than allowed by FC-BB-5 or comprises a payload size
larger than 2112 bytes.
53. The computer readable medium of 37, wherein the network, the
fabric, and the standards are respectively a Fibre Channel over
Ethernet (FCoE) network, an FCoE fabric, and FCoE standards.
54. The computer readable medium of 37, wherein the negotiated
frame size is larger than allowed by FC-BB-5 or comprises a payload
size larger than 2112 bytes.
55. The computer readable medium of 38, wherein the network, the
fabric, and the standards are respectively a Fibre Channel over
Ethernet (FCoE) network, an FCoE fabric, and FCoE standards.
56. The computer readable medium of 38, wherein the negotiated
frame size is larger than allowed by FC-BB-5 or comprises a payload
size larger than 2112 bytes.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. Patent
Application Ser. No. 12/269,716, filed Nov. 12, 2008, the entire
disclosure of which is incorporated herein by reference in its
entirety for all purposes.
FIELD OF THE INVENTION
[0002] This relates generally to frame size selection during
network communications and more specifically to performing FCoE
network communications by using frames that are larger than those
usually allowed by FCoE.
BACKGROUND OF THE INVENTION
[0003] Fibre Channel (FC) is a known networking protocol for high
speed communications. Ethernet is another known networking
protocol. As Ethernet networks have become faster and more capable
another known protocol--Fibre Channel over Ethernet (FCoE) has
emerged. FCoE is intended to allow FC-like communication over
Ethernet networks by tunneling FC frames over Ethernet. Due to
their high speed and reliability FC and FCoE are often used for
storage area networks (SANs).
[0004] Both Fibre Channel and Ethernet use frames for
communication. Frames are sets of data that are sequentially
transmitted that include one or more header and/or trailer fields
indicating various transmission related information (such as sender
and recipient identification, etc.) and a data or payload field
including the data that is actually being transmitted by the frame.
Fibre Channel allows for variable size frames, but currently limits
the data field of its frames to a maximum of 2112 bytes. This limit
is also preserved in the FCoE standard. However, the Ethernet
standard currently allows for larger frames, e.g., ones with frame
length of up to 9000 bytes (some implementations of Ethernet that
are not strictly standard compliant may allow for frames with frame
length of up to 12000 bytes).
[0005] Since FCoE is often used for storage networking and thus for
communications with storage devices, various sets of data that need
to be transferred over FCoE are often significantly larger than the
2112 byte limit to the data field of an FCoE frame. Therefore,
often multiple FCoE frames may need to be transmitted to perform a
requested data transfer (e.g. a hard drive write or read
operation). The use of large number of frames tends to increase
latency and/or the computational requirements at the devices that
transmit the frames, those that receive the frames as well as
intermediary devices that forward the frames over a network. Sender
devices must split data to be sent into multiple payloads for
multiple frames, construct each frame and place the proper headers
in it. Receiver devices must process the headers of each received
frame and recombine the multiple payloads of received frames in a
single data set. Intermediary devices (such as switches and
routers) may need to examine the headers of each received frame to
determine where to forward it to.
[0006] When to end devices set up a communication link over FC or
FCoE (as well as other protocols, such as Ethernet), they usually
negotiate a maximum frame size for the communications link. The
maximum frame size must be such that it can be handled by both end
devices, as well as any networking devices (e.g., hubs, switches,
routers, etc.) which are to transport the communications between
the two end devices over the network. The maximum frame size is
referred to as a maximum transfer unit (MTU). The process of
negotiating the maximum frame size is referred to as "path MTU
discovery" as it involves discovering the MTU for the entire path
of communication between the end devices. There exist path MTU
discovery protocols for existing FC and FCoE protocols, however
these protocols are limited to frames with maximum payload of 2112
bytes and cannot negotiate larger frames.
SUMMARY OF THE INVENTION
[0007] Embodiments of the invention relate to performing network
communications according to an existing protocol by using frames
that are larger than those usually allowed by the existing
protocol. Thus, embodiments of the present invention provide for an
extension of the existing protocol which allows for the use of
larger frames. Embodiments provide for use of various negotiation
and initialization mechanisms of the existing protocol with
additional modifications to allow for the negotiation of the use of
larger frames. Some embodiments ensure that the negotiations are
performed in such a manner that devices that feature the
improvements of the present invention can communicate with devices
that do not feature these improvements.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 is a diagram illustrating an exemplary FCoE network
according to embodiments of the invention.
[0009] FIG. 2 is a flowchart showing an exemplary method for
performing communications according to embodiments of the present
invention.
[0010] FIGS. 3A and B include another more detailed flowchart
showing an exemplary method for performing communications according
to embodiments of the present invention.
[0011] FIG. 4 is a diagram including an exemplary conventional FIP
frame and an exemplary FIP frame according to embodiments of the
invention.
[0012] FIG. 5 is a diagram including an exemplary conventional FCoE
frame and an exemplary FCoE frame according to embodiments of the
invention.
[0013] FIGS. 6A and 6B are diagrams showing exemplary communication
between two devices that illustrate some of the advantages of
embodiments of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] In the following description of preferred embodiments,
reference is made to the accompanying drawings which form a part
hereof, and in which it is shown by way of illustration specific
embodiments in which the invention can be practiced. It is to be
understood that other embodiments can be used and structural
changes can be made without departing from the scope of the
embodiments of this invention.
[0015] This relates to performing network communications according
to an existing protocol by using frames that are larger than those
usually allowed by the existing protocol. Thus, embodiments of the
present invention provide for an extension of the existing protocol
which allows for the use of larger frames. Embodiments provide for
use of various negotiation and initialization mechanisms of the
existing protocol with additional modifications to allow for the
negotiation of the use of larger frames. Some embodiments ensure
that the negotiations are performed in such a manner that devices
that feature the improvements of the present invention can
communicate with devices that do not feature these
improvements.
[0016] While embodiments of the invention are discussed herein in
conjunction with the FCoE protocol, they are not thus limited, but
may apply to extending any protocol that limits frame size to allow
for larger frames. Thus, embodiments of the present invention may
apply to other protocols (i.e., other than FCoE) that tunnel the FC
protocol over Ethernet, or protocols that tunnel the FC protocol
over other types of networks, or other protocols that may not even
be related to the FC protocol. The FCoE protocol may be any
protocol that is known in the art to as an FCoE protocol and
recognized by a person of skill in the art as applicable to the
present invention. An example FCoE protocol is the on defined by
the last draft of the FCoE standard developed and published by
Technical Committee T11 (or T11) of the International Committee for
Information Technology Standards (INCITS). The last draft noted
above is referred to as the FC-BB-5 draft. However, embodiments of
the present invention can also be applied to different
versions/drafts of the above standard or different FCoE
standards.
[0017] FIG. 1 is a diagram illustrating an exemplary FCoE network.
The FCoE network 100 may include one or more FCoE switches 108-111.
The FCoE switches may be together referred to as an FCoE fabric or
a fabric. The FCoE network may be built on or based on an Ethernet
network. Thus, the FCoE network may also include other elements
(not shown), such as Ethernet (i.e., not incorporating the complete
FCoE functionality or implementing partial FCoE functionality)
switches, hubs routers, etc. In some embodiments, the FCoE network
may be based on a standard Ethernet network. In other embodiments,
the FCoE network may be based on an enhanced version of Ethernet
such as, for example, converged enhanced Ethernet (CEE).
[0018] Various FCoE devices 101-107 can be connected to the FCoE
network. These may include initiators 103, 105 and 106 and targets
101, 102, 104 and 107. The initiators usually initiate
communications over FCoE with targets. The initiators can be
computers such as storage servers. The targets can be storage
devices, such as hard drives, RAID arrays, tape drives, solid state
storage devices, etc. However, this need not be the case. For
example, in some embodiments, a target may be a computer as well.
In some embodiments, a single device can act as an initiator and a
target in different communication sessions. Thus, in general,
devices 101-107 are FCoE capable electronic devices and need not be
storage devices and computers as shown in FIG. 1.
[0019] An initiator (such as initiator 105) can access a target
(such as target 101) through the FCoE fabric to read data and/or
store data. Again, in alternative embodiments, targets can be
accessed for entirely different reasons. If the communications are
performed according to the conventional FCoE protocol and
relatively large amount of data is transferred, the 2112 byte limit
on the data field of the conventional FCoE frame can, as discussed
above, cause the initiator, the target and the fabric to perform a
relatively high amount of processing in order to create, transmit
and receive a relatively high amount of frames. If, however, the
initiator, the target and the fabric are implemented according to
the present invention, they may be able to use larger frames and
thus can reduce the number of frames and amount of processing
required to transmit them.
[0020] FIG. 2 is a flow chart showing an exemplary general method
for communication according to embodiments of the present
invention. At step 200, the initiator, the target and the fabric
perform conventional initialization procedures according to the
underlying protocol used. In the present example, the underlying
protocol is FCoE. In step 202, the initiator, the target and the
fabric perform negotiation for defining a maximum extended frame
size to be used. The negotiations of step 202 are usually not
defined by the underlying protocol (e.g., FCoE) as they are
negotiations for frame size that may be larger than the maximum
allowed by the underlying protocol (e.g., 2112 bytes). At step 204,
it is determined whether extended frame size communication is
supported by all parties to the communication (i.e., the initiator,
the target and the fabric). This determination may be based on the
negotiations during step 202. If it is supported, communication
proceeds according to the extended frame size negotiated in step
202. If one or more of the initiator, target and fabric do not
support the extended frame size, then communications continue
according a conventional frame size determined during the
conventional initialization procedure performed in step 200 (step
208).
[0021] Thus, embodiments of the invention may allow for the use of
higher frame size when possible (i.e., when all parties to the
communication implement the present invention) but may revert to
conventional communication when necessary (i.e., when legacy
devices that do not implement the present invention are
present).
[0022] In some embodiments, the two steps of initialization 200 and
202 may be combined. Thus, devices and the fabric may negotiate for
the extended frame size while performing conventional negotiation
and initialization according to the underlying protocol. A
particular embodiment of this type is described in more detail
below with reference to FIGS. 3A and B.
[0023] At step 300 of FIG. 3A, the FCoE fabric sends an
initialization FIP frame to all connected devices. The term "FIP"
refers to FCoE initialization protocol. FIP is a known protocol
generally used in conventional FCoE networks in order to initialize
connections. The FIP protocol is usually performed by sending and
receiving FIP frames as defined by the protocol. These FIP frames
may correspond to or include a FIP advertisement, FIP solicitation,
fabric login (or FLOGI) request or response as defined by the FC
protocol.
[0024] FIG. 4 shows a couple of exemplary FIP frames. Frame 400 is
a conventional FIP frame, while frame 401 is an FIP frame modified
according to embodiments of the invention. Fields 402-406 of both
frames are known and defined by the existing FIP standard (as well
as by the Ethernet standard). The descriptor lists 404 of both
frames include various initialization information including a field
specifying the payload size a device that sends the FIP frame is
capable of handling. This latter field indicates a conventional
payload size, or a payload size according to the existing FCoE
protocol. Thus, the value held by this field may be referred to as
ConvPyLdSize. Devices that can handle extended size frames
according to embodiments of the present invention may be able to
handle payload sizes larger than those indicated by the
ConvPyLdSize value they place in their FIP frames as discussed in
more detail below.
[0025] The main difference of the new FIP frame 401 from frame 400
is that it includes some additional header definitions in FIP
header field 403. In this embodiment, the FIP frame includes a
receive multiplier field 407 which is not present in frame 400. The
receive multiplier field can be used to indicate an extended
payload size, as discussed below in more detail. In the presently
discussed example, the received multiplier field is two bits long;
however, this is not required for all embodiments.
[0026] The receive multiplier field can be positioned in such a
manner in the FIP header, so that conventional devices that do not
implement and are not aware of the present invention will always
create FIP frames that include a known string, such as a set of
zeroes ("0,0") as the receive multiplier field. As the FIP protocol
requires that unused space in the FIP header must be set to "0",
the above can be achieved by simply defining the receive multiplier
field as comprising bits that are not used by the conventional FIP
header.
[0027] Referring back to FIG. 3A, the initialization FIP frame sent
by the FCoE fabric in step 300 may include (1,1) as its receive
multiplier field. When sent to all devices as FIP advertisement or
solicitation, or when sent as a FIP solicitation frame to a
specific device, this frame may indicate to devices implementing
the present invention that the FCoE fabric and/or the FCOE first
and second devices implement the present invention. Conventional
FCoE devices that do not implement the present invention ignore the
additionally defined fields of the FIP frame.
[0028] If a device that implements the present invention (e.g.,
initiator 105 or target 101 of FIG. 1) wishes to communicate over
the FCoE network 100, then the device may login to the FCoE fabric
100 (step 302). The device may login to the fabric according to the
FIP protocol by sending the fabric an FIP frame that represents a
FLOGI request. However, in addition to the usual information
required by the FIP protocol, the FIP frame of step 302 can include
an additional value in the receive multiplier field which indicates
the size of an extended frame the device may be capable of
handling. More specifically, the receive multiplier of the FIP
frame may include one of the following three sets of bits--(0,0),
(0,1) or (1,0). The size of an extended frame the device can handle
can be defined in terms of the size of an extended payload in the
extended frame by the following equation:
ExtPyLdSize=2.sup.RMConvPyLdSize, (1)
where the ExtPyLdSize indicates the extended payload size the
device is capable of handling and ConvPyLdSize indicates the
payload size the device conventionally advertises as being able to
handle in the FIP frame. RM is the binary value of the receive
multiplier field of the new FIP frame 401.
[0029] Thus, for example, if a device can handle an extended
payload of 4224 bytes, it can send out an FIP frame that indicates
the maximum ConvPyLdSize of 2112, and a receive multiplier of
(0,1), or 1 in decimal. Equation (1) would result in an extended
payload size of 4224. In another example if a device can handle an
extended payload of 8448 bytes, it can send an FIP frame that again
indicates the maximum ConvPyLdSize of 2112 but includes an RM value
of (1,0) or 2 in decimal. In this case, Eq. (1) would result in
8448 bytes.
[0030] It should be noted that in the presently discussed
embodiments, the maximum extended payload size is 8448 because, as
discussed above, only values of (0,0), (0,1) and (1,0) are allowed
for the receive multiplier field during step 302. This may be
sufficient for some FCoE embodiments, because FCoE uses Ethernet
frames and the frame length of the Ethernet frames is limited to
9000 bytes. Thus, FCoE cannot exceed this limit unless the Ethernet
standard is modified to include larger frames as well. Alternative
embodiments may feature larger extended payload sizes.
[0031] Furthermore, while the above examples show the extended
payload size defined by a FIP frame being varied by solely varying
the RM value, this need not be the case. For example, if a device
can handle an extended payload size of 4000 bytes, it can indicate
that by setting the ConvPyLdSize value to 2000 and the RM value to
(0,1).
[0032] At step 304, the fabric responds to the device's login by
sending an FIP frame to the device as an acknowledgement. The FIP
frame sent by the fabric can include a negotiated extended payload
size. The negotiated extended payload size can be the smaller of
the payload size sent by the device in step 302 and the largest
payload size that the fabric can handle. Thus, the negotiated
payload size is a payload size that can be handled by both the
device and the fabric. The FIP frame sent by the fabric may also
include other conventional data as specified by the existing FCoE
protocol.
[0033] Steps 302 and 304 can be performed by all devices connected
to the FCoE network 100 that implement an embodiment of the present
invention and wish to communicate over the FCoE network. Thus,
these steps can be performed by both targets and initiators. After
steps 302 and 304 are performed by a plurality of devices, there
may exist one or more negotiated extended payload sizes
corresponding to different devices and their respective
negotiations with the fabric in steps 302 and 304.
[0034] It should be noted that during steps 302 and 304 negotiation
as to the size of the extended frame is performed while
simultaneously performing conventional initialization and
negotiation according to the existing FCoE protocol. Accordingly,
the FIP frames being transmitted during steps 302 and 304 include
both conventional initialization information as defined by the FCoE
protocol and information as to the size of the extended frame as
required by embodiments of the present invention. Thus, FIG. 3
shows an example in which the steps 200 and 202 of FIG. 2 are
performed simultaneously.
[0035] According to the FC and FCoE protocols, if an initiator
wishes to communicate with a target after the initial fabric login,
it logs into the target itself. This is referred to as port login.
According to the FCoE protocol, an initiator performs a port login
by sending a predefined type of FCoE frame. The type of FCoE frame
may include or be analogous to a port login (PLOGI) request in the
FC protocol.
[0036] FIG. 5 is a diagram showing a conventional FCoE frame 500
and an FCoE frame according to embodiments of the present invention
501. Frames 500 and 501 can be frames that include PLOGI requests
as discussed above. Fields 502-508 are known and defined in the
FCoE and/or Ethernet standards. The major difference between the
two frames is that new frame 501 includes an additional field
within the FCoE headers field 503. This is again the receive
multiplier or RM field 509. The RM field can be similar to that of
the FIP frame 401. More specifically, it can be made of two bits
and can be positioned in such a manner so that for conventional
FCoE frames (such as frame 500) the values associated with the RM
field are always zero. As noted above, in other embodiments the RM
field can be of different size. Furthermore, a conventional payload
size value ConvPyLdSize can be stored in the FC Header field 504 of
the FCoE frame.
[0037] Referring back to FIG. 3A, in step 306, an initiator that
implements the invention (such as initiator 105 of FIG. 5) and
needs to communicate with a target (such as target 101) sends an
FCoE frame to the target. The FCoE frame is a PLOGI FCoE frame or,
in other words, it is an FCoE frame that includes a PLOGI request.
The FCoE frame is addressed to the target but is initially sent to
the FCoE fabric which is to forward it to the target.
[0038] The PLOGI FCoE frame includes frame size information (or,
more accurately, payload size information) indicating a suggested
extended payload size. The suggested extended payload size can be,
for example, the payload size that was negotiated for the initiator
in steps 302 and 304. However, in certain circumstances, the
initiator can suggest a smaller payload size than the one
negotiated in steps 302 and 204 in frame 306. For example, the
initiator may determine that a smaller payload size may be
preferable for the communications that are being initiated.
[0039] The extended payload size can be defined in the PLOGI FCoE
frame based on the RM bits and the conventional payload size
(ConvPyLdSize) stored in that frame. These values can be inserted
in Equation (1) above to arrive at the extended payload size. Thus,
the extended payload size can be encoded in an FCoE frame in a
manner similar to its encoding in an FIP frame discussed above.
[0040] In step 308 of FIG. 3A, the fabric forwards the PLOGI FCoE
frame received from the initiator to the target specified in that
frame. Before forwarding, the fabric may optionally reduce the
payload size indicated in the PLOGI FCoE frame to match the maximum
payload size negotiated between the fabric and the target in steps
302 and 304. Thus, for example, the initiator and the fabric may
negotiate the maximum payload size of 8448 during steps 302 and 304
and the target may negotiate a smaller payload size of 4224 with
the fabric during its own iteration of steps 302 and 304. If then
the initiator sends a PLOGI FCoE frame indicating a payload size of
8448 to the fabric, the fabric may note that the target negotiated
a smaller size of 4224 (indicating that is the maximum size the
target can handle for communications through the fabric), and may
as a result reduce the payload size indicated by the PLOGI FCoE
frame before forwarding that frame to the target.
[0041] In step 310 of FIG. 3B, the target has received the PLOGI
FCoE frame and sends an FCoE frame in response to the PLOGI FCoE
frame. The response frame may include a response to the PLOGI
request defined by the received PLOGI FCoE frame. The response
frame may be an FCoE frame composed in accordance with existing
FCoE protocols and may include a PLOGI response (or
acknowledgement) that is in accordance with existing Fibre Channel
protocols.
[0042] However, the response or acknowledgement FCoE frame may
include additional information defining a suggested buffer size.
The suggested buffer size may be defined in a manner similar to
that used by the PLOGI FCoE frame of step 306. Thus, the response
FCoE frame may include an RM value and a ConvPyLdSize value which
together may define the suggested buffer size according to Equation
(1) above.
[0043] The response FCoE frame may define the same suggested pay
load size value as the one defined by the PLOGI FCoE frame received
by the target. However, if the target, for various reasons wishes
to use a smaller pay load size, it can define a smaller suggested
buffer size in the response FCoE frame. Reasons for using a smaller
buffer size may include, for example, temporary inability to use a
larger buffer due to a temporary lack of resources.
[0044] In step 312, the fabric forwards the response FCoE frame to
the initiator (said frame having been addressed to the initiator by
the target). In step 314, the initiator receives the response FCoE
frame and begins communications using the buffer size specified by
the response FCoE frame. These communications can include, for
example, a request to read and/or write data from/to a storage
drive. The target can respond using the same buffer size. Thus, the
buffer size included in the response FCoE frame can be considered
to be a final negotiated buffer size. Communications can continue
using that buffer size as long as the logical connection between
the initiator and the target persists. Once the connection is torn
down, a new connection may be set up (by having the initiator issue
a new PLOGI FCoE frame) and a new extended buffer size can be
negotiated when setting up the new connection.
[0045] Thus, the process of steps 302-314 simultaneously performs
two functions--it sets up an FCoE connection between the target and
the initiator according to known FCoE protocols and at the same
time it negotiates an extended frame size (or extended buffer size)
in accordance with embodiments of the present invention.
[0046] Furthermore, some embodiments of the invention ensure that
the process of negotiation is transparent to legacy devices that do
not feature the present invention and that it defaults to buffer
sizes that are safe for such legacy devices when such devices are
present. Thus, for example, the embodiment discussed above
partially stored the extended buffer size in the RM field. The RM
field may be specifically placed in an area of the FCoE frame that
is known to always store `0`s for legacy devices. Thus, when
setting up a connection, a legacy device will always issue FCoE
frames with RM field of 0, which, according to Equation (1), would
make the suggested size equal to the ConvPyLdSize specified by the
frame. Thus, the legacy device will always suggest using the
conventional pay load size, or the pay load size as defined by
conventional protocols. Other devices will not exceed that size,
even if they do implement the present invention, and will thus
operate according to the conventional protocols when communicating
with a conventional device. Thus, embodiments of the present
invention are compatible with legacy devices that may not implement
the present invention. This is true for legacy end devices (i.e.,
initiators and targets), as well as for devices that are part of
the fabric (i.e., FCoE switches, routers, etc.)
[0047] But when two communicating devices and the fabric do
implement the present invention, they can communicate using much
higher payload sizes than previously possible under the FCoE
protocol and can thus reduce network overhead, reduce latency and
improve throughput speeds.
[0048] FIGS. 6A and 6B are diagrams showing communication between
two devices that illustrate some of the advantages of embodiments
of the present invention. More specifically, FIG. 6A shows
conventional communication between conventional FCoE devices 601
and 602. This communication may require four data frames 603 with
payload of 2112 each to perform a single exemplary read command.
FIG. 6B, on the other hand, illustrates communication according to
embodiments of the present invention between devices 604 and 605
that implement such embodiments. In the communication of FIG. 6B, a
single data frame 606 with a payload of 8448 may be used to perform
the same exemplary read command. As noted above, this can reduce
network processing overhead and improve networking performance.
[0049] It should be noted that FIGS. 6A and 6B do not show the
fabric or various frames that are exchanged when setting up the
connection.
[0050] While the above discussed embodiments provide for initiator
to target frame size negotiation, this need not be the case. Some
more advanced embodiments of the invention may include aggregator
switches in the fabric that may allow two end devices to
communicate using different frame (or pay load) sizes. For example,
a first device using a pay load size of 8448 bytes can communicate
with a second device using a payload size of 2112 bytes. The
aggregator switch may split frames originating from the first
device into multiple frames with smaller payload sizes and send
them to the second device. Similarly, the aggregator switch may
combine frames originating from the second device into fewer frames
with larger payloads and send these to the first device. The
aggregator switch may also pad payloads as needed to get the
correct payload sizes.
[0051] In some embodiments, the aggregator switch can be
transparent to the end devices. In other words, the aggregator
switch may behave in such a manner that it appears to each end
devices that it is communicating with a compatible device and there
is no mismatch of payload sizes. Thus, the aggregator switch may be
configured to modify the suggested payload sizes passed between the
two end devices during the initialization process of FIGS. 3A and
3B so that each end device believes it is communicating with
another device that is capable of handling the same payload size as
it.
[0052] An aggregator switch may be especially useful when combining
an FCoE fabric that implements the present invention with one that
does not. Thus, the aggregator switch can allow the benefits of the
present invention to be better utilized in that situation instead
of having various devices that implement the invention default to
low payload sizes when communicating with conventional devices.
[0053] Furthermore, the aggregator switch may be useful when
connecting an FCoE network that implements embodiments of the
invention with an FC network that does not. Thus, the aggregator
switch functionality may be built into an FCoE/FC bridge.
[0054] The discussion above mentions various devices such as
computers, storage drives, initiators, targets and switches (e.g.,
the switches that form the fabric). Exemplary behavior and actions
of these devices are discussed. The devices may be designed to
perform such behavior in one or more ways known in the art. For
example, one or more of the devices may include one or more
processors. Each processor can be a central processing unit (CPU),
an embedded processor, a digital signal processor, a controller,
etc. Each of the processors may be connected to a computer readable
medium, such as a memory or a storage medium. The memory can be,
for example RAM, ROM, EPROM, FLASH, etc. The storage medium can be
a hard drive, a disk drive, a tape drive, a flash drive, an optical
drive. The storage medium may include software or firmware
comprising instructions executable by the processor. The processor
may execute the instructions to allow the device to perform the
functions discussed above as well as other functions. Alternatively
or in addition, some or all of the functions of the device can be
performed by application specific circuitry instead of a
programmable processor.
[0055] The functionality discussed above can be performed by the
main CPU of a device (if the device includes one), or by a
secondary processor or logic of the device. For example, if one of
the devices discussed above is a computer, the functionality
discussed above can be performed by the main CPU of the computer,
or by a controller of a host bus adapter (HBA) or network interface
card (NIC) of the computer.
[0056] Embodiments above are discussed in terms of controlling or
modifying the payload size of various frames. It is noted that
since the payload is part of the frame, the payload directly
affects the frame size. Thus controlling or modifying the payload
of a frame results in controlling and modifying the frame size of
the frame. Therefore, controlling and modifying the payload can be
considered a special case for controlling and modifying the frame
size. While some embodiments control the frame size by controlling
the payload size (as discussed above), other embodiments may
control the frame size directly, i.e., by directly referring to a
frame size during initialization, instead of only referring to a
payload size.
[0057] A person of skill in the art would recognize that various
variations of embodiments discussed above can be made. For example,
the negotiation process of FIGS. 3A and 3B can be modified. The way
the extended payload size is defined in various frames can also be
modified. Furthermore, as noted above, embodiments of the invention
are not only limited to FCoE and can be used in conjunction with
various other networking protocols.
[0058] Although embodiments of this invention have been fully
described with reference to the accompanying drawings, it is to be
noted that various changes and modifications will become apparent
to those skilled in the art. Such changes and modifications are to
be understood as being included within the scope of embodiments of
this invention as defined by the appended claims.
* * * * *