WO2019011003A1 - 一种光网络中光监控信道处理的方法和装置 - Google Patents

一种光网络中光监控信道处理的方法和装置 Download PDF

Info

Publication number
WO2019011003A1
WO2019011003A1 PCT/CN2018/080303 CN2018080303W WO2019011003A1 WO 2019011003 A1 WO2019011003 A1 WO 2019011003A1 CN 2018080303 W CN2018080303 W CN 2018080303W WO 2019011003 A1 WO2019011003 A1 WO 2019011003A1
Authority
WO
WIPO (PCT)
Prior art keywords
overhead
code block
osc frame
block unit
network device
Prior art date
Application number
PCT/CN2018/080303
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 ES18832094T priority Critical patent/ES2928313T3/es
Priority to EP18832094.9A priority patent/EP3641160B1/en
Publication of WO2019011003A1 publication Critical patent/WO2019011003A1/zh
Priority to US16/741,121 priority patent/US10826636B2/en

Links

Images

Classifications

    • 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/077—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal using a supervisory or additional signal
    • 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]
    • 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
    • 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/077—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal using a supervisory or additional signal
    • H04B10/0773—Network aspects, e.g. central monitoring of transmission parameters
    • 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/077—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal using a supervisory or additional signal
    • H04B10/0775—Performance monitoring and measurement of transmission parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J14/00—Optical multiplex systems
    • H04J14/02—Wavelength-division multiplex systems
    • H04J14/0227—Operation, administration, maintenance or provisioning [OAMP] of WDM networks, e.g. media access, routing or wavelength allocation
    • 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/1611—Synchronous digital hierarchy [SDH] or SONET
    • 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
    • H04Q2011/0083—Testing; Monitoring

