US20020191640A1 - Multi-protocol agile framer - Google Patents

Multi-protocol agile framer Download PDF

Info

Publication number
US20020191640A1
US20020191640A1 US10/153,321 US15332102A US2002191640A1 US 20020191640 A1 US20020191640 A1 US 20020191640A1 US 15332102 A US15332102 A US 15332102A US 2002191640 A1 US2002191640 A1 US 2002191640A1
Authority
US
United States
Prior art keywords
data
data stream
framing
protocol
source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/153,321
Other versions
US6654383B2 (en
Inventor
Charles Haymes
Mark Ritter
Thomas Rower
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US10/153,321 priority Critical patent/US6654383B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HAYMES, CHARLES LOUIS, RITTER, MARK B., ROWER, THOMAS
Publication of US20020191640A1 publication Critical patent/US20020191640A1/en
Application granted granted Critical
Publication of US6654383B2 publication Critical patent/US6654383B2/en
Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTERNATIONAL BUSINESS MACHINES CORPORATION
Assigned to GOOGLE LLC reassignment GOOGLE LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: GOOGLE INC.
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0602Systems characterised by the synchronising information used
    • H04J3/0605Special codes used as synchronising signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J3/00Time-division multiplex systems
    • H04J3/02Details
    • H04J3/06Synchronising arrangements
    • H04J3/0602Systems characterised by the synchronising information used
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04JMULTIPLEX COMMUNICATION
    • H04J2203/00Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
    • H04J2203/0089Multiplexing, e.g. coding, scrambling, SONET
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities

Definitions

  • the present invention relates generally to data transmission systems, and more particularly relates to a data framer that is capable of automatically supporting two or more data framing protocols.
  • data communication protocols for transferring information between a source and a destination over a communication network, typically employ a framing architecture for synchronizing data between the source and destination.
  • a data frame may be divided into various sections, including a message section and an information section (e.g., framing data) associated with the message section which is used, for example, to identify the frame boundaries and maintain the communication network path.
  • the information section typically resides in a header and/or a trailer portion of the data frame.
  • Different data communication protocols often utilize different frame organizations for sending data over the communication network.
  • a data framer is a device which generally functions in a data link layer of a data transmission system.
  • the framer searches an incoming data stream for a data frame of a preset format or protocol. Once the frame boundaries have been identified using the preset protocol, valid user data is located within the frame by subsequent processing stages.
  • the framer organizes the user data into a frame corresponding to the preset protocol for transmission over the communication network.
  • Conventional framers are generally capable of processing only a single framing protocol. Since the conventional framer conducts all functions specifically for a selected protocol, received data streams that do not match the selected protocol will not be identified as valid. Likewise, transmitted data streams will only be framed in accordance with the single selected protocol. Additionally, there often exist variants of a given protocol for different data transmission rates. Framers are typically optimized for a targeted data rate. Thus, when the data rate changes, the framer settings must typically be manually modified to correspond to the selected protocol at the desired data rate.
  • the present invention provides techniques for forming a multi-protocol framer for use, for example, in a data transmission system.
  • the multi-protocol framer is capable of automatically detecting a particular data transfer protocol in an input data stream received from a transmission medium, such as, for example, a fiber optic network. Once the particular protocol has been detected by the framer, the framer is configured to extract valid data from the input data stream and/or frame valid data for transfer over the transmission medium according to the detected protocol.
  • a data framer may be provided that is not only capable of automatically handling multiple data transfer protocols, but eliminates the need for knowing the protocol type a priori.
  • Each of the framing circuits is configured to extract user data from the source data stream in accordance with a different data framing protocol associated with the respective framing circuit.
  • the controller is operative to: (i) receive the source data stream and automatically determine which of the at least two different data framing protocols corresponds to the source data stream; and (ii) route the source data stream to one of the first framing circuit and the second framing circuit in response to a match between the determined data framing protocol of the source data stream and one of the first and second data framing protocols.
  • FIG. 1 is a block diagram illustrating a system integration of the multi-protocol agile framer, in accordance with the present invention.
  • FIG. 2 is a block diagram illustrating a receive side multi-protocol framer, formed in accordance with one aspect of the present invention.
  • FIG. 3 is a block diagram illustrating an exemplary decision tree utilized by the illustrative multi-protocol framer of FIG. 2 for determining the protocol of the incoming data stream, in accordance with the present invention.
  • FIG. 4 is a block diagram illustrating a transmit side multi-protocol framer, formed in accordance with the present invention.
  • FIG. 5 is a block diagram illustrating a generalized data processing system for implementing the methodologies of the present invention.
  • the present invention provides techniques for forming a multi-protocol framer.
  • the multi-protocol framer is described herein with specific reference to synchronous optical network (SONET)/synchronous digital hierarchy (SDH), Ethernet wide area network (WAN), Ethernet local area network (LAN), Fibre Channel WAN, and Fibre Channel LAN protocols for transferring data over a fiber optic network. It is to be appreciated, however, that the present invention is not limited to these or any particular data transmission protocols and/or communication mediums.
  • LAN protocol standards may be found, for example, in International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) documents TR 8802-1:2001, ISO/IEC 10038-1993, Institute of Electrical and Electronics Engineers (IEEE) document 802.7-1989 and IEEE 802.1q-1998, which are incorporated herein by reference.
  • ISO International Organization for Standardization
  • ISO International Electrotechnical Commission
  • IEEE Institute of Electrical and Electronics Engineers
  • the present invention provides techniques for automatically detecting the protocol of a received input data stream and locking to the framing architecture used by this protocol. Once the protocol has been determined on the receive side of the framer, the transmit side of the framer can be automatically set to correspond to the detected protocol. In this manner, a framer formed in accordance with the present invention is able to advantageously determine its own functionality without manual interaction.
  • the data framer of the present invention may provide the ability to change the data framing protocol in response to a user-selectable control signal.
  • FIG. 1 illustrates an exemplary data transmission system, formed in accordance with the present invention.
  • the illustrative data transmission system 100 preferably includes clock and data recovery (CDR) circuitry 102 , a pair of multi-protocol agile framers 104 and 106 , a pair of media access controllers (MACs) 112 and 114 , and a switcher/router 116 .
  • the CDR circuitry 102 is coupled to a transmission medium, such as, for example, a fiber optic network 118 for transferring data.
  • the CDR circuitry 102 functions, at least in part, to operatively serialize and/or deserialize the incoming or outgoing data stream, respectively.
  • one of the framers 104 is operatively configured to receive an input data stream 120 from the CDR circuitry 102 .
  • the input data stream 120 may comprise data frames of one of a plurality of undetermined protocols.
  • another of the framers 106 is operatively configured to send an output data stream 122 to the CDR circuitry 102 .
  • the output data stream 122 may comprise data frames of one of a plurality of protocols, and is preferably matched to the protocol of the input data stream.
  • One the receive-side, multi-protocol framer 104 is preferably configured to automatically detect the protocol of the input data stream 120 and extract valid data therefrom. Once the protocol has been determined, valid data can be easily located within a given frame corresponding to the detected protocol.
  • framer 104 includes a first output 124 for providing SONET/SDH-type data to the switcher/router 116 for transmission.
  • Framer 104 also preferably includes a second output 130 for providing Ethernet/Fibre Channel-type data to the media access controller (MAC) 112 , which is operatively coupled to the switcher/router 116 .
  • the MAC 112 functions, at least in part, to evaluate switch routing in the system.
  • multi-protocol framer 106 is preferably configured to receive either SONET/SDH-type data 126 directly from the switcher/router 116 or receive Ethernet/Fibre Channel-type data 128 from the switcher/router 116 via MAC 114 .
  • the data received from the switcher/router 116 is preferably framed by the transmit-side multi-protocol framer 106 using the protocol detected by the receive-side multi-protocol framer 104 .
  • the framed data is then sent to the CDR circuitry 102 as an output data stream 122 for transferring data to a destination via the fiber optic network 118 .
  • the multi-protocol framer 200 is preferably organized into several functional blocks for ease of explanation, including a Protocol Lock and Frame Synchronization Engine 202 , a SONET/SDH framing block 204 and an Ethernet/Fibre Channel framing block 208 . It is to be appreciated that each of these functional blocks may be implemented by individual circuitry corresponding thereto, such as, for example, a digital signal processor (DSP) or alternative processing device. Alternatively, a single circuit may be used to implement more than one functional block. Moreover, the present invention contemplates that one or more functional blocks associated with the framer may be implemented in software running on a processor, hardware, or a combination of software and hardware, as will be understood by those skilled in the art.
  • DSP digital signal processor
  • the Protocol Lock and Frame Synchronization Engine 202 preferably receives an input data stream 226 presented thereto, for example, from a fiber optic network, and searches for a frame synchronization pattern in the input data stream.
  • the data stream may include framing bytes A 1 and A 2 , which indicate the beginning of a synchronous transport signal (STS) frame.
  • STS synchronous transport signal
  • the data stream may include a 01/10 bit sequence every 66 bits, indicating the beginning of a LAN-type data frame.
  • the Protocol Lock and Frame Synchronization Engine 202 preferably includes two or more state machines 210 and 212 , each of the state machines 210 , 212 being configured to operatively detect a different predetermined protocol in the input data stream 226 .
  • the present invention contemplates that additional state machines (not shown) may be added to the Protocol Lock and Frame Synchronization Engine 202 for detecting additional data transfer protocols corresponding thereto in the input data stream, thus expanding the protocol detection capability of the framer.
  • the state machines 210 , 212 preferably each receive the input data stream 226 and operate substantially in parallel, to essentially scan the input data stream and detect a data frame in accordance with predefined protocol standards associated therewith. By operating in parallel, the state machines 210 , 212 are able to detect an undetermined protocol in the input data stream more quickly. Therefore, the speed of a data framer formed in accordance with the present invention is significantly improved.
  • that state machine may be referred to as being in an “in-frame” or “lock” condition, and the other state machine(s) may be disabled or otherwise shut off until the in-frame condition has ended. By disabling the unused state machine(s), power consumption in the framer may be reduced.
  • state machine 210 When the Protocol Lock and Frame Synchronization Engine 202 identifies the input data stream as being a WAN-type protocol, state machine 210 , which is used in this instance for detecting a WAN-type protocol in the data stream 226 , preferably generates a control signal indicating that it is in an in-frame condition.
  • the in-frame control signal generated by state machine 210 may be used to operatively disable state machine 212 and/or transfer the input data stream to subsequent processing circuitry associated with state machine 210 .
  • the in-frame state machine e.g., 210
  • the in-frame state machine e.g., 210
  • the in-frame state machine preferably continues to periodically monitor the input data stream 226 to determine whether the in-frame condition still exists.
  • State machine 210 transfers the input data stream, which has been previously identified as being a WAN-type protocol, to the SONET/SDH framing block 204 via line 214 .
  • the SONET/SDH framing block 204 preferably determines whether the incoming data stream is a SONET/SDH protocol or a WAN interface sublayer (WIS) protocol, defined by the SONET/SDH standard and WIS standard (e.g., ANSI T1.416-1999, which is incorporated herein by reference), respectively, as known by those skilled in the art.
  • WIS WAN interface sublayer
  • WIS standard e.g., ANSI T1.416-1999, which is incorporated herein by reference
  • the SONET/SDH framing block 204 may operatively detect certain overhead bytes which are utilized in the SONET/SDH protocol, but which are unused and set to a particular logic level, such as, for example, logic zero, in the WIS protocol. It is to be appreciated that alternative techniques for identifying a particular protocol or differentiating between two or more protocols in the input data stream may be employed, in accordance with the invention.
  • the SONET/SDH framing block 204 When the incoming data stream 214 to the SONET/SDH framing block 204 is determined to be a purely SONET/SDH protocol, the SONET/SDH framing block 204 preferably transfers the data stream directly to subsequent processing circuitry (e.g., switcher/router 116 in FIG. 1), for example, via line 222 .
  • a WIS block 228 included in the SONET/SDH framing block 204 preferably transfers the data stream to state machine 212 via line 218 for further processing. Since a WIS frame essentially contains a plurality of Ethernet/Fibre Channel frames, the WIS data stream 218 can be further processed in accordance with a LAN-type protocol.
  • state machine 212 When the Protocol Lock and Frame Synchronization Engine 202 identifies the input data stream 226 as being a LAN-type protocol, state machine 212 preferably generates an in-frame control signal.
  • the in-frame control signal generated by state machine 212 may be used in a manner consistent with state machine 210 , as previously described, to operatively disable state machine 210 , along with any unused circuitry associated therewith (e.g., SONET/SDH framing block 204 ), and/or route the data stream to subsequent processing circuitry associated with state machine 212 .
  • the in-frame state machine e.g., 212
  • the in-frame state machine preferably continues to periodically monitor the data stream to determine whether the in-frame condition still exists.
  • State machine 212 operatively routes the data stream, which has already been determined to be a LAN-type protocol, to a scrambler/descrambler 206 included in the Ethernet/Fibre Channel framing block 208 .
  • the scrambler/descrambler 206 is preferably configured to extract payload and overhead fields within the incoming frame which has been previously scrambled in order to provide sufficient bit transitions (e.g., zero-to-one or one-to-zero) in the data stream.
  • the data stream in fiber optic systems employing a receiver phase lock loop, the data stream must generally be encoded to include a predetermined number of bit transitions in order to allow the receiver phase lock loop to recover a clock signal from the received data with low jitter.
  • the WIS data stream 218 can be further processed by the Ethernet/Fibre Channel framing block 208 .
  • the scrambler/descrambler 206 may additionally provide data encoding/decoding for error detection and/or correction purposes. For example, in a LAN-type protocol, for every 66 bits of data received there is only 64 bits of real data.
  • the descrambler is preferably configured to transpose the 66-bit data stream 216 into a 64-bit data stream 224 (e.g., using a 66-bit/64-bit decoder).
  • the Ethernet/Fibre Channel framing block 208 preferably determines whether the incoming data stream 216 is an Ethernet protocol or a Fibre Channel protocol, as defined by the Ethernet and Fibre Channel standards, respectively.
  • the Ethernet/Fibre Channel framing block 208 may be configured to differentiate between Ethernet and Fibre Channel protocols using various techniques, such as, for example, ordered set signaling, start-of-file (SOF) and end-of-file (EOF) recognition, and open fiber control (OFC) signaling, as will be explained in further detail below.
  • SOF start-of-file
  • EEF end-of-file
  • OFC open fiber control
  • ordered sets in the context of a Fibre Channel protocol, are four-byte transmission words containing data and special characters as a first transmission character.
  • An ordered set may be, for example, a frame delimiter, a primitive signal, or a primitive sequence. Ordered sets are used, at least in part, to distinguish Fibre Channel control information from data and provide the availability to obtain bit and word synchronization, which also establishes word boundary alignment.
  • Frame signaling (FSIG) in accordance with IEEE Standard 802.3ae is used to signal an ordered set of Fibre Channel code, and always begins with special character K28.2.
  • the special character K28.2 in the byte 0 position of the ordered set will always indicate Fibre Channel ordered set data, such as, for example, K28.2-Dx1.y1-Dx2.y2-Dx3.y3, and is then translated back into the proper Fibre Channel ordered set, for example, K28.5-Dx1.y1-Dx2.y2-Dx3.y3.
  • Fibre Channel utilizes specific ordered sets for both SOF and EOF.
  • Ethernet utilizes only a single control character for SOF and EOF.
  • the control characters for delimiters SOF and EOF will always reside in the same byte position. In the Ethernet protocol, however, only the SOF character resides in the same byte position, and the EOF character may reside in any byte position.
  • the bytes exiting a 66-bit/64-bit decoder (not shown) residing in Ethernet/Fibre Channel framing block 208 are preferably compared with expected SOF and/or EOF characters specific to the Ethernet protocol and the Fibre Channel protocol substantially simultaneously.
  • a state machine included in the Ethernet/Fibre Channel framing block 208 preferably begins counting data packets with proper SOF and EOF termination up to a user-definable count to assure no chance of false Fibre Channel detection.
  • Ethernet data is presumed.
  • an Ethernet-specific state machine preferably searches for SOF characters in the proper byte location and begins counting properly formatted Ethernet packets up to a user-definable maximum count.
  • the present invention preferably utilizes the above-described maximum count to provide hysteresis in the protocol determination process, such that the framer is less susceptible to “glitches” caused by single packet errors in the data stream, and/or other anomalies.
  • a “valid packet” counter (not shown) may be included in the Ethernet/Fibre Channel framing block 208 .
  • the valid packet counter may be initialized to a predetermined count.
  • the count associated with the valid packet counter is either incremented or decremented by one such that a single packet error does not cause the Ethernet/Fibre Channel determination process to undesirably “glitch” or switch to using another protocol.
  • a comparator (not shown) may be used in conjunction with the valid packet counter for comparing the counter value with a predetermined count value in order to determine whether the protocol should be changed (e.g., an unacceptable number of packet errors were detected), as will be understood by those skilled in the art. If no protocol is found which provides a sufficiently low error rate, the framer may, in accordance with the invention, indicate a loss of link (LOL) in a manner determined by the standard associated with the particular protocol or by the user.
  • LOL loss of link
  • the Ethernet/Fibre Channel framing block 208 may first look for an Ethernet protocol, rather than a Fibre Channel protocol. To accomplish this, the Ethernet/Fibre Channel framing block 208 may be configured to detect the variable EOF control character location. Alternatively, SOF and Ethernet preamble characters may be used to define a unique pseudo-ordered set which is different from the SOF ordered set definitions corresponding to a Fibre Channel protocol.
  • An OFC signaling technique may also be utilized in accordance with the present invention to discriminate between an Ethernet protocol and a Fibre Channel protocol, as previously stated.
  • the OFC signaling technique which may be employed in the CDR circuitry 102 of the data transfer system 100 (see FIG. 1), relies on OFC employed in setting up 850 nanometer (nm) wavelength division multiplexing (WDM) Fibre Channel links for transporting several data streams over a single fiber.
  • WDM wavelength division multiplexing
  • Fibre Channel links may employ a signal generated by high-speed front-end circuitry which is processed by OFC circuitry in the CDR circuitry 102 to generate a laser enable signal (e.g., Laser_En).
  • a laser enable signal e.g., Laser_En
  • the laser enable signal may be a high logic level when the high-speed front-end circuitry detects a signal, as will be understood by those skilled in the art. Since neither Ethernet nor SONET protocols utilize this signal, any link where the laser enable signal goes to a high logic level would automatically be considered a Fibre Channel link.
  • FIG. 3 depicts an illustrative decision tree 300 utilized by the multi-protocol framer of FIG. 2 for determining the protocol of the incoming data stream, in accordance with the present invention.
  • the incoming data stream is determined to be either a WAN-type protocol or a LAN-type protocol at node 302 .
  • the framer routes the WAN-type protocol data stream 320 to node 304 .
  • Node 304 determines whether data stream 320 is a SONET/SDH protocol or a WIS protocol.
  • SONET/SDH data stream 310 is routed to a predetermined destination.
  • WIS protocol data stream 324 is routed to node 308 for further processing.
  • Node 308 operatively determines whether data stream 324 is an Ethernet protocol or a Fibre Channel protocol. Since the data stream received at node 308 was previously determined to be a WAN-type protocol, node 308 will output either an Ethernet WAN protocol data stream 316 or a Fibre Channel WAN protocol data stream 318 to respective predetermined destinations.
  • node 306 determines whether the incoming data stream is a LAN-type protocol
  • the LAN-type protocol data stream 322 is routed to node 306 for further processing.
  • Node 306 operatively determines whether data stream 322 is an Ethernet protocol or a Fibre Channel protocol. Since the data stream received at node 306 was previously determined to be a LAN-type protocol, node 306 will output either an Ethernet LAN protocol data stream 312 or a Fibre Channel LAN protocol data stream 314 to respective predetermined destinations. It is to be appreciated that nodes 306 and 308 each function, at least in part, to differentiate between Ethernet and Fibre Channel protocols in a given input data stream. Therefore, nodes 306 and 308 may be implemented by the same or similar functional blocks (e.g., block 208 in FIG. 2).
  • the decision tree 300 will change accordingly to correspond thereto.
  • a decision tree may also be defined for a multi-protocol framer that is configured for transmit-side operation in a manner consistent with the decision tree 300 shown in the figure, as will be understood by those skilled in the art.
  • the multi-protocol framer 400 like the receive-side multi-protocol framer shown in FIG. 2, includes a Protocol Lock and Frame Synchronization Engine 202 , a SONET/SDH framing block 204 and an Ethernet/Fibre Channel framing block 208 .
  • each of these functional blocks may be implemented by individual circuitry corresponding thereto, such as, for example, a digital signal processor (DSP).
  • DSP digital signal processor
  • a single circuit may be used to implement more than one functional block.
  • the present invention contemplates that one or more functional blocks associated with the framer may be implemented in software running on a processor, hardware, or a combination of software and hardware, as will be understood by those skilled in the art.
  • the multi-protocol framer 400 is preferably configured to receive, although not necessarily concurrently, at least one of a first data stream 402 originating from a SONET/SDH source and a second data stream 404 originating from an Ethernet/Fibre Channel source.
  • the first data stream 402 is routed to SONET/SDH framing block 204 which operatively processes the received data and generates a SONET/SDH protocol output data stream 408 .
  • a first state machine 210 included in the Protocol Lock and Frame Synchronization Engine 202 , is preferably configured to process data in accordance with a WAN-type protocol. State machine 210 receives the SONET/SDH protocol data stream 408 and generates a WAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414 , or an alternative communications medium.
  • Data stream 404 originating from an Ethernet/Fibre Channel source is routed to Ethernet/Fibre Channel framing block 208 which operatively processes the received data and generates a Ethernet/Fibre Channel protocol output data stream 406 .
  • the Ethernet/Fibre Channel protocol data stream 406 is preferably encoded by a scrambler/descrambler 206 included in the Ethernet/Fibre Channel framing block 208 in order to provide sufficient bit transitions (e.g., zero-to-one or one-to-zero) in the data stream, a process known as “scrambling.”
  • the data stream must generally be encoded to include a predetermined number of bit transitions in order to allow the receiver phase lock loop to recover the clock signal from the received data with reduced jitter.
  • scrambler/descrambler 206 When the destination protocol of source data stream 404 is a WAN-type protocol (e.g., as determined by the receive-side framer or by the source data stream itself), scrambler/descrambler 206 generates an encoded Ethernet/Fibre Channel protocol data stream which is preferably routed through a second state machine 212 , included in the Protocol Lock and Frame Synchronization Engine 202 , to WIS block 228 included in the SONET/SDH framing block 204 . WIS block 228 processes the received data stream 410 in accordance with a WIS protocol and is further processed by the SONET/SDH block 204 to generate a SONET/SDH protocol output data stream 408 .
  • WIS block 228 processes the received data stream 410 in accordance with a WIS protocol and is further processed by the SONET/SDH block 204 to generate a SONET/SDH protocol output data stream 408 .
  • State machine 210 receives the SONET/SDH protocol data stream 408 and generates a WAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414 .
  • a multiplexer (MUX) 412 may be included in the framer 400 for selectively routing the data stream output by state machine 212 to either the fiber optic network 414 or to the WIS block 228 .
  • a second MUX 416 may also be included for selectively routing either the LAN-type data stream (e.g., from state machine 212 ) or the WAN-type data stream (e.g., from state machine 210 ) to the fiber optic network 414 .
  • the scrambler/descrambler 206 When the destination protocol of source data stream 404 is a LAN-type protocol, the scrambler/descrambler 206 generates an encoded Ethernet/Fibre Channel protocol data stream 406 which is routed to the second state machine 212 included in the Protocol Lock and Frame Synchronization Engine 202 .
  • the second state machine 212 is preferably configured to process data in a LAN-type protocol. State machine 212 receives the encoded Ethernet/Fibre Channel protocol data stream 406 and generates an appropriate LAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414 . In this instance, the output data stream does not pass through the WIS block 228 for further processing.
  • the protocol to be output during the transmit operation may be determined by a control signal (e.g., in-frame control signal), or other means, generated by a state machine associated with the receive-side framer, as previously described.
  • a control signal e.g., in-frame control signal
  • the present invention contemplates that information regarding the destination protocol may be encoded into the incoming data stream received by framer 400 , as will be understood by those skilled in the art.
  • the protocol used by the transmit-side framer 400 may be user-selectable.
  • the multi-protocol framer is depicted in the figures as including protocol-specific functional blocks corresponding to a particular protocol, one or more of these blocks may be shared by more than one protocol.
  • the scrambler/descrambler is preferably protocol-independent, and may therefore be used for each of the protocols received.
  • the encoder/decoder functions are substantially identical, except for minor variations, such as in mapping control ordered sets (e.g., in Fibre Channel protocol) or characters (e.g., in Ethernet protocol). Consequently, decoding and/or encoding of these protocols can be performed using the same hardware, with slight modifications thereto.
  • the WIS frame overhead is a subset of the SONET/SDH overhead. Accordingly, at least a portion of the SONET/SDH functional blocks can be disabled when an Ethernet/Fibre Channel WAN data stream is received.
  • the multi-protocol framer in accordance with another aspect of the invention, is preferably configured to provide information associated with the detected protocol to enable, for example, further protocol-specific processing. This can be accomplished, for example, via a serial management interface, such as a multiplexed data input/output (MDIO)/multiplexed data clock (MDC) interface, or in-band if coded data is used at the interface.
  • a serial management interface such as a multiplexed data input/output (MDIO)/multiplexed data clock (MDC) interface, or in-band if coded data is used at the interface.
  • MDIO multiplexed data input/output
  • MDC multiplexed data clock
  • IP Internet Protocol
  • IP data from different protocols can be operatively fed into one switch if a first-in first-out (FIFO) buffer, or an alternative buffering arrangement, is included at the switch input.
  • FIFO first-in first-out
  • Buffering enables the data framer to handle small deviations in the data rates of the incoming data stream.
  • the acceptable deviations in the data rate for a given protocol may be set forth, for example, in the standard corresponding to the particular protocol used, as will be understood by those skilled in the art.
  • XAUI refers to 10 Gigabit Attachment Unit Interface and all data rates are given in gigabits per second (Gbs).
  • Gbs gigabits per second
  • the CDR circuitry must be configured to lock to any frequency within this range in order for the framer to function properly. Moreover, if additional protocols and/or data rates are included in the multi-protocol framer, the CDR circuitry must be configured to cover these additional frequencies as well.
  • the CDR circuitry can be configured so that it can automatically lock to the incoming frequency, such as by including a phase lock loop (PLL) circuit.
  • PLL phase lock loop
  • the CDR circuitry can be configured such that a plurality of narrower frequency bands are provided to choose from.
  • the framer in accordance with the present invention, may be configured to initiate a frequency band change in the CDR circuitry to enable the CDR circuitry to lock to the incoming frequency, as will be understood by those skilled in the art. This procedure can be repeated until the framer detects a valid framing sequence for one of the supported protocols in the data stream.
  • the multi-protocol agile framer of the present invention described herein may be implemented, in whole or in part, in accordance with a processing system 500 , including a controller or processor 502 , memory 504 and a user interface 506 .
  • a processing system 500 including a controller or processor 502 , memory 504 and a user interface 506 .
  • processor as used herein is intended to include any processing device, such as, for example, one that includes a central processing unit (CPU) and/or other processing circuitry (e.g., digital signal processor (DSP), microprocessor, controller, etc.). Additionally, it is to be understood that the term “processor” may refer to more than one processing device, and that various elements associated with a processing device may be shared by other processing devices.
  • CPU central processing unit
  • DSP digital signal processor
  • processor may refer to more than one processing device, and that various elements associated with a processing device may be shared by other processing devices.
  • memory as used herein is intended to include memory and other computer-readable media associated with a processor or CPU, such as, for example, random access memory (RAM), read only memory (ROM), fixed storage media (e.g., a hard drive), removable storage media (e.g., a diskette), flash memory, etc.
  • user interface as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, etc.) for entering data to the processor, and/or one or more output devices (e.g., monitor, etc.) for presenting the results associated with the processor.
  • an application program, or software components thereof, including instructions or code for performing the methodologies of the present invention may be stored in one or more of the associated storage media (e.g., ROM, fixed or removable storage) and, when ready to be utilized, loaded in whole or in part (e.g., into RAM) and executed by the processor 502 .
  • the components shown in FIGS. 1 and 2 may be implemented in various forms of hardware, software, or combinations thereof, e.g., one or more digital signal processors (DSPs) with associated memory, application-specific integrated circuit(s), functional circuitry, etc.
  • DSPs digital signal processors

Abstract

A data framer capable of supporting at least two different data framing protocols potentially present in a source data stream includes two or more framing circuits and a controller coupled to the framing circuits. Each of the framing circuits is configured to extract user data from the source data stream in accordance with a different data framing protocol associated with the respective framing circuit. The controller is operative to: (i) receive the source data stream and automatically determine which of the at least two different data framing protocols corresponds to the source data stream; and (ii) route the source data stream to one of the first framing circuit and the second framing circuit in response to a match between the determined data framing protocol of the source data stream and one of the first and second data framing protocols.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This application claims the benefit of U.S. Provisional Application Serial No. 60/294,972 filed on May 31, 2001, the disclosure of which is incorporated herein by reference.[0001]
  • FIELD OF THE INVENTION
  • The present invention relates generally to data transmission systems, and more particularly relates to a data framer that is capable of automatically supporting two or more data framing protocols. [0002]
  • BACKGROUND OF THE INVENTION
  • It is well known that data communication protocols, for transferring information between a source and a destination over a communication network, typically employ a framing architecture for synchronizing data between the source and destination. A data frame may be divided into various sections, including a message section and an information section (e.g., framing data) associated with the message section which is used, for example, to identify the frame boundaries and maintain the communication network path. The information section typically resides in a header and/or a trailer portion of the data frame. Different data communication protocols often utilize different frame organizations for sending data over the communication network. [0003]
  • A data framer is a device which generally functions in a data link layer of a data transmission system. When utilized at the receiver side of the system, the framer searches an incoming data stream for a data frame of a preset format or protocol. Once the frame boundaries have been identified using the preset protocol, valid user data is located within the frame by subsequent processing stages. On the transmit side, the framer organizes the user data into a frame corresponding to the preset protocol for transmission over the communication network. [0004]
  • Conventional framers are generally capable of processing only a single framing protocol. Since the conventional framer conducts all functions specifically for a selected protocol, received data streams that do not match the selected protocol will not be identified as valid. Likewise, transmitted data streams will only be framed in accordance with the single selected protocol. Additionally, there often exist variants of a given protocol for different data transmission rates. Framers are typically optimized for a targeted data rate. Thus, when the data rate changes, the framer settings must typically be manually modified to correspond to the selected protocol at the desired data rate. [0005]
  • It would be advantageous, therefore, to provide a framer that is capable of automatically supporting multiple framing protocols and/or data transmission rates. [0006]
  • SUMMARY OF THE INVENTION
  • The present invention provides techniques for forming a multi-protocol framer for use, for example, in a data transmission system. The multi-protocol framer is capable of automatically detecting a particular data transfer protocol in an input data stream received from a transmission medium, such as, for example, a fiber optic network. Once the particular protocol has been detected by the framer, the framer is configured to extract valid data from the input data stream and/or frame valid data for transfer over the transmission medium according to the detected protocol. Thus, using the techniques of the present invention, a data framer may be provided that is not only capable of automatically handling multiple data transfer protocols, but eliminates the need for knowing the protocol type a priori. [0007]
  • In accordance with one aspect of the invention, a data framer capable of supporting at least two different data framing protocols potentially present in a source data stream includes two or more framing circuits and a controller coupled to the framing circuits. Each of the framing circuits is configured to extract user data from the source data stream in accordance with a different data framing protocol associated with the respective framing circuit. The controller is operative to: (i) receive the source data stream and automatically determine which of the at least two different data framing protocols corresponds to the source data stream; and (ii) route the source data stream to one of the first framing circuit and the second framing circuit in response to a match between the determined data framing protocol of the source data stream and one of the first and second data framing protocols. [0008]
  • These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.[0009]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating a system integration of the multi-protocol agile framer, in accordance with the present invention. [0010]
  • FIG. 2 is a block diagram illustrating a receive side multi-protocol framer, formed in accordance with one aspect of the present invention. [0011]
  • FIG. 3 is a block diagram illustrating an exemplary decision tree utilized by the illustrative multi-protocol framer of FIG. 2 for determining the protocol of the incoming data stream, in accordance with the present invention. [0012]
  • FIG. 4 is a block diagram illustrating a transmit side multi-protocol framer, formed in accordance with the present invention. [0013]
  • FIG. 5 is a block diagram illustrating a generalized data processing system for implementing the methodologies of the present invention. [0014]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • The present invention provides techniques for forming a multi-protocol framer. The multi-protocol framer is described herein with specific reference to synchronous optical network (SONET)/synchronous digital hierarchy (SDH), Ethernet wide area network (WAN), Ethernet local area network (LAN), Fibre Channel WAN, and Fibre Channel LAN protocols for transferring data over a fiber optic network. It is to be appreciated, however, that the present invention is not limited to these or any particular data transmission protocols and/or communication mediums. [0015]
  • A detailed description of the SONET standard may be found, for example, in American National Standards Institute (ANSI) documents T1.105-1995, T1.105.02-1995, T1.105.04-1995 and T1.105.09-1996, which are incorporated herein by reference. The WAN synchronization standard may be found, for example, in ANSI T1TR3GPP 27.103-300, which is incorporated herein by reference. Likewise, an overview of LAN protocol standards may be found, for example, in International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) documents TR 8802-1:2001, ISO/IEC 10038-1993, Institute of Electrical and Electronics Engineers (IEEE) document 802.7-1989 and IEEE 802.1q-1998, which are incorporated herein by reference. The Fibre Channel protocol standard is described, for example, in the document “Fibre Channel—Physical and Signaling Interface” (ANSI X3.230-1994). Accordingly, a detailed description of these conventional data transfer protocols will not be presented herein. [0016]
  • In a data transmission system including a framer, one way to decide which framing format to use for transferring data between a source and a destination is to manually set the data transfer protocol from outside the framer. However, this has conventionally required a priori knowledge of the protocol used by the source. Moreover, whenever the protocol of an incoming data stream changes, control settings associated with the framer must also be manually changed to correspond to the incoming protocol in order to recognize the incoming data as being valid. [0017]
  • To enable a protocol change without manual interaction and without requiring a priori knowledge of the data framing protocol used by the source, the present invention provides techniques for automatically detecting the protocol of a received input data stream and locking to the framing architecture used by this protocol. Once the protocol has been determined on the receive side of the framer, the transmit side of the framer can be automatically set to correspond to the detected protocol. In this manner, a framer formed in accordance with the present invention is able to advantageously determine its own functionality without manual interaction. In addition, the data framer of the present invention may provide the ability to change the data framing protocol in response to a user-selectable control signal. [0018]
  • FIG. 1 illustrates an exemplary data transmission system, formed in accordance with the present invention. The illustrative [0019] data transmission system 100 preferably includes clock and data recovery (CDR) circuitry 102, a pair of multi-protocol agile framers 104 and 106, a pair of media access controllers (MACs) 112 and 114, and a switcher/router 116. The CDR circuitry 102 is coupled to a transmission medium, such as, for example, a fiber optic network 118 for transferring data. The CDR circuitry 102 functions, at least in part, to operatively serialize and/or deserialize the incoming or outgoing data stream, respectively. On a receive side of the system, one of the framers 104 is operatively configured to receive an input data stream 120 from the CDR circuitry 102. The input data stream 120 may comprise data frames of one of a plurality of undetermined protocols. On the transmit side of the system, another of the framers 106 is operatively configured to send an output data stream 122 to the CDR circuitry 102. Like the input data stream 120, the output data stream 122 may comprise data frames of one of a plurality of protocols, and is preferably matched to the protocol of the input data stream.
  • One the receive-side, [0020] multi-protocol framer 104 is preferably configured to automatically detect the protocol of the input data stream 120 and extract valid data therefrom. Once the protocol has been determined, valid data can be easily located within a given frame corresponding to the detected protocol. Preferably, framer 104 includes a first output 124 for providing SONET/SDH-type data to the switcher/router 116 for transmission. Framer 104 also preferably includes a second output 130 for providing Ethernet/Fibre Channel-type data to the media access controller (MAC) 112, which is operatively coupled to the switcher/router 116. The MAC 112 functions, at least in part, to evaluate switch routing in the system.
  • On the transmit-side, [0021] multi-protocol framer 106 is preferably configured to receive either SONET/SDH-type data 126 directly from the switcher/router 116 or receive Ethernet/Fibre Channel-type data 128 from the switcher/router 116 via MAC 114. In either case, the data received from the switcher/router 116 is preferably framed by the transmit-side multi-protocol framer 106 using the protocol detected by the receive-side multi-protocol framer 104. The framed data is then sent to the CDR circuitry 102 as an output data stream 122 for transferring data to a destination via the fiber optic network 118.
  • With reference now to FIG. 2, there is shown an illustrative multi-protocol agile framer configured for receive-side operation, in accordance with one aspect of the present invention. The [0022] multi-protocol framer 200 is preferably organized into several functional blocks for ease of explanation, including a Protocol Lock and Frame Synchronization Engine 202, a SONET/SDH framing block 204 and an Ethernet/Fibre Channel framing block 208. It is to be appreciated that each of these functional blocks may be implemented by individual circuitry corresponding thereto, such as, for example, a digital signal processor (DSP) or alternative processing device. Alternatively, a single circuit may be used to implement more than one functional block. Moreover, the present invention contemplates that one or more functional blocks associated with the framer may be implemented in software running on a processor, hardware, or a combination of software and hardware, as will be understood by those skilled in the art.
  • The Protocol Lock and [0023] Frame Synchronization Engine 202 preferably receives an input data stream 226 presented thereto, for example, from a fiber optic network, and searches for a frame synchronization pattern in the input data stream. For example, for a WAN protocol, the data stream may include framing bytes A1 and A2, which indicate the beginning of a synchronous transport signal (STS) frame. Alternatively, in the case of a LAN protocol, the data stream may include a 01/10 bit sequence every 66 bits, indicating the beginning of a LAN-type data frame. The Protocol Lock and Frame Synchronization Engine 202 preferably includes two or more state machines 210 and 212, each of the state machines 210, 212 being configured to operatively detect a different predetermined protocol in the input data stream 226. The present invention contemplates that additional state machines (not shown) may be added to the Protocol Lock and Frame Synchronization Engine 202 for detecting additional data transfer protocols corresponding thereto in the input data stream, thus expanding the protocol detection capability of the framer.
  • The [0024] state machines 210, 212 preferably each receive the input data stream 226 and operate substantially in parallel, to essentially scan the input data stream and detect a data frame in accordance with predefined protocol standards associated therewith. By operating in parallel, the state machines 210, 212 are able to detect an undetermined protocol in the input data stream more quickly. Therefore, the speed of a data framer formed in accordance with the present invention is significantly improved. When one of the state machines detects a particular data frame corresponding to its configured protocol, that state machine may be referred to as being in an “in-frame” or “lock” condition, and the other state machine(s) may be disabled or otherwise shut off until the in-frame condition has ended. By disabling the unused state machine(s), power consumption in the framer may be reduced.
  • When the Protocol Lock and [0025] Frame Synchronization Engine 202 identifies the input data stream as being a WAN-type protocol, state machine 210, which is used in this instance for detecting a WAN-type protocol in the data stream 226, preferably generates a control signal indicating that it is in an in-frame condition. The in-frame control signal generated by state machine 210 may be used to operatively disable state machine 212 and/or transfer the input data stream to subsequent processing circuitry associated with state machine 210. Once the protocol of the input data stream has been identified, the in-frame state machine (e.g., 210) preferably continues to periodically monitor the input data stream 226 to determine whether the in-frame condition still exists. It is to be appreciated that once the state machine is in an in-frame condition, indicating that the data transfer protocol is known, frame boundaries can be easily determined corresponding to the detected protocol. Thus, to determine whether the in-frame condition still exists, the state machine need only monitor the input data stream for the expected frame boundaries, as will be understood by those skilled in the art.
  • [0026] State machine 210 transfers the input data stream, which has been previously identified as being a WAN-type protocol, to the SONET/SDH framing block 204 via line 214. The SONET/SDH framing block 204 preferably determines whether the incoming data stream is a SONET/SDH protocol or a WAN interface sublayer (WIS) protocol, defined by the SONET/SDH standard and WIS standard (e.g., ANSI T1.416-1999, which is incorporated herein by reference), respectively, as known by those skilled in the art. To accomplish this, the SONET/SDH framing block 204 may be configured to detect one or more predetermined byte locations in the input data stream. For example, the SONET/SDH framing block 204 may operatively detect certain overhead bytes which are utilized in the SONET/SDH protocol, but which are unused and set to a particular logic level, such as, for example, logic zero, in the WIS protocol. It is to be appreciated that alternative techniques for identifying a particular protocol or differentiating between two or more protocols in the input data stream may be employed, in accordance with the invention.
  • When the [0027] incoming data stream 214 to the SONET/SDH framing block 204 is determined to be a purely SONET/SDH protocol, the SONET/SDH framing block 204 preferably transfers the data stream directly to subsequent processing circuitry (e.g., switcher/router 116 in FIG. 1), for example, via line 222. Alternatively, when the data stream 214 is not recognized as a SONET/SDH protocol, a WIS block 228 included in the SONET/SDH framing block 204 preferably transfers the data stream to state machine 212 via line 218 for further processing. Since a WIS frame essentially contains a plurality of Ethernet/Fibre Channel frames, the WIS data stream 218 can be further processed in accordance with a LAN-type protocol.
  • When the Protocol Lock and [0028] Frame Synchronization Engine 202 identifies the input data stream 226 as being a LAN-type protocol, state machine 212 preferably generates an in-frame control signal. The in-frame control signal generated by state machine 212 may be used in a manner consistent with state machine 210, as previously described, to operatively disable state machine 210, along with any unused circuitry associated therewith (e.g., SONET/SDH framing block 204), and/or route the data stream to subsequent processing circuitry associated with state machine 212. As previously described, once the protocol of the input data stream 226 has been identified, the in-frame state machine (e.g., 212) preferably continues to periodically monitor the data stream to determine whether the in-frame condition still exists.
  • [0029] State machine 212 operatively routes the data stream, which has already been determined to be a LAN-type protocol, to a scrambler/descrambler 206 included in the Ethernet/Fibre Channel framing block 208. The scrambler/descrambler 206 is preferably configured to extract payload and overhead fields within the incoming frame which has been previously scrambled in order to provide sufficient bit transitions (e.g., zero-to-one or one-to-zero) in the data stream. As will be understood by those skilled in the art, in fiber optic systems employing a receiver phase lock loop, the data stream must generally be encoded to include a predetermined number of bit transitions in order to allow the receiver phase lock loop to recover a clock signal from the received data with low jitter. As previously stated, since a WIS frame essentially contains a plurality of Ethernet/Fibre Channel frames, the WIS data stream 218 can be further processed by the Ethernet/Fibre Channel framing block 208. The scrambler/descrambler 206 may additionally provide data encoding/decoding for error detection and/or correction purposes. For example, in a LAN-type protocol, for every 66 bits of data received there is only 64 bits of real data. Thus, the descrambler is preferably configured to transpose the 66-bit data stream 216 into a 64-bit data stream 224 (e.g., using a 66-bit/64-bit decoder).
  • The Ethernet/Fibre [0030] Channel framing block 208 preferably determines whether the incoming data stream 216 is an Ethernet protocol or a Fibre Channel protocol, as defined by the Ethernet and Fibre Channel standards, respectively. The Ethernet/Fibre Channel framing block 208 may be configured to differentiate between Ethernet and Fibre Channel protocols using various techniques, such as, for example, ordered set signaling, start-of-file (SOF) and end-of-file (EOF) recognition, and open fiber control (OFC) signaling, as will be explained in further detail below. Alternative protocol differentiation techniques suitable for use with the present invention are similarly contemplated.
  • As will be understood by those skilled in the art, ordered sets, in the context of a Fibre Channel protocol, are four-byte transmission words containing data and special characters as a first transmission character. An ordered set may be, for example, a frame delimiter, a primitive signal, or a primitive sequence. Ordered sets are used, at least in part, to distinguish Fibre Channel control information from data and provide the availability to obtain bit and word synchronization, which also establishes word boundary alignment. Frame signaling (FSIG) in accordance with IEEE Standard 802.3ae is used to signal an ordered set of Fibre Channel code, and always begins with special character K28.2. The special character K28.2 in the byte[0031] 0 position of the ordered set will always indicate Fibre Channel ordered set data, such as, for example, K28.2-Dx1.y1-Dx2.y2-Dx3.y3, and is then translated back into the proper Fibre Channel ordered set, for example, K28.5-Dx1.y1-Dx2.y2-Dx3.y3.
  • Another technique for distinguishing between Ethernet and Fibre Channel protocols is SOF and EOF recognition. Frame delimiters SOF and EOF immediately precede and follow, respectively, the contents of a given frame. SOF and EOF are handled differently in Ethernet and Fibre Channel. For instance, Fibre Channel utilizes specific ordered sets for both SOF and EOF. Alternatively, Ethernet utilizes only a single control character for SOF and EOF. Moreover, since the Fibre Channel protocol employs ordered sets of four bytes, the control characters for delimiters SOF and EOF will always reside in the same byte position. In the Ethernet protocol, however, only the SOF character resides in the same byte position, and the EOF character may reside in any byte position. These differences are set forth, for example, in the 10 Gigahertz (GHz) Fibre Channel standard document version 1.0, section 14, pp. 53ff (Mar. 10, 2001) and the 10 GHz Ethernet standard document IEEE 802.3ae, Draft 2.3, section 48.3, pg. 296ff, which are incorporated herein by reference. [0032]
  • More specifically, the bytes exiting a 66-bit/64-bit decoder (not shown) residing in Ethernet/Fibre [0033] Channel framing block 208 are preferably compared with expected SOF and/or EOF characters specific to the Ethernet protocol and the Fibre Channel protocol substantially simultaneously. When a Fibre Channel ordered set with proper SOF and EOF control character alignment and/or ordered set sequence is detected, a state machine included in the Ethernet/Fibre Channel framing block 208 preferably begins counting data packets with proper SOF and EOF termination up to a user-definable count to assure no chance of false Fibre Channel detection. If Fibre Channel sets are not detected, or if EOF control characters are detected in wrong or otherwise unexpected byte positions in the data stream for a Fibre Channel protocol, then Ethernet data is presumed. In this instance, an Ethernet-specific state machine preferably searches for SOF characters in the proper byte location and begins counting properly formatted Ethernet packets up to a user-definable maximum count.
  • The present invention preferably utilizes the above-described maximum count to provide hysteresis in the protocol determination process, such that the framer is less susceptible to “glitches” caused by single packet errors in the data stream, and/or other anomalies. Various techniques can be employed for providing such hysteresis, in accordance with the present invention. For example, a “valid packet” counter (not shown) may be included in the Ethernet/Fibre [0034] Channel framing block 208. The valid packet counter may be initialized to a predetermined count. If, after some time, the Ethernet or Fibre Channel SOF and/or EOF formatting is found to be in error, the count associated with the valid packet counter is either incremented or decremented by one such that a single packet error does not cause the Ethernet/Fibre Channel determination process to undesirably “glitch” or switch to using another protocol. A comparator (not shown) may be used in conjunction with the valid packet counter for comparing the counter value with a predetermined count value in order to determine whether the protocol should be changed (e.g., an unacceptable number of packet errors were detected), as will be understood by those skilled in the art. If no protocol is found which provides a sufficiently low error rate, the framer may, in accordance with the invention, indicate a loss of link (LOL) in a manner determined by the standard associated with the particular protocol or by the user.
  • It is to be appreciated that there are various alternative methods that may be used to implement the protocol determination and switching functions of the present invention. For example, in accordance with another aspect of the invention, the Ethernet/Fibre [0035] Channel framing block 208 may first look for an Ethernet protocol, rather than a Fibre Channel protocol. To accomplish this, the Ethernet/Fibre Channel framing block 208 may be configured to detect the variable EOF control character location. Alternatively, SOF and Ethernet preamble characters may be used to define a unique pseudo-ordered set which is different from the SOF ordered set definitions corresponding to a Fibre Channel protocol.
  • An OFC signaling technique may also be utilized in accordance with the present invention to discriminate between an Ethernet protocol and a Fibre Channel protocol, as previously stated. The OFC signaling technique, which may be employed in the [0036] CDR circuitry 102 of the data transfer system 100 (see FIG. 1), relies on OFC employed in setting up 850 nanometer (nm) wavelength division multiplexing (WDM) Fibre Channel links for transporting several data streams over a single fiber. For example, for an OFC function, Fibre Channel links may employ a signal generated by high-speed front-end circuitry which is processed by OFC circuitry in the CDR circuitry 102 to generate a laser enable signal (e.g., Laser_En). The laser enable signal may be a high logic level when the high-speed front-end circuitry detects a signal, as will be understood by those skilled in the art. Since neither Ethernet nor SONET protocols utilize this signal, any link where the laser enable signal goes to a high logic level would automatically be considered a Fibre Channel link.
  • By way of example only, FIG. 3 depicts an [0037] illustrative decision tree 300 utilized by the multi-protocol framer of FIG. 2 for determining the protocol of the incoming data stream, in accordance with the present invention. As previously described, the incoming data stream is determined to be either a WAN-type protocol or a LAN-type protocol at node 302. When a WAN-type protocol is detected, the framer routes the WAN-type protocol data stream 320 to node 304. Node 304 determines whether data stream 320 is a SONET/SDH protocol or a WIS protocol. When a SONET/SDH protocol is detected, SONET/SDH data stream 310 is routed to a predetermined destination. Similarly, when node 304 determines that data stream 320 is a WIS protocol, WIS protocol data stream 324 is routed to node 308 for further processing. Node 308 operatively determines whether data stream 324 is an Ethernet protocol or a Fibre Channel protocol. Since the data stream received at node 308 was previously determined to be a WAN-type protocol, node 308 will output either an Ethernet WAN protocol data stream 316 or a Fibre Channel WAN protocol data stream 318 to respective predetermined destinations.
  • When [0038] node 302 determines that the incoming data stream is a LAN-type protocol, the LAN-type protocol data stream 322 is routed to node 306 for further processing. Node 306 operatively determines whether data stream 322 is an Ethernet protocol or a Fibre Channel protocol. Since the data stream received at node 306 was previously determined to be a LAN-type protocol, node 306 will output either an Ethernet LAN protocol data stream 312 or a Fibre Channel LAN protocol data stream 314 to respective predetermined destinations. It is to be appreciated that nodes 306 and 308 each function, at least in part, to differentiate between Ethernet and Fibre Channel protocols in a given input data stream. Therefore, nodes 306 and 308 may be implemented by the same or similar functional blocks (e.g., block 208 in FIG. 2).
  • As the number and/or type of protocols handled by the multi-protocol framer of the present invention changes, the [0039] decision tree 300 will change accordingly to correspond thereto. A decision tree may also be defined for a multi-protocol framer that is configured for transmit-side operation in a manner consistent with the decision tree 300 shown in the figure, as will be understood by those skilled in the art.
  • With reference now to FIG. 4, there is shown an illustrative multi-protocol [0040] agile framer 400 configured for transmit-side operation, in accordance with the present invention. The multi-protocol framer 400, like the receive-side multi-protocol framer shown in FIG. 2, includes a Protocol Lock and Frame Synchronization Engine 202, a SONET/SDH framing block 204 and an Ethernet/Fibre Channel framing block 208. It is to be appreciated that each of these functional blocks may be implemented by individual circuitry corresponding thereto, such as, for example, a digital signal processor (DSP). Alternatively, a single circuit may be used to implement more than one functional block. Moreover, the present invention contemplates that one or more functional blocks associated with the framer may be implemented in software running on a processor, hardware, or a combination of software and hardware, as will be understood by those skilled in the art.
  • During a transmit operation, the [0041] multi-protocol framer 400 is preferably configured to receive, although not necessarily concurrently, at least one of a first data stream 402 originating from a SONET/SDH source and a second data stream 404 originating from an Ethernet/Fibre Channel source. The first data stream 402 is routed to SONET/SDH framing block 204 which operatively processes the received data and generates a SONET/SDH protocol output data stream 408. A first state machine 210, included in the Protocol Lock and Frame Synchronization Engine 202, is preferably configured to process data in accordance with a WAN-type protocol. State machine 210 receives the SONET/SDH protocol data stream 408 and generates a WAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414, or an alternative communications medium.
  • [0042] Data stream 404 originating from an Ethernet/Fibre Channel source is routed to Ethernet/Fibre Channel framing block 208 which operatively processes the received data and generates a Ethernet/Fibre Channel protocol output data stream 406. The Ethernet/Fibre Channel protocol data stream 406 is preferably encoded by a scrambler/descrambler 206 included in the Ethernet/Fibre Channel framing block 208 in order to provide sufficient bit transitions (e.g., zero-to-one or one-to-zero) in the data stream, a process known as “scrambling.” As previously explained, in fiber optic systems employing a receiver phase lock loop, the data stream must generally be encoded to include a predetermined number of bit transitions in order to allow the receiver phase lock loop to recover the clock signal from the received data with reduced jitter.
  • When the destination protocol of [0043] source data stream 404 is a WAN-type protocol (e.g., as determined by the receive-side framer or by the source data stream itself), scrambler/descrambler 206 generates an encoded Ethernet/Fibre Channel protocol data stream which is preferably routed through a second state machine 212, included in the Protocol Lock and Frame Synchronization Engine 202, to WIS block 228 included in the SONET/SDH framing block 204. WIS block 228 processes the received data stream 410 in accordance with a WIS protocol and is further processed by the SONET/SDH block 204 to generate a SONET/SDH protocol output data stream 408. State machine 210 receives the SONET/SDH protocol data stream 408 and generates a WAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414. A multiplexer (MUX) 412 may be included in the framer 400 for selectively routing the data stream output by state machine 212 to either the fiber optic network 414 or to the WIS block 228. A second MUX 416 may also be included for selectively routing either the LAN-type data stream (e.g., from state machine 212) or the WAN-type data stream (e.g., from state machine 210) to the fiber optic network 414.
  • When the destination protocol of [0044] source data stream 404 is a LAN-type protocol, the scrambler/descrambler 206 generates an encoded Ethernet/Fibre Channel protocol data stream 406 which is routed to the second state machine 212 included in the Protocol Lock and Frame Synchronization Engine 202. The second state machine 212 is preferably configured to process data in a LAN-type protocol. State machine 212 receives the encoded Ethernet/Fibre Channel protocol data stream 406 and generates an appropriate LAN-type protocol frame for transmission to a predetermined destination via fiber optic network 414. In this instance, the output data stream does not pass through the WIS block 228 for further processing.
  • It is to be appreciated that the protocol to be output during the transmit operation may be determined by a control signal (e.g., in-frame control signal), or other means, generated by a state machine associated with the receive-side framer, as previously described. Alternatively, the present invention contemplates that information regarding the destination protocol may be encoded into the incoming data stream received by [0045] framer 400, as will be understood by those skilled in the art. Additionally, the protocol used by the transmit-side framer 400 may be user-selectable.
  • Although the multi-protocol framer is depicted in the figures as including protocol-specific functional blocks corresponding to a particular protocol, one or more of these blocks may be shared by more than one protocol. For example, the scrambler/descrambler is preferably protocol-independent, and may therefore be used for each of the protocols received. Likewise, the encoder/decoder functions are substantially identical, except for minor variations, such as in mapping control ordered sets (e.g., in Fibre Channel protocol) or characters (e.g., in Ethernet protocol). Consequently, decoding and/or encoding of these protocols can be performed using the same hardware, with slight modifications thereto. [0046]
  • Advantageously, once the protocol of the incoming data stream has been determined, those functional blocks associated with the unused protocol can be powered down or otherwise disabled, thus significantly reducing overall power consumption in the framer. For example, the WIS frame overhead is a subset of the SONET/SDH overhead. Accordingly, at least a portion of the SONET/SDH functional blocks can be disabled when an Ethernet/Fibre Channel WAN data stream is received. [0047]
  • Since information regarding the protocol of the received data stream may be utilized for subsequent data processing (e.g., in a data link layer), the multi-protocol framer, in accordance with another aspect of the invention, is preferably configured to provide information associated with the detected protocol to enable, for example, further protocol-specific processing. This can be accomplished, for example, via a serial management interface, such as a multiplexed data input/output (MDIO)/multiplexed data clock (MDC) interface, or in-band if coded data is used at the interface. When all data to be transferred is in Internet Protocol (IP) format, the transmit side can be switched to the proper output format. IP data from different protocols can be operatively fed into one switch if a first-in first-out (FIFO) buffer, or an alternative buffering arrangement, is included at the switch input. Buffering enables the data framer to handle small deviations in the data rates of the incoming data stream. The acceptable deviations in the data rate for a given protocol may be set forth, for example, in the standard corresponding to the particular protocol used, as will be understood by those skilled in the art. [0048]
  • With regard to the CDR circuitry, as previously described in conjunction with FIG. 1, clock and data recovery of the incoming data stream must be done before the data originating from the fiber optic network is received by the framer. As shown in Table 1 below, the data rate is different for the various protocols described herein that can be recovered by the multi-protocol framer of the present invention. [0049]
    TABLE 1
    Line
    Protocol MAC Data Rate XAUI Data Rate Data Rate
    SONET/SDH n/a n/a 9.95328
    Ethernet WAN 9.294196 4 × 3.125  9.95328
    Ethernet LAN 10 4 × 3.125  10.3125
    Fibre Channel WAN 9.294196 4 × 3.1875 9.95328
    Fibre Channel LAN 10.2 4 × 3.1875 10.51875
  • In Table 1, the term “XAUI” refers to 10 Gigabit Attachment Unit Interface and all data rates are given in gigabits per second (Gbs). The CDR circuitry must be configured to lock to any frequency within this range in order for the framer to function properly. Moreover, if additional protocols and/or data rates are included in the multi-protocol framer, the CDR circuitry must be configured to cover these additional frequencies as well. [0050]
  • There are various approaches which can be employed to insure that the CDR circuitry is operational within the frequency range of interest. One technique is to configure the CDR circuitry so that it can automatically lock to the incoming frequency, such as by including a phase lock loop (PLL) circuit. In an alternative embodiment, the CDR circuitry can be configured such that a plurality of narrower frequency bands are provided to choose from. When the data stream received by the multi-protocol framer from the CDR circuitry does not provide any usable information, the framer, in accordance with the present invention, may be configured to initiate a frequency band change in the CDR circuitry to enable the CDR circuitry to lock to the incoming frequency, as will be understood by those skilled in the art. This procedure can be repeated until the framer detects a valid framing sequence for one of the supported protocols in the data stream. [0051]
  • As shown in FIG. 5, the multi-protocol agile framer of the present invention described herein may be implemented, in whole or in part, in accordance with a [0052] processing system 500, including a controller or processor 502, memory 504 and a user interface 506. It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a central processing unit (CPU) and/or other processing circuitry (e.g., digital signal processor (DSP), microprocessor, controller, etc.). Additionally, it is to be understood that the term “processor” may refer to more than one processing device, and that various elements associated with a processing device may be shared by other processing devices. The term “memory” as used herein is intended to include memory and other computer-readable media associated with a processor or CPU, such as, for example, random access memory (RAM), read only memory (ROM), fixed storage media (e.g., a hard drive), removable storage media (e.g., a diskette), flash memory, etc. Furthermore, the term “user interface” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, etc.) for entering data to the processor, and/or one or more output devices (e.g., monitor, etc.) for presenting the results associated with the processor.
  • Accordingly, an application program, or software components thereof, including instructions or code for performing the methodologies of the present invention, may be stored in one or more of the associated storage media (e.g., ROM, fixed or removable storage) and, when ready to be utilized, loaded in whole or in part (e.g., into RAM) and executed by the [0053] processor 502. In any case, it is to be appreciated that one or more of the components shown in FIGS. 1 and 2 may be implemented in various forms of hardware, software, or combinations thereof, e.g., one or more digital signal processors (DSPs) with associated memory, application-specific integrated circuit(s), functional circuitry, etc.
  • Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made therein by one skilled in the art without departing from the scope of the appended claims. [0054]

Claims (20)

What is claimed is:
1. A data framer capable of supporting at least two different data framing protocols potentially present in a source data stream, the data framer comprising:
a first framing circuit configured to selectively extract user data from the source data stream in accordance with a first of the at least two data framing protocols;
a second framing circuit configured to selectively extract user data from the source data stream in accordance with a second of the at least two data framing protocols; and
a controller coupled to the first and at least second framing circuits, at least one of the controller, the first framing circuit and the second framing circuit being operative to: (i) receive the source data stream and automatically determine which of the at least two different data framing protocols corresponds to the source data stream; and (ii) route the source data stream to one of the first framing circuit and the second framing circuit in response to a match between the determined data framing protocol of the source data stream and one of the first and second data framing protocols.
2. The data framer of claim 1, wherein each of the framing circuits comprises at least one state machine, the at least one state machine being configured to receive the source data stream and determine whether the data framing protocol corresponding to the source data stream substantially matches a data framing protocol associated therewith, each of the at least one state machines including a different respective data framing protocol corresponding thereto.
3. The data framer of claim 2, wherein each of the state machines associated with the framing circuits are configured to determine the data framing protocol corresponding to the source data stream substantially concurrently.
4. The data framer of claim 2, wherein the controller is configured to operatively disable one or more state machines associated with data framing protocols not matching the determined data framing protocol corresponding to the source data stream.
5. The data framer of claim 1, wherein:
the first data framing protocol is a wide area network (WAN) protocol; and
the second data framing protocol is a local area network (LAN) protocol.
6. The data framer of claim 1, wherein:
the first data framing protocol is a synchronous optical network (SONET)/synchronous digital hierarchy (SDH) protocol; and
the second data framing protocol is one of an Ethernet protocol and a Fibre Channel protocol.
7. The data framer of claim 1, further comprising a scrambler/descrambler operatively coupled between the controller and at least one of the first framing circuit and the second framing circuit, the scrambler/descrambler, in a first mode of operation, being configured to selectively insert predetermined bit transitions into a destination data stream and, in a second mode of operation, being configured to selectively remove predetermined bit transitions from the source data stream.
8. The data framer of claim 1, wherein the controller is further operative to: (iii) detect the status of at least one of the framing circuits, the at least one framing circuit monitoring the source data stream for expected frame boundaries corresponding to the determined data framing protocol of the source data stream; and (iv) automatically determine a new data framing protocol corresponding to the source data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored source data stream.
9. The data framer of claim 1, wherein the controller is further operative to: (iii) detect the status of at least one of the framing circuits, the at least one framing circuit monitoring the source data stream for expected frame boundaries corresponding to the determined data framing protocol of the source data stream; and (iv) automatically determine a new data framing protocol corresponding to the source data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored source data stream for a predetermined number of consecutive frames of the source data stream.
10. The data framer of claim 1, wherein the controller is additionally configured to change a data framing protocol of the data framer in response to a user-selectable control signal presented to the data framer.
11. A method of transferring data between a source and a destination, the method comprising the steps of:
receiving an input data stream from the source;
automatically determining a data framing protocol corresponding to the input data stream from at least two data framing protocols potentially present in the input data stream;
in a first mode of operation, extracting data in accordance with the determined data framing protocol corresponding to the input data stream; and
in a second mode of operation, framing data in accordance with the determined data framing protocol corresponding to the input data stream.
12. The method of claim 11, further comprising the steps of:
monitoring the input data stream for expected frame boundaries corresponding to the determined data framing protocol of the input data stream; and
automatically determining a new data framing protocol corresponding to the input data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored input data stream.
13. The method of claim 11, further comprising the steps of:
monitoring the input data stream for expected frame boundaries corresponding to the determined data framing protocol of the input data stream; and
automatically determining a new data framing protocol corresponding to the input data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored input data stream for a predetermined number of consecutive frames of the input data stream.
14. The method of claim 11, wherein a first of the data framing protocols is a wide area network (WAN) protocol and a second of the data framing protocols is a local area network (LAN) protocol.
15. The method of claim 11, wherein a first of the data framing protocols is a synchronous optical network (SONET)/synchronous digital hierarchy (SDH) protocol and a second of the data framing protocols is one of an Ethernet protocol and a Fibre Channel protocol.
16. The method of claim 11, further comprising the steps of:
in a first mode of operation, selectively inserting one or more predetermined bit transitions into an output data stream; and
in a second mode of operation, selectively removing one or more predetermined bit transitions from the input data stream.
17. Apparatus for transferring data between a source and a destination, the apparatus being capable of supporting at least two different data framing protocols potentially present in a source data stream, the apparatus comprising:
at least one processor being operative to: (i) receive the source data stream; (ii) automatically determine a data framing protocol corresponding to the source data stream; (iii) in a first mode of operation, extract data in accordance with the determined data framing protocol corresponding to the source data stream; and (iv) in a second mode of operation, framing data in accordance with the determined data framing protocol corresponding to the source data stream.
18. The apparatus of claim 17, wherein the at least one processor is further operative to: (v) monitor the source data stream for expected frame boundaries corresponding to the determined data framing protocol of the source data stream; and (vi) automatically determine a new data framing protocol corresponding to the source data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored source data stream.
19. The apparatus of claim 17, wherein the at least one processor is further operative to: (v) monitor the source data stream for expected frame boundaries corresponding to the determined data framing protocol of the source data stream; and (vi) automatically determine a new data framing protocol corresponding to the source data stream when the expected frame boundaries do not substantially match frame boundaries corresponding to the monitored source data stream for a predetermined number of consecutive frames of the source data stream.
20. The apparatus of claim 17, wherein the at least one processor is further operative to: (v) in a first mode of operation, selectively insert one or more predetermined bit transitions into a destination data stream; and (vi) in a second mode of operation, selectively remove one or more predetermined bit transitions from the source data stream.
US10/153,321 2001-05-31 2002-05-22 Multi-protocol agile framer Expired - Fee Related US6654383B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/153,321 US6654383B2 (en) 2001-05-31 2002-05-22 Multi-protocol agile framer

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29497201P 2001-05-31 2001-05-31
US10/153,321 US6654383B2 (en) 2001-05-31 2002-05-22 Multi-protocol agile framer

Publications (2)

Publication Number Publication Date
US20020191640A1 true US20020191640A1 (en) 2002-12-19
US6654383B2 US6654383B2 (en) 2003-11-25

Family

ID=23135702

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/153,321 Expired - Fee Related US6654383B2 (en) 2001-05-31 2002-05-22 Multi-protocol agile framer

Country Status (4)

Country Link
US (1) US6654383B2 (en)
JP (1) JP4405257B2 (en)
CN (1) CN100499416C (en)
WO (1) WO2002098035A1 (en)

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030039207A1 (en) * 2001-08-21 2003-02-27 Koichi Maeda Transmission apparatus equipped with an alarm transfer device
US20030147425A1 (en) * 2002-02-04 2003-08-07 Syntera Communications Method and circuit for processing data in communication networks
US20040148555A1 (en) * 2003-01-24 2004-07-29 Dennis Blackburn Apparatus and method for accommodating loss of signal
US20040181810A1 (en) * 2003-03-12 2004-09-16 Wegener Communications, Inc. Recasting DVB video system to recast digital broadcasts
US20040193998A1 (en) * 2003-03-25 2004-09-30 Wegener Communications, Inc. Software download control system, apparatus and method
US20050135421A1 (en) * 2003-12-19 2005-06-23 Luke Chang Serial ethernet device-to-device interconnection
US20050147197A1 (en) * 2001-06-25 2005-07-07 Silicon Laboratories Inc. Method and apparatus for acquiring a frequency without a reference clock
US6988227B1 (en) * 2001-06-25 2006-01-17 Silicon Laboratories Inc. Method and apparatus for bit error rate detection
US20060077999A1 (en) * 2004-10-12 2006-04-13 Erran Kagan System and method for simultaneous communication on modbus and DNP 3.0 over Ethernet for electronic power meter
US20060085724A1 (en) * 2003-05-30 2006-04-20 Wegener Communications, Inc. Error correction apparatus and method
US20060098681A1 (en) * 2004-10-22 2006-05-11 Cisco Technology, Inc. Fibre channel over Ethernet
US20060171318A1 (en) * 2004-10-22 2006-08-03 Cisco Technology, Inc. Active queue management methods and devices
US20060195881A1 (en) * 2004-12-08 2006-08-31 Imagine Communications, Ltd. Distributed statistical multiplexing of multi-media
US20070058530A1 (en) * 2005-09-14 2007-03-15 Sbc Knowledge Ventures, L.P. Apparatus, computer readable medium and method for redundant data stream control
US20070133616A1 (en) * 2001-04-17 2007-06-14 Keller Richard B Utilizing available sonet overhead bytes for additional signaling channels
US20070260953A1 (en) * 2006-01-27 2007-11-08 Stmicroelectronics S.A. Scan test
US20080042757A1 (en) * 2006-08-04 2008-02-21 Zhuo Fu Robust false locking prevention in referenceless frequency acquisition
EP1971056A2 (en) * 2007-03-14 2008-09-17 Hitachi Communication Technologies, Ltd. Multiplexed optical signal transmission apparatus
US20090167943A1 (en) * 2007-12-27 2009-07-02 Vimicro Corporation Apparatus and Method for Synchronizing Video and Audio Data
US7570660B1 (en) * 2003-10-02 2009-08-04 Ciena Corporation Apparatus for implementing transparent subwavelength networks
US7801125B2 (en) 2004-10-22 2010-09-21 Cisco Technology, Inc. Forwarding table reduction and multipath network forwarding
US7830793B2 (en) 2004-10-22 2010-11-09 Cisco Technology, Inc. Network device architecture for consolidating input/output and reducing latency
USRE41919E1 (en) 2003-06-25 2010-11-09 Steve Olivier Rapid decryption of data by key synchronization and indexing
US7961621B2 (en) 2005-10-11 2011-06-14 Cisco Technology, Inc. Methods and devices for backward congestion notification
US7969971B2 (en) 2004-10-22 2011-06-28 Cisco Technology, Inc. Ethernet extension for the data center
US20110164622A1 (en) * 2007-03-14 2011-07-07 Yukihisa Tamura Operation and construction method of network using multi-rate interface panel
US8107491B2 (en) 2004-10-20 2012-01-31 Electro Industries/Gauge Tech System and method for providing communication between intelligent electronic devices via an open channel
US8121038B2 (en) 2007-08-21 2012-02-21 Cisco Technology, Inc. Backward congestion notification
US8149710B2 (en) 2007-07-05 2012-04-03 Cisco Technology, Inc. Flexible and hierarchical dynamic buffer allocation
US8180919B1 (en) * 2004-07-30 2012-05-15 Xilinx, Inc. Integrated circuit and method of employing a processor in an integrated circuit
US8238347B2 (en) 2004-10-22 2012-08-07 Cisco Technology, Inc. Fibre channel over ethernet
US8259720B2 (en) 2007-02-02 2012-09-04 Cisco Technology, Inc. Triple-tier anycast addressing
US20160309005A1 (en) * 2015-04-14 2016-10-20 Lsis Co., Ltd. Method of automatically setting protocol in programmable logic controller system
US10330713B2 (en) 2012-12-21 2019-06-25 Electro Industries/Gauge Tech Intelligent electronic device having a touch sensitive user interface
US10772101B2 (en) 2015-12-08 2020-09-08 Huawei Technologies Co., Ltd. Systems and methods for determining air interface configuration

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010030971A1 (en) * 2000-01-05 2001-10-18 Moody Francis A. Parallel interconnect implemented with hardware
DE10129108A1 (en) * 2001-06-16 2003-01-02 Harman Becker Automotive Sys Method and circuit arrangement for data transmission
JP2003078497A (en) * 2001-09-04 2003-03-14 Fujitsu Ltd Transmission device
WO2003071722A1 (en) * 2001-12-21 2003-08-28 Infineon Technologies Ag Multi-mode framer and pointer processor for optically transmitted data
US7164692B2 (en) * 2002-04-08 2007-01-16 Jeffrey Lloyd Cox Apparatus and method for transmitting 10 Gigabit Ethernet LAN signals over a transport system
US7020729B2 (en) * 2002-05-16 2006-03-28 Intel Corporation Protocol independent data transmission interface
US7362771B1 (en) 2002-05-30 2008-04-22 Marvell International Ltd. Reduced latency FIFO
US7729617B2 (en) 2002-06-04 2010-06-01 Samir Satish Sheth Flexible, dense line card architecture
US6983342B2 (en) * 2002-10-08 2006-01-03 Lsi Logic Corporation High speed OC-768 configurable link layer chip
US8160109B2 (en) * 2002-11-01 2012-04-17 Broadcom Corporation Method and system for synchronizing a transceiver and a downstream device in an optical transmission network
US7843922B1 (en) * 2002-12-18 2010-11-30 Cypress Semiconductor Corporation Method and apparatus for separation of control and data packets
US7493392B1 (en) 2002-12-20 2009-02-17 Cypress Semiconductor Corporation Method and apparatus for assembly of virtually concatenated data
US7420975B1 (en) 2002-12-20 2008-09-02 Cypress Semiconductor Corporation Method and apparatus for a high-speed frame tagger
US7020814B2 (en) * 2003-03-18 2006-03-28 Cisco Technology, Inc. Method and system for emulating a Fiber Channel link over a SONET/SDH path
US7522641B2 (en) * 2003-04-25 2009-04-21 Farrokh Mohamadi Ten gigabit copper physical layer system
US7187650B2 (en) * 2003-06-10 2007-03-06 Cisco Technology, Inc. Fibre channel frame-mode GFP with distributed delimiter
US6956847B2 (en) * 2003-06-19 2005-10-18 Cisco Technology, Inc. Multi-rate, multi-protocol, multi-port line interface for a multiservice switching platform
US7363395B2 (en) * 2003-12-31 2008-04-22 Intel Corporation Intermediate device capable of communicating using different communication protocols
US7568026B2 (en) * 2004-02-13 2009-07-28 Cisco Technology, Inc. Method and system for efficient link recovery for fibre channel over SONET/SDH transport path
US7653066B2 (en) * 2004-11-04 2010-01-26 Cisco Technology Inc. Method and apparatus for guaranteed in-order delivery for FICON over SONET/SDH transport
US7881341B2 (en) * 2005-09-30 2011-02-01 Intel Corporation Reconfigurable media controller to accommodate multiple data types and formats
JP4646839B2 (en) * 2006-03-17 2011-03-09 富士通株式会社 Optical transmission device, optical transmission system, and optical transmission method
US8793390B2 (en) * 2006-05-23 2014-07-29 Blue Coat Systems, Inc. Systems and methods for protocol detection in a proxy
JP2008258701A (en) * 2007-04-02 2008-10-23 Hitachi Communication Technologies Ltd Operation of network using multi-rate adaptive interface board, and actualizing method
FR2928059B1 (en) * 2008-02-22 2016-01-08 Thales Sa METHOD AND DEVICE FOR DELINEATION OF A DATA STREAM AND COMMUNICATION SYSTEM COMPRISING SAID DEVICE.
US8693864B2 (en) 2008-10-15 2014-04-08 Mitsubishi Electric Corporation Optical network system, optical redundant switching apparatus, and WDM apparatus
US20100131661A1 (en) * 2008-11-26 2010-05-27 Inventec Coprporation Fiber channel storage server
CN104717203B (en) * 2015-02-02 2019-01-11 珠海格力电器股份有限公司 Bus communication protocol recognition methods
JP6629450B2 (en) * 2015-12-08 2020-01-15 ホアウェイ・テクノロジーズ・カンパニー・リミテッド System and method for user equipment state configuration for multiple services
CN105553601B (en) * 2015-12-09 2019-06-25 浪潮电子信息产业股份有限公司 For the SDH framer design method of the verification platform of height reusability
CN108712784B (en) * 2018-05-11 2020-07-24 成都六零加信息技术有限公司 Communication method and device
CN109739918A (en) * 2018-12-29 2019-05-10 联想(北京)有限公司 A kind of information processing method and equipment

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4935925A (en) * 1987-03-11 1990-06-19 Aristacom International, Inc. Adaptive digital network interface
US5428614A (en) * 1990-09-26 1995-06-27 Shaver; Christopher J. Expected value data framer and method
US5696899A (en) * 1992-11-18 1997-12-09 Canon Kabushiki Kaisha Method and apparatus for adaptively determining the format of data packets carried on a local area network
US5619650A (en) * 1992-12-31 1997-04-08 International Business Machines Corporation Network processor for transforming a message transported from an I/O channel to a network by adding a message identifier and then converting the message
US5613096A (en) * 1994-11-04 1997-03-18 Canon Information Systems, Inc. Network protocol sensor
US5533018A (en) * 1994-12-21 1996-07-02 National Semiconductor Corporation Multi-protocol packet framing over an isochronous network
US5568471A (en) * 1995-09-06 1996-10-22 International Business Machines Corporation System and method for a workstation monitoring and control of multiple networks having different protocols
US5826018A (en) * 1996-04-02 1998-10-20 Hewlett-Packard Company Method and appparatus for automatically determining the starting location and starting protocol of LAN data in a WAN link frame
US5842039A (en) * 1996-05-28 1998-11-24 Allen Bradley Company, Llc Most recent first dynamic protocol detection for use with a programmable controller
US6108350A (en) * 1998-03-09 2000-08-22 3Com Corporation Method and apparatus for detecting the protocol used by an end station and negotiating a protocol used by the endpoint
US6330287B1 (en) * 1999-02-26 2001-12-11 Trw Inc. Digital channelizer having efficient architecture for window presum using distributed arithmetic for providing window presum calculations in one clock cycle

Cited By (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
USRE43420E1 (en) 2001-04-17 2012-05-29 Null Networks Llc Utilizing available SONET overhead bytes for additional signaling channels
US7564849B2 (en) * 2001-04-17 2009-07-21 Keller Richard B Utilizing available SONET overhead bytes for additional signaling channels
US20070133616A1 (en) * 2001-04-17 2007-06-14 Keller Richard B Utilizing available sonet overhead bytes for additional signaling channels
US7205852B2 (en) 2001-06-25 2007-04-17 Silicon Laboratories Inc. Method and apparatus for acquiring a frequency without a reference clock
US20050147197A1 (en) * 2001-06-25 2005-07-07 Silicon Laboratories Inc. Method and apparatus for acquiring a frequency without a reference clock
US6988227B1 (en) * 2001-06-25 2006-01-17 Silicon Laboratories Inc. Method and apparatus for bit error rate detection
US20030039207A1 (en) * 2001-08-21 2003-02-27 Koichi Maeda Transmission apparatus equipped with an alarm transfer device
US20070076624A1 (en) * 2002-02-04 2007-04-05 Andy Annadurai Method and circuit for processing data in communication networks
US20030147425A1 (en) * 2002-02-04 2003-08-07 Syntera Communications Method and circuit for processing data in communication networks
US7292607B2 (en) * 2002-02-04 2007-11-06 Sartre Satire Llc Method and circuit for processing data in communication networks
US7684442B2 (en) 2002-02-04 2010-03-23 Andy Annadurai Method and circuit for processing data in communication networks
US7263648B2 (en) 2003-01-24 2007-08-28 Wegener Communications, Inc. Apparatus and method for accommodating loss of signal
US20040148555A1 (en) * 2003-01-24 2004-07-29 Dennis Blackburn Apparatus and method for accommodating loss of signal
US7032235B2 (en) 2003-03-12 2006-04-18 Wegener Communications, Inc. Recasting DVB video system to recast digital broadcasts
US20040181810A1 (en) * 2003-03-12 2004-09-16 Wegener Communications, Inc. Recasting DVB video system to recast digital broadcasts
US7171606B2 (en) 2003-03-25 2007-01-30 Wegener Communications, Inc. Software download control system, apparatus and method
US20040193998A1 (en) * 2003-03-25 2004-09-30 Wegener Communications, Inc. Software download control system, apparatus and method
US7937638B2 (en) 2003-05-30 2011-05-03 Wegener Communications, Inc. Error correction apparatus and method
US20080228787A1 (en) * 2003-05-30 2008-09-18 Wegener Communications, Inc. Error Correction Apparatus and Method
US20060085724A1 (en) * 2003-05-30 2006-04-20 Wegener Communications, Inc. Error correction apparatus and method
US7506235B2 (en) 2003-05-30 2009-03-17 Wegener Communications Error correction apparatus and method
USRE41919E1 (en) 2003-06-25 2010-11-09 Steve Olivier Rapid decryption of data by key synchronization and indexing
US7570660B1 (en) * 2003-10-02 2009-08-04 Ciena Corporation Apparatus for implementing transparent subwavelength networks
US7751442B2 (en) * 2003-12-19 2010-07-06 Intel Corporation Serial ethernet device-to-device interconnection
US20060153238A1 (en) * 2003-12-19 2006-07-13 Gershon Bar-On Transfer of control data between network components
US20050135421A1 (en) * 2003-12-19 2005-06-23 Luke Chang Serial ethernet device-to-device interconnection
US8180919B1 (en) * 2004-07-30 2012-05-15 Xilinx, Inc. Integrated circuit and method of employing a processor in an integrated circuit
US7609719B2 (en) * 2004-10-12 2009-10-27 Electro Industries/Gauge Tech System and method for simultaneous communication on modbus and DNP 3.0 over Ethernet for electronic power meter
US9705703B2 (en) 2004-10-12 2017-07-11 Electro Industries/Gauge Tech System and method for simultaneous communication on Modbus and DNP 3.0 over Ethernet for electronic power meter
US20060077999A1 (en) * 2004-10-12 2006-04-13 Erran Kagan System and method for simultaneous communication on modbus and DNP 3.0 over Ethernet for electronic power meter
US8189617B2 (en) 2004-10-12 2012-05-29 Electro Industries/Gauge Tech System and method for simultaneous communication on Modbus and DNP 3.0 over Ethernet for electronic power meter
US20100046545A1 (en) * 2004-10-12 2010-02-25 Electro Industries/Gauge Tech System and method for simultaneous communication on modbus and dnp 3.0 over ethernet for electronic power meter
US8107491B2 (en) 2004-10-20 2012-01-31 Electro Industries/Gauge Tech System and method for providing communication between intelligent electronic devices via an open channel
US7801125B2 (en) 2004-10-22 2010-09-21 Cisco Technology, Inc. Forwarding table reduction and multipath network forwarding
US7564869B2 (en) 2004-10-22 2009-07-21 Cisco Technology, Inc. Fibre channel over ethernet
US9246834B2 (en) 2004-10-22 2016-01-26 Cisco Technology, Inc. Fibre channel over ethernet
WO2006047194A3 (en) * 2004-10-22 2007-04-19 Cisco Tech Inc Fibre channel over ethernet
US20060098681A1 (en) * 2004-10-22 2006-05-11 Cisco Technology, Inc. Fibre channel over Ethernet
US8160094B2 (en) 2004-10-22 2012-04-17 Cisco Technology, Inc. Fibre channel over ethernet
US8842694B2 (en) 2004-10-22 2014-09-23 Cisco Technology, Inc. Fibre Channel over Ethernet
US7830793B2 (en) 2004-10-22 2010-11-09 Cisco Technology, Inc. Network device architecture for consolidating input/output and reducing latency
US8238347B2 (en) 2004-10-22 2012-08-07 Cisco Technology, Inc. Fibre channel over ethernet
US20060171318A1 (en) * 2004-10-22 2006-08-03 Cisco Technology, Inc. Active queue management methods and devices
US8532099B2 (en) 2004-10-22 2013-09-10 Cisco Technology, Inc. Forwarding table reduction and multipath network forwarding
US7969971B2 (en) 2004-10-22 2011-06-28 Cisco Technology, Inc. Ethernet extension for the data center
US8565231B2 (en) 2004-10-22 2013-10-22 Cisco Technology, Inc. Ethernet extension for the data center
US7602720B2 (en) 2004-10-22 2009-10-13 Cisco Technology, Inc. Active queue management methods and devices
US20060195881A1 (en) * 2004-12-08 2006-08-31 Imagine Communications, Ltd. Distributed statistical multiplexing of multi-media
US8621543B2 (en) * 2004-12-08 2013-12-31 Imagine Communications Ltd. Distributed statistical multiplexing of multi-media
US20070058530A1 (en) * 2005-09-14 2007-03-15 Sbc Knowledge Ventures, L.P. Apparatus, computer readable medium and method for redundant data stream control
US7961621B2 (en) 2005-10-11 2011-06-14 Cisco Technology, Inc. Methods and devices for backward congestion notification
US8792352B2 (en) 2005-10-11 2014-07-29 Cisco Technology, Inc. Methods and devices for backward congestion notification
US7739566B2 (en) * 2006-01-27 2010-06-15 Stmicroelectronics S.A. Scan test circuitry using a state machine and a limited number of dedicated pins
US20070260953A1 (en) * 2006-01-27 2007-11-08 Stmicroelectronics S.A. Scan test
US7375591B2 (en) 2006-08-04 2008-05-20 Silicon Laboratories Inc. Robust false locking prevention in referenceless frequency acquisition
US20080042757A1 (en) * 2006-08-04 2008-02-21 Zhuo Fu Robust false locking prevention in referenceless frequency acquisition
US8743738B2 (en) 2007-02-02 2014-06-03 Cisco Technology, Inc. Triple-tier anycast addressing
US8259720B2 (en) 2007-02-02 2012-09-04 Cisco Technology, Inc. Triple-tier anycast addressing
EP1971056A3 (en) * 2007-03-14 2014-11-19 Hitachi, Ltd. Multiplexed optical signal transmission apparatus
EP1971056A2 (en) * 2007-03-14 2008-09-17 Hitachi Communication Technologies, Ltd. Multiplexed optical signal transmission apparatus
US20110164622A1 (en) * 2007-03-14 2011-07-07 Yukihisa Tamura Operation and construction method of network using multi-rate interface panel
US8149710B2 (en) 2007-07-05 2012-04-03 Cisco Technology, Inc. Flexible and hierarchical dynamic buffer allocation
US8121038B2 (en) 2007-08-21 2012-02-21 Cisco Technology, Inc. Backward congestion notification
US8804529B2 (en) 2007-08-21 2014-08-12 Cisco Technology, Inc. Backward congestion notification
US20090167943A1 (en) * 2007-12-27 2009-07-02 Vimicro Corporation Apparatus and Method for Synchronizing Video and Audio Data
US10330713B2 (en) 2012-12-21 2019-06-25 Electro Industries/Gauge Tech Intelligent electronic device having a touch sensitive user interface
US20160309005A1 (en) * 2015-04-14 2016-10-20 Lsis Co., Ltd. Method of automatically setting protocol in programmable logic controller system
US10044838B2 (en) * 2015-04-14 2018-08-07 Lsis Co., Ltd. Method of automatically setting protocol in programmable logic controller system
US10772101B2 (en) 2015-12-08 2020-09-08 Huawei Technologies Co., Ltd. Systems and methods for determining air interface configuration

Also Published As

Publication number Publication date
US6654383B2 (en) 2003-11-25
CN1520652A (en) 2004-08-11
WO2002098035A1 (en) 2002-12-05
CN100499416C (en) 2009-06-10
JP4405257B2 (en) 2010-01-27
JP2005508106A (en) 2005-03-24

Similar Documents

Publication Publication Date Title
US6654383B2 (en) Multi-protocol agile framer
US7916756B2 (en) Transmission apparatus
US6690682B1 (en) Bit multiplexing of packet-based channels
US7031341B2 (en) Interfacing apparatus and method for adapting Ethernet directly to physical channel
CA2459286C (en) Method for supporting sdh/sonet aps on ethernet
US6584535B1 (en) Configurable serial interconnection
US6366557B1 (en) Method and apparatus for a Gigabit Ethernet MAC (GMAC)
US6771671B1 (en) Data flow synchronization and ordering
US7372854B2 (en) Communication node system, control node system, and communication system using node systems in ethernet-passive optical network
US11659072B2 (en) Apparatus for adapting a constant bit rate client signal into the path layer of a telecom signal
JP6867473B2 (en) Methods and equipment for sending services, methods and equipment for receiving services, and network systems.
US7308006B1 (en) Propagation and detection of faults in a multiplexed communication system
WO2001006728A1 (en) Data transmission apparatus and method for transmitting data between physical layer side device and network layer device
JP6236945B2 (en) Transmission apparatus, transmission system, and transmission method
EP1489782A1 (en) Data transfer device,method and system using fragmentation and reassembly
US7570667B1 (en) System, apparatus, and method for increasing resiliency in communications
US7295554B1 (en) Word Multiplexing of encoded signals into a higher bit rate serial data stream
US7953106B2 (en) Transmission apparatus
US7948904B1 (en) Error detection for data frames
US7590135B2 (en) Methods and apparatus to perform security related operations on received signals
US20020037018A1 (en) Apparatus and method for reducing the line rate of time-multiplexed signals
KILARU et al. Possibilities of implementation of synchronous Ethernet in popular Ethernet version using timing and interference constraints
US8428073B1 (en) Learning and unlearning in a network switch
EP0717537A1 (en) Line coding for ATM

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HAYMES, CHARLES LOUIS;RITTER, MARK B.;ROWER, THOMAS;REEL/FRAME:012930/0471

Effective date: 20020521

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
AS Assignment

Owner name: GOOGLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:026894/0001

Effective date: 20110817

FPAY Fee payment

Year of fee payment: 8

SULP Surcharge for late payment

Year of fee payment: 7

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20151125

AS Assignment

Owner name: GOOGLE LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044142/0357

Effective date: 20170929