WO2019170064A1 - 光网络中以太数据处理的方法、装置和系统 - Google Patents

光网络中以太数据处理的方法、装置和系统 Download PDF

Info

Publication number
WO2019170064A1
WO2019170064A1 PCT/CN2019/076905 CN2019076905W WO2019170064A1 WO 2019170064 A1 WO2019170064 A1 WO 2019170064A1 CN 2019076905 W CN2019076905 W CN 2019076905W WO 2019170064 A1 WO2019170064 A1 WO 2019170064A1
Authority
WO
WIPO (PCT)
Prior art keywords
path
data
data frame
information
overhead information
Prior art date
Application number
PCT/CN2019/076905
Other languages
English (en)
French (fr)
Inventor
苏伟
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP19764123.6A priority Critical patent/EP3755001A4/en
Publication of WO2019170064A1 publication Critical patent/WO2019170064A1/zh
Priority to US17/013,131 priority patent/US11223422B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
    • H04J3/1605—Fixed allocated frame structures
    • H04J3/1652—Optical Transport Network [OTN]
    • H04J3/1658—Optical Transport Network [OTN] carrying packets or ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/07—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems
    • H04B10/075—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal
    • H04B10/079—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal using measurements of the data signal
    • H04B10/0795—Performance monitoring; Measurement of transmission parameters
    • H04B10/07953—Monitoring or measuring OSNR, BER or Q
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/27—Arrangements for networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001—Provisions 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/0073—Services, e.g. multimedia, GOS, QOS
    • H04J2203/0082—Interaction of SDH with non-ATM protocols
    • H04J2203/0085—Support of Ethernet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0079—Operation or maintenance aspects