Definitions

  • the embodiments of the present invention relate to the field of optical communications, and in particular, to an overhead processing technology in an optical network.
  • the optical transport network is the core technology of the next-generation transport network. It has rich operation and management and maintenance (OAM) capabilities and powerful tandem connection monitoring (Tandem Connection Monitoring). TCM) capability and Forward Error Correction (FEC) capability enable flexible scheduling and management of large-capacity services.
  • OAM optical transport network
  • TCM tandem Connection Monitoring
  • FEC Forward Error Correction
  • the Optical Supervisory Channel (OSC) is used to transmit OAM-related information in the OTN, and to protect related information.
  • the OAM-related information and the protection-related information are also often referred to as overhead.
  • OTN has the characteristics of large bandwidth and low latency, making it an ideal transmission method for many emerging services, such as 4K/8K, virtual reality and so on. As new services continue to emerge, network traffic continues to grow, making the scale of OTN expanding, making network maintenance and management more and more challenging.
  • OSC as the primary means of transmitting OAM and protecting information, also faces many problems.
  • the current packaging method has a large delay. Taking the Ethernet frame encapsulation of the OSC as an example, the intermediate node needs to extract and parse all the overhead information contained in the Ethernet frame, and then reprocess and encapsulate it into a new payload area. The current practice of this approach is too long for the OSC to introduce a large processing delay. In addition, the current packaging method is not easy to expand, and the compatibility is poor, which is not suitable for the demand of OSC for large-scale networks in the future.
  • Embodiments of the present invention describe a method and apparatus for OSC processing to improve OSC performance in an OTN network.
  • an embodiment of the present invention provides a method for processing overhead in an optical transport network, where the method includes:
  • An optical monitoring channel (OSC) frame is generated, where the OSC frame includes a plurality of overhead code block units, each of the plurality of overhead code block units carries an overhead, and the OSC frame carries overhead identification information,
  • the cost identifier information is used to identify an overhead type of an overhead carried by the multiple overhead code block units;
  • the overhead includes an optical transmission section overhead (OTS OH), an optical multiplexing section overhead (OMS OH), and an integrated optical branch signal overhead (OTSiA OH).
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • OTS OH optical transmission section overhead
  • OMS OH optical multiplexing section overhead
  • OTSiA OH integrated optical branch signal overhead
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • OCS_DCC optical transport segment data communication channel
  • OMS_DCC optical multiplex segment data communication channel
  • the overhead identifier information is located in an overhead area of the OSC frame, and the overhead identifier information includes a net of at least one of the plurality of overhead code block units in the OSC frame. Location information in the flood zone and overhead type information of the overhead carried by the at least one overhead code block unit.
  • the overhead identifier information is located in at least one overhead code block unit of the plurality of overhead code block units, and the overhead identifier information is used to indicate in the at least one overhead code block unit.
  • the generating an OSC frame may be refined to: encapsulate the OTS OH, OMS OH, and OTSiA OH into the plurality of overhead code block units; mapping the plurality of overhead code block units to The payload area of the OSC frame.
  • the mapping the plurality of overhead code block units to the payload area of the OSC frame comprises: mapping a partial overhead code block unit of the plurality of overhead code block units into a payload area of the OSC frame a preset location, mapping another portion of the overhead code block unit to any idle location in the payload area of the OSC frame; or mapping the plurality of overhead code block units to any of the OSC frame payload areas Free location.
  • each of the plurality of overhead code block units includes at least two 66B data code blocks.
  • an embodiment of the present invention provides a network device in an optical network, where the network device is configured to implement the functions of the first aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the network device includes a processor and a transmitter.
  • the processor is configured to support a network device to perform a corresponding function of the methods mentioned in the first aspect. For example: generate an OSC frame.
  • the transmitter is configured to support the network device to perform the sending action mentioned in the first aspect.
  • the embodiment of the present invention provides a method for overhead processing in an optical transport network, where the method includes:
  • the network device receives a first optical monitoring channel (OSC) frame, where the first OSC frame includes multiple overhead code block units, and each of the plurality of overhead code block units carries an overhead,
  • An OSC frame carries overhead identifier information, where the identifier identifier information is used to identify an overhead type of an overhead carried by the multiple overhead code block units;
  • OSC optical monitoring channel
  • the second OSC frame includes a second overhead code block unit carrying a second OTS OH and an overhead code block unit carrying the OMS OH and OTSiA OH in the first OSC frame;
  • the overhead includes a first optical transmission section overhead (OTS OH), an optical multiplexing section overhead (OMS OH), and an integrated optical branch signal overhead (OTSiA OH).
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • the first OTS OH is used to implement operation, management, and maintenance (OAM) of a transmission segment between an upstream network device adjacent to the network device and the network device.
  • the second OTS OH is used to implement OAM of a transmission segment between the network device and a downstream network device adjacent to the network device.
  • an OSC frame includes an overhead area and a payload area, and the plurality of overhead code block units are located in a payload area of the OSC frame.
  • the overhead identification information is located in an overhead area of the first OSC frame, and the overhead identification information includes at least one of the plurality of overhead code block units in the first Location information in a payload area of an OSC frame and overhead type information of an overhead carried by the at least one overhead code block unit.
  • the overhead identification information is located in at least one overhead code block unit of the plurality of overhead code block units included in the first OSC frame, and the overhead identification information is used to indicate the at least one The type of overhead of the overhead carried by each overhead code block unit in the overhead code block unit.
  • each of the plurality of overhead code block units includes at least two 66B data code blocks.
  • the generating the second OSC frame includes: generating the second OTS OH and encapsulating to the second overhead code block unit; mapping the second overhead code block unit and the first OSC frame An overhead code block unit carrying the OMS OH and OTSiA OH to a payload area of the second OSC frame.
  • mapping the second overhead code block unit and the overhead code block unit that carries the OMS OH and OTSiA OH in the first OSC frame to the payload area of the second OSC frame includes: mapping The second overhead code block unit and the partial overhead code block unit in the overhead code block unit carrying the OMS OH and OTSiA OH in the first OSC frame are preset in a payload area of the second OSC frame Position, another portion of the overhead code block unit is mapped to any idle location in the payload area of the second OSC frame; or mapping the second overhead code block unit and the first OSC frame to carry the OMS OH And an overhead code block unit of the OTSiA OH to any idle location in the second OSC frame payload area.
  • an embodiment of the present invention provides a network device in an optical network, where the network device is configured to implement the functions of the third aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the network device includes a receiver, a processor, and a transmitter.
  • the receiver is configured to perform the receiving action of the third aspect.
  • the processor is configured to support a network device to perform a corresponding function of the methods mentioned in the third aspect. For example: generate a second OSC frame.
  • the transmitter is configured to support the network device to perform the sending action mentioned in the third aspect.
  • an embodiment of the present invention provides a method for overhead processing in an optical transport network, where the method includes:
  • the network device receives a first optical monitoring channel (OSC) frame, where the first OSC frame includes multiple overhead code block units, and each of the plurality of overhead code block units carries an overhead,
  • An OSC frame carries overhead identifier information, where the identifier identifier information is used to identify an overhead type of an overhead carried by the multiple overhead code block units;
  • OSC optical monitoring channel
  • the second OSC frame includes a third overhead code block unit carrying a second OTS OH, a fourth overhead code block unit carrying a second OMS OH, and the OTSiA carried in the first OSC frame Overhead code block unit of OH;
  • the overhead includes a first optical transport section overhead (OTS OH), a first optical multiplex section overhead (OMS OH), and an integrated optical tributary signal overhead (OTSiA OH).
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • OAM operation, management, and maintenance
  • the OAM of the multiplex section between the first network device having the optical multiplexing function and the network device located upstream of the network device is implemented, and there is no other device between the first network device and the network device.
  • the second OTS OH is used to implement OAM of a transmission segment between the network device and a downstream network device adjacent to the network, where the second OMS OH is used to implement the network device and
  • the OAM of the multiplex section between the second network devices having the optical multiplex section function downstream of the network device, and the network device having the optical multiplexing function between the network device and the second network device.
  • an OSC frame includes an overhead area and a payload area, and the plurality of overhead code block units are located in a payload area of the OSC frame.
  • the overhead identification information is located in an overhead area of the first OSC frame, and the overhead identification information includes at least one of the plurality of overhead code block units in the first Location information in a payload area of an OSC frame and overhead type information of an overhead carried by the at least one overhead code block unit.
  • the overhead identification information is located in at least one overhead code block unit of the plurality of overhead code block units included in the first OSC frame, and the overhead identification information is used to indicate the at least one The type of overhead of the overhead carried by each overhead code block unit in the overhead code block unit.
  • each of the plurality of overhead code block units includes at least two 66B data code blocks.
  • the generating the second OSC frame includes: generating the second OTS OH and encapsulating to the third overhead code block unit; generating the second OMS OH and encapsulating to the fourth overhead code block unit Mapping the third overhead code block unit, the fourth overhead code block unit, and the overhead code block unit carrying the OTSiA OH in the first OSC frame to a payload area of the second OSC frame.
  • mapping the third overhead code block unit, the fourth overhead code block unit, and the overhead code block unit that carries the OTSiA OH in the first OSC frame to a payload area of the second OSC frame includes: mapping the third overhead code block unit, the fourth overhead code block unit, and the partial overhead code block unit of the overhead code block unit carrying the OTSiA OH in the first OSC frame to the second OSC a preset position in the payload area of the frame, another part of the overhead code block unit is mapped to any idle position in the payload area of the second OSC frame; or mapping the third overhead code block unit and the fourth overhead The code block unit and the overhead code block unit carrying the OTSiA OH in the first OSC frame to any idle location in the payload area of the second OSC frame.
  • an embodiment of the present invention provides a network device in an optical network, where the network device is configured to implement the functions of the fifth aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the network device includes a receiver, a processor, and a transmitter.
  • the receiver is configured to perform the receiving action of the fifth aspect.
  • the processor is configured to support a network device to perform a corresponding function of the methods mentioned in the fifth aspect. For example: generating a second OSC frame, extracting the first OTS OH, and the like.
  • the transmitter is configured to support the network device to perform the sending action mentioned in the fifth aspect.
  • the present invention provides a method for overhead processing in another optical transport network, the method comprising:
  • the OSC frame includes a plurality of overhead code block units, each of the plurality of overhead code block units carrying an overhead, the OSC frame carrying overhead identification information, the overhead identification information An overhead type used to identify an overhead carried by the plurality of overhead code block units;
  • the overhead includes an optical transmission section overhead (OTS OH), an optical multiplexing section overhead (OMS OH), and an integrated optical branch signal overhead (OTSiA OH).
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • OTS OH optical transmission section overhead
  • OMS OH optical multiplexing section overhead
  • OTSiA OH integrated optical branch signal overhead
  • the overhead further includes one or more of an optical channel overhead (OCh OH), an optical transport segment data communication channel (OTS_DCC), and an optical multiplex segment data communication channel (OMS_DCC).
  • OCS_DCC optical transport segment data communication channel
  • OMS_DCC optical multiplex segment data communication channel
  • the overhead identifier information is located in an overhead area of the OSC frame, and the overhead identifier information includes a net of at least one of the plurality of overhead code block units in the OSC frame. Location information in the flood zone and overhead type information of the overhead carried by the at least one overhead code block unit.
  • the overhead identifier information is located in at least one overhead code block unit of the plurality of overhead code block units, and the overhead identifier information is used to indicate in the at least one overhead code block unit.
  • each of the plurality of overhead code block units includes at least two 66B data code blocks.
  • an embodiment of the present invention provides a network device in another optical network, where the network device is configured to implement the functions of the seventh aspect.
  • the functions may be implemented by hardware or by corresponding software implemented by hardware.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the network device includes a receiver and a processor.
  • the receiver is configured to perform the receiving action of the seventh aspect.
  • the processor is configured to support a network device to perform a corresponding function of the methods mentioned in the seventh aspect. For example: extraction overhead, etc.
  • the overhead identifier information may also be preset location information.
  • the OSC frame may further include forward error correction (FEC) information.
  • FEC forward error correction
  • the method described in the first aspect further adds FEC information; the methods described in the third, fifth, and seventh aspects also require FEC verification on the received OSC frame.
  • the OSC frame includes an OSC frame alignment indication code block and an OSC frame overhead code block, where the OSC frame overhead code block is used to carry the operation, operation, and Maintaining (OAM) information, the OSC frame alignment indicator code block is used to identify the OSC frame.
  • OAM Maintaining
  • the ninth aspect, the embodiment of the present invention provides an optical network system, where the system includes the network device of the second aspect, the network device of the fourth aspect, and the network device of the eighth aspect; or The system includes the second aspect and the network device of the eighth aspect; or the system includes the second aspect, the fourth aspect, and the network device of the sixth aspect and the eighth aspect Or, comprising the network device of the second aspect, the network device of the sixth aspect, and the network device of the eighth aspect.
  • the solution provided by the present invention can separately carry different overheads through an OSC frame format, which simplifies the processing of overhead of the network device, thereby reducing the overhead processing delay.
  • the overhead processing technology provided by the present invention provides a flexible encapsulation and mapping manner, and has good scalability.
  • FIG. 1 is a schematic diagram of a possible application scenario according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of a possible OSC frame structure
  • FIG. 3 is a schematic diagram of still another possible OSC frame structure
  • FIG. 4 is a schematic structural diagram of a possible OSC frame payload area
  • FIG. 5 is a schematic structural diagram of a possible overhead code block unit
  • FIG. 6 is a schematic structural diagram of two possible OTS OH code block units
  • Figure 7 is a schematic diagram showing the structure of two possible OMS OH code block units
  • Figure 8 is a schematic diagram of two possible MSI structures
  • FIG. 9 is a schematic diagram of still another possible MSI structure
  • FIG. 10 is a schematic diagram of still another possible MSI structure
  • FIG. 11 is a schematic structural diagram of a possible OTSiA or OCh OH code block unit
  • FIG. 12 is a schematic diagram of a possible OSC frame structure including floating mapping indication information
  • Figure 13 is a schematic diagram of a possible structure of adding FEC
  • FIG. 16 is a flowchart of still another possible network device OSC frame processing
  • 20 is a schematic diagram of another possible network device structure.
  • the network architecture and the service scenario described in the embodiments of the present invention are intended to more clearly illustrate the technical solutions of the embodiments of the present invention, and do not constitute a limitation of the technical solutions provided by the embodiments of the present invention.
  • a person skilled in the art can understand that the technical solutions provided by the embodiments of the present invention are applicable to similar technical problems as the network architecture evolves and new service scenarios appear.
  • an OTN may include a plurality of different device types, for example, a line terminal (LT), an optical amplifier (OA), and an optical add-drop multiplexer (Optical Add-Drop). Multiplexer, referred to as OADM).
  • the LT is sometimes referred to as an Optical Transport Module (OTM) for modulating an electrical signal onto a predetermined optical signal (wavelength) or demodulating an electrical signal from a particular optical signal.
  • OTM Optical Transport Module
  • the OA can also be called an Optical Line Amplifier (OLA), which is mainly used to amplify an optical signal to support transmission of a longer distance while ensuring the specific performance of the optical signal.
  • 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 (FOADM), configurable OADM (ROADM), and so on.
  • FOADM fixed OADM
  • ROADM configurable OADM
  • a plurality of LTs and multiplexers/demultiplexers are combined to form a device, such as device 1 in FIG.
  • OTN In order to facilitate the management of the network, OTN is divided into different levels. As shown in FIG. 1 , the OTN includes an Optical Transport Section (OTS), an Optical Multiplex Section (OMS), and an Optical Tributary Signal Assembly (OTSiA).
  • OTN defines a rich overhead (OH), which is used to transmit different levels of OAM and/or protection information, and the optical layer overhead passes through the optical monitoring channel (Optical).
  • Supervisory Channel referred to as OSC
  • OSC optical monitoring channel
  • OTS OH the OTS overhead
  • OTS OH is used to implement operation and maintenance and management between two adjacent optical transmission devices.
  • the segment of device 1 and its neighboring device OA in Figure 1 is considered a transport segment.
  • the OMS overhead (hereinafter referred to as OMS OH) is used to implement operation and maintenance and management between two adjacent optical multiplexing devices (see the related example in FIG. 1).
  • the OTSiA overhead (hereinafter referred to as OTSiA OH) is used to implement operation and management of one or more optical signals transmitted between two devices.
  • One of the two devices is a source node device that transmits an optical signal, and the other is a destination node (also referred to as a sink node) that transmits an optical signal.
  • the OTN levels supported by different devices may be different.
  • the types/numbers of overheads that different OTN devices need to process are different.
  • device 1 in Figure 1 needs to handle the three overheads mentioned above, namely OTS OH, OMS OH and OTSiA OH; whereas OA devices only need to process OTS OH.
  • ROADM equipment only needs to handle OTS OH and OMS OH.
  • optical channel is an optical signal type/hierarchy defined by the International Telecommunication Union-Telecommunication Sector (ITU-T) for single carrier.
  • the overhead of this signal/hierarchy is OCh OH (ie optical channel overhead).
  • OTSiA is an optical signal type/hierarchy defined by ITU-T for multiple carriers, and its corresponding overhead is OTSiA OH.
  • the two types of signals may be used separately or at the same time, and the embodiment of the present invention does not limit this.
  • the current OSC mainly adopts an Ethernet frame or an optical data unit (ODU) frame encapsulation method, and the manners supported by various manufacturers are not uniform, resulting in poor interoperability.
  • the current approach has the problem of large processing delays. For example, when an Ethernet frame is used to carry overhead, the intermediate node needs to extract and parse all the overhead information of the Ethernet frame payload area, reprocess and encapsulate it into a new payload area, and the processing period is too long to introduce a large processing. Delay.
  • the current encapsulation method uses a fixed bandwidth allocation method. This method has low bandwidth utilization and is inconvenient to expand, and has poor compatibility, which is not suitable for the demand of OSC for large-scale networks in the future.
  • Embodiments of the present invention define new OSC frames.
  • OTN devices can use this unified OSC frame format to solve interworking problems and improve device interoperability.
  • the OSC frame is composed of a plurality of 66B code blocks (ie, one data block having a length of 66 bits), and includes an overhead area and a payload area.
  • the overhead area includes an Alignment Marker (AM) code block and an overhead OH code block.
  • the OSC frame overhead code block is used to carry operation, management, and maintenance (OAM) information of an OSC frame, and the OSC frame alignment indication code block is used to identify an OSC frame.
  • Its payload area contains a series of data blocks that carry the optical layer overhead.
  • FIG. 2 provides a schematic diagram of a possible OSC frame structure.
  • the OSC frame is composed of 2560 66B code blocks.
  • FIG. 2 further describes an AM code block (length: 4 66B code blocks) and an OH code block (length: 4 66B code blocks) included in an OSC frame.
  • the parameters included in these two code blocks are described in detail in Table 1. It should be noted that the parameters of Table 1 are only one possible implementation example, and the parameters included in the actual and the length of each parameter may be different. For example, not only the parameters in Table 1 but also some other parameters have been added. Or, only the partial parameters given in Table 1 are included.
  • Table 1 contains the parameter information of the AM code block and the OH code block in FIG.
  • FIG. 3 provides another schematic diagram of an OSC frame structure. Different from the structure of the OSC frame shown in FIG. 2, the OSC shown in FIG. 3 is composed of 640 66B code blocks, and a shorter frame period is used. The AM code block and the OH code block size are one 66B code block. Figure 3 further describes the information contained in the AM and OH code blocks. The parameters included in these two code blocks are described in detail in Table 2. It should be noted that the parameters of Table 2 are only one possible implementation example, and the parameters included in the actual and the length of each parameter may be different. For example, not only the parameters in Table 2 but also some other parameters are added, or only some of the parameters given in Table 2 are included. For example, an AM code block of an OSC frame does not contain a BIP8 field, but is replaced with a RES field (ie, a reserved field).
  • RES field ie, a reserved field
  • Table 2 Parameter information contained in the AM code block and the OH code block in FIG.
  • FIG. 2 and 3 show the payload area (Payload) contained in the OSC frame, which are 2552 and 638 66B code blocks, respectively.
  • FIG. 4 shows a schematic diagram of an OSC frame payload area, which is applicable to OSC frames of different lengths.
  • the payload area of the OSC frame contains different overhead code block units and idle code blocks.
  • the idle code block may be an IDLE code block (0x1E) defined by IEEE802.3.
  • different overhead code block units such as OTS OH, OMS OH, and OTSiA OH code block units, are floating or fixedly mapped to the OSC frame payload area, and rate adaptation is performed by the idle code block.
  • each overhead code block unit occupies at least two consecutive 66B code blocks.
  • Each 66B code block contains a 2-bit sync header and 64-bit data content.
  • each of the following is taken as an example of two 66B code blocks per overhead code block size.
  • the size of the overhead code block unit used in the actual application is not specifically limited in the embodiment of the present invention, for example, it may also be a single 66B code block.
  • FIG. 5 shows a schematic diagram of the structure of a possible overhead code block unit. Specifically, the overhead code block unit includes the following fields:
  • Synchronization Header Synchronization Header, sync header, fixed to 01 for synchronization;
  • BU_TYPE (8 bits): Block Unit Type, code block unit type (hereinafter referred to as: code block unit type indication field), Table 3 shows a possible value list and corresponding cost type. It should be noted that this field is optional. When the different types of overhead have a fixed location in the payload area of the OSC frame, for example, the OTS OH code block unit occupies the first and second 66B code blocks of the payload area of the OSC frame, this field is not needed;
  • CRC8 (8 bits): Cyclic Redundancy Check 8, 8-bit cyclic redundancy check, used to detect whether there is an error after data transmission. It should be noted that this field is optional. If there is no such field, it can be set to the reserved (RES) field.
  • FIG. 6 shows the structure of two possible OTS OH code block units.
  • the OTS OH code block unit is suitable for OSC frames of length 2560*66B, and is also applicable to OSC frames of other lengths.
  • the first structure includes a BU_TYPE field, which is used to indicate the type of the overhead carried by the overhead code block unit.
  • the second structure is fixedly mapped to a predetermined position in the payload area of the OSC frame.
  • the OTS OH code block unit occupies the 1st and 2nd 66B code blocks in the payload area of the OSC frame, and thus does not include the BU_TYPE field.
  • Table 4 The meaning of each field included in the overhead code block unit is explained in Table 4.
  • Figure 7 shows the structure of two possible OMS OH code block units. Similar to the OTS OH code block unit, the OMS OH code block unit is suitable for OSC frames of length 2560*66B, and is also applicable to OSC frames of other lengths. Specifically, the first structure includes a BU_TYPE field, which is used to indicate the type of the overhead carried by the overhead code block unit. The second type of overhead structure is fixedly mapped to a specific location in the payload area of the OSC frame. For example, the OMS OH code block unit occupies the third and fourth 66B code blocks in the payload area of the OSC frame, and thus does not include the BU_TYPE. Field. The meaning of each field contained in the code block unit is shown in Table 5.
  • FIG. 8 shows a schematic of two possible MSI structures.
  • the MSI structure is used to indicate the optical spectrum resource occupancy of a multiplex section. It needs to be implemented in conjunction with the OMS OH code block unit dedicated multiframe indication field (ie, MFASi).
  • Table 6 The meanings of the fields contained in these two possible MSI structures are explained in Table 6.
  • TPID a special TPID value
  • the second way saves overhead compared to the first.
  • the length of the MSI given in FIG. 9 is not necessarily the same as the length of the MSI given in FIG. 8. Specifically, if the 13 and 12 bits are taken as n and m respectively, the length of one MSI shown in FIG. 9 is 108 bits. Since the three bands are separately shown, the values of specific n and m may be smaller than the above example values. In the structure shown in FIG. 9, n and m can select the length according to the maximum possible value of each band. The embodiment of the present invention does not limit the length, and only needs to indicate the resource occupancy of one band.
  • FIG. 10 shows a schematic diagram of another possible MSI structure. Different from the structural diagram given in FIG. 8, the MSI structure shown in FIG. 10 distinguishes between a Media Channel (abbreviated as MC in the figure) and an OTSiA to represent resources. Therefore, the Type field included in the structure of Fig. 8 is not required in Fig. 10.
  • the multiframes ie, the MFASi field
  • the resource occupancy of multiple OTSiA and Media Channels is respectively indicated.
  • each field is shown in Table 6, and is not described here. It should be noted that the MSIs shown in Figure 10 contain fields that are not identical. Specifically, the MC_TPID and the OTSiA_TPID included in FIG. 10 further divide the TPID in FIG. 8 by using different fields to respectively indicate the Media Channel and the OTSiA, instead of using the Type field in combination with the TPID field to indicate, but three There is no essential difference in the meaning of the fields.
  • the indication of the spectrum segment can also be expressed by other means, for example, by ⁇ starting center frequency n1, terminating center frequency n2>.
  • the embodiment of the present invention does not limit the specific manner of representing the spectrum segment.
  • n and m cannot take a value of 0, so for some fields, the value of the two fields is 0 to determine that this field has no actual meaning. If the resource information is filled in the MSI field in sequence, when parsing the fields with n and m values of 0, it can be determined that the spectrum resource occupation information has been indicated.
  • the multiple MSI structures described above may also add a field to indicate the number of spectrum segments, which simplifies the processing of MSI information. The number of specific spectrum segments depends on the band and actual usage supported by the MSI.
  • the minimum spectrum is based on the minimum spectral granularity (or frequency slice) equal to 3.125GHz.
  • the segment only occupies 1 spectrum granularity, then the S-band contains 3 spectral segments, the C-band contains 1404 spectral segments, and the L-band contains 2264 spectral segments, so there are at most 3671 spectral segments.
  • usually a plurality of consecutive spectrum segments can be combined to be regarded as one spectrum segment, so the actual number of spectrum segments that an MSI needs to represent is greatly reduced.
  • FIG. 11 shows a schematic diagram of a possible OCh/OTSiA OH code block unit.
  • the structure given in FIG. 11 can represent OCh OH or OTSiA OH, specifically by the OTSiAO_TYPE field in the structure.
  • Table 7 indicates whether a field is shared by two different overheads or a certain cost.
  • Table 7 shows the structure of the structure contained in Figure 11
  • one overhead code block unit indicates the type of overhead carried by it by combining two fields (ie, BU_TYPE and OTSiA_Type).
  • Floating mapping indicator field also known as floating mapping indication information
  • This information is used to indicate the specific location of a particular overhead code block unit in the payload area and the overhead type of the overhead it carries. For example, by using ⁇ BU_TYPE, X>, where BU_TYPE indicates the type of the overhead code block unit, and X indicates that the code block unit starts from the Xth code block of the OSC frame payload area.
  • BU_TYPE indicates the type of the overhead code block unit
  • X indicates that the code block unit starts from the Xth code block of the OSC frame payload area.
  • it can also be represented by ⁇ BU_TYPE, OTSiA_Type, X>.
  • the present invention does not impose any restrictions on the specific representation of the floating mapping indication information and its location in the OSC frame.
  • the floating map indicates that the information is placed in the overhead area of the OSC frame. Since the type and number of overheads contained in an OSC frame are variable, the length of the floating map indication information is also variable. In general, the ⁇ length is an integer multiple of the 66B code block size, ie the size is y*66B, where y is a positive integer. In addition, since the payload area of each OSC frame may contain different information (such as the ith frame and the i+1th frame as shown in FIG. 12), the floating mapping indication information of the ith frame and the i+1th frame may be different. The embodiment of the present invention does not specifically limit the location and specific format of the OSC frame for the floating mapping indication information.
  • FEC Forward Error Correction
  • the RSC (514, 544) (an FEC encoding mode) is added to the OSC frame shown in FIG. 2, and the processing steps of adding the FEC to the OSC frame are as follows:
  • Step 1 coding conversion, that is, performing 4*66B to 257B code block conversion on the OSC frame shown in FIG. 2;
  • Compressing the AM code block in the OSC frame specifically, compressing the synchronization header (ie, the SyncHD field) included in the AM code block, and compressing the four 2-bit "10" information into 1-bit information "1", and other parts constant. Similarly, similar processing is performed on the OH code block.
  • the synchronization header ie, the SyncHD field
  • idle code block When four consecutive 66B code blocks include an idle code block, there are four possible arrangements including one idle code block, that is, (free code block, data code block, data code block, data code block), (data code block, Idle code block, data code block, data code block), (data code block, data code block, idle code block, data code block) and (data code block, data code block, data code block, idle code block), similar
  • the specific treatment is:
  • Step A compressing four 2-bit sync headers "01" or "10" into 1-bit information "1";
  • Step B 7 bits are used in the last idle code block to indicate the location information of the included idle code block (ie, indicating which of the 15 possibilities mentioned above is the current 4 code blocks), so that the When this information is obtained, it can be restored to the original code block information, that is, the inverse processing of the code conversion.
  • step A and step B may be performed in the order of AB or BA, or alternately used for encoding processing according to specific needs.
  • Step 2 FEC encoding, specifically, performing FEC encoding on the converted information
  • FEC encoding is performed every 20 257B units, and 300-bit FEC check information (ie, one RS (514, 544) code word) is generated and added to the set of 257B data blocks.
  • 300-bit FEC check information ie, one RS (514, 544) code word
  • the tail is as shown in Figure 13.
  • an OSC frame of length 2560*66B can generate exactly 32 RS (514,544) codewords.
  • FIG. 13 shows a schematic structural diagram involved in the above steps. Furthermore, this way of adding FEC can identify the location of the RS (514, 544) codeword with the fixed pattern information contained in the AM code block of the OSC frame.
  • an OSC frame without FEC information is mapped into another OSC frame format by bit synchronization mapping, and the second OSC format includes an FEC field, so that corresponding FEC information can be added. It should be noted that, when mapping different frames, it may be necessary to complete the rate adaptation function by inserting partial padding information.
  • an OSC frame without FEC information is mapped into another OSC frame format by a Bit Synchronous Generic Mapping Procedure (BGMP), and the second OSC format includes an FEC field. So that the corresponding FEC information can be added. It should be noted that, when mapping different frames, it may be necessary to complete the rate adaptation function by inserting partial padding information.
  • BGMP Bit Synchronous Generic Mapping Procedure
  • the difference between the second method and the third method is that the mapping method used is different.
  • the embodiment of the present invention does not limit the OSC frame format with FEC and the FEC encoding mode adopted.
  • Floating mapping refers to mapping overhead code block units to any idle location of an OSC frame payload area.
  • Fixed mapping refers to mapping overhead code block units to a pre-fixed location of an OSC frame payload area.
  • mapping is floating into the OSC frame.
  • This kind of floating mapping or hybrid mapping provides a certain flexibility, scalability, and can be well adapted to the needs of large-scale networks for OSC in the future.
  • One embodiment of the present invention provides a method, apparatus, and system for overhead processing in an optical network.
  • the first type is the first node, which is the starting node of the service, that is, the customer service is transmitted from the node in the network.
  • the second type is the last node, which is the destination node of the service, that is, the client service is transmitted to this node to terminate.
  • the third type is an intermediate node.
  • the main function of this type of node is to forward the service.
  • it can be an OLA and a ROADM as shown in FIG. 1. It should be noted that different types of devices need to process/operate different overheads according to specific functions.
  • an Optical Monitoring Channel (OSC) frame is generated, where the OSC frame includes a plurality of overhead code block units, and each of the plurality of overhead code block units carries an overhead, and the OSC frame carries An overhead identifier information, where the identifier identifier information is used to identify an overhead type of an overhead carried by the multiple overhead code block units;
  • OSC Optical Monitoring Channel
  • the overhead may include the overhead listed in Table 3.
  • the overhead includes OTS OH, OMS OH, and OTSiA OH.
  • the overhead may further include OCh OH, OTS_DCC, and the like.
  • OTSiA OH and OCh OH may be one or more.
  • Different overheads are encapsulated into different overhead code block units. For example, each overhead is carried by a single overhead code block unit.
  • the generating the OSC frame specifically includes the following steps:
  • Step 1 Encapsulate multiple overheads into multiple overhead code block units
  • Step 2 Mapping the plurality of overhead code block units to a payload area of the OSC frame
  • Step 3 Generate an OSC frame overhead and add it to the overhead area of the OSC frame.
  • the OSC frame overhead includes an OSC frame overhead code block and an OSC frame alignment indication code block.
  • the OSC frame overhead code block is configured to carry operation, management, and maintenance information of the OSC frame, where the OSC frame alignment indication code block is used to identify the OSC frame.
  • the rate of the OSC frame and the rate of the mapped overhead code block unit do not necessarily match.
  • rate adaptation by idle code blocks may be required.
  • one overhead code block unit can be a floating mapping method.
  • the overhead identification information In order to distinguish the type of the overhead carried by each of the plurality of overhead code block units, the overhead identification information needs to be identified.
  • the overhead identifier information corresponds to the MAP field described above, and the location information of the OSC frame and its specific meaning are described in the “Overall Overview” section, and details are not described herein.
  • the overhead identifier information corresponds to one or more code block unit type fields, and the specific location of the information in the OSC frame and its specific meaning are described in the “Overall Overview” section, where Do not repeat them. For example, assign different BU_TYPE values for different overheads. As shown in Table 3, when the code block unit is placed with OTS OH, BU_TYPE is set to 1.
  • BU_TYPE is set to 2. It should be noted that the difference between the two is that the former is placed in the overhead area of the OSC frame.
  • the location of the overhead code block unit contained in the payload area of the OSC frame can be known, and the overhead type information carried by the OSC frame can be known.
  • the latter is placed in the payload area of the OSC frame.
  • the field is placed in an overhead code block unit, indicating the type of overhead carried by the overhead code block unit.
  • the location information can also be used to determine the type of overhead carried by an overhead code block unit. For example, place the OTS OH in a fixed location on an OSC frame as mentioned in the "Overall Overview" section.
  • the head node transmits the OSC frame.
  • the first node sends the OSC frame to other network devices.
  • its downstream neighbor nodes such as: the last node.
  • the last node receives the OSC frame, where the OSC frame includes a plurality of overhead code block units, each of the plurality of overhead code block units carries an overhead, and the OSC frame carries the overhead identification information.
  • the overhead identifier information is used to identify an overhead type of the overhead carried by the multiple overhead code block units;
  • the last node receives the OSC frame sent by the first node.
  • the last node realizes identifying the starting position of an OSC frame by discovering the OSC frame alignment indicator code block, so that subsequent parsing operations can be performed.
  • the various overheads include OTS OH, OMS OH, and OTSiA OH.
  • the multiple overheads further include: one or more of OCh OH, OMS DCC, and OTS DCC. It should be noted that the last node can also receive the OSC frame from the intermediate node.
  • the information enables the node that receives the OSC frame to quickly identify the overhead code block unit that needs to be parsed.
  • the last node identifies, according to the overhead identification information, an overhead type of an overhead carried by each of the plurality of overhead code block units from the OSC frame;
  • the plurality of overhead code block units include at least an OTS OH code block unit, an OMS OH code block unit, and an OTSiA OH code block unit; optionally, an OCh OH code block unit, an OTS_DCC code block unit, and an OMS_DCC One or more of the code block units.
  • the step may further include: deleting the idle code block.
  • the last node optionally, if the received OSC frame contains FEC information, the last node also needs to perform FEC check on the received OSC frame.
  • different overhead code block units may be distinguished by a code block unit type indication field (eg, BU_TYPE).
  • BU_TYPE code block unit type indication field
  • BU_TYPE code block unit type indication field
  • the specific OTSiA OH number can be distinguished by the TPID.
  • the type of overhead included in different overhead code block units may also be identified by floating mapping indication information (e.g., the MAP field in Figure 12).
  • different overhead code block units are identified by a fixed location. For example, if OTS OH and OMS OH are fixed to the first, second, and third, and fourth code blocks, respectively, the node can identify different overhead code block units by identifying the location information after receiving the OSC frame.
  • the end node proposes an overhead from each of the overhead code block units according to the overhead type of the overhead carried by each of the overhead code block units.
  • the corresponding overhead is extracted from the corresponding overhead code block unit
  • the OTS OH is extracted from the OTS OH code block unit.
  • OTSiA OH or OCh OH is extracted from the OTSiA/OCh OH code block unit.
  • OAM processing is performed from the value of the specific field included in the parsed overhead.
  • the PMI field in the OTS OH overhead can be used to determine whether there is a loss of the received service data. More fields and their meanings can be found in the relevant tables in the "Overall Overview" section, which are not described here.
  • the last node also needs to extract the OSC frame overhead information to complete the monitoring and management of the OSC frame. For example, a corresponding field of the OSC frame overhead is proposed to determine whether an OSC frame has a bit error or the like during transmission.
  • a node can flexibly transmit various overhead information of an OTN.
  • This method of overhead processing is flexible and improves bandwidth utilization.
  • the method adopts flexible mapping mode, has good compatibility and high scalability, and can adapt to the demand of large-scale network for OSC in the future.
  • An embodiment of the present invention provides yet another method, apparatus, and system for overhead processing in an optical network.
  • an intermediate device capable of handling part of the overhead may be included.
  • OLA OLA
  • the OLA network device belongs to the network device of the transmission segment, that is, the device terminates its transmission segment with the previous node and starts its transmission segment with the next node, so the overhead associated with the transmission segment needs to be processed.
  • the intermediate node receives a first optical monitoring channel (OSC) frame
  • the first OSC frame includes a plurality of overhead code block units, and each of the plurality of overhead code block units carries an overhead
  • the first OSC frame carries the overhead identifier information, where the identifier identifier information is used to identify an overhead type of the overhead carried by the multiple overhead code block units;
  • the intermediate node receives an OSC frame from its upstream node.
  • This upstream node can be a head node device, or an intermediate node device.
  • the overhead includes OTS OH, OMS OH, and OTSiA OH.
  • the overhead further includes one or more of OCh OH, OMS DCC, and OTS DCC.
  • a first overhead code block unit carrying an optical transmission section overhead is identified from the first OSC frame according to the overhead identification information; and the first overhead code block unit is extracted from the first overhead code block unit OTS OH;
  • the intermediate device determines the overhead code block unit that needs to be parsed according to the overhead identification information.
  • the intermediate device is a transmission segment device. Therefore, the intermediate device needs to parse out the transmission segment overhead contained in the received first OSC frame.
  • the intermediate device parses the overhead code block unit according to a preset format. For example: follow any of the frame formats described in the "Overall Overview" section.
  • the intermediate node generates a second OSC frame, where the second OSC frame includes a second overhead code block unit for carrying the second OTS OH and an overhead code block unit carrying other overheads in the first OSC frame;
  • the step includes:
  • the second OTS OH is generated and encapsulated into a second overhead code block unit. Wherein, the OTS OH is used for OAM operation in the next transmission segment;
  • An OSC frame overhead is generated and added to the overhead area of the second OSC frame.
  • the above first and second steps may be performed in any order, and the present invention is not limited thereto.
  • the end node also needs to perform FEC check on the received OSC frame.
  • the overhead code block unit carrying other overheads includes an overhead code block unit carrying OMS OH and OTSiA OH. It may also include overhead code block units that carry OCh OH and OMS DCC.
  • the intermediate node does not need to handle these overheads and can therefore map directly from the first OSC frame to the second OSC frame. It should be noted that the direct mapping means that the intermediate node does not need to further analyze the overhead code block unit and directly performs mapping. This improves the processing efficiency, and the delay introduced by the intermediate node for OSC frame processing is also lower than that of the prior art.
  • mapping step mentioned in section 163 can be performed in the same manner as described in section 141 of FIG. 14, and details are not described herein again.
  • the intermediate node transmits the second OSC frame.
  • the intermediate node sends an OSC frame to its downstream node, for example, the last node.
  • the last node receives an OSC frame from its upstream node, such as an OLA node in this embodiment.
  • the intermediate node in this embodiment may also need to process the OTS_DCC, and the processing method is similar to the foregoing processing method for the OTS overhead, and details are not described herein again.
  • the intermediate node needs to extract the OSC frame overhead code block included in the OSC frame for monitoring and managing the OSC frame itself. For example: determining whether there is a bit error in the OSC frame during transmission.
  • the multiple overhead information of the OTN is flexibly transmitted, so that the node that receives the OSC frame only needs to extract and process the required overhead, and transparently transmits other overheads to speed up The overhead processing speed.
  • the OSC frame format is flexible, bandwidth utilization is high, compatibility is good, scalability is good, and it can adapt to the demand of large-scale network for OSC in the future.
  • An embodiment of the present invention provides a method, apparatus, and system for overhead processing in an optical network.
  • intermediate devices that handle partial overhead may also be included.
  • a ROADM network device belongs to a network device of a multiplex section, that is, the device terminates its transmission segment and multiplex section with the previous node and starts its transmission segment and multiplex section with the next node, and therefore needs to process the transmission segment and The overhead associated with the multiplex section.
  • the difference between the root embodiment 2 of this embodiment is that the overhead code block units to be processed by the intermediate node are different.
  • the intermediate node in this embodiment needs to perform a similar operation on the OMS OH, that is, the second overhead code block unit carrying the optical multiplex section overhead is identified, and Extracting the optical multiplexing segment overhead;
  • the intermediate node in this embodiment also needs to perform a similar operation on the OMS OH, that is, generate a new OMS OH and encapsulate it into the fourth overhead code.
  • Block unit it should be noted that the generated new OMS OH is used for the next multiplex section for OAM operation.
  • the third overhead code block unit and the fourth overhead code block unit mentioned above, and other overhead code block units that do not need to be processed need to be mapped to the payload area of the second frame.
  • the overhead that is not required to be processed in this embodiment refers to other overhead code block units except the overhead code block unit that carries OTS OH and OMS OH, for example, an OTSiA OH overhead code block unit.
  • the intermediate node in this embodiment needs to determine, according to the cross configuration information, which payload area to which the new OSC frame should be mapped.
  • the cross-configuration information can be manually configured, or automatically configured when the NMS is configured in an end-to-end configuration, or automatically created when the path is created through the control plane rerouting of the device.
  • device 1 has two OTSiA OHs, one of which is device 2 and the other node is device 2.
  • the intermediate node ROADM1 receives the OSC frame including the OTSiA#i OH and OTSiA#j OH overhead code block units, it is necessary to separately place the two overheads into different OSC frames.
  • the overhead code block unit carrying the OTSiA #i OH is mapped to the OSC frame sent to the OA device between the ROADM1 and the ROADM2.
  • the other OTSiA OH code block unit, that is, the OTSiA#j OH overhead code block unit is directly mapped to the OSC frame sent to the other end node.
  • the intermediate node mentioned in this embodiment also needs to process the OMS DCC related overhead, that is, terminate the OMS_DCC it receives and generate the OMS_DCC of the next multiplex section.
  • the multiple overhead information of the OTN is flexibly transmitted, so that the node that receives the OSC frame only needs to extract and process the required overhead, so that other overheads are transparently transmitted.
  • the OSC frame format is flexible, bandwidth utilization is high, compatibility is good, scalability is good, and it can adapt to the demand of large-scale network for OSC in the future.
  • the payload area that maps the overhead code block unit to the OSC frame mentioned in Embodiment 1-3 may be a floating mapping manner or a mixture of the two.
  • mapping method refer to the description in the "Overall Overview" section, which is not described here.
  • the network devices (the first node, the last node, and the intermediate node) described in Embodiments 1-3 above may use various OSC frame structures described in the "Overall Overview" section. One. The flow description of the above embodiments 1-3 does not describe the OSC frame structure, and only relevant fields or information are mentioned when needed.
  • the head node includes a transmitting unit 181 and a processing unit 182. among them:
  • the processing unit is configured to construct an OSC frame. Specifically, for performing the actions described in section 141 of FIG. 14;
  • the sending unit is configured to send an OSC frame constructed by the processing unit to another network device (such as a certain downstream network device), that is, to perform the action described in part 142 of FIG. 14.
  • another network device such as a certain downstream network device
  • the processing unit 182 further includes a first processing unit 1821, a second processing unit 1822, and a third processing unit 1823.
  • the first processing unit 1821 is configured to construct an overhead code block unit.
  • the second processing unit 1822 is configured to construct an OSC frame overhead.
  • the third processing unit 1823 is configured to map the objects constructed by the first and second processing units to the OSC frame.
  • the processing unit further includes a first processing unit, a second processing unit, a third processing unit, and a fourth processing unit.
  • the former implementation manners of the first processing unit, the second processing unit, and the third processing unit are the same, and are not described herein.
  • the fourth processing unit is configured to add FEC information to the OSC frame.
  • FIG. 19 is a schematic structural diagram of still another possible network device. Specifically, the schematic diagram shows a possible structure of the last node involved in the foregoing method embodiment.
  • the end node includes a receiving unit 191 and a processing unit 192. among them:
  • the receiving unit 191 is configured to receive an OSC frame from another network device (such as an upstream neighbor node thereof);
  • the processing unit 192 is configured to parse an OSC frame received by the receiving unit. Specifically, it is used to perform steps 152 to 153 in FIG.
  • the intermediate node includes a receiving unit 201, a first processing unit 202, a second processing unit 203, and a transmitting unit 204.
  • the receiving unit 201 is configured to receive an OSC frame from another network device (such as its upstream neighbor node), specifically performing the operation of receiving the OSC frame in step 161 in FIG.
  • the first processing unit 202 is configured to parse the OSC frame received by the receiving unit, specifically including performing the parsing operation in step 162 shown in FIG. 16.
  • the second processing unit is configured to construct a new OSC frame, specifically performing step 163 shown in FIG.
  • the sending unit 204 is configured to send a new OSC frame constructed by the second processing unit, that is, perform step 164 shown in FIG. 16.
  • the receiving unit 201 is configured to receive an OSC frame from another network device (eg, its upstream neighbor node), specifically performing the operation of receiving the OSC frame in step 171 of FIG.
  • the first processing unit 202 is configured to parse the OSC frame received by the receiving unit, specifically including performing the parsing operation in step 172 shown in FIG.
  • the second processing unit is configured to construct a new OSC frame, specifically performing the actions described in step 173 shown in FIG.
  • the transmitting unit 204 is configured to send a new OSC frame constructed by the second processing unit, that is, perform step 174 shown in FIG.
  • first processing unit and second processing unit may be combined into one processing unit.
  • the second processing unit can also be divided into a plurality of processing units.
  • the second processing unit may be further divided into a third processing unit and a fourth processing unit, respectively configured to encapsulate multiple overheads into different overhead code block units, and map the multiple overhead code block units Go to an OSC frame.
  • the above processing unit, the transmitting unit and the receiving unit may also be a processor, a transmitter and a receiver, respectively.
  • 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 for implementing the described functions for each particular application, but such implementation should not be considered to be beyond the scope of the present invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Time-Division Multiplex Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Optical Communication System (AREA)
  • Small-Scale Networks (AREA)

Abstract

本发明实施例涉及光通信领域，尤其涉及光传送网络中的开销处理技术。在一种开销发送的方法中，网络设备生成光监控信道(OSC)帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述OSC帧携带开销标识信息，用于标识所述多个开销码块单元所承载的开销的开销类型，所述开销包括光传输段开销、光复用段开销和集成光支路信号开销；所述网络设备发送所述OSC帧。通过采用本发明提供的开销处理技术，网络设备可以从接收到的OSC帧提取并解析需要处理的开销码块单元，而透传无需解析的开销码块单元，从而降低了开销处理周期，即开销处理时延。此外，本发明提供的开销处理技术提供灵活的封装和映射方式，可扩展性好。

Description

一种光网络中光监控信道处理的方法和装置
本申请要求于2017年7月14日提交中国专利局、申请号201710577112.7、发明名称为“一种光网络中光监控信道处理的方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明实施例涉及光通信领域，尤其涉及光网络中的开销处理技术。
背景技术
光传送网(Optical Transport Network，简称OTN)作为下一代传送网的核心技术，具备丰富的操作、管理与维护(Operation Administration and Maintenance，简称OAM)能力、强大的串联连接监视(Tandem Connection Monitoring，简称TCM)能力和带外前向错误纠正(Forward Error Correction，简称FEC)能力，能够实现大容量业务的灵活调度和管理。其中，光监控信道(Optical Supervisory Channel，简称OSC)用于在OTN中传送OAM相关信息，还有保护相关信息，其中OAM相关信息和保护相关信息也时常称做开销。
OTN具备大带宽和低时延的特性，因而成为了许多新兴业务的理想传输方式，例如：4K/8K，虚拟现实等。随着新业务的不断涌现，网络流量也不断地增长，使得OTN的规模不断扩展，也使得网络的维护管理变得越来越具有挑战性。OSC，作为传送OAM和保护信息的主要手段，也面临着很多问题。当前的封装方式存在较大的时延。以OSC采用以太网帧封装为例，中间节点需要将以太帧中包含的所有开销信息都提取出来并进行解析，然后重新处理并封装到新的净荷区。当前这种做法针对OSC的处理周期过长，引入较大的处理延时。此外，当前的封装方式不便于扩展，兼容性差，不适用于未来大规模网络对OSC的需求。
因此，需要一种OSC处理技术，来解决上述提到的OSC当前面临的问题。
发明内容
本发明实施例描述了一种OSC处理的方法和装置，以改善OTN网络中的OSC性能。
第一方面，本发明实施例提供了一种光传送网中开销处理的方法，所述方法包括：
生成光监控信道(OSC)帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
发送所述OSC帧。
需要说明的是，所述开销包括光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)。可选地，所述开销还包括光信道开销(OCh OH)、光传输段数据通信信道(OTS_DCC)和光复用段数据通信信道(OMS_DCC)的一种或多种。还需要说明的是，一个OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区。
在一种可能的实现中，所述开销标识信息位于所述OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述OSC帧的净荷区中的位置信 息和所述至少一个开销码块单元所承载的开销的开销类型信息。
在另一种可能的实现中，所述开销标识信息位于所述多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中的每个开销码块单元所承载的开销的开销类型。
在一种可能的设计中，所述生成OSC帧可以细化为：封装所述OTS OH、OMS OH和OTSiA OH到所述多个开销码块单元中；映射所述多个开销码块单元到OSC帧的净荷区。具体地，所述映射所述多个开销码块单元到OSC帧的净荷区包括：将所述多个开销码块单元中的部分开销码块单元映射到所述OSC帧的净荷区中预先设定的位置，将另一部分开销码块单元映射到所述OSC帧的净荷区中任意空闲位置；或者，将所述多个开销码块单元映射到所述OSC帧净荷区中任意空闲位置。
在一种可能的设计中，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
第二方面，本发明实施例提供了一种光网络中的网络设备，该网络设备用于实现所述第一方面的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或者软件包括一个或者多个与上述功能相应的模块。
在一种可能的设计中，该网络设备包括处理器和发送器。所述处理器用于支持网络设备执行第一方面中提及的方法中相应的功能。例如：生成OSC帧。所述发送器，用于支持网络设备执行第一方面中提及的发送动作。
第三方面，本发明实施例提供了又一种光传送网中开销处理的方法，所述方法包括：
网络设备接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
根据所述开销标识信息，从所述第一OSC帧中识别出承载第一OTS OH的第一开销码块单元；从所述第一开销码块单元中提取所述第一OTS OH；
生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元；
发送所述第二OSC帧。
需要说明的是，所述开销包括第一光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)。可选地，所述开销还包括光信道开销(OCh OH)、光传输段数据通信信道(OTS_DCC)和光复用段数据通信信道(OMS_DCC)的一种或多种。所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)。而所述第二OTS OH用于实现所述网络设备和与所述网络设备相邻的下游网络设备之间的传输段的OAM。还需要说明的是，一个OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区。
在一种可能的设计中，所述开销标识信息位于所述第一OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述第一OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
在另一种可能的设计中，所述开销标识信息位于所述第一OSC帧包括的多个开销码块 单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中的每个开销码块单元所承载的开销的开销类型。
在一种可能的设计中，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
在一种可能的设计中，所述生成第二OSC帧包括：生成所述第二OTS OH并封装到第二开销码块单元；映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。具体地，所述映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元中的部分开销码块单元到所述第二OSC帧的净荷区中预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧净荷区中任意空闲位置。
第四方面，本发明实施例提供了又一种光网络中的网络设备，该网络设备用于实现所述第三方面的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或者软件包括一个或者多个与上述功能相应的模块。
在一种可能的设计中，该网络设备包括接收器、处理器和发送器。所述接收器用于执行第三方面的接收动作。所述处理器用于支持网络设备执行第三方面中提及的方法中相应的功能。例如：生成第二OSC帧。所述发送器，用于支持网络设备执行第三方面中提及的发送动作。
第五方面，本发明实施例提供了再一种光传送网中开销处理的方法，所述方法包括：
网络设备接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
根据所述开销标识信息，从所述第一OSC帧中识别出承载第一OTS OH的第一开销码块单元和承载第一OMS OH的第二开销码块单元；从所述第一开销码块单元和所述第二开销码块单元中分别提取所述第一OTS OH和所述第一OMS OH；
生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第三开销码块单元，承载第二OMS OH的第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元；
发送所述第二OSC帧。
需要说明的是，所述开销包括第一光传输段开销(OTS OH)、第一光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)。可选地，所述开销还包括光信道开销(OCh OH)、光传输段数据通信信道(OTS_DCC)和光复用段数据通信信道(OMS_DCC)的一种或多种。其中，所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)，所述第一OMS OH用于实现对位于所述网络设备上游的具备光复用功能的第一网络设备和所述网络设备之间的复用段的OAM，所述第一网络设备和所述网络设备之间没有其他具备复用段功能的网络设备。而，所述第二 OTS OH用于实现所述网络设备和与所述网络相邻的下游网络设备之间的传输段的OAM，所述第二OMS OH用于实现对所述网络设备和与所述网络设备下游的具备光复用段功能的第二网络设备之间的复用段的OAM，所述网络设备和所述第二网络设备之间没有其他具备光复用功能的网络设备。还需要说明的是，一个OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区。
在一种可能的设计中，所述开销标识信息位于所述第一OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述第一OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
在另一种可能的设计中，所述开销标识信息位于所述第一OSC帧包含的多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中的每个开销码块单元所承载的开销的开销类型。
在一种可能的设计中，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
在一种可能的设计中，所述生成第二OSC帧包括：生成所述第二OTS OH并封装到第三开销码块单元；生成所述第二OMS OH并封装到第四开销码块单元；映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。具体地，所述映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：映射所述所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元的部分开销码块单元到所述第二OSC帧的净荷区中预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区中任意空闲位置。
第六方面，本发明实施例提供了再一种光网络中的网络设备，该网络设备用于实现所述第五方面的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或者软件包括一个或者多个与上述功能相应的模块。
在一种可能的设计中，该网络设备包括接收器、处理器和发送器。所述接收器用于执行第五方面的接收动作。所述处理器用于支持网络设备执行第五方面中提及的方法中相应的功能。例如：生成第二OSC帧，提取第一OTS OH等。所述发送器，用于支持网络设备执行第五方面中提及的发送动作。
第七方面，本发明提供了另一种光传送网中开销处理的方法，所述方法包括：
接收OSC帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
根据所述开销标识信息，从所述OSC帧中识别出所述多个开销码块单元中的每一个开销码块单元所承载的开销的开销类型；
根据所述每一个开销码块单元所承载的开销的开销类型，从所述每一个开销码块单元中提出开销。
需要说明的是，所述开销包括光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)。可选地，所述开销还包括光信道开销(OCh OH)、光传输段数据通信信道(OTS_DCC)和光复用段数据通信信道(OMS_DCC)的一种或多种。还需要说明的是，一个OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区。
在一种可能的实现中，所述开销标识信息位于所述OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
在另一种可能的实现中，所述开销标识信息位于所述多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中的每个开销码块单元所承载的开销的开销类型。
在一种可能的设计中，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
第八方面，本发明实施例提供了另一种光网络中的网络设备，该网络设备用于实现所述第七方面的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。所述硬件或者软件包括一个或者多个与上述功能相应的模块。
在一种可能的设计中，该网络设备包括接收器和处理器。所述接收器用于执行第七方面的接收动作。所述处理器用于支持网络设备执行第七方面中提及的方法中相应的功能。例如：提取开销等。
需要说明的是，上述第一方面至第八方面，所述开销标识信息还可以为预先设定的位置信息。可选地，所述OSC帧还可以包括前向纠错(FEC)信息。具体地，第一方面描述的方法还要添加FEC信息；第三方面、第五方面和第七方面描述的方法还需要对接收到的OSC帧进行FEC校验。具体地，上述第一方面至第八方面中，所述OSC帧包含OSC帧对齐指示码块和OSC帧开销码块，所述OSC帧开销码块用于携带所述OSC帧的操作、运行和维护(OAM)信息，所述OSC帧对齐指示码块用于标识所述OSC帧。
第九方面，本发明实施例提供了一种光网络系统，所述系统包括所述第二方面的网络设备、所述第四方面的网络设备和所述第八方面的网络设备；或者，所述系统包括所述第二方面和所述第八方面的网络设备；或者，所述系统包括所述第二方面、所述第四方面和所述第六方面和所述第八方面的网络设备；或者，包括所述第二方面的网络设备、所述第六方面的网络设备和所述第八方面的网络设备。
相较于现有技术，本发明提供的方案可以通过一个OSC帧格式对不同的开销进行分开承载，简化了网络设备对开销的处理，从而降低了开销处理时延。此外，本发明提供的开销处理技术提供灵活的封装和映射方式，可扩展性好。
附图说明
下面将参照所示附图对本发明实施例进行更详细的描述：
图1为本发明实施例的一种可能的应用场景示意图；
图2为一种可能的OSC帧结构示意图；
图3为又一种可能的OSC帧结构示意图；
图4为一种可能的OSC帧净荷区的结构示意图；
图5为一种可能的开销码块单元的结构示意图；
图6为两种可能的OTS OH码块单元结构示意图；
图7为两种可能的OMS OH码块单元结构示意图；
图8为两种可能的MSI结构示意图；
图9为又一种可能的MSI结构示意图；
图10为再一种可能的MSI结构示意图；
图11为一种可能的OTSiA或OCh OH码块单元结构示意图；
图12为一种可能的包含浮动映射指示信息的OSC帧结构示意图；
图13为一种可能的添加FEC的结构示意图；
图14为一种可能的网络设备OSC帧处理流程图；
图15为又一种可能的网络设备OSC帧处理流程图；
图16为再一种可能的网络设备OSC帧处理流程图；
图17为另一种可能的网络设备OSC帧处理流程图；
图18为一种可能网络设备结构示意图；
图19为又一种可能网络设备结构示意图；
图20为另一种可能网络设备结构示意图。
具体实施方式
本发明实施例描述的网络架构以及业务场景是为了更加清楚地说明本发明实施例的技术方案，并不构成对本发明实施例提供的技术方案的限制。本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题同样适用。
总体概述：
本发明的实施例适用于光网络，例如：光传送网络(Optical transport Network，简称OTN)。如图1所示，一个OTN可以包括多种不同的设备类型，例如：线路终端(Line Terminal，简称LT)、光放大器(Optical Amplifier，简称OA)、光分插复用器(Optical Add-Drop Multiplexer,简称OADM)等。LT有时也被称为光传送模块(Optical Transport Module，简称OTM)，用于将电信号调制到预先设定的光信号(波长)上或者是从特定的光信号上解调出电信号。OA也可被称为光线路放大器(Optical Line Amplifier，简称OLA)，主要用于对光信号进行放大，以支持在保证光信号的特定性能的前提下传输更远的距离。OADM用于对光信号进行空间的变换，从而使其可以从不同的输出端口(有时也称为方向)输出。根据能力不同，OADM可以分为固定的OADM(FOADM)，可配置的OADM(ROADM)等。一般地，多个LT和复用器/解复用器组合构成一个设备，例如图1中的设备1。
为了便于对网络进行管理，OTN分为不同的层次。如图1所示，OTN包括光传输段(Optical Transport Section，简称OTS)，光复用段(Optical Multiplex Section,简称OMS)和集成光支路信号(Optical Tributary Signal Assembly,简称OTSiA)等。为了实现对不同段进行有效的运维和管理，OTN定义了丰富的开销(overhead，简称OH)，分别用于传递不同层次的OAM和/或保护信息，光层开销都通过光监控信道(Optical Supervisory Channel， 简称OSC)来进行传送。例如，OTS开销(后续简称OTS OH)，用于实现两个相邻光传输设备之间的运维和管理。例如，图1中的设备1与其相邻的设备OA这一段被视为一个传输段。该开销可能包含的具体参数和其含义举例参见表4，此处不做赘述。又如，OMS开销(后续简称OMS OH)，用于实现两个相邻的具备光复用功能的设备之间的运维和管理(参见图1的相关例子)。再如，OTSiA开销(后续简称OTSiA OH)，用于实现对在两个设备之间传输的一个或者多个光信号的运维和管理。所述两个设备的其中一个为传输光信号的源节点设备，另一个为传输光信号的目的节点(又称宿节点)。例如，图1中的设备1和设备2。
如图1所示，不同的设备所支持的OTN层次可能不同。对应地，不同的OTN设备需要处理的开销种类/个数不同。例如：图1中的设备1需要处理上面提到的三种开销，即OTS OH、OMS OH和OTSiA OH；而OA设备仅需要处理OTS OH。又如：ROADM设备仅需要处理OTS OH和OMS OH。
需要说明的是，光信道(Optical Channel，简称OCh)是国际电信联盟-电信分部(International Telecommunication Union-Telecommunication Sector，简称ITU-T)早期针对单载波定义的一种光信号类型/层次，对应这个信号/层次的开销为OCh OH(即光信道开销)。前面提到的OTSiA是ITU-T近期定义的针对多载波的一种光信号类型/层次，其对应的开销为OTSiA OH。两种信号类型可以单独出现，或者同时出现，本发明实施例对此不作任何限定。
当前的OSC主要采用以太帧或者光数据单元(ODU)帧的封装方式，各个厂家支持的方式不统一，导致互通性差。其次，当前的方式存在处理延时大的问题。例如：采用以太帧来承载开销时，中间节点需要将以太帧净荷区的所有开销信息都提取出来并解析，重新处理并封装到新的净荷区，处理周期过长从而引入较大的处理延时。第三，当前的封装方式采用固定带宽分配的方式。这种方式的带宽利用率低且不便于扩展，兼容性差，不适用于未来大规模网络对OSC的需求。
本发明的实施例定义了新的OSC帧。OTN设备可以使用这个统一的OSC帧格式，从而解决互通问题，提升了设备的互操作性。该OSC帧由多个66B码块(即长度为66bit的一个数据块)组成，包含开销区和净荷区。开销区包含对齐指示(Alignment Marker，简称AM)码块和开销OH码块。其中，OSC帧开销码块用于携带一个OSC帧的操作、管理和维护(OAM)信息，OSC帧对齐指示码块用于识别一个OSC帧。其净荷区包含了一系列承载光层开销的数据码块。
下面结合更多的附图，对本发明实施例定义的OSC帧结构进行详细描述。
图2提供了一种可能的OSC帧结构示意图。具体地，该OSC帧由2560个66B码块组成。图2对OSC帧包含的AM码块(长度：4个66B码块)和OH码块(长度：4个66B码块)进行了进一步的描述。这两个码块包含的参数具体介绍如表1所示。需要说明的是，表1的参数仅是一种可能的实现举例，实际中包含的参数和每个参数的长度可能有所不同。例如，不但包括表1中的参数还增加了一些其他参数。或者，仅包含表1中给出的部分参数。
Figure PCTCN2018080303-appb-000001
表1图2中的AM码块和OH码块包含的参数信息
图3提供了又一种OSC帧结构示意图。跟图2所示OSC帧的结构不同的是，图3所示的OSC由640个66B码块组成，使用了更短的帧周期。其中的AM码块和OH码块大小为1个66B码块。图3对AM和OH码块所包含的信息做了进一步的描述。这两个码块包含的参数具体介绍如表2所示。需要说明的是，表2的参数仅是一种可能的实现举例，实 际中包含的参数和每个参数的长度可能有所不同。例如，不但包括表2中的参数还增加了一些其他参数，或者是仅包含表2中给出的部分参数。例如：一个OSC帧的AM码块不包含BIP8字段，而用RES字段(即保留字段)替代。
Figure PCTCN2018080303-appb-000002
表2图3中的AM码块和OH码块包含的参数信息
图2和图3给出了OSC帧包含的净荷区(Payload)，大小分别为2552和638个66B码块。进一步地，图4给出了一种OSC帧净荷区的示意图，这个示例适用于不同长度的OSC帧。例如，图2和图3给出的OSC帧。如图4所示，OSC帧的净荷区包含了不同的开销码块单元和空闲码块。其中，空闲码块可以是IEEE802.3定义的IDLE码块(0x1E)。具体地，不同的开销码块单元，例如：OTS OH、OMS OH以及OTSiA OH码块单元，浮动或者固定映射到OSC帧净荷区，通过空闲码块进行速率适配。其中，每种开销码块单元占用至少两个连续的66B码块。每个66B码块包含2比特的同步头和64比特的数据内容。为了方面描述，后续均以每个开销码块大小为2个66B码块为例。但是，本发明实施例对实际应用时采用的开销码块单元的大小不做特殊限定，如：还可以是单个的66B码块。
下面结合图5，对开销码块单元进行更进一步的描述。图5给出了一种可能的开销码块单元的结构示意图。具体地，该开销码块单元包括如下字段：
SyncHD(2 bits)：Synchronization Header，同步头，固定设置为01，用于同步；
BU_TYPE(8 bits):Block Unit Type,码块单元类型(后续称之为：码块单元类型指示字段)，表3示出了一种可能的取值列表和对应的开销类型。需要说明的是，这个字段是可选的。当不同类型的开销在OSC帧的净荷区有固定的位置时，例如OTS OH码块单元占据OSC帧的净荷区的第一个和第二个66B码块，则无需此字段；
CRC8(8 bits)：Cyclic Redundancy Check 8，8比特循环冗余校验，用于检测在数据传输后是否存在错误。需要说明的是，这个字段是可选的，如果没有此字段，可以将其设置为保留(RES)字段。
Figure PCTCN2018080303-appb-000003
表3 BU_TYPE的取值和对应的开销类型示例
根据BU_TYPE类型的不同，图5中的其他未标示的字段包含的具体字段信息也不同。下面将结合具体的BU_TYPE类型，给出一些开销的具体结构示例。
图6给出了两种可能的OTS OH码块单元的结构示意图。该OTS OH码块单元适用于长度为2560*66B的OSC帧，也适用于其他长度的OSC帧。具体地，第一种结构包含BU_TYPE字段，用于指示该开销码块单元所承载的开销类型。而第二种结构因固定映射到 OSC帧净荷区中预先设定的位置。例如：OTS OH码块单元占据OSC帧的净荷区中第1个和第2个66B码块，从而不包含BU_TYPE字段。该开销码块单元包含的每个字段的含义解释如表4所示。
Figure PCTCN2018080303-appb-000004
Figure PCTCN2018080303-appb-000005
表4两种可能的OTS OH码块单元的字段解释
图7给出了两种可能的OMS OH码块单元的结构示意图。类似OTS OH码块单元，该OMS OH码块单元适用于长度为2560*66B的OSC帧，也适用于其他长度的OSC帧。具体地，第一种结构包含BU_TYPE字段，用于指示该开销码块单元所承载的开销类型。而第二种开销结构因固定映射到OSC帧净荷区中特定的位置，例如：OMS OH码块单元占据OSC帧的净荷区中第3个和第4个66B码块，从而不包含BU_TYPE字段。该码块单元包含的每个字段的含义表5所示。
Figure PCTCN2018080303-appb-000006
表5两种可能的OMS OH码块单元的字段解释
下面结合图8-10，进一步对MSI的定义进行解释。
图8给出了两种可能的MSI结构示意图。具体地，该MSI结构用于指示一个复用段的光频谱资源占用情况。需要结合OMS OH码块单元专用复帧指示字段(即MFASi)来实现。如图8所示，以一个OSC帧中的OMS OH开销码块单元包含的MSI字段长度为64或者62比特为例，通过256个复帧(即：MFASi＝0,1，…,255)实现了表示512个频谱资源的占用情况。这两种可能的MSI结构包含的字段的含义解释见表6。
Figure PCTCN2018080303-appb-000007
表6两种可能的MSI包含的字段解释
需要说明的是，第一种和第二种方式的区别是第一种方式采用单独的OCCU字段来表示占用空闲状态，而第二种利用特殊的TPID取值(即TPID＝0)来表示资源的空闲状态，而其他TPID取值表示资源已被占用。因此，无需额外的字段来表示资源空闲这一含义。第二种方式比第一种方式节约开销。
图9给出了又一种可能的MSI结构示意图。跟图8给出的结构示意图不同的是，图9 给出的MSI结构区分不同波段的资源的占用情况，即用不同的字段来表示不同波段的资源占用情况。具体地，一个单帧中包含S_MSI[x],L_MSI[x]和C_MSI[x]，其中x＝0,1，…,255,分别用来表示S波段、L波段和C波段的频谱资源占用情况。通过结合复帧(即MFASi字段),从而完整地表示三个波段的资源占用情况。具体地，每个字段的含义请参见表6，此处不做赘述。需要说明的是，图9给出的MSI的长度跟图8给出的MSI长度不一定相同。具体地，如果按照n和m分别取13和12比特为例，那么图9所示的一个MSI的长度为108比特。因为三个波段分开表示，具体n和m的取值可能小于上述的示例值。在图9所示的结构中，n和m可以根据每个波段的最大可能值来选取长度，本发明实施例不对这个长度做任何限定，仅要求可以表示出一个波段的资源占用情况。
图10给出了再一种可能的MSI结构示意图。跟图8给出的结构示意图不同的是，图10给出的MSI结构区分Media Channel(图中简写为MC)和OTSiA来表示资源。因此，图10中无需图8结构中包含的Type字段。具体地，一个OSC单帧中包含OTSiA_MSI[x],MC_MSI[x],其中x＝0,1，…,255,分别用来表示OTSiA和Media Channel的频谱资源占用情况。通过结合复帧(即MFASi字段),从而分别表示了多个OTSiA和Media Channel的资源占用情况。具体地，每个字段的含义请参见表6，此处不做赘述。需要说明的是图10给出的MSI包含的字段不完全相同。具体地，图10包含的MC_TPID和OTSiA_TPID是将图8中的TPID做了进一步的划分，即采用不同的字段来分别指示Media Channel和OTSiA，而并非采用Type字段结合TPID字段来指示，但三个字段的含义无本质区别。
要说明的是，上面四种MSI结构的示例中，频谱段的指示还可以通过其他方式来表示，例如：通过<起始中心频率n1，终止中心频率n2>。本发明实施例对表示频谱段的具体方式不做任何限定。
还需要补充说明的是，当前并没有表示频谱段数量的字段，可通过分析每个MSI包含的n和m取值来判断是否资源占用情况表示完毕。一般地，n和m不能取值为0，因此对于某些字段该两个字段取值为0可以判断这个字段无实际含义。如果资源信息是按照顺序填充到MSI字段的话，当解析到n和m取值为0的字段时，即可以判断频谱资源占用信息已经表示完毕。可选地，上述的多种MSI结构还可以增加一个字段来表示频谱段的数量，这样可以简化针对MSI信息的处理。具体频谱段的数量，取决于MSI所支持的波段和实际使用情况。若一个复用段支持S(1460nm到1530nm)、C(1530nm到1565nm)和L(1565nm到1625nm)波段，基于最小频谱粒度(或称为频谱单元，frequency slice)等于3.125GHz为例，最小频谱段仅占用1个频谱粒度，则S波段包含3个频谱段，C波段包含1404个频谱段，L波段包含2264个频谱段，因此最多存在3671频谱段。在实际使用时，通常多个连续频谱段可以合并从而被视为一个频谱段，因此一个MSI需要表示的频谱段的实际数量会大大降低。
图11给出了一种可能OCh/OTSiA OH码块单元的结构示意图。需要说明的是，图11给出的结构可以表示OCh OH或者OTSiA OH，具体通过该结构中的OTSiAO_TYPE字段来区分。例如：OTSiAO_TYPE＝1表示当前开销码块单元承载的OTSiA OH；OTSiAO_TYPE＝0承载为OCh OH。具体的参数解释见表7。需要说明的是，表7的最后一列指出了某个字段到底两种不同开销共有，还是某种开销特有。
Figure PCTCN2018080303-appb-000008
Figure PCTCN2018080303-appb-000009
表7图11中的结构示意图包含的字段解释
需要说明的是，在图11的示例中，一个开销码块单元通过两个字段(即BU_TYPE和OTSiA_Type)结合来指示其承载的开销类型。如表3所示，OTSiA OH和OCh OH也可以分别使用不同的码块单元类型，即BU_TYPE＝0x03时为OTSiA OH，BU_TYPE＝0x04时为OCh OH。
可选地，当OSC帧所包含的开销码块单元位置可以变化时，即各种开销码块单元通过浮动映射的方式添加到OSC帧的净荷区，可以在OSC帧的开销区中增加一个浮动映射指示字段(又称浮动映射指示信息)。该信息用于指出具体的某一个开销码块单元在净荷区的具体位置和其承载的开销的开销类型。例如通过使用<BU_TYPE,X>来表示，其中BU_TYPE表示开销码块单元的类型，而X则表示该码块单元起始于OSC帧净荷区的第X个码块。或者，还可以通过<BU_TYPE,OTSiA_Type,X>来表示。本发明对浮动映射指示信息的具体表示形式和其在OSC帧的位置不任何限制。
下面结合图12对这个浮动映射指示信息做进一步的说明。需要说明的是，在图12中，MAP字段为上一段描述的浮动映射指示信息。
在图12给出的结构示例中，该浮动映射指示信息放置OSC帧的开销区。因为一个OSC帧包含的开销类型和个数是可变的，这个浮动映射指示信息的长度也是可变的。一般地，岂长度是66B码块大小的整数倍，即大小为y*66B，其中y为正整数。此外，因为每一个OSC帧的净荷区包含的信息可能不同(如图12给出的第i帧和第i+1帧)，因此第i帧和第i+1帧的浮动映射指示信息可能不同。本发明的实施例对于该浮动映射指示信息在OSC帧的位置和具体格式不做具体限定。
可选地，在一个网络设备发送OSC帧之前，可以添加前向错误纠正(Forward Error Correction,简称FEC)信息，用于支持接收到该OSC帧的网络设备自动纠正传输中发生的错误。
在一种可能的实现中，以图2示出的OSC帧添加RS(514,544)(一种FEC编码方式)为例，OSC帧添加FEC的处理步骤如下：
步骤1：编码转换，即对图2所示的OSC帧进行4*66B至257B码块的转换；
对OSC帧中的AM码块进行压缩，具体地，将AM码块包含的同步头(即SyncHD字段)进行压缩，4个2比特的“10”信息压缩为1比特信息“1”，其他部分保持不变。类似地，对OH码块也做类似处理。
对于净荷区所包含的66B码块，存在两种可能的处理方式。当4个连续的66B码块都是数据码块(即非空闲码块，或者说都是承载了开销的开销码块单元)时，压缩4个2比 特的同步头“01”为1比特信息“0”，其他信息保持不变。当4个连续的66B码块包含空闲码块时，包含一个空闲码块的可能排列有4种，即(空闲码块，数据码块，数据码块，数据码块)、(数据码块，空闲码块，数据码块，数据码块)、(数据码块，数据码块，空闲码块，数据码块)和(数据码块，数据码块，数据码块、空闲码块)，类似地，含两个空闲码块的可能排列有6种，含三个空闲码块的的可能排列有4种，含4个空闲码块的可能排列有1种，一共有15钟可能性。针对这种情况，具体的处理方式为：
步骤A：压缩4个2比特的同步头“01”或者“10”为1比特信息“1”；
步骤B：在最后一个空闲码块中使用7比特来表示包含的空闲码块的位置信息(即指示当前4个码块为上述提到的15种可能性的哪一种)，从而使得在收到这个信息时可以还原为原来的码块信息，即做编码转换的逆处理。
需要说明的是，上述的7比特的长度值仅是示例，另外，步骤A和步骤B可以按照AB或者BA的顺序执行，或者按照具体的需要交替是用来进行编码处理。
步骤2：FEC编码，具体地，对经过转换处理后的信息进行FEC编码；
从OSC帧的AM码块开始，以每20个257B为一个单位，进行FEC编码，生成300比特FEC校验信息(即一个RS(514，544)码字)并添加到这一组257B数据块的尾部，具体如图13所示。从图13可以看出，一个长度为2560*66B的OSC帧正好可以生成32个RS(514,544)码字。
需要说明的是，图13给出了上述步骤中涉及的结构示意图。此外，这种添加FEC的方式可以用OSC帧的AM码块中包含的固定图案信息来识别RS(514，544)码字的位置。
在另一种可能的实现中，一个不带FEC信息的OSC帧通过比特同步映射方式映射另一个OSC帧格式中，第二个OSC格式包含了FEC字段，从而可以添加对应的FEC信息。需要说明的是，在进行不同帧的映射时可能需要通过插入部分填充信息来完成速率的适配功能。
在又一种可能的实现中，一个不带FEC信息的OSC帧通过比特同步通用映射规程(Bit synchronous Generic Mapping Procedure，简称BGMP)映射另一个OSC帧格式中，第二个OSC格式包含了FEC字段，从而可以添加对应的FEC信息。需要说明的是，在进行不同帧的映射时可能需要通过插入部分填充信息来完成速率的适配功能。
需要说明的是，第二种和第三种方式区别在于采用的映射方法不同。本发明的实施例对于带FEC的OSC帧格式以及采用的FEC编码方式不做任何限定。
需要说明的是，针对一个指定的开销码块单元，是采用浮动映射放入OSC帧的净荷区中任意空闲位置，还是放在OSC帧的净荷区中固定的位置，要根据具体的需要来选择。本发明实施例不对具体的映射方式做限定。所谓浮动映射指的是将开销码块单元映射到一个OSC帧净荷区的任意空闲位置。而固定映射指的是将开销码块单元映射到一个OSC帧净荷区的预先固定的位置。一般地，所有OTN设备都需要处理OTS OH和OMS OH。因此，可以将OTS OH和OMS OH设定为放置在OSC帧的固定位置。而对于其他开销(例如：OTSiA OH、OMS_DCC和OCh OH等)则浮动映射到OSC帧中。这种浮动映射或者混合映射方式提供了一定的灵活性，可扩展性好，能够很好的适应未来大规模网络对OSC的需求。
下面将基于上面所述的本发明涉及OSC帧格式的共性方面，对本发明实施例进一步详细说明。
实施例1
本发明的一个实施例提供了一种光网络中开销处理的方法、装置和系统。针对一个业务，需要对OSC帧进行处理的节点(或网络设备)有三类。第一类是首节点，该类节点为该业务的起始节点，即客户业务从这个节点开始在网络中传输。第二类是末节点，该类节点为该业务的目的节点，即客户业务传输到这个节点终止。第三类是中间节点，该类节点的主要功能是对该业务进行转发，例如，可以为如图1所示的OLA和ROADM。需要说明的是，根据具体的功能不同，不同类型的设备需要对不同的开销进行处理/操作。
在一种可能的组网结构中，网络中仅包含第一类和第二类节点，即首节点和末节点。在这种组网下，不同的节点对OSC帧的处理流程描述如下。
如图14所示，首节点对一个OSC帧的处理流程描述如下：
在141部分，生成光监控信道(OSC)帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
需要说明的是，所述开销可以包括表3中列举的开销。例如，所述开销包括OTS OH、OMS OH和OTSiA OH。可选地，该开销还可以包括OCh OH和OTS_DCC等。每一个开销的含义参见表3，此处不做赘述。还需要说明的是，其中，OTSiA OH和OCh OH可能是一个或者多个。不同的开销被封装到不同的开销码块单元。例如，每一个开销由一个单独的开销码块单元承载。
所述生成OSC帧具体地包括如下步骤：
步骤1：将多种开销分别封装到多个开销码块单元中；
步骤2：映射所述多个开销码块单元到OSC帧的净荷区；
步骤3：生成OSC帧开销，并添加到OSC帧的开销区。
需要说明的是，上述前两个步骤可以按照任意顺序执行，本发明不做任何限定。
其中，所述OSC帧开销包括OSC帧开销码块和OSC帧对齐指示码块。所述OSC帧开销码块用于携带所述OSC帧的操作、管理和维护信息，所述OSC帧对齐指示码块用于标识所述OSC帧。一般地，OSC帧的速率和映射进来的开销码块单元的速率不一定匹配。可选地，在映射开销码块单元到OSC帧的净荷区的过程中，可能需要通过空闲码块进行速率适配。
需要说明的是，映射一个开销码块单元到OSC帧的方式有多种。例如：可以是浮动映射方式。又如：可以是浮动固定混合映射方式。也就是说，当多个开销码块单元映射到一个OSC帧中，可以全都采用浮动映射的方式，或者是两者固定和浮动映射混合的方式。关于不同的映射方式的介绍参看“总体概述”部分，此处不做赘述。
为了区分多个开销码块单元中每个开销码块单元所承载的开销类型，需要通过开销标识信息来识别。在一种可能的实现中，所述开销标识信息对应为前面描述的MAP字段，其在OSC帧的位置信息和其具体含义见“总体概述”部分相关的介绍，此处不做赘述。在另一种可能的实现中，所述开销标识信息对应为一个或者多个码块单元类型字段，该信息在OSC 帧的具体位置和其具体含义见“总体概述”部分相关的介绍，此处不做赘述。例如，为不同的开销分配不同的BU_TYPE值。如表3所示，当码块单元放置的是OTS OH，BU_TYPE设置为1。类似的，如果是OMS OH，则BU_TYPE设置为2。需要说明的是，这两者的区别在于，前者放置在OSC帧的开销区。通过解析该字段，既可知道OSC帧的净荷区里包含的开销码块单元的位置，又可知道其承载的开销类型信息。而后者放置在OSC帧的净荷区。具体地，该字段放置在一个开销码块单元里，表示了该开销码块单元承载的开销类型。此外，还可以通过位置信息来确定一个开销码块单元承载的开销类型。例如：在“总体概述”部分提到的将OTS OH放置在一个OSC帧的固定位置。
在142部分，首节点发送所述OSC帧。
具体地，首节点发送所述OSC帧给其他网络设备。例如，其下游邻居节点，又如：末节点。
需要说明的是，首节点在添加所述OSC帧开销都所述OSC帧的开销区之后(或者说发送OSC帧的步骤之前)，还可能需要为所述OSC帧添加前向纠错(FEC)信息。具体的操作方式参见“总体概述”部分描述的三种方式，此处不做赘述。
如图15所示，末节点对一个OSC帧的处理流程描述如下：
在151部分，末节点接收OSC帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；
具体地，末节点接收首节点发送的OSC帧。其中，末节点通过发现OSC帧对齐指示码块来实现识别一个OSC帧的起始位置，从而可以进行后续的解析操作。所述多种开销包括OTS OH、OMS OH和OTSiA OH。可选地，所述多个开销还包括：OCh OH，OMS DCC和OTS DCC的一个或多个。需要说明的是，末节点还可以从中间节点接收OSC帧。
所述开销标识信息的位置信息和其含义描述参见上述针对图14的步骤141的描述，此处不再赘述。需要说明的是，该信息能够让接收到OSC帧的节点快速识别出其需要解析的开销码块单元。
在152部分，末节点根据所述开销标识信息，从所述OSC帧中识别出所述多个开销码块单元中的每一个开销码块单元所承载的开销的开销类型；
具体地，所述多个开销码块单元至少包括OTS OH码块单元、OMS OH码块单元和OTSiA OH码块单元；可选地，还可以包括OCh OH码块单元、OTS_DCC码块单元和OMS_DCC码块单元的一个或者多个。可选地，该步骤还可以包括：删除空闲码块。此外，可选地，如果收到的OSC帧包含FEC信息，末节点还需要对收到的OSC帧进行FEC校验。
在一种可能的实现中，可以通过码块单元类型指示字段(例如：BU_TYPE)来区分不同的开销码块单元。如果一个BU_TYPE类型用来表示两种开销，那么需要进一步通过其他信息来识别具体包含的开销类型。例如,以图11所示的开销结构为例，如果BU_TYPE＝3用来表示OTSiA OH和OCh OH，那么就需要通过OTSiA_Type这个字段来区分具体指示的类型。此外，OTSiA OH一般包含多路，因此，还需要通过一个字段来区分当前识别的开销码块单元指示的是哪一路OTSiA OH。具体地，如图11和表7的解释，可以通过TPID来区分具体的OTSiA OH编号。在另一个可能的实现中，还可以通过浮动映射指示信息(例 如：图12中的MAP字段)来识别出不同的开销码块单元所包含的开销类型。在又一种可能的实现中，通过固定的位置来识别出不同的开销码块单元。例如：如果OTS OH和OMS OH分别固定为第1,2和第3,4个码块，那么节点接收到OSC帧后可以通过识别位置信息来识别出不同的开销码块单元。
在153部分，末节点根据所述每一个开销码块单元所承载的开销的开销类型，从所述每一个开销码块单元中提出开销。
具体地，从对应的开销码块单元中提取出对应的开销，例如：从OTS OH码块单元中提取出OTS OH。从OTSiA/OCh OH码块单元中提取出OTSiA OH或者OCh OH。从解析出的开销中包含的具体字段的取值，来进行OAM处理。例如，可以通过OTS OH开销中的PMI字段来判断是否接收到的业务数据存在丢失问题。更多的字段和其含义可参看“总体概述”部分中相关表格里的描述，此处不做赘述。
需要说明的是，末节点还需要提取出OSC帧开销信息，来完成对OSC帧的监控和管理。例如：提出OSC帧开销的对应字段来确定在传输过程中OSC帧是否存在误码等。
通过采用本发明实施例描述的开销处理方法，节点可以灵活地传递OTN的多种开销信息。该开销处理的方法灵活，提高了带宽利用率。此外，该方法采用灵活的映射方式，兼容性好，可扩展性高，能够适应未来大规模网络对OSC的需求。
实施例2
本发明的一个实施例提供又一种光网络中开销处理的方法、装置和系统。在又一种可能的组网结构中，除了首节点和末节点外，还可能包含能够处理部分开销的中间设备。例如：OLA。OLA网络设备属于传输段的网络设备，即该设备终结其与上一个节点的传输段并开始其与下一个节点的传输段，因此需要处理传输段相关的开销。
首节点和末节点的行为同实施例1所述，此处不再赘述。下面着重描述中间设备(例如：OLA)的行为。如图16所示，OLA对OSC帧的处理流程描述如下：
在161部分，中间节点接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载一种开销；所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元所承载的开销的开销类型；；
具体地，中间节点从其上游节点接收OSC帧。这个上游节点可以是首节点设备，或者中间节点设备。所述开销包括OTS OH、OMS OH和OTSiA OH。可选地，所述开销还包括：OCh OH，OMS DCC和OTS DCC的一个或多个。关于所述多个开销码块单元映射到所述第一OSC帧的方式和所述开销标识信息的具体描述参见图14中141部分的相关描述，此处不再赘述。
在162部分，根据所述开销标识信息，从所述第一OSC帧中识别出承载光传输段开销(OTS OH)的第一开销码块单元；从所述第一开销码块单元中提取所述OTS OH；
具体地，中间设备根据开销标识信息来确定需要解析的开销码块单元。在本实施例中，中间设备为传输段设备。因此，中间设备需要解析出收到的第一OSC帧里包含的传输段开销。具体如何确定一个开销码块单元承载的开销类型的方式见实施例1中针对图14的141部分的相关描述，此处不再赘述。确定了需要解析的开销码块单元后，中间设备按照预先 设定的格式对该开销码块单元进行解析。例如：按照“总体概述”部分描述的任意一种帧格式。
在163部分，中间节点生成第二OSC帧，所述第二OSC帧包括用于承载第二OTS OH的第二开销码块单元和所述第一OSC帧中承载其他开销的开销码块单元；
具体地，该步骤包括：
生成所述第二OTS OH并将其封装到第二开销码块单元。其中，该OTS OH用于下一个传输段进行OAM操作；
映射所述第二开销码块单元和所述第一OSC帧中承载其他开销的开销码块单元到所述第二OSC帧的净荷区；
生成OSC帧开销并添加到所述第二OSC帧的开销区。
需要说明的是，上述第一个和第二个步骤可以按照任意顺序执行，本发明不做任何限定。可选地，如果OSC帧包含FEC信息，末节点还需要对收到的OSC帧进行FEC校验。
具体地，所述承载其他开销的开销码块单元包括承载OMS OH和OTSiA OH的开销码块单元。还可以包括承载了OCh OH和OMS DCC等的开销码块单元。中间节点无需处理这些开销，因此可以从第一OSC帧中直接映射到第二OSC帧中去。需要说明的是，所谓直接映射指的是：中间节点无须对对开销码块单元进行进一步的解析，直接进行映射。这样提升了处理效率，中间节点对OSC帧处理引入的时延也相对于现有技术较低。
需要说明的是，163部分提及的映射步骤可以采用的方法跟图14中141部分描述的相同，此处不再赘述。
在164部分，中间节点发送所述第二OSC帧。
具体地，中间节点发送OSC帧给其下游节点，例如：末节点。
需要说明的是，在包含例如OLA的中间设备的OTN中，末节点是从其上游节点接收OSC帧，例如此实施例中的OLA节点。还需要说明的是，本实施例的中间节点还可能需要处理OTS_DCC，处理的方法类似上述针对OTS开销的处理方法，此处不再赘述。
还需要说明的是，中间节点要提取出OSC帧中包含的OSC帧开销码块，用于对OSC帧自身进行监控和管理。例如：确定OSC帧在传输过程中是否存在误码等。
通过采用本发明实施例描述的开销处理方法，灵活地来传递OTN的多种开销信息，使接收到所述OSC帧的节点仅需提取并处理其所需要的开销，而透传其他开销，加快了开销处理速度。此外，该OSC帧格式灵活，带宽利用率高，兼容性好，可扩展性好，能够适应未来大规模网络对OSC的需求。
实施例3
本发明的一个实施例提供了再一种光网络中开销处理的方法、装置和系统。在一种可能的组网结构中，除了首节点和末节点外，还可能包含处理部分开销的中间设备。例如：ROADM网络设备属于复用段的网络设备，即该设备终结其与上一个节点的传输段以及复用段并开始其与下一个节点的传输段和复用段，因此需要处理传输段和复用段相关的开销。需要说明的是，本实施例根实施例2的区别在于中间节点要处理的开销码块单元不同。
首节点和末节点的行为同实施例1所述，此处不再赘述。下面着重描述中间设备ROADM的行为。如图17所示，本实施例中的中间节点对OSC帧处理的流程跟实施例2 中描述的中间节点的处理流程类似，此处不再赘述。主要的的区别在于162部分和163部分，具体描述如下：
针对162部分：除了对OTS OH码块单元进行处理外，本实施例中的中间节点还需要对OMS OH进行类似的操作，即识别出承载光复用段开销的第二开销码块单元，并从中提取出所述光复用段开销；
针对163部分：除了生成第二OTS OH并封装到第三开销码块单元，本实施例中的中间节点还需要对OMS OH进行类似的操作，即生成新的OMS OH并封装到第四开销码块单元；需要说明的是，所述生成的新的OMS OH用于下一个复用段进行OAM操作。此外，本实施例中需要将上述提到的第三开销码块单元和第四开销码块单元，以及其他无需处理的开销码块单元映射到第二帧的净荷区。其中，本实施例中无需处理的开销指的是除了承载OTS OH和OMS OH的开销码块单元的其他开销码块单元，例如：OTSiA OH开销码块单元。
需要说明的是，在处理承载OTSiA OH/OCh OH的开销码块单元时，本实施例中的中间节点需要根据交叉配置信息来确定接收该开销应该映射到哪一个新的OSC帧的净荷区。其中，交叉配置信息可以是手工配置，也可以是网管端到端配置时自动下发，或者通过设备的控制平面重路由创建路径时自动配置。以图1为例，设备1有两个OTSiA OH，其中一个的末节点为设备2，而另外一个的末节点不是设备2。因此，当中间节点ROADM1收到了包含了OTSiA#i OH和OTSiA#j OH开销码块单元的OSC帧后，需要将这两个开销分别放置到不同的OSC帧去。例如：将承载了OTSiA#i OH的开销码块单元映射到发送给ROADM1和ROADM2之间的OA设备的OSC帧去。而将另一个OTSiA OH码块单元，即OTSiA#j OH开销码块单元，直接映射到发送给另外一个末节点的OSC帧中。
还需要说明的是，可选的，本实施例中提及的中间节点还需要处理OMS DCC相关的开销，即终结其收到的OMS_DCC并生成下一个复用段的OMS_DCC。
通过采用本发明实施例描述的OSC帧格式，灵活地来传递OTN的多种开销信息，使接收到所述OSC帧的节点仅需提取并处理其所需要的开销，而使得其他开销透传，加快了开销处理速度。此外，该OSC帧格式灵活，带宽利用率高，兼容性好，可扩展性好，能够适应未来大规模网络对OSC的需求。
需要说明的是，实施例1-3中提及的将开销码块单元映射到OSC帧的净荷区可以是浮动映射方式，或者是两者混合的方式。具体的映射方式参见“总体概述”部分的描述，此处不做赘述。
还需要说明的是，根据具体应用的需要，上述实施例1-3描述的网络设备(首节点、末节点、中间节点)使用OSC帧可以采用“总体概述”部分描述的多种OSC帧结构的一种。上述实施例1-3的流程描述没有赘述OSC帧结构，仅在需要时提及了相关的字段或信息。
实施例4
图18为一种可能网络设备结构示意图。具体地，该示意图给出了上述方法实施例中所涉及的首节点的一种可能的结构示意图。首节点包括发送单元181和处理单元182。其中：
所述处理单元，用于构造OSC帧。具体地，用于执行图14中的141部分中描述的动作；
所述发送单元，用于发送所述处理单元构造的OSC帧给其他网络设备(如：某一下游网络设备)，即用于执行图14的142部分中描述的动作。
在一种可能的实现中，所述处理单元182进一步包括第一处理单元1821、第二处理单元1822和第三处理单元1823。所述第一处理单元1821用于构造开销码块单元。所述第二处理单元1822用于构造OSC帧开销。所述第三处理单元1823用于映射第一和第二处理单元构造的对象至OSC帧。
在另一种可能的实现中，所述处理单元进一步包括第一处理单元、第二处理单元、第三处理单元和第四处理单元。其中，所述第一处理单元、第二处理单元和第三处理单元的功能根前一种实现方式相同，此处不做赘述。所述第四处理单元用于为OSC帧添加FEC信息，具体的操作方式参见本说明书前面的三个例子，此处不做赘述。
图19为又一种可能网络设备结构示意图，具体地，该示意图给出了上述方法实施例中所涉及的末节点的一种可能的结构示意图。末节点包括接收单元191和处理单元192。其中：
所述接收单元191，用于从其他网络设备(如：其上游邻居节点)接收OSC帧；
所述处理单元192，用于解析所述接收单元接收到的OSC帧。具体地，用于执行图15中的步骤152至153。
图20为另一种可能网络设备结构示意图。具体地，该示意图给出了上述方法实施例中所涉及的中间节点的一种可能的结构示意图。中间节点包括接收单元201、第一处理单元202、第二处理单元203和发送单元204。
在一种可能的实现中，所述接收单元201用于从其他网络设备(如：其上游邻居节点)接收OSC帧，具体地执行图16中步骤161的接收OSC帧的操作。所述第一处理单元202用于解析所述接收单元接收到的OSC帧，具体地包括执行图16所示的步骤162中的解析操作。所述第二处理单元用于构造一个新的OSC帧，具体地执行图16所示的步骤163。所述发送单元204用于发送所述第二处理单元构造的新的OSC帧，即执行图16中所示的步骤164。
在另一种可能的实现中，所述接收单元201用于从其他网络设备(如：其上游邻居节点)接收OSC帧，具体地执行图17中步骤171的接收OSC帧的操作。所述第一处理单元202用于解析所述接收单元接收到的OSC帧，具体地包括执行图17所示的步骤172中的解析操作。所述第二处理单元用于构造一个新的OSC帧，具体地执行图17所示的步骤173描述的动作。所述发送单元204用于发送所述第二处理单元构造的新的OSC帧，即执行图17中所示的步骤174。
需要说明的是，上述第一处理单元和第二处理单元可以合并为一个处理单元。此外，所述第二处理单元还可以划分为多个处理单元。例如：所述第二处理单元还可以划分为第三处理单元和第四处理单元，分别用于将多个开销封装到不同的开销码块单元中，和将所述多个开销码块单元映射到一个OSC帧。具体地，参看上述实施例2-3里提及的生成OSC帧的相关描述，此处不再赘述。还需要说明的是上述的处理单元，发送单元和接收单元也可以分别是处理器，发送器和接收器。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。具体地，例如：上述处理单元或处理器可以是中央处理器，通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。上述的这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (30)

  1. 一种光传送网中开销处理的方法，其特征在于，所述方法包括：
    生成光监控信道(OSC)帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中各个开销码块单元所承载的开销的开销类型，所述多种开销类型的开销包括光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)；
    发送所述OSC帧。
  2. 如权利要求1所述的方法，其特征在于，所述OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区，所述开销标识信息位于所述OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
  3. 如权利要求1所述的方法，其特征在于，所述开销标识信息位于所述多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中每个开销码块单元所承载的开销的开销类型。
  4. 如权利要求1至3任一所述的方法，其特征在于，所述生成OSC帧包括：
    封装所述OTS OH、OMS OH和OTSiA OH到所述多个开销码块单元中；
    映射所述多个开销码块单元到OSC帧的净荷区。
  5. 如权利要求4所述的方法，其特征在于，所述映射所述多个开销码块单元到OSC帧的净荷区包括：将所述多个开销码块单元中的部分开销码块单元映射到所述OSC帧的净荷区中预先设定的位置，将另一部分开销码块单元映射到所述OSC帧的净荷区中任意空闲位置；或者，将所述多个开销码块单元映射到所述OSC帧净荷区中任意空闲位置。
  6. 如权利要求1至5任一所述的方法，其特征在于，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
  7. 一种光网络中的网络设备，其特征在于，所述网络设备包括：
    处理单元，用于生成光监控信道(OSC)帧，所述OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中各个开销码块单元所承载的开销的开销类型，所述多种开销类型的开销包括光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)；
    发送单元，用于发送所述OSC帧。
  8. 如权利要求7所述的网络设备，其特征在于，所述OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述OSC帧的净荷区，所述开销标识信息位于所述OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
  9. 如权利要求7所述的网络设备，其特征在于，所述开销标识信息位于所述多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块 单元中每个开销码块单元所承载的开销的开销类型。
  10. 如权利要求7至9任一所述的网络设备，其特征在于，所述处理单元包括第一处理单元和第二处理单元，其中：所述第一处理单元，用于封装所述OTS OH、OMS OH和OTSiA OH到所述多个开销码块单元中；所述第二处理单元，用于映射所述多个开销码块单元到OSC帧的净荷区。
  11. 如权利要求10所述的网络设备，其特征在于，所述第二处理单元映射所述多个开销码块单元到OSC帧的净荷区包括：所述第二处理单元将所述多个开销码块单元中的部分开销码块单元映射到所述OSC帧的净荷区中预先设定的位置，将另一部分开销码块单元映射到所述OSC帧的净荷区中任意空闲位置；或者，所述第二处理单元将所述多个开销码块单元映射到所述OSC帧净荷区中任意空闲位置。
  12. 如权利要求8至11任一所述的网络设备，其特征在于，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
  13. 一种光传送网中开销处理的方法，其特征在于，所述方法包括：
    网络设备接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中各个开销码块单元所承载的开销的开销类型；所述多种开销类型的开销包括第一光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)，所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)；
    根据所述开销标识信息，从所述第一OSC帧中识别出承载所述第一OTS OH的第一开销码块单元；从所述第一开销码块单元中提取所述第一OTS OH；
    生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元，所述第二OTS OH用于实现所述网络设备和与所述网络设备相邻的下游网络设备之间的传输段的OAM；
    发送所述第二OSC帧。
  14. 如权利要求13所述的方法，其特征在于，所述第一OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述第一OSC帧的净荷区，所述开销标识信息位于所述第一OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述第一OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
  15. 如权利要求13所述的方法，其特征在于，所述开销标识信息位于所述第一OSC帧包括的多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中每个开销码块单元所承载的开销的开销类型。
  16. 如权利要求13至15任一所述的方法，其特征在于，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
  17. 如权利要求13至16任一所述的方法，其特征在于，所述生成第二OSC帧包括：
    生成所述第二OTS OH并封装到第二开销码块单元；
    映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。
  18. 如权利要求17所述的方法，其特征在于，所述映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元中的部分开销码块单元到所述第二OSC帧的净荷区中预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧净荷区中任意空闲位置。
  19. 一种光网络中的网络设备，其特征在于，所述网络设备包括：
    接收单元，用于接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中各个开销码块单元所承载的开销的开销类型；所述多种开销类型的开销包括第一光传输段开销(OTS OH)、光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)，所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)；
    处理单元，用于根据所述开销标识信息，从所述第一OSC帧中识别出承载所述第一OTS OH的第一开销码块单元；从所述第一开销码块单元中提取所述第一OTS OH；
    所述处理单元，还用于生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元，所述第二OTS OH用于实现所述网络设备和与所述网络设备相邻的下游网络设备之间的传输段的OAM；
    发送单元，用于发送所述第二OSC帧。
  20. 如权利要求19所述的网络设备，其特征在于，所述处理单元包括第一处理单元和第二处理单元，所述第一处理单元和第二处理单元用于生成所述第二OSC帧，其中：
    所述第一处理单元，用于生成所述第二OTS OH并封装到第二开销码块单元；
    所述第二处理单元，用于映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。
  21. 如权利要求20所述的网络设备，其特征在于，所述第二处理单元映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：所述第二处理单元映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元中的部分开销码块单元到所述第二OSC帧的净荷区中预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，所述第二处理单元映射所述第二开销码块单元和所述第一OSC帧中承载所述OMS OH和OTSiA OH的开销码块单元到所述第二OSC帧净荷区中任意空闲位置。
  22. 一种光传送网中开销处理的方法，其特征在于，所述方法包括：
    网络设备接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中的各个开销码块单元所承载的开销的开销类型；所述多种开销类型的开销包括第一光传输段开销(OTS OH)、第一光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)，所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)，所述第一OMS OH用于实现对位于所述网络设备上游的具备光复用功能的第一网络设备和所述网络设备之间的复用段的OAM，所述第一网络设备和所述网络设备之间没有其他具备复用段功能的网络设备；
    根据所述开销标识信息，从所述第一OSC帧中识别出承载所述第一OTS OH的第一开销码块单元和承载所述第一OMS OH的第二开销码块单元；从所述第一开销码块单元和所述第二开销码块单元中分别提取所述第一OTS OH和所述第一OMS OH；
    生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第三开销码块单元、承载第二OMS OH的第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元，所述第二OTS OH用于实现所述网络设备和与所述网络相邻的下游网络设备之间的传输段的OAM，所述第二OMS OH用于实现对所述网络设备和与所述网络设备下游的具备光复用段功能的第二网络设备之间的复用段的OAM，所述网络设备和所述第二网络设备之间没有其他具备光复用功能的网络设备；
    发送所述第二OSC帧。
  23. 如权利要求22所述的方法，其特征在于，所述第一OSC帧包括开销区和净荷区，所述多个开销码块单元位于所述第一OSC帧的净荷区，所述开销标识信息位于所述第一OSC帧的开销区，所述开销标识信息包含所述多个开销码块单元中至少一个开销码块单元在所述第一OSC帧的净荷区中的位置信息和所述至少一个开销码块单元所承载的开销的开销类型信息。
  24. 如权利要求22所述的方法，其特征在于，所述开销标识信息位于所述第一OSC帧包含的多个开销码块单元的至少一个开销码块单元中，所述开销标识信息用于指示所述至少一个开销码块单元中的每个开销码块单元所承载的开销的开销类型。
  25. 如权利要求22至24任一所述的方法，其特征在于，所述多个开销码块单元中每个开销码块单元包括至少2个66B数据码块。
  26. 如权利要求22至25任一所述的方法，其特征在于，所述生成第二OSC帧包括：
    生成所述第二OTS OH并封装到第三开销码块单元；
    生成所述第二OMS OH并封装到第四开销码块单元；
    映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。
  27. 如权利要求26所述的方法，其特征在于，所述映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：映射所述所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元的部分开销码块单元到所述第二OSC帧的净荷区中 预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区中任意空闲位置。
  28. 一种光网络中的网络设备，其特征在于，所述网络设备包括：
    接收单元，用于接收第一光监控通道(OSC)帧，所述第一OSC帧包括多个开销码块单元，所述多个开销码块单元中每个开销码块单元承载多种开销类型中一种开销类型的开销，所述第一OSC帧携带开销标识信息，所述开销标识信息用于标识所述多个开销码块单元中的各个开销码块单元所承载的开销的开销类型；所述多种开销类型的开销包括第一光传输段开销(OTS OH)、第一光复用段开销(OMS OH)和集成光支路信号开销(OTSiA OH)，所述第一OTS OH用于实现对与所述网络设备相邻的上游网络设备和所述网络设备之间的传输段的操作、管理和维护(OAM)，所述第一OMS OH用于实现对位于所述网络设备上游的具备光复用功能的第一网络设备和所述网络设备之间的复用段的OAM，所述第一网络设备和所述网络设备之间没有其他具备复用段功能的网络设备；
    处理单元，用于根据所述开销标识信息，从所述第一OSC帧中识别出承载所述第一OTS OH的第一开销码块单元和承载所述第一OMS OH的第二开销码块单元；从所述第一开销码块单元和所述第二开销码块单元中分别提取所述第一OTS OH和所述第一OMS OH；
    所述处理单元，还用于生成第二OSC帧，所述第二OSC帧包括承载第二OTS OH的第三开销码块单元、承载第二OMS OH的第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元，所述第二OTS OH用于实现所述网络设备和与所述网络设备相邻的下游网络设备之间的传输段的OAM，所述第二OMS OH用于实现对所述网络设备和与所述网络设备下游的具备光复用段功能的第二网络设备之间的复用段的OAM，所述网络设备和所述第二网络设备之间没有其他具备光复用功能的网络设备；
    发送单元，用于发送所述第二OSC帧。
  29. 如权利要求28所述的网络设备，其特征在于，所述处理单元包括第一处理单元和第二处理单元，其中：
    所述第一处理单元，用于生成所述第二OTS OH并封装到第三开销码块单元，还用于生成所述第二OMS OH并封装到第四开销码块单元；
    所述第二处理单元，用于映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区。
  30. 如权利要求29所述的网络设备，其特征在于，所述第二处理单元映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区包括：所述第二处理单元映射所述所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元的部分开销码块单元到所述第二OSC帧的净荷区中预先设定的位置，另一部分开销码块单元映射到所述第二OSC帧的净荷区中任意空闲位置；或者，所述第二处理单元映射所述第三开销码块单元、第四开销码块单元和所述第一OSC帧中承载所述OTSiA OH的开销码块单元到所述第二OSC帧的净荷区中任意空闲位置。
PCT/CN2018/080303 2017-07-14 2018-03-23 一种光网络中光监控信道处理的方法和装置 WO2019011003A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
ES18832094T ES2928313T3 (es) 2017-07-14 2018-03-23 Método y dispositivo para procesar el canal de supervisión óptica en una red óptica
EP18832094.9A EP3641160B1 (en) 2017-07-14 2018-03-23 Method and device for processing optical supervisory channel in optical network
US16/741,121 US10826636B2 (en) 2017-07-14 2020-01-13 Optical supervisory channel processing method and apparatus in optical network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710577112.7A CN109257093B (zh) 2017-07-14 2017-07-14 一种光网络中光监控信道处理的方法和装置
CN201710577112.7 2017-07-14

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/741,121 Continuation US10826636B2 (en) 2017-07-14 2020-01-13 Optical supervisory channel processing method and apparatus in optical network

Publications (1)

Publication Number Publication Date
WO2019011003A1 true WO2019011003A1 (zh) 2019-01-17

Family

ID=65001085

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/080303 WO2019011003A1 (zh) 2017-07-14 2018-03-23 一种光网络中光监控信道处理的方法和装置

Country Status (5)

Country Link
US (1) US10826636B2 (zh)
EP (1) EP3641160B1 (zh)
CN (1) CN109257093B (zh)
ES (1) ES2928313T3 (zh)
WO (1) WO2019011003A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11552722B2 (en) * 2020-12-10 2023-01-10 Ciena Corporation Precision time protocol using a coherent optical DSP frame

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101227450A (zh) * 2007-01-16 2008-07-23 华为技术有限公司 一种开销信息的传输方法、系统及设备
WO2010121512A1 (zh) * 2009-04-21 2010-10-28 华为技术有限公司 一种数据通讯方法及数据通讯系统以及相关设备
CN101959083A (zh) * 2009-07-21 2011-01-26 华为技术有限公司 数据处理方法和数据处理设备
CN103825751A (zh) * 2012-11-16 2014-05-28 华为技术有限公司 开通业务的方法、单板、网管设备和系统

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100582093B1 (ko) * 2003-09-02 2006-05-22 한국전자통신연구원 광 전달망 시스템에서의 광 감시 채널 프레이밍 장치 및그 방법
CN100479352C (zh) * 2006-02-21 2009-04-15 华为技术有限公司 光随路信号加载、监控的方法及装置
CN101369848B (zh) * 2008-10-17 2011-02-09 烽火通信科技股份有限公司 监控光传送网复用段与光通道信号质量的方法
ES2700233T3 (es) * 2013-04-10 2019-02-14 Huawei Tech Co Ltd Método para ajustar velocidad de interfaz de línea, y nodo
CN107710699B (zh) * 2016-04-08 2020-07-21 华为技术有限公司 一种故障检测的方法和设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101227450A (zh) * 2007-01-16 2008-07-23 华为技术有限公司 一种开销信息的传输方法、系统及设备
WO2010121512A1 (zh) * 2009-04-21 2010-10-28 华为技术有限公司 一种数据通讯方法及数据通讯系统以及相关设备
CN101959083A (zh) * 2009-07-21 2011-01-26 华为技术有限公司 数据处理方法和数据处理设备
CN103825751A (zh) * 2012-11-16 2014-05-28 华为技术有限公司 开通业务的方法、单板、网管设备和系统

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
EP3641160B1 (en) 2022-09-07
US20200153529A1 (en) 2020-05-14
CN109257093A (zh) 2019-01-22
CN109257093B (zh) 2021-09-14
ES2928313T3 (es) 2022-11-17
EP3641160A1 (en) 2020-04-22
US10826636B2 (en) 2020-11-03
EP3641160A4 (en) 2020-07-15

Similar Documents

Publication Publication Date Title
US11082199B2 (en) Data transmission method in optical network and optical network device
EP4027650A1 (en) Method and device for service processing in optical transport network, and system
EP4099712A1 (en) Service bearing method, apparatus and system
US10090960B2 (en) Method, apparatus and system for processing flexible-rate signal
US11245491B2 (en) Method and apparatus for transmitting optical transport unit signal
WO2017201757A1 (zh) 一种业务传送方法和第一传送设备
WO2019128665A1 (zh) 一种数据传输方法、通信设备及存储介质
US20230164624A1 (en) Service data processing, exchange and extraction methods, devices, and computer-readable medium
US11223422B2 (en) Method and apparatus for processing ethernet data in optical network, and system
WO2020253628A1 (zh) 一种数据处理方法、光传输设备及数字处理芯片
WO2019011003A1 (zh) 一种光网络中光监控信道处理的方法和装置
EP2884687B1 (en) Method and device for data mapping in optical transport network
CN116264587A (zh) 一种数据传输的方法以及相关装置
WO2020063300A1 (zh) 一种数据传输方法、通信设备及存储介质
CN113472826A (zh) 一种业务承载、提取方法、数据交换方法及设备
WO2019061406A1 (zh) 一种业务数据发送方法及装置
WO2024001220A1 (zh) 切片方法、业务处理方法、通信节点及存储介质
WO2024051586A1 (zh) 一种光传送网中的数据帧的处理方法、装置和系统
WO2023232097A1 (zh) 业务数据处理方法和装置

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: 18832094

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: 2018832094

Country of ref document: EP

Effective date: 20200116