Definitions

  • the embodiments of the present application relate to the field of optical communications, and in particular, to an Ethernet data processing technology in an optical network.
  • FlexE 1.0 specifies the implementation of different rates of service transmission by binding n 100G physical links (PHY), such as 10G, n*25G, 40G, and so on. This technology is mainly used in short-distance scenarios such as data center equipment interconnection.
  • PHY physical links
  • This technology is mainly used in short-distance scenarios such as data center equipment interconnection.
  • OTN optical transport network
  • OTN-bearing FlexE data-related standards are developed by the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) to determine FlexE service data through OTN containers such as Flexible Optical Data Unit (ODUflex). To carry it.
  • ITU-T International Telecommunication Union-Telecommunication Standardization Sector
  • ODUflex Flexible Optical Data Unit
  • the mapping method used by the FlexE service data mapping to the ODUflex is an Idle Mapping Procedure (IMP).
  • ETH Optical Data Unit k
  • BMP Bit-Synchronous Mapping Procedure
  • GMP Generic Mapping Procedure
  • ODUk Optical Data Unit k
  • the current solution formats the interface data of one format on the client side interface of the first node or the last node of the OTN path, converts the interface data into another format, and then the interface data. Send it out.
  • This kind of solution requires the planning and design of the format conversion capability of the client-side interface during network construction. Otherwise, this interworking requirement cannot be supported and is not flexible enough.
  • the embodiments of the present application describe a method, apparatus, and system for Ethernet data processing to improve flexibility in supporting FlexE and ETH interface interworking.
  • an embodiment of the present application provides a method for data processing in an optical network.
  • the method includes:
  • an optical network device After an optical network device extracts the Ethernet data from the data frame of the first path, and converts the Ethernet data into another format, the converted Ethernet data into another format is placed into the data frame of the second path.
  • the optical network device is a destination device of the first path and is a source device of the second path;
  • the optical network device proposes overhead information from a data frame of the first path, and inserts the overhead information into a data frame of the second path.
  • the format of the Ethernet data is a flexible Ethernet (FlexE) service frame format, and the other frame format is an Ethernet data format other than the FlexE service frame format; or the Ethernet The format of the data is an Ethernet data format other than the FlexE service frame format, and the other frame format is a FlexE service frame format.
  • FlexE flexible Ethernet
  • the other frame format is an Ethernet data format other than the FlexE service frame format
  • the data frame type of the first path is a flexible optical data unit (ODUflex), and the data frame type of the second path is an optical data unit k (ODUk); or, the first The data frame type of the path is ODUk, and the data frame type of the second path is ODUflex; or the data frame type of the first path and the second path are both ODUflex.
  • ODUflex flexible optical data unit
  • ODUk optical data unit k
  • the above overhead insertion has various forms, including: direct insertion, insertion after mathematical operation, first buffering, and then insertion.
  • the optical network device proposes overhead information from a data frame of the first path, and inserts the overhead information into a data frame of the second path, including: the optical network.
  • the device extracts first overhead information from the data frame of the first path; the optical network device directly inserts the first overhead information into a data frame of the second path.
  • the first overhead information is a path trace identifier, status information, and the like.
  • the optical network device proposes the overhead information from the data frame of the first path, and inserts the overhead information into the data frame of the second path, including:
  • the optical network device extracts second overhead information from a data frame of the first path
  • the optical network device acquires third overhead information according to the second overhead information and the data frame information of the third path, where the third path and the second path are mutually reverse paths;
  • the optical network device directly inserts the third overhead information into a data frame of the second path.
  • the second overhead information includes one or more of a backward defect indication (BDI) and a backward error indication (BEI).
  • the data frame information of the third path includes verification information and error indication information.
  • the method may also include one or more of the following overhead processing steps:
  • the payload type information includes a service type and a mapping manner
  • the fourth overhead information is one or more of protection switching indication information, delay measurement information, and general communication channel information.
  • the network device may select one or more of the above various designs according to a specific design.
  • an embodiment of the present application provides a data processing apparatus.
  • the apparatus includes a processor and a memory coupled to the memory, the processor for performing the method as described in the first aspect or any one of the first aspects.
  • an embodiment of the present application provides a data processing apparatus.
  • the apparatus includes a processor coupled to a memory for reading instructions in the memory to implement the method as described in the first aspect or the first aspect.
  • an embodiment of the present application provides an optical network system.
  • the system includes a first device, a second device, and a third device, wherein the second device includes the data processing device described in any one of the second aspect or the second aspect, the first device is a source device of the first path, where the third device is a destination device of the second path.
  • an embodiment of the present invention provides a computer storage medium, comprising instructions, when executed on a computer, causing a computer to perform the method provided by any of the above first aspect or the first aspect.
  • an embodiment of the present application provides a computer program product comprising instructions, when executed on a computer, causing a computer to perform the method provided by any of the above first aspect or the first aspect.
  • the solution provided by the present application can implement data format conversion through the network side interface of the intermediate device or the first and last nodes, without pre-planning design of the device interface capability, and improving the flexibility of interworking between the FlexE interface and the ETH interface. Sex.
  • the intermediate device also manages the two OTN paths in a unified manner through overhead processing, which reduces the complexity of management.
  • FIG. 1 is a schematic diagram of a possible application scenario according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of a possible hardware structure of a network device
  • FIG. 3 is a schematic flow chart of a possible data processing method
  • Figure 4a is a schematic diagram of possible Ethernet data and overhead processing
  • Figure 4b is another schematic diagram of possible Ethernet data and overhead conversion
  • Figure 4c is another schematic diagram of possible Ethernet data and overhead conversion
  • FIG. 5 is a schematic diagram of a flow of a data processing method provided by an embodiment
  • FIG. 6 is a schematic diagram of overhead processing provided by an embodiment
  • FIG. 7 is a schematic structural diagram of a possible network device.
  • the network architecture and the service scenario described in the embodiments of the present application are for the purpose of more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation of the technical solutions provided by the embodiments of the present application.
  • the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems, as the network architecture evolves and the new service scenario occurs.
  • optical network such as an Optical Transport Network (OTN).
  • OTN Optical Transport Network
  • An optical network is usually connected by multiple devices through optical fibers. It can be composed of different topology types such as line type, ring shape, and mesh type according to specific needs.
  • the optical network 201 shown in FIG. 1 is a mesh network composed of eight devices 202. Wherein, 203 indicates an optical fiber; and 204 indicates a customer service interface for realizing transmission of customer service data.
  • a network may have multiple customer service interfaces 204.
  • the customer service interface is sometimes referred to as the User Network Interface (UNI).
  • Device 202 may have different functions depending on actual needs. In general, optical network devices are classified into optical layer devices, electrical layer devices, and opto-electric hybrid devices.
  • An optical layer device refers to a device that can process optical layer signals, such as an optical amplifier (OA) and an optical add-drop multiplexer (OADM).
  • OA optical amplifier
  • OADM optical add-drop multiplexer
  • OVA Optical Line Amplifier
  • OADM is used to spatially transform optical signals so that they can be output from different output ports (sometimes referred to as directions).
  • OADM can be divided into fixed OADM (Fixed OADM, FOADM), configurable OADM (Reconfigurable OADM, ROADM) and so on.
  • a electrical layer device refers to a device capable of processing electrical layer signals, such as a device capable of processing an Optical Data Unit (ODU) signal.
  • An opto-electric hybrid device refers to a device that has both the ability to process optical layer signals and electrical layer signals. It should be noted that, according to specific integration needs, the optical network device can aggregate devices with multiple different functions. The present application is applicable to optical network devices of different forms and integrations. Unless otherwise indicated, devices referred to herein that implement the techniques disclosed herein include at least the processing capabilities of electrical layer signals.
  • FIG. 2 shows a hardware structure diagram of an optical network device 202.
  • the device 202 includes a power source 202A, a fan 202B, and an auxiliary board 202C, and may further include a tributary board 202D, a circuit board 202E, a cross board 202F, an optical layer processing board (not shown), and programmable.
  • the service board 202G and the system control and communication type board 202H It should be noted that the type and number of boards specifically included in one device 202 may be different according to specific needs. For example, a network device that is a core node may not have a tributary board 202D. A network device that is an edge node may have multiple tributary boards 202D.
  • the power source 202A is used to supply power to the device, and may include primary and backup power sources.
  • Fan 202B is used to dissipate heat from the device.
  • the auxiliary board 202C is used to provide external alarms or access auxiliary functions such as an external clock.
  • the tributary board 202D, the cross board 202F, the circuit board 202E, and the programmable service board 202G are primarily electrical layer signals (e.g., ODU frames in the OTN) for processing the optical network.
  • the tributary board 202D is used for receiving and transmitting various customer services, such as Synchronous Digital Hierachy (SDH) services, packet services, Ethernet services, and pre-transmission services.
  • SDH Synchronous Digital Hierachy
  • the tributary board 202D can be divided into a client side optical module and a processor.
  • the client side optical module may be an optical transceiver for receiving and/or transmitting a client signal.
  • the processor is configured to implement mapping and demapping processing of the client signal to the ODU frame.
  • the cross-board 202F is used to implement the exchange of ODU frames to complete the exchange of one or more types of ODU signals.
  • the circuit board 202E mainly implements processing of the line side ODU frame.
  • the circuit board 202E can be divided into a line side optical module and a processor.
  • the line side optical module may be a line side optical transceiver for receiving and/or transmitting an ODU signal.
  • the processor is configured to implement multiplexing and demultiplexing of the ODU frame on the line side, or mapping and demapping processing.
  • the programmable service board 202G is used to implement the data processing method disclosed herein.
  • the system control and communication type board 202H is used to implement system control and communication. Specifically, information can be collected from different boards through the backplane, or control commands can be sent to the corresponding boards.
  • a specific component for example, a processor
  • the present application does not impose any limitation.
  • the embodiment of the present application does not impose any limitation on the type of the board included in the device, and the specific functional design and quantity of the board.
  • the devices mentioned later include at least a programmable service board 202G. It should be noted that the programmable service board 202G can also be integrated with other boards into one board. The present application does not impose any limitation on the board name that specifically implements the data processing technology disclosed in the present application.
  • MAC Media Access Cotnrol
  • the FlexE interface supports multiple rates such as 10G, 25G, 40G, and 100G.
  • the ETH interface also supports different rates, such as 10G, 25G, and 100G.
  • the difference is that when two interfaces are mapped to OTN, their mapping paths are different.
  • the FlexE interface signal is mapped into the ODUflex through the IMP.
  • the ETH interface data may be mapped to ODUk or ODUflex through GMP or BMP.
  • the present application provides a data processing technique. It should be noted that this technique is applied to any device on a path connecting two different interfaces.
  • a path connecting two different interfaces is ABCGF
  • the node implementing the data processing technology is one of A, B, C, G, and F.
  • the data processing technology is implemented on the network side interface, not on the client side interface.
  • the so-called client-side interface means that the interface is directly connected to the client interface through a link, and is usually located on the tributary board 202D shown in FIG. 2.
  • the network side interface refers to that the interface is directly connected to other network devices that are also used for service transmission through a link, and is usually located on the circuit board 202E shown in FIG. 2.
  • the advantage of this is that there is no need to plan ahead for the client-side interface capability of the network device.
  • interworking with different Ethernet interfaces is required, use the device that can provide conversion capability in the network or add the conversion capability to the required device in real time. Yes, it provides a certain flexibility, in addition to reducing the cost of network upgrades.
  • the advantage over the prior art is that the network side interface can support the conversion requirements of different client side interfaces on the same device.
  • the first path does not pass through the fiber link in the network, but only exists in the first node or the end node.
  • the data processing technology provided by the present application can also be applied to other more complicated scenarios, for example, a scenario that requires two or more data conversions.
  • an OTN container has a corresponding data frame format, and unless otherwise specified, containers and data frames may be used interchangeably in this application.
  • Figure 3 shows a schematic flow chart of a possible data processing.
  • the data processing method includes two major steps, one is data processing or data conversion, and the other is overhead processing.
  • the process includes:
  • An optical network device extracts the Ethernet data from the data frame of the first path, and converts the Ethernet data into another format, and then inserts the data into the second path by converting the Ethernet data into another format.
  • the optical network device is a destination device of the first path and is a source device of the second path;
  • the optical network device may be an intermediate device to support interface interworking requirements of multiple different service paths.
  • the first path and the second path are connected in series through the optical network device, thereby implementing data transmission on two different types of interfaces, that is, two paths are connected in series to form one path supporting end-to-end data transmission.
  • the path as ABCGF and device B as an example to implement the data processing technology
  • the AB constitutes a path, that is, the first path is used to carry the above-mentioned Ethernet data
  • the BCGF constitutes another path, that is, the second path. Used to carry Ethernet data in another format.
  • the intermediate device processes the Ethernet data carried in the received optical network data frame, converts it into a target format, and then places it into the data frame to be sent.
  • the Ethernet data may be data in the FlexE interface format or data in the ETH interface format.
  • another format may be the ETH interface format or the FlexE interface format. This conversion allows the peer interface to receive the data correctly and perform the necessary data processing. For example, the MAC frame data stream is parsed from the data.
  • the optical network device sends overhead information from a data frame of the first path, and inserts the overhead information into a data frame of the second path.
  • the intermediate device needs to extract the overhead information in the data frame of the first path, and insert the overhead information into the data frame of the second path in a certain manner.
  • This is different from the traditional approach, which is that each path generates overhead independently.
  • the advantage of this is that the management of the two paths can be reduced to the management of one path, reducing the management cost.
  • there may be a plurality of specific contents included in the overhead information, and the corresponding insertion methods are not necessarily the same, for example, direct insertion, insertion after mathematical operations, first caching, and then insertion. Specifically, please refer to FIG. 6 and related descriptions, which are not described herein.
  • FIG. 4a-c show examples of four possible intermediate devices for Ethernet data processing and overhead processing. It should be noted that these examples are also applicable to the scenario where the network side boards of the source node and the last node device mentioned above have the data processing capability disclosed in the present application. It should also be noted that the rate of the FlexE Client in Figures 4a-c is not indicated in the figure. Unless otherwise specified, the rate is the same as the corresponding ETH interface rate. The same is not strictly equal, but the rate difference is small.
  • the FlexE Clients for ETH rates at 10Gbps, 40Gbps, and 100Gbps are 10Gbps, 40Gbps, and 100Gbps, respectively. It should also be noted that these specific interfaces and data formats are merely examples. The data processing given in this application is applicable to formats that are currently in use but not shown, as well as new Ethernet interfaces and data formats that may appear later. .
  • Figure 4a shows a schematic diagram of possible Ethernet data and overhead processing. This example is for interface rates of 10G and 25G.
  • the left side of Figure 4a shows some operations of the FlexE interface and the data frame format for this interface.
  • the FlexE Client is the data format corresponding to the FlexE interface.
  • the signal may be a 66b code block stream defined by Chapter 82 of the Institute of Electrical and Electronics Engineers (IEEE) 802.3 standard (where b represents a bit).
  • ODUflex is an OTN container that carries the FlexE Client. Specifically, the IMPE client data frame is mapped to the ODUflex when the IMP is used.
  • the FlexE Shim is the adaptation sublayer of the FlexE interface that multiplexes multiple FlexE Clients to the 100-way Ethernet physical link.
  • the corresponding basic frame format is the FlexE instance frame format.
  • the FlexE Shim can include multiple FlexE instance frames that are multiplexed.
  • the right side of Figure 4a shows the ETH interface.
  • the mapping method adopted is BMP.
  • ETHXGR can use the 66b code block stream defined in Chapter 49 of the IEEE 802.3 standard.
  • Figure 4a includes the conversion of the FlexE interface to the ETH interface, or the conversion of the ETH interface to the FlexE interface.
  • the specific operations of the intermediate device are separately described below. It should be noted that the intermediate device receives the Ethernet data through the OTN container and performs corresponding processing.
  • these processes are performed by the first node or the last node, and are subsequently omitted when specifically explaining the operation of the intermediate device.
  • the intermediate device demaps the FlexE Client from ODUflex and converts data to form ETCXGR, for example: ETC10GR or ETC25GR. Then, the intermediate device maps the ETCXGR to the corresponding OTN container through the BMP mode, for example, ODU2e or ODUflex. This completes the conversion of the Ethernet data (ie FlexE Client). In addition, the intermediate device needs to take out the corresponding overhead from the received ODUflex and insert it into the corresponding OTN container obtained previously.
  • Figures 2b and 4c show two other possible Ethernet data and overhead processing diagrams.
  • the corresponding rates of the two graphs are: 40G and 100G respectively.
  • the data format of the ETH interface is the same as that of Figure 4a, which is also ETCXGR.
  • Figure 4c corresponds to 10G, 40G and 100G.
  • the data format of the ETH interface is MAC frame data format.
  • the operation of the intermediate device is similar to that explained above with respect to Figure 4a. The main difference is that there is one or more differences in the data format, rate, or mapping method. Explain separately below.
  • the operation of the intermediate node differs from that of Figure 4a in that: first, the processed signal rate is different, the rate in Figure 4b is higher, and the corresponding mapping/demapping of the data format for the ETH interface is different. , using GMP. Second, data processing is also different. Specifically, in Figure 4a, the intermediate device only needs to convert the code block stream of another format from the 66b code block stream of one format. In FIG. 4b, the intermediate device needs to perform other processing, such as deletion or addition of an idle code block, and an operation of inserting or deleting the indication information. Specifically, the ETH interface is converted to a FlexE interface and X is 40 as an example.
  • the intermediate device first parses the ETC40GR from the ODU3; then, the intermediate device deletes the alignment indication information included in the ETC40GR, and then inserts the idle code block, that is, performs rate compensation or rate adaptation, thereby obtaining a 40G FlexE client; finally, the The intermediate device maps the FlexE Client to the ODUflex through the IMP. It should be noted that, before the insertion of the idle code block, if the ETC 40GR is subjected to scrambling processing in the ODU 3 through the ETH interface, the intermediate device also needs to perform descrambling processing.
  • Figure 4a and 4b focus on the ETH interface data format is the Ethernet physical coding format (ie ETCXGR),
  • Figure 4c is for the ETH interface data format is the MAC Ethernet data frame format. That is to say, there are various data formats corresponding to the ETH interface.
  • the interface conversion process of Figure 4c is specifically described below.
  • the intermediate device For data processing, the intermediate device first performs 66b decoding on the FlexE client to form Media Independent Interface (MII) interface data, and then performs processing such as frame gap addition or deletion, and converts to The corresponding MAC frame data stream is then mapped to the OTN container by GFP via the GFP.
  • MII Media Independent Interface
  • Different speeds of the FlexE Client correspond to different OTN containers. Specifically, the 10FlexE Client corresponds to ODU2, the 40G rate corresponds to ODU3, and the 100G corresponds to ODU4.
  • the intermediate device also needs overhead processing.
  • ETH interface to FlexE interface This process is the inverse of the above conversion of FlexE interface to ETH interface. Specifically, the intermediate device performs frame gap addition or deletion processing on the MAC frame data stream, and forms MII interface data, and performs 66b encoding on the MII interface data to generate a FlexE client. The intermediate device then maps the FlexE Client to ODUflex via the IMP. Similarly, overhead is also handled as an insert.
  • the solution provided by the present application can implement data format conversion through the intermediate device, the client side interface of the first node, or the client interface of the last node, without prior planning and design, and the flexibility of realizing the interworking between the FlexE interface and the ETH interface is improved.
  • the device that implements the data format conversion manages the two OTN paths in a unified manner, which reduces the management complexity.
  • one or more of the above mentioned first path and second path may directly utilize optical fiber transmission.
  • the ODUk can be encapsulated into the OTUk format and sent out through the optical transmitter.
  • one or more of the first path and the second path may be multiplexed onto a higher rate path for transmission.
  • the ODU1 or ODUflex can be encapsulated into a higher-rate ODUk (for example, ODU2, ODU3, or ODUCn, etc.) and then sent out.
  • One embodiment of the present application provides a method, apparatus, and system for data processing.
  • the network scenario of FIG. 1 is taken as an example. It is assumed that the device at the transmitting end is A, the device at the receiving end is F, and the device responsible for converting is C. It should be noted that A, C and F are only examples and can be replaced with other devices. In this embodiment, the types of UNI interfaces supported by A and F are different. For example, the A device supports the ETH interface, while the F device supports the FlexE interface.
  • FIG. 5 is a schematic flowchart diagram of the embodiment. Each step is described in detail below.
  • S501 Send a data frame that carries the Ethernet data.
  • the device A After acquiring the Ethernet data from the UNI interface, the device A encapsulates the data into an optical network data frame and sends it out.
  • the format of the Ethernet data is different depending on the interface format. For example, if it is a FlexE interface, the data format is the FlexE service frame format. For another example, if it is an ETH interface, the data format may be an Ethernet data format of the physical layer, for example: ETC10GR; or, the data may also be an Ethernet MAC frame data stream format.
  • device A, device B, and device C constitute a path for transmitting the Ethernet data. They are the first node (also known as the source node), the intermediate node, and the last node (also called the destination node) of this path. That is, device A transmits the data frame carrying the Ethernet data to the next device, that is, device B.
  • S502 parsing the Ethernet data from the data frame, and converting the Ethernet data into another format and then inserting another data frame;
  • S503 Parse the overhead information from the data frame, and insert the another data frame.
  • this step is also performed by device C.
  • devices C, G, and F constitute the second path.
  • the device C is the first node of the second path
  • the device G is the intermediate node
  • the device G is the last node.
  • the intermediate device B and the device G only forward the received data frame, and the action is not shown in FIG. 5. It should also be noted that if a plurality of intermediate devices are provided with conversion capability, a device that performs a conversion operation is selected in advance through a network management system or a control system.
  • the processing for overhead includes but is not limited to the following types: direct insertion, insertion after mathematical operations, first caching, and then insertion.
  • Direct insertion means that the overhead proposed from the data frame of one path is not processed and is directly inserted into the data frame of another path.
  • Insertion after mathematical operations refers to the overhead proposed in the data frame from one path, combined with the intermediate device to obtain other information or information, perform mathematical operations (for example: or, or more complex operations), and then operate The result is inserted directly into the data frame of another path.
  • the proposed overhead is first placed in the buffer, and the overhead is read from the buffer at a suitable time and inserted into the new data frame. Doing so can accommodate differences in rates or other formats in two different data frames. It should be noted that the manner that may be used when performing overhead processing depends on the type included in the specific data frame. This application does not limit this.
  • the data frame is taken as an example of the ODUk defined in the 2016 G.709 standard issued by ITU-T, and the ODUk includes the overhead as shown in Table 1.
  • Table 1 further explains the meaning of these cost examples. It should be noted that the present application does not limit the location and the length of these overheads in the ODUk frame, and may be defined by referring to the provisions of the G.709 standard. It should also be noted that the overhead shown in Table 1 also exists in the ODUflex frame.
  • each level includes TTI, BIP8, BEI, BDI and STAT overhead.
  • Figure 6 shows the way in which the overhead is handled. It should be noted that in an optical network, services are usually bidirectional. That is, if there is a path carrying a service from device A to device C, there is also a reverse path, that is, from device C to The path of device A is used to carry reverse traffic transmission. Usually, the passing devices of the two paths that are mutually reverse paths are the same.
  • the upstream direction of Figure 6 is the FlexE to ETH interface.
  • the first cost refers to a part of the overhead included in the OTN container (the ODUflex is illustrated in FIG.
  • the intermediate device receives the data frame from the first path
  • the second overhead is the second device in the second device.
  • the corresponding overhead contained in the data frame to be sent on the path (illustrated as ODUk in Figure 6).
  • the downlink direction in the figure is the reverse direction of the uplink direction
  • the third overhead is data frame information obtained by the intermediate device in this direction, and the information includes part of the overhead included in the received data frame or other locally acquired data.
  • the frame information (for example, the error indication information shown in FIG. 6), and the fourth overhead is the corresponding overhead that needs to be included in the data frame of the corresponding next path.
  • the TTI and STAT overheads are direct insertions.
  • the intermediate device takes out such overhead from the data frame of the first path and directly inserts it into the data frame of the second path.
  • BEI and BDI processing requires mathematical operations before insertion. Specifically, the intermediate device needs to perform comprehensive processing on the received BEI information and the check result in the third overhead in the downlink direction (for example, BIP8 information), that is, after performing an OR process, inserting the result into the second overhead.
  • the intermediate device needs to combine the BDI information proposed in the first overhead and the ODUk signal in the reverse direction to comprehensively judge. As shown in FIG.
  • the intermediate device needs to calculate the BIP8 check value of the received ODUflex frame and compare it with the received BIP8 overhead to determine whether there is a bit error.
  • the head node inserts the calculated BIP8 of the current frame into the BIP8 field of its subsequent frame.
  • the BIP value of the kth frame is inserted into the k+m frame, and m is a positive integer not less than 1.
  • the intermediate device performs BIP8 comparison, the corresponding frame needs to be selected in the received data frame to parse the BIP8 value for comparison.
  • the intermediate device as the first node of the second path, also needs to generate a BIP check value of one ODUk frame and insert it into the BIP8 field of another ODUk frame after the frame.
  • FIG. 6 only shows an example of PM overhead processing in the uplink direction.
  • the processing in the downlink direction is similar and will not be described here.
  • This application is directed to APS/PCC.
  • the APS/PCC overhead proposed by the intermediate device is first placed in the buffer, and then inserted into the APS/ of the data frame in the second path in the order of placement (ie, first-in-first-out order).
  • PCC overhead field Similarly, this is also true for DM information.
  • the DM information may be simple or accurate delay measurement information, and the application does not require any format or accuracy of the specific information.
  • the advantage of this is that the data frames of the two paths may have differences in frame frequency (or frame rate) whether they are the same or not, so the difference can be eliminated by caching.
  • the method of processing is similar to APS/PCC and will not be described again.
  • the intermediate device needs to fill in the service carried by the second path. That is to say, in the data frame on the second path, for example: ODUk or ODUflex, the intermediate device inserts the payload type information according to the converted data format.
  • the data format of the corresponding path of the second path is ODU2e.
  • the intermediate device can insert 0x03 in the PT field of the ODU2e to indicate that the OTN container carries the ETC10GR and adopts the BMP mapping mode. .
  • the value inserted by the intermediate device in the PT field of the ODUflex can be 0x1D, indicating that the supported FlexE Client is in the IMP mapping mode.
  • a unique value can be used to represent payload type information.
  • payload type information can be used to represent payload type information through multiple fields. This application does not limit this.
  • FIG. 7 is a schematic structural diagram of a possible network device.
  • the network device includes a processor 701 and a memory 702, the processor 701 being coupled to the memory 702.
  • the memory 702 is used to store program instructions and data. It should be noted that the network device may be used to implement the network device for data processing mentioned in FIG. 3 or FIG. 5 above to implement interworking of different Ethernet interfaces. Some examples will be given below. It should also be noted that the memory 702 is an optional component.
  • the network device is an execution device of the steps shown in FIG.
  • the memory 702 stores program instructions and data that support the steps shown in FIG. 3, and the processor 701 is configured to perform the method steps shown in FIG.
  • the processing unit 701 may also be divided into a data processing unit and an overhead processing unit, respectively, for performing steps 301 and 302 shown in FIG. 3, respectively.
  • the network device is device C shown in FIG.
  • the processing unit 701 is configured to perform the steps 502-503 in FIG. 5.
  • the network device may further include an optical transmitter and an optical receiver, configured to send or receive an optical network data frame.
  • the embodiment of the present application further provides a chip in which a circuit for implementing the functions of the processor 701 and one or more interfaces are integrated.
  • the chip can complete the method steps of any one or more of the foregoing embodiments; when the memory is not integrated in the chip, the chip can be connected to the external memory through the interface, the chip
  • the actions performed by the network device in the above embodiment are implemented according to the program code stored in the external memory.
  • processor 701 and the memory 702 may be located in a programmable service board in the OTN hardware structure diagram described in FIG. 2.
  • the processing unit or processor may be a central processing unit, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device. , transistor logic, hardware components, or any combination thereof. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the solution. A person skilled in the art can use different methods to implement the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present application.
  • the computer program product includes one or more computer instructions.
  • the processes or functions described in accordance with embodiments of the present application are generated in whole or in part.
  • the computer can be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • the computer instructions can be stored in a computer readable storage medium or transferred from one computer readable storage medium to another computer readable storage medium, for example, the computer instructions can be from a website site, computer, server or data center Transfer to another website site, computer, server, or data center by wire (eg, coaxial cable, fiber optic, digital subscriber line (DSL), or wireless (eg, infrared, wireless, microwave, etc.).
  • the computer readable storage medium can be any available media that can be accessed by a computer or a data storage device such as a server, data center, or the like that includes one or more available media.
  • the usable medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

Abstract

本申请实施例涉及光通信领域，尤其涉及光传送网络中的数据处理技术。在一种数据处理的方法中，一个光网络设备从一个路径的数据帧中提取出以太数据，并将所述以太数据转换为另一格式后，放置到另一路径的数据帧中，其中，所述光网络设备为所述路径的目的设备且为所述另一路径的源设备；此外，所述光网络设备还从所述路径的数据帧中提出开销信息，并将所述开销信息插入所述另一路径的数据帧中。本申请提供的数据处理方法可以实现不同类型的以太接口的互通。此外，通过跨路径的开销处理，该方法降低了路径管理复杂度。

Description

光网络中以太数据处理的方法、装置和系统
本申请要求于2018年3月7日提交中国国家知识产权局、申请号为201810187414.8，发明名称为“光网络中以太数据处理的方法、装置和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及光通信领域，尤其涉及光网络中的以太数据处理技术。
背景技术
当前，光互联论坛(Optical Internetworking Forum，OIF)在制定灵活以太网(Flexible Ethernet，FlexE)接口技术相关的标准。其中，FlexE 1.0规定了通过绑定n个100G物理链路(PHY)，来实现不同速率的业务传送，例如10G、n*25G、40G等。该项技术主要应用于数据中心设备互联等短距离场景。对于FlexE数据的长距传输，可以通过光传送网(Optical transport network，OTN)进行承载传送。OTN承载FlexE数据相关的标准由国际电信联盟电信标准化部门(International Telecommunication Union-Telecommunication Standardization Sector，ITU-T)制定，确定FlexE业务数据通过灵活光数据单元(Flexible Optical Data Unit，ODUflex)这类OTN容器来进行承载。具体地，FlexE业务数据映射到ODUflex采用的映射方式是空闲映射规程(Idle Mapping Procedure，IMP)。
在FlexE接口出现之前，OTN技术针对传统的以太(ETH)接口有已经标准化的承载方式。具体地，ETH接口通过比特同步映射规程(Bit-synchronous Mapping Procedure,BMP)或通用映射规程(Generic Mapping Procedure,GMP)映射到OTN容器中，例如：光数据单元k(Optical Data Unit k,ODUk)。FlexE接口和ETH接口都可以用于承载以太网数据。因此，在支持两种接口的OTN网络中，可能存在两个接口的互通需求。
针对这个互通需求，当前的解决方案在OTN路径的首节点或者末节点的客户侧接口上对一种格式的接口数据进行格式转换，转换为另一种格式的接口数据，然后再将该接口数据发送出去。这种方案需要在建网时进行客户侧接口的格式转换能力的规划设计，否则无法支持这种互通需求，不够灵活。
发明内容
本申请实施例描述了一种以太数据处理的方法、装置和系统，以提高支持FlexE和ETH接口互通的灵活性。
第一方面，本申请实施例提供了一种光网络中数据处理的方法。该方法包括：
一个光网络设备从第一路径的数据帧中提取出以太数据，并将所述以太数据转换为另一格式后，将所述转换为另一格式的以太数据放置到第二路径的数据帧中，其中，所述光网络设备为所述第一路径的目的设备且为所述第二路径的源设备；
所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中。
在一种可能的设计中，所述以太数据的格式为灵活以太网(FlexE)业务帧格式，所述另一帧格式为除FlexE业务帧格式以外的其他以太网数据格式；或者，所述以太数据的格式为除FlexE业务帧格式以外的其他以太网数据格式，所述另一帧格式为FlexE业务帧格式。
在一种可能的设计中，所述第一路径的数据帧类型为灵活光数据单元(ODUflex)，所述第二路径的数据帧类型为光数据单元k(ODUk)；或者，所述第一路径的数据帧类型为ODUk，所述第二路径的数据帧类型为ODUflex；或者，所述第一路径和所述第二路径的数据帧类型均为ODUflex。
上述的开销插入有多种形式，包括：直接插入、进行数学运算后插入、先缓存后再插入等。
在一种可能的设计中，所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括：所述光网络设备从所述第一路径的数据帧提取第一开销信息；所述光网络设备将所述第一开销信息直接插入所述第二路径的数据帧中。具体地，该第一开销信息为路径踪迹标识、状态信息等。
在另一种可能的设计中，所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括：
所述光网络设备从所述第一路径的数据帧提取第二开销信息；
所述光网络设备根据所述第二开销信息和第三路径的数据帧信息，获取第三开销信息，其中，所述第三路径和所述第二路径互为反向路径；
所述光网络设备将所述第三开销信息直接插入所述第二路径的数据帧中。
具体地，该第二开销信息包括后向缺陷指示(BDI)和后向错误指示(BEI)的一个或多个。该第三路径的数据帧信息包括校验信息和错误指示信息。
在其他的设计中，该方法还可能包括如下开销处理步骤的一个或者多个：
确定所述第二路径承载的净荷类型信息，并将所述净荷类型信息插入所述第二路径的数据帧中；具体地，该净荷类型信息包括业务类型和映射方式；
对所述第一路径的数据帧进行数据校验，确定所述第一路径的数据帧是否存在误码；
计算所述第二路径的第一数据帧的数据校验值，并将所述数据校验值插入所述第一数据帧之后的第二个数据帧中；以及，
从所述第一路径的数据帧中提取第四开销信息，将所述第四开销信息放置到缓存器中，并将从所述缓存器中提出的所述第四开销信息插入所述第二路径的数据帧中。具体地，该第四开销信息为保护倒换指示信息、延迟测量信息和通用通信通道信息的一个或多个。
需要说明的是，在实际的应用中，网络设备可以根据具体设计选择上述多种设计中的一个或者多个。
第二方面，本申请实施例提供了一种数据处理装置。该装置包括处理器和存储器，所述处理器和所述存储器耦合，所述处理器用于执行如第一方面或者第一方面的任一设计中描述的方法。
第三方面，本申请实施例提供了一种数据处理装置。该装置包括处理器，所述处理器和存储器耦合，所述处理器用于读取所述存储器中的指令，以实现如第一方面或者第一方面的任一设计中描述的方法。
第四方面，本申请实施例提供了光网络系统。该系统包括第一设备，第二设备和第三设备，其中，所述第二设备包括第二方面或者第二发面任一设计中描述的的数据处理装置，所 述第一设备为所述第一路径的源设备，所述第三设备为所述第二路径的目的设备。
第五方面，本发明实施例提供一种计算机存储介质，包括指令，当其在计算机上运行时，使得计算机执行上述第一方面或者第一方面的任一设计提供的方法。
第六方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面或者第一方面的任一设计提供的方法。
相较于现有技术，本申请提供的方案可以通过中间设备或者首末节点的网络侧接口来实现数据格式转换，无须进行设备接口能力的提前规划设计，提高了FlexE接口和ETH接口互通的灵活性。此外，中间设备还通过开销处理，将两个OTN路径进行合一管理，降低了管理的复杂度。
附图说明
下面将参照所示附图对本申请实施例进行更详细的描述：
图1为本申请实施例的一种可能的应用场景示意图；
图2为一种可能的网络设备硬件结构示意图；
图3为一种可能的数据处理方法流程示意图；
图4a为一种可能的以太数据和开销处理示意图；
图4b为另一种可能的以太数据和开销转换示意图；
图4c为又一种可能的以太数据和开销转换示意图；
图5为一个实施例提供的数据处理方法流程的示意图；
图6为一个实施例提供的开销处理示意图；
图7为一种可能网络设备的结构示意图。
具体实施方式
本申请实施例描述的网络架构以及业务场景是为了更加清楚地说明本申请实施例的技术方案，并不构成对本申请实施例提供的技术方案的限制。本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题同样适用。
本申请的实施例适用于光网络，例如：光传送网络(Optical transport Network，简称OTN)。一个光网络通常由多个设备通过光纤连接而成，可以根据具体需要组成如线型、环形和网状等不同的拓扑类型。如图1所示的光网络201是一个由8个设备202组成的一个网状(mesh)网络。其中，203指示的是光纤；204指示的客户业务接口，用于实现客户业务数据的传输。一个网络可能有多个客户业务接口204。客户业务接口有时也被称为用户网络接口(User Network Interface，UNI)。根据实际的需要，设备202可能具备不同的功能。一般地来说，光网络设备分为光层设备、电层设备以及光电混合设备。光层设备指的是能够处理光层信号的设备，例如：光放大器(Optical Amplifier，OA)、光分插复用器(Optical Add-Drop Multiplexer,OADM)。OA也可被称为光线路放大器(Optical Line Amplifier，OLA)，主要用于对光信号进行放大，以支持在保证光信号的特定性能的前提下传输更远的距离。OADM用于对光信号进行空间的变换，从而使其可以从不同的输出端口(有时也称为方向)输出。根据能力不同，OADM可以分为固定的OADM(Fixed OADM，FOADM)，可配置的OADM (Reconfigurable OADM，ROADM)等。电层设备指的是能够处理电层信号的设备，例如：能够处理光数据单元(Optical Data Unit,ODU)信号的设备。光电混合设备指的是同时具备处理光层信号和电层信号能力的设备。需要说明的是，根据具体的集成需要，光网络设备可以集合多种不同功能的设备。本申请对适用于不同形态和集成度的光网络设备。除非特殊说明，本申请后续提到实施本申请揭示的技术的设备至少包括电层信号的处理能力。
图2给出了一个光网络设备202的硬件结构示意图。具体地，该设备202包括电源202A、风扇202B、辅助类单板202C，还可能包括支路板202D、线路板202E、交叉板202F、光层处理单板(图中未示出)、可编程业务板202G以及系统控制和通信类单板202H。需要说明的是，根据具体的需要，一个设备202具体包含的单板类型和数量可能不相同。例如，作为核心节点的网络设备可能没有支路板202D。作为边缘节点的网络设备可能有多个支路板202D。其中，电源202A用于为设备供电，可能包括主用和备用电源。风扇202B用于为设备散热。辅助类单板202C用于提供外部告警或者接入外部时钟等辅助功能。支路板202D、交叉板202F、线路板202E和可编程业务板202G主要是用于处理光网络的电层信号(例如，OTN中的ODU帧)。其中，支路板202D用于实现各种客户业务的接收和发送，例如同步数字体系(Synchronous Digital Hierachy,SDH)业务、分组业务、以太网业务和前传业务等。更进一步地，支路板202D可以划分为客户侧光模块和处理器。其中，客户侧光模块可以为光收发器，用于接收和/或发送客户信号。处理器用于实现对客户信号到ODU帧的映射和解映射处理。交叉板202F用于实现ODU帧的交换，完成一种或多种类型的ODU信号的交换。线路板202E主要实现线路侧ODU帧的处理。具体地，线路板202E可以划分为线路侧光模块和处理器。其中，线路侧光模块可以为线路侧光收发器，用于接收和/或发送ODU信号。处理器用于实现对线路侧的ODU帧的复用和解复用，或者映射和解映射处理。可编程业务板202G用于实现本申请揭示的数据处理方法。系统控制和通信类单板202H用于实现系统控制和通信。具体地，可以通过背板从不同的单板收集信息，或者将控制指令发送到对应的单板上去。需要说明的是，除非特殊说明，具体的组件(例如：处理器)可以是一个或多个，本申请不做任何限制。还需要说明的是，本申请实施例不对设备包含的单板类型，以及单板具体的功能设计和数量做任何限制。除非特殊说明，后续提及的设备至少包括具备可编程业务板202G。需要说明的是，可编程业务板202G也可以跟其他单板集成为一个单板。本申请对具体实现本申请揭示的数据处理技术的单板名称不做任何限制。
到目前为止，承载媒质接入控制层(Media Access Cotnrol，MAC)的MAC帧数据流的接口有两种类型，从而对应着不同的封装方式。一种是传统的ETH接口，另一种则是FlexE接口。每个接口都可以支持不同的速率。例如，FlexE接口支持10G、25G、40G和100G等多种速率。类似地，ETH接口也支持不同速率，例如：10G，25G和100G。不同的是，两个接口在映射到OTN时，它们的映射路径不同。具体地，FlexE接口信号通过IMP映射到ODUflex中。而ETH接口数据可能通过GMP或者BMP映射到ODUk或者是ODUflex中。因此，当OTN网络中同时存在这两种接口时，可能需要在这两个不同类型的接口之间建立业务路径，来实现传递MAC帧数据流的目的。因为两种接口的映射路径不同，可能导致一些问题。例如，需要进行数据格式的转换，否则无法实现两个接口的互通。此外，因为两者使用的映射方式和承载容器可能不一致，导致针对一个业务传输需要两条路径来支持，会为业务路径管理带来复杂性。为此，本申请提供了一种数据处理技术。需要说明的是，该技术应用于连接两个不同接口的路径上的任一设备。例如，在图1中，一条连接两个不同接口(即一个FlexE接口 和一个ETH接口)的路径为A-B-C-G-F，那么实施该数据处理技术的节点是A、B、C和G、F中的其中一个。需要说明的是，对于首节点和末节点，即A和F，该数据处理技术是在网络侧接口上实现的，而不是在客户侧接口上实现的。所谓客户侧接口指的是所述接口通过链路直接连接客户接口，通常位于图2所示的支路板202D上。而网络侧接口指的是所述接口通过链路跟其他也用于业务传输的网络设备直接连接，通常位于图2所示的线路板202E。这么做的好处是，无须对网络设备的客户侧接口能力进行提前规划，在需要进行不同以太网接口进行互通时，使用网络中能提供转换能力的设备或者实时增加该转换能力到需要的设备即可，提供了一定的灵活性，此外还降低网络的升级成本。针对首节点和末节点的网络侧接口上支持该数据处理技术的情况，与现有技术比的好处是，该网络侧接口可以支持同一设备上的不同客户侧接口的转换需求。与中间设备配置本申请揭示的数据处理能力不同的是，当业务的首节点或者末节点配置该能力时，第一路径没有经过网络中的光纤链路，而仅存在于首节点或者末节点内部。需要说明的是，本申请提供的数据处理技术还可以应用到其他更复杂的场景中，例如，需要进行两次或者更多次数的数据转换的场景。还需要说明的是，一个OTN容器有对应的数据帧格式，除非特殊说明，在本申请中，容器和数据帧可以替换使用。
图3给出了一种可能的数据处理的流程示意图。简言之，该数据处理方法包括两大步骤，一个是数据处理或称数据转换，另一个是开销处理。具体地，该流程包括：
S301：一个光网络设备从第一路径的数据帧中提取出以太数据，并将所述以太数据转换为另一格式后，将所述转换为另一格式的以太数据放置到第二路径的数据帧中，其中，所述光网络设备为所述第一路径的目的设备且为所述第二路径的源设备；
具体地，该光网络设备可以为一个中间设备，以支持多个不同业务路径的接口互通需求。其中，第一路径和第二路径通过该光网络设备来串联，从而实现两个不同类型接口上的数据传输，即两个路径串联构成一个支持端到端数据传输的一条路径。以路径为A-B-C-G-F，设备B来实现该数据处理技术为例，那么A-B构成了一条路径，即第一路径，用于承载上述的以太数据，而B-C-G-F则构成了另一条路径，即第二路径，用于承载另一格式的以太数据。
该中间设备对接收的光网络数据帧中承载的以太数据进行处理，转换为目标的格式后再放置到待发送的数据帧中去。需要说明的是，这个以太数据可能是FlexE接口格式的数据，也可能是ETH接口格式的数据。对应的，另一格式可能是ETH接口格式，或者是FlexE接口格式。这个转换可以使得对端的接口能正确地接收数据，并进行后续必要的数据处理。例如，从数据中解析出MAC帧数据流。
S302：所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中。
具体地，该中间设备需要将第一路径的数据帧中的开销信息提取出来，并采用一定的方式来将这些开销信息插入到第二路径的数据帧中。这跟传统的方法，也就是每条路径都独立产生开销的方法有所不同。这么做的好处是，可以使得两条路径的管理减少为一条路径的管理，降低了管理代价。需要说明的是，开销信息可能包含的具体内容有很多种，其对应的插入方法也不一定相同，例如：直接插入、进行数学运算后插入、先缓存后再插入等。具体地，请参见图6和其相关描述，此处不予赘述。
需要说明的是，上述两个步骤可以互换或者并行执行。例如，先执行S302再执行S301。下面针对不同速率的接口类型，进一步揭示上述两个步骤中的以太数据处理和开销处理。图4a-c给出了四种可能的中间设备进行以太数据处理和开销处理的例子。需要说明的是，这些 例子也适用于前面提到的源节点和末节点设备的网络侧单板具备本申请揭示的数据处理能里的场景。还需要说明的是，图4a-c中的FlexE Client的速率没有在图中标出。除非特殊说明，其速率跟对应的ETH接口速率相同。所述相同并不是严格相等，而是速率相差较小。例如，速率为10Gbps、40Gbps和100Gbps的ETH速率对应的FlexE Client分别为10Gbps，40Gbps和100Gbps。还需要说明的是，这些具体的接口和数据格式仅是举例，本申请给出的数据处理适用对于当前在使用但是没有示出的格式，以及后续可能出现的新的以太接口和数据格式也适用。
图4a给出了一种可能的以太数据和开销处理示意图。这个例子针对的接口速率为10G和25G。具体地，图4a的左侧表示的是FlexE接口和针对这个接口的数据帧格式的一些操作。其中，FlexE Client为FlexE接口对应的数据格式。该信号可以是电气和电子工程师协会(Institute of Electrical and Electronics Engineers,IEEE)802.3标准第82章定义的66b码块流(其中，b表示比特(bit))。ODUflex为承载FlexE Client的OTN容器。具体地，FlexE Client数据帧映射到ODUflex时采用IMP。FlexE Shim是FlexE接口中将多路FlexE Client复用到n路100G的以太物理链路的适配子层，对应的基本帧格式是FlexE实例帧格式。FlexE Shim可以包括经过复用的多个FlexE实例帧。图4a的右侧表示的是ETH接口。其中，ETCXGR指的是ETH接口对应的数据格式。其中，X是个变量，X＝10表示该接口速率为10Gbps，对应的OTN容器为ODU2e(即y＝2e)。X＝25表示该接口速率为25Gbps，对应的OTN容器为ODUflex(即y＝flex)。采用的映射方式均为BMP。ETHXGR可以采用IEEE 802.3标准第49章定义的66b码块流。
取决于数据的流向，图4a包括FlexE接口到ETH接口的转换，或者是ETH接口到FlexE接口的转换。下面分别进行说明中间设备的具体操作。需要说明的是，中间设备通过OTN容器接收以太数据并进行对应的处理。图4a还包括了以太接口到OTN容器的映射/解映射过程，例如：FlexE接口<＝>FlexE Shim<＝>FlexE Client<＝>ODUflex，以及ETH接口到OTN容器的映射/解映射过程，例如：ETH接口<＝>ETCXGR<＝>ODUy。但是这些过程是首节点或者末节点来执行的，后续在具体解释中间设备的操作时予以省略。
FlexE接口到ETH接口的转换：中间设备从ODUflex中解映射出FlexE Client，并进行数据转换形成ETCXGR，例如：ETC10GR或者ETC25GR。然后，该中间设备将ETCXGR通过BMP方式映射到对应的OTN容器，例如：ODU2e或ODUflex。这样就完成了以太数据(即FlexE Client)的转换。此外，该中间设备还需要从接收到ODUflex中取出对应的开销，插入到之前获得的对应的OTN容器中。
ETH接口到FlexE接口的转换：这个过程为FlexE接口到ETH接口的转换的逆过程。简言之，就是将ETCXGR从ODUy中取出来，然后转换成目标格式后，使用IMP将其放到ODUflex。此外，还需要对开销进行类似的处理。
需要说明的是，在进行FlexE Client或者是ETCXGR映射到OTN容器中还可能需要进行其他处理，例如：扰码处理。本申请对此不作任何限制。
类似地，图4b和图4c给出了其他两种可能的以太数据和开销处理示意图。这两个图分别对应的速率为：图4b对应的是40G和100G，ETH接口的数据格式跟图4a同，即也是ETCXGR；图4c对应的是10G、40G和100G，ETH接口的数据格式为MAC帧数据格式。在这两个例子中，中间设备的操作类似上述针对图4a的解释。主要区别在于数据格式、速率或映射方式中有一个或者多个不同。下面分别进行解释。
在图4b中，中间节点的操作跟图4a中的差别在于：首先，处理的信号速率不一样，图4b中的速率更高，对应的针对ETH接口的数据格式的映射/解映射方式也不同，采用的是GMP。其次，数据处理也有所区别。具体地，在图4a中，中间设备仅需要从一种格式的66b码块流转换另一种格式的码块流。而在图4b中，中间设备需要进行其他处理，例如：空闲码块的删除或者增加，以及对齐指示信息的插入或者删除的操作。具体地，以ETH接口转换为FlexE接口且X为40作为例子。中间设备首先从ODU3中解析出ETC40GR；然后，该中间设备将ETC40GR中包括的对齐指示信息删除，然后插入空闲码块，即进行速率补偿或速率适配，从而得到40G的FlexE client；最后，该中间设备将FlexE Client通过IMP映射到ODUflex中。需要说明的是，在插入空闲码块之前，如果ETC40GR在通过ETH接口承载到ODU3中有进行扰码处理，那么对应地，中间设备还需要进行解扰码的处理。
跟图4a和图4b聚焦在ETH接口的数据格式为以太物理编码格式(即ETCXGR)不同，图4c针对的是ETH接口的数据格式为MAC以太数据帧格式的情况。也就是说，ETH接口对应的数据格式有多种。下面针对图4c的接口转换过程进行具体介绍。
FlexE接口到ETH接口的转换：针对数据的处理，中间设备先对FlexE client进行66b解码处理，形成媒介无关接口(Media Independent Interface，MII)接口数据，之后进行帧间隙增加或删除等处理，转换为对应的MAC帧数据流，之后通过GFP将MAC帧数据流映射到OTN容器中。不同速率的FlexE Client对应的OTN容器不同。具体地，10FlexE Client对应为ODU2，40G速率对应的是ODU3，100G对应的是ODU4。此外，类似图4a和图4b，中间设备还需要进行开销处理。
ETH接口到FlexE接口的转换：该过程是上述FlexE接口到ETH接口的转换的逆过程。具体地，中间设备对MAC帧数据流进行帧间隙增加或删除等处理，并形成MII接口数据，对MII接口数据进行66b编码，生成FlexE client。之后，该中间设备通过IMP将此FlexE Client映射入ODUflex。类似地，开销也要进行插入处理。
本申请提供的方案可以通过中间设备、首节点的客户侧接口或者末节点的客户接口来实现数据格式转换，无须进行提前的规划设计，提高了实现FlexE接口和ETH接口互通的灵活性。此外，实现数据格式转换的设备将两个OTN路径进行合一管理，降低了管理的复杂度。
需要说明的是，针对中间设备而言，上述提到的第一路径和第二路径的一个或者多个可能直接利用光纤传输。例如，如果某一个路径对应的数据帧格式是ODUk时，可以将ODUk封装到OTUk格式后，通过光发送器发送出去。或者，所述第一路径和第二路径的一个或者多个可能复用到更高速率的路径上传输。例如，如果某一个路径对应的数据帧格式是ODU1或ODUflx，可以将这个ODU1或ODUflex封装到更高速率的ODUk(例如：ODU2，ODU3或ODUCn等)上，再发送出去。
下面将基于上面描述的适用于本申请的一些共性方面，对本申请实施例进一步详细说明。需要说明的是，本申请中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以其他本申请未描述的顺序实施。
本申请的一个实施例提供了一种数据处理的方法、装置和系统。在本实施例中，以图1的网络场景为例，假设本实施例的发送端设备为A，接收端设备为F，负责进行转换的设备为C。需要说明的是，A、C和F仅是示例，可以替换为其他的设备。在本实施例中，A和F所支持的UNI接口类型不同。例如，A设备支持ETH接口，而F设备支持FlexE接口。
图5为本实施例提供的流程示意图。下面对每个步骤进行详细的介绍。
S501:发送承载了以太数据的数据帧；
具体地，设备A从UNI接口获取到以太数据后，将其封装到光网络数据帧中后发送出去。取决于接口格式，该以太数据的格式不同。例如：如果是FlexE接口，那么该数据格式是FlexE业务帧格式。又如，如果是ETH接口，那么该数据格式可能是物理层的以太数据格式，例如：ETC10GR；或者，该数据还可以是以太网MAC帧数据流格式。
需要说明的是，在本实施例中，设备A、设备B和设备C构成了传送该以太数据的路径。它们分别为这个路径的首节点(又称源节点)、中间节点和末节点(又称目的节点)。也就是说，设备A将承载了所述以太数据的数据帧发送给下一个设备，也就是设备B。
S502:从所述数据帧中解析出所述以太数据，并将所述以太数据转换为另一格式后放入另一数据帧；
S503:从所述数据帧中解析出开销信息，并插入所述另一数据帧；
具体地，这两个步骤都是中间设备(即设备C)执行的。其中，S502和S503的具体描述可参见S301和S302的描述，此处不再赘述。
S504:发送所述另一数据帧。
具体地，这个步骤也是设备C执行的。其中，设备C、G和F构成了第二路径。其中，设备C是第二路径的首节点，设备G是中间节点，设备G是末节点。
需要说明的是，中间设备B和设备G仅对接收到数据帧进行转发，该动作在图5中未示出。还需要说明的是，如果多个中间设备都具备有转换能力，那么提前通过网络管理系统或者控制系统来选择一个作为执行转换操作的设备。
图4a-c描述的数据转换解释同样适用于本实施例，此处不再赘述。下面就S503中提及的开销处理进行说明。对于开销的处理包括但不限于如下类型：直接插入、进行数学运算后插入、先缓存后再插入等。直接插入指的是对从一个路径的数据帧中提出的开销不进行处理，直接插入到另一个路径的数据帧中去。进行数学运算后插入指的是对从一个路径的数据帧中提出的开销，结合中间设备可以获得其他一个或者多个信息，进行数学运算(例如：或，或者更复杂的运算)，然后将运算的结果直接插入到另一个路径的数据帧中。先缓存后再插入指的是对提出的开销先放入缓存器中，等到合适的时间再从缓存器中读取这个开销插入到新的数据帧中。这么做可以适配两种不同数据帧中的速率或其他格式上的差异。需要说明的是，具体在进行开销处理时可能用到的方式取决于具体数据帧中包含的类型。本申请对此不作限制。
下面，以数据帧为ITU-T制定的2016年发布的G.709标准中定义的ODUk为例，ODUk包括如表1所示的开销。表1进一步解释了这些开销示例的含义。需要说明的是，本申请对这些开销在ODUk帧中的位置和所占的长度不做限制，可以参照G.709标准的规定也可自行定义。还需要说明的是，表1所示的开销也存在于ODUflex帧中。
表1 ODUk/ODUflex所包含的开销和其含义
Figure PCTCN2019076905-appb-000001
Figure PCTCN2019076905-appb-000002
下面就这些开销的具体插入方式进行说明。
针对PM和TCM开销，如表1所示，这两种开销结合使用，提供不同层次的路径监控功能。也就是说，每一个层次都包括TTI、BIP8、BEI、BDI和STAT开销等。图6给出了具体开销处理的方式。需要说明的是，在光网络中，业务通常都是双向的，也就是说，如果从设备A到设备C存在一条承载一个业务的路径，那么还会存在一条反向路径，即从设备C到设备A的路径用于承载反向的业务传输。通常，这两条互为反向路径的路径的经过的设备是相同的。图6的上行方向为FlexE到ETH接口。其中，第一开销指的是中间设备收到的OTN容器(图6中示例为ODUflex)中包含的部分开销，即第一路径上数据帧包含的部分开销，第二开销是中间设备在第二路径上要发送的数据帧(图6中示例为ODUk)包含的对应的开销。对应地，图中的下行方向为上行方向的反方向，第三开销为中间设备在这个方向上获得的数据帧信息，该信息包括收到的数据帧包括的部分开销或本地获取的其他的数据帧信息(例如，图6所示的错误指示信息)，而第四开销为对应的下一路径的数据帧中需要包括的对应的开销。具体地，TTI和STAT开销为直接插入。也就是说，中间设备从第一路径的数据帧中取出这类开销，直接插入到第二路径的数据帧中。BEI和BDI处理需要进行数学运算后再插入。具体地，中间设备需要将收到的BEI信息和下行方向中第三开销中的校验结果(例如：BIP8信息)进行综合处理，即进行“或”处理后，将结果插入到第二开销中的BEI字段。针对BDI，中间设备需要结合从第一开销中提出的BDI信息和反方向上ODUk信号情况来综合判断。如图6所示，如果错误指示信息表明存在信号或帧丢失告警(例如：ODUk-LOS，或者ODUk帧丢失告警LOF等)，即 表明反方向上的ODUk信号丢失，那么BDI的值为1；否则，则直接将第一开销中的提出BDI信息插入第二开销中的对应字段。针对BIP8，中间设备需要计算收到的ODUflex帧的BIP8校验值，并跟收到的对应的BIP8开销比较，来判断是否存在误码。通常，首节点将计算得到的当前帧的BIP8插入到其后续帧的BIP8字段中。例如：将第k帧的BIP值插入到k+m帧中去，m为不小于1的正整数。对应地，中间设备进行BIP8比较时，需要去接收到的数据帧中选择对应的帧来解析出BIP8值进行比较。此外，中间设备作为第二路径的首节点，还需要生成一个ODUk帧的BIP校验值，并插入到该帧之后的另一个ODUk帧的BIP8字段。
需要说明的是，图6仅给出了上行方向上的PM开销处理示例。在下行方向上的处理类似，此处不予赘述。
针对表1中提及的其他开销的处理描述如下。
本申请针对APS/PCC，中间设备将提出的APS/PCC开销首先放到缓存器中，之后按照放置的先后顺序(即先入先出的顺序)依次插入到第二路径中的数据帧的APS/PCC开销字段。类似地，针对DM信息也是这么操作。需要说明的是，所述DM信息可以是简单的或者精确的延迟测量信息，本申请对具体信息的格式和准确性不做任何要求。这么做的好处是，两个路径的数据帧不论是否相同，都可能存在帧频率(或者帧速率)的差异，因此可以通过缓存的方法来消除这种差异。针对GCC，处理的方法类似APS/PCC，不再赘述。需要说明的是，一个OTN数据帧中可能有多个GCC字段，例如：包括GCC1和GCC2。针对PT开销处理，中间设备需要就第二路径所承载的业务来填写。也就是说，在第二路径上的数据帧中，例如：ODUk或ODUflex，中间设备根据转换后的数据格式来插入净荷类型信息。以10G FlexE Client以太格式到ETC10GR以太格式转换为例，对应的第二路径的数据类型为ODU2e，中间设备可以在ODU2e中PT字段中插入0x03来表示该OTN容器承载的是ETC10GR，采用BMP映射方式。在反方向上，即ETC10GR到FlexE Client格式的转换，中间设备在ODUflex的PT字段插入的值可以为0x1D，表示承载的FlexE Client，采用IMP映射方式。类似地，对于OTN容器承载的其他类型的业务类型，例如：25G、40G、100G以及更高速率，都可以使用一个唯一的数值来表示净荷类型信息。当然，本领域技术人员可以，也可以通过多个字段来表示净荷类型信息。本申请对此不做限制。
图7为一种可能网络设备结构示意图。该网络设备包括处理器701和存储器702，所述处理器701和所述存储器702耦合。其中，所述存储器702用于存储程序指令和数据。需要说明的是，该网络设备可以用于实现上述图3或图5里提及的进行数据处理的网络设备，以实现不同以太接口的互通。下面将给出一些例子。还需要说明的是，存储器702是一个是可选的组件。
在一种可能的实现中，该网络设备为图3所示步骤的执行设备。所述存储器702存储了支持图3所示步骤所述的程序指令和数据，而所述处理器701用于执行图3所示的方法步骤。可选地，所述处理单元701还可以划分为如数据处理单元和开销处理单元，分别用于执行图3所示的步骤301和302。
在另一种可能的实现中，该网络设备为图5所示的设备C。具体地，所述处理单元701用于执行图5中的502-503步骤。可选地，所述网络设备还可以包括光发送器和光接收器，用于发送或者接收光网络数据帧。
本申请实施例还提供一种芯片，该芯片中集成了用于实现上述处理器701的功能的电路和一个或者多个接口。当该芯片中集成了存储器时，该芯片可以完成前述实施例中的任一个 或者多个实施例的方法步骤；当该芯片中未集成存储器时，可以通过接口与外置的存储器连接，该芯片根据外置的存储器中存储的程序代码来实现上述实施例中网络设备执行的动作。
需要说明的是，上述描述的执行的动作仅是具体举例，处理器实际执行的动作参照图3或图5相关的描述中提及的动作/步骤。还需要说明的是，所述处理器701和所述存储器702在图2所述的OTN硬件结构图中，可能位于可编程业务板中。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，随机接入存储器等。具体地，例如：上述处理单元或处理器可以是中央处理器，通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。上述的这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
当使用软件实现时，上述实施例描述的方法步骤可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
最后应说明的是：以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (23)

  1. 一种光网络中数据处理的方法，其特征在于，所述方法包括：
    一个光网络设备从第一路径的数据帧中提取出以太数据，并将所述以太数据转换为另一格式后，将所述转换为另一格式的以太数据放置到第二路径的数据帧中，其中，所述光网络设备为所述第一路径的目的设备且为所述第二路径的源设备；
    所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中。
  2. 如权利要求1所述的方法，其特征在于，所述以太数据的格式为灵活以太网(FlexE)业务帧格式，所述另一帧格式为除FlexE业务帧格式以外的其他以太网数据格式；或者，所述以太数据的格式为除FlexE业务帧格式以外的其他以太网数据格式，所述另一帧格式为FlexE业务帧格式。
  3. 如权利要求1或2所述的方法，其特征在于，所述第一路径的数据帧类型为灵活光数据单元(ODUflex)，所述第二路径的数据帧类型为光数据单元k(ODUk)；或者，所述第一路径的数据帧类型为ODUk，所述第二路径的数据帧类型为ODUflex；或者，所述第一路径和所述第二路径的数据帧类型均为ODUflex。
  4. 如权利要求1-3任意一项所述的方法，其特征在于，所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括：
    所述光网络设备从所述第一路径的数据帧提取第一开销信息；
    所述光网络设备将所述第一开销信息直接插入所述第二路径的数据帧中。
  5. 如权利要求4所述的方法，其特征在于，所述第一开销信息包括路径踪迹标识(TTI)和状态(STAT)的一个或多个。
  6. 如权利要求1-5任意一项所述的方法，其特征在于，所述光网络设备从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括：
    所述光网络设备从所述第一路径的数据帧提取第二开销信息；
    所述光网络设备根据所述第二开销信息和第三路径的数据帧信息，获取第三开销信息，其中，所述第三路径和所述第二路径互为反向路径；
    所述光网络设备将所述第三开销信息直接插入所述第二路径的数据帧中。
  7. 如权利要求6所述的方法，其特征在于，所述第二开销信息包括后向缺陷指示(BDI)和后向错误指示(BEI)的一个或多个。
  8. 如权利要求6-7所述的方法，其特征在于，所述第三路径的数据帧信息包括校验信息和错误指示信息。
  9. 如权利要求1-8任意一项所述的方法，其特征在于，所述方法还包括如下步骤的一个 或多个：
    所述光网络设备确定所述第二路径承载的净荷类型信息，并将所述净荷类型信息插入所述第二路径的数据帧中；
    所述光网络设备对所述第一路径的数据帧进行数据校验，确定所述第一路径的数据帧是否存在误码；
    所述光网络设备计算所述第二路径的第一数据帧的数据校验值，并将所述数据校验值插入所述第一数据帧之后的第二个数据帧中；以及，
    所述光网络设备从所述第一路径的数据帧中提取第四开销信息，将所述第四开销信息放置到缓存器中，并将从所述缓存器中提出的所述第四开销信息插入所述第二路径的数据帧中。
  10. 如权利要求9所述的方法，其特征在于，所述净荷类型信息包括业务类型和映射方式。
  11. 如权利要求9或10所述的方法，其特征在于，所述第四开销信息为保护倒换指示信息、延迟测量信息和通用通信通道信息的一个或多个。
  12. 一种数据处理装置，其应用于一个光网络设备中，其特征在于，所述装置包括处理器和存储器，所述处理器和所述存储器耦合，所述处理器用于执行如下步骤：
    从第一路径的数据帧中提取出以太数据，并将所述以太数据转换为另一格式后，将所述转换为另一格式的以太数据放置到第二路径的数据帧中，其中，所述处理器所述的光网络设备为所述第一路径的目的设备且为所述第二路径的源设备；
    从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中。
  13. 如权利要求12所述的装置，其特征在于，所述以太数据的格式为灵活以太网(FlexE)业务帧格式，所述另一格式为除FlexE业务帧格式以外的其他以太网数据格式；或者，所述以太数据的格式为除FlexE业务帧格式以外的其他以太网数据格式，所述另一格式为FlexE业务帧格式。
  14. 如权利要求12或13所述的装置，其特征在于，所述第一路径的数据帧类型为灵活光数据单元(ODUflex)，所述第二路径的数据帧类型为光数据单元k(ODUk)；或者，所述第一路径的数据帧类型为ODUk，所述第二路径的数据帧类型为ODUflex；或者，所述第一路径和所述第二路径的数据帧类型均为ODUflex。
  15. 如权利要求12-14任意一项所述的装置，其特征在于，所述从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括所述处理器：
    从所述第一路径的数据帧提取第一开销信息；
    将所述第一开销信息直接插入所述第二路径的数据帧中。
  16. 如权利要求15所述的装置，其特征在于，所述第一开销信息包括路径踪迹标识(TTI)和状态(STAT)的一个或多个。
  17. 如权利要求12-16任意一项所述的装置，其特征在于，所述从所述第一路径的数据帧中提出开销信息，并将所述开销信息插入所述第二路径的数据帧中，包括所述处理器：
    从所述第一路径的数据帧提取第二开销信息；
    根据所述第二开销信息和第三路径的开销信息，获取第三开销信息，其中，所述第三路径和所述第二路径互为反向路径；
    将所述第三开销信息直接插入所述第二路径的数据帧中。
  18. 如权利要求17所述的装置，其特征在于，所述第二开销信息包括后向缺陷指示(BDI)和后向错误指示(BEI)的一个或多个。
  19. 如权利要求17或18所述的装置，其特征在于，所述第三路径的开销信息包括检验信息和错误指示信息。
  20. 如权利要求12-19任意一项所述的装置，其特征在于，所述处理器还执行如下步骤的一个或多个：
    确定所述第二路径承载的净荷类型信息，并将所述净荷类型信息插入所述第二路径的数据帧中；
    对所述第一路径的数据帧进行数据校验，确定所述第一路径的数据帧是否存在误码；
    计算所述第二路径的第一数据帧的数据校验值，并将所述数据校验值插入所述第一数据帧之后的第二个数据帧中；以及，
    从所述第一路径的数据帧中提取第四开销信息，将所述第四开销信息放置到缓存器中，并将从所述缓存器中提出的所述第四开销信息插入所述第二路径的数据帧中。
  21. 如权利要求20所述的装置，其特征在于，所述净荷类型信息包括业务类型和映射方式。
  22. 如权利要求20或21所述的装置，其特征在于，所述第四开销信息为保护倒换指示信息、延迟测量信息和通用通信通道信息的一个或多个。
  23. 一种光网络系统，其特征在于，所述系统包括第一设备，第二设备和第三设备，其中，所述第二设备包括如权利要求12-22任一所述的数据处理装置，所述第一设备为所述第一路径的源设备，所述第三设备为所述第二路径的目的设备。
PCT/CN2019/076905 2018-03-07 2019-03-05 光网络中以太数据处理的方法、装置和系统 WO2019170064A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19764123.6A EP3755001A4 (en) 2018-03-07 2019-03-05 METHOD, APPARATUS AND SYSTEM FOR PROCESSING ETHERNET DATA IN AN OPTICAL NETWORK
US17/013,131 US11223422B2 (en) 2018-03-07 2020-09-04 Method and apparatus for processing ethernet data in optical network, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810187414.8A CN110248260B (zh) 2018-03-07 2018-03-07 光网络中以太数据处理的方法、装置和系统
CN201810187414.8 2018-03-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/013,131 Continuation US11223422B2 (en) 2018-03-07 2020-09-04 Method and apparatus for processing ethernet data in optical network, and system

Publications (1)

Publication Number Publication Date
WO2019170064A1 true WO2019170064A1 (zh) 2019-09-12

Family

ID=67846827

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/076905 WO2019170064A1 (zh) 2018-03-07 2019-03-05 光网络中以太数据处理的方法、装置和系统

Country Status (4)

Country Link
US (1) US11223422B2 (zh)
EP (1) EP3755001A4 (zh)
CN (1) CN110248260B (zh)
WO (1) WO2019170064A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114173223A (zh) * 2020-08-21 2022-03-11 中兴通讯股份有限公司 业务调度方法、分组光传送网设备和存储介质
CN115118371A (zh) * 2021-03-18 2022-09-27 华为技术有限公司 光网络中以太数据处理的方法、装置以及系统
CN116418865A (zh) * 2021-12-29 2023-07-11 苏州盛科通信股份有限公司 网络数据的控制方法、装置和存储介质及电子设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102196321A (zh) * 2010-03-05 2011-09-21 华为技术有限公司 100ge数据在光传送网中的传送方法和数据发送装置
CN102480408A (zh) * 2010-11-24 2012-05-30 中兴通讯股份有限公司 伪线仿真系统的调度方法及装置
CN106411454A (zh) * 2015-07-30 2017-02-15 华为技术有限公司 用于数据传输的方法、发送机和接收机
US20180034573A1 (en) * 2015-06-30 2018-02-01 Ciena Corporation Flexible ethernet switching systems and methods

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101656588A (zh) * 2009-09-21 2010-02-24 中兴通讯股份有限公司 一种传输数据的方法及系统
CN103297866B (zh) * 2012-02-29 2016-03-09 华为技术有限公司 上、下行带宽分配方法、设备和嵌套系统
CN103688499B (zh) * 2013-03-15 2016-12-14 华为技术有限公司 一种光通道数据单元odu业务传送装置和方法
US10218823B2 (en) * 2015-06-30 2019-02-26 Ciena Corporation Flexible ethernet client multi-service and timing transparency systems and methods
EP3713158B1 (en) * 2015-06-30 2022-02-09 Ciena Corporation Time transfer systems and methods over a stream of ethernet blocks
US9853722B1 (en) * 2016-06-17 2017-12-26 Ciena Corporation Systems and methods for path protection switching due to client protection switching
JP2018046373A (ja) * 2016-09-13 2018-03-22 富士通株式会社 伝送装置及び伝送方法
US10469168B2 (en) * 2017-11-01 2019-11-05 Fujitsu Limited Disaggregated integrated synchronous optical network and optical transport network switching system
US10979209B1 (en) * 2018-10-08 2021-04-13 Acacia Communications, Inc. System, method, and apparatus for mapping synchronous and asynchronous data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102196321A (zh) * 2010-03-05 2011-09-21 华为技术有限公司 100ge数据在光传送网中的传送方法和数据发送装置
CN102480408A (zh) * 2010-11-24 2012-05-30 中兴通讯股份有限公司 伪线仿真系统的调度方法及装置
US20180034573A1 (en) * 2015-06-30 2018-02-01 Ciena Corporation Flexible ethernet switching systems and methods
CN106411454A (zh) * 2015-07-30 2017-02-15 华为技术有限公司 用于数据传输的方法、发送机和接收机

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3755001A4

Also Published As

Publication number Publication date
US20200403698A1 (en) 2020-12-24
EP3755001A4 (en) 2021-04-21
EP3755001A1 (en) 2020-12-23
CN110248260A (zh) 2019-09-17
US11223422B2 (en) 2022-01-11
CN110248260B (zh) 2021-10-26

Similar Documents

Publication Publication Date Title
US11700083B2 (en) Method and apparatus for processing service data in optical transport network
US20180098076A1 (en) Data Processing Method, Communications Device, and Communications System
US11967992B2 (en) Data transmission method and apparatus in optical transport network
WO2018090856A1 (zh) 用于建立灵活以太网群组的方法和设备
JP2010541509A (ja) クライアント信号を送信及び受信する方法、装置、及びシステム
US11223422B2 (en) Method and apparatus for processing ethernet data in optical network, and system
CN109391461B (zh) 透传业务频率的方法和设备
WO2019071369A1 (zh) 光网络中数据传输方法及光网络设备
US9048967B2 (en) Asymmetric OTN network traffic support
EP1816803A1 (en) Transmission processing method for data frame and system thereof
JP5078878B2 (ja) 光トランスポート・ネットワーク信号の同期交換のための方法および装置
WO2012155710A1 (zh) 一种实现otn业务映射及解映射的方法和装置
WO2019090696A1 (zh) 光传输单元信号的传输方法和装置
WO2019047110A1 (zh) 一种光传送网中时延测量的方法、装置和系统
CN102843293A (zh) 一种处理报文的方法和网元设备
US7583599B1 (en) Transporting stream client signals via packet interface using GFP mapping
US8699524B2 (en) Method and apparatus for generating resize control overhead in optical transport network
WO2021218721A1 (zh) 业务处理的方法和装置
WO2020051851A1 (zh) 光传送网中的数据传输方法及装置
WO2024051586A1 (zh) 一种光传送网中的数据帧的处理方法、装置和系统
JP2014220709A (ja) 多重伝送システム及び多重伝送方法
US11902403B2 (en) Method for receiving code block stream, method for sending code block stream, and communications apparatus
WO2022194290A1 (zh) 光网络中以太数据处理的方法、装置以及系统
WO2010135864A1 (zh) 传送客户数据的方法、设备及通信系统
JP6929436B2 (ja) ビット・ブロック・ストリームを処理する方法及び装置、ビット・ブロック・ストリームのレート・マッチングのための方法及び装置、並びにビット・ブロック・ストリームを切り替える方法及び装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19764123

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019764123

Country of ref document: EP

Effective date: 20200914