US9270367B2 - Method and system for automatically discovering ODUflex bandwith lossless adjustment capability - Google Patents
Method and system for automatically discovering ODUflex bandwith lossless adjustment capability Download PDFInfo
- Publication number
- US9270367B2 US9270367B2 US13/976,421 US201113976421A US9270367B2 US 9270367 B2 US9270367 B2 US 9270367B2 US 201113976421 A US201113976421 A US 201113976421A US 9270367 B2 US9270367 B2 US 9270367B2
- Authority
- US
- United States
- Prior art keywords
- link
- end interface
- message
- interface
- opposite end
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related, expires
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 230000003287 optical effect Effects 0.000 claims abstract description 11
- 238000013507 mapping Methods 0.000 claims description 55
- 230000001960 triggered effect Effects 0.000 claims description 3
- 230000008569 process Effects 0.000 description 17
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 5
- 238000012795 verification Methods 0.000 description 5
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000009432 framing Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
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/079—Arrangements for monitoring or testing transmission systems; Arrangements for fault measurement of transmission systems using an in-service signal using measurements of the data signal
- H04B10/0793—Network aspects, e.g. central monitoring of transmission parameters
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- 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
- H04J14/0254—Optical medium access
- H04J14/0256—Optical medium access at the optical channel layer
- H04J14/0258—Wavelength identification or labelling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/19—Flow control; Congestion control at layers above the network layer
Definitions
- the present document relates to the field of communication, and especially, to a method and system for automatically discovering an ODUflex bandwidth hitless resizing capability.
- ODUflex Optical Data Unit
- ODU4 ODU2e
- flexible rate ODU ODUflex
- the ODUflex is used to transparently bit-transmit client signals at any rates through Optical Transport Network (OTN) and use a Generic Mapping Procedure (GMP) to map the ODUflex into a High Order ODU (HO ODU).
- GMP Generic Mapping Procedure
- HO ODU High Order ODU
- the ODUflex can be adaptive to client signals at any rates, and then a Low Order ODU (LO ODU) is mapped into a corresponding number of tributary timeslots of the HO ODU.
- LO ODU Low Order ODU
- the ODUflex is divided into two kinds, one is used for bearing ODUflex(CBR) of Constant Bit Rate (CBR) client signals, and the CBR client signals are mapped into the ODUflex(CBR) through the GMP; and the other one is used for bearing ODUflex(GFP) of packet client signals, and the packet client signals are encapsulated into the ODUflex(GFP) through a Generic Framing Procedure (GFP).
- CBR Constant Bit Rate
- GMP Generic Framing Procedure
- the ODUflex(GFP) since the bandwidth of the packet client signals will be changed over time, allocating fixed bandwidths to the ODUflex(GFP) will not be beneficial to the effective utilization of bandwidth resources. If the ODUflex(GFP) can support a dynamic bandwidth adjustment, not only various bandwidth requirements of the packet client signals can be better satisfied, but also the bandwidth utilization ratio can be effectively improved and the bandwidth resources can be saved. Therefore, the ODUflex(GFP) is required to have a bandwidth hitless resizing capability.
- the ODUflex(GFP) bandwidth hitless resizing means that the ODUflex(GFP) is required to complete the bandwidth resizing in the case of dynamic and no interruption of the existing services.
- the technical problem required to be solved by the present document is to provide a method and system for automatically discovering an ODUflex bandwidth hitless resizing capability, to automatically discover the ODUflex bandwidth hitless resizing capability.
- the present document provides a method for automatically discovering a flexible rate Optical Data Unit (ODUflex) bandwidth hitless resizing capability, which comprises:
- a source end interface of a link sending link summary message to an opposite end interface of the link, wherein the link summary message carries information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability;
- the opposite end interface of the link feeding back message to the source end interface of the link according to said information or according to said information and whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability, and the source end interface of the link determining whether the link supports the ODUflex bandwidth hitless resizing capability according to the message fed back by the opposite end interface of the link.
- the above method can further be characterized in that: the link summary message carrying the information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability is implemented by the following way: a data link object of the link summary message including a subobject, and the subobject including a field which represents whether the source end interface supports the ODUflex bandwidth hitless resizing capability.
- the step of, after receiving the link summary message, the opposite end interface of the link feeding back message to the source end interface of the link according to said information or according to said information and whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability comprises:
- the link summary not-acknowledgment message includes an object used for describing error causes.
- the above method can further be characterized in that: the object used for describing the error causes includes information used for indicating that the error causes are unacceptable non-negotiable link summary parameters.
- the above method can further be characterized in that: the opposite end interface of the link reading the field in the subobject is performed in a condition that a local interface mapping relationship or a remote end interface mapping relationship carried in the link summary message is matched with an interface mapping relationship stored in the opposite end.
- the above method can further be characterized in that: the ODUflex bandwidth hitless resizing capability is defined through a G.hao protocol.
- the above method can further be characterized in that: the step of a source end interface of the link sending link summary message to an opposite end interface of the link is specifically: the source end interface of the link periodically sending the link summary message to the opposite end interface of the link through a link management protocol.
- the present document further provides a system for automatically discovering a flexible rate Optical Data Unit (ODUflex) bandwidth hitless resizing capability, which comprises:
- a node in which a source end interface of a link is located configured to send link summary message to a node in which an opposite end interface of the link is located, wherein the link summary message carries information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability; and configured to determine whether the link supports the ODUflex bandwidth hitless resizing capability according to message fed back by the node in which the opposite end interface of the link is located;
- the node in which the opposite end interface of the link is located configured to: after receiving the link summary message, feed back message to the node in which the source end interface of the link is located according to said information or according to said information and whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability.
- the above system can further be characterized in that: the link summary message carrying the information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability is implemented by the following way: a data link object of the link summary message including a subobject, and the subobject including a field which represents whether the source end interface supports the ODUflex bandwidth hitless resizing capability.
- the node in which the opposite end interface of the link is located comprises:
- a reading module configured to: after receiving the link summary message, read the field in the subobject;
- a first judgment module configured to: judge whether the field represents that the source end interface supports the ODUflex bandwidth hitless resizing capability
- a second judgment module configured to: if the first judgment module judges that the field represents that the source end interface supports the ODUflex bandwidth hitless resizing capability, judge whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability;
- a first sending module configured to: if the first judgment module judges that the field represents that the source end interface does not support the ODUflex bandwidth hitless resizing capability or the second judgment module judges that the opposite end interface of the link does not support the ODUflex bandwidth hitless resizing capability, feed back link summary not-acknowledgment message to the node in which the source end interface of the link is located; and
- a second sending module configured to: if the second judgment module judges that the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability, feed back link summary acknowledgment message to the node in which the source end interface of the link is located;
- the link summary not-acknowledgment message includes an object used for describing error causes
- the object used for describing the error causes includes information used for indicating that the error causes are unacceptable non-negotiable link summary parameters.
- the reading module comprises:
- a matching unit configured to: after receiving the link summary message, perform matching between a local interface mapping relationship or a remote end interface mapping relationship carried in the link summary message and an interface mapping relationship stored in the opposite end, and if the matching is consistent, trigger a reading unit;
- the reading unit configured to: after being triggered, read the field in the subobject.
- the above system can further be characterized in that: the ODUflex bandwidth hitless resizing capability is defined through a G.hao protocol.
- a method and system for automatically discovering an ODUflex bandwidth hitless resizing capability are provided in the present document, and by extending a DATA_LINK object in the Link Management Protocol (LMP), the LMP is enabled to automatically discover an attribute of whether the link supports the ODUflex bandwidth hitless resizing (i.e. the G.hao protocol).
- LMP Link Management Protocol
- shortages of the control plane are remedied and functions of the control plane are enhanced.
- FIG. 1 is a schematic diagram of a system for automatically discovering the ODUflex bandwidth hitless resizing capability according to the example of the present document.
- FIG. 2 is a flow diagram of automatically discovering the ODUflex bandwidth hitless resizing capability according to the embodiment of the present document.
- FIG. 3 is a schematic diagram of a format of a Hitless Resize subobject according to the example of the present document.
- FIG. 4 is a process of automatically discovering that the link supports a G.hao protocol in the example 1 of the present document.
- FIG. 5 is a process of automatically discovering that the link does not support a G.hao protocol in the example 2 of the present document.
- FIG. 6 is a process of automatically discovering that the link does not support a G.hao protocol in the example 3 of the present document.
- the ITU-T has raised a suggestion with regard to the ODUflex bandwidth hitless resizing, i.e. the G.hao protocol, and in the G.hao protocol, the ODUflex bandwidth hitless resizing is divided into two stages, namely Link Connection Resizing (LCR) and Bandwidth Resizing (BWR), so as to perform hitless resizing on an ODUflex.
- LCR Link Connection Resizing
- BWR Bandwidth Resizing
- LMP Link Management Protocol
- IETF Internet Engineering Task Force
- Control channel management the control channel management is with respect to negotiation and maintenance of an LMP session itself, and it is used for establishing a control channel between adjacent physical nodes on a control plane after discovered by the neighbor, so as to perform parameter negotiation and transmission of signaling message.
- Link summary association the main object of the link summary association is to discover and negotiate a Traffic Engineering (TE) link IP mapping relationship and a data link summary between adjacent nodes, it can be implemented by interacting link aggregation message and replying message.
- the link aggregation message will normally contain: a TE link ID required to be announced, all links contained by the TE link and the related link summaries.
- Link connectivity verification has two main objects, one is to verify the connectivity of specific data links, and the other is to automatically map a local interface ID and a remote end interface ID of data links and TE links.
- the link connectivity verification is an optical function in the LMP and is decided by a negotiable Verification Flag configured in the parameter negotiation process;
- Fault management a whole set of fault location mechanism is raised in the LMP to determine a specific link which has a fault. This process is initiated by a node which has a data link fault detected in the downstream, and through an interaction between channel fault message and recovery message, link statuses are detected hop-by-hop toward upstream along the LSP until the link which has the fault is located.
- the link fault management is also an optical function and is decided by a negotiable Fault Management Flag configured in the parameter negotiation process.
- a link summary association function of the LMP three pieces of message such as LinkSummary message, LinkSummaryAck message and LinkSummaryNack message are defined, objects of the three pieces of message are link summaries which are divided into a negotiable summary and a non-negotiable summary.
- a DATA_LINK object is carried to represent a summary of the link at one end.
- the following two subobjects such as an Interface Switching Type subobject and a Wavelength subobject are defined for the link summary, and by carrying these two subobjects, the support to the two attributes of interface switching type and wavelength of the link is implemented in an auto-discovery program.
- the defined subobjects do not support an auto-discovery function of an attribute of whether the link supports the G.hao protocol.
- a method for automatically discovering an ODUflex bandwidth hitless resizing capability is provided in the embodiment of the present document, information of whether a source end interface of a link supports the ODUflex bandwidth hitless resizing capability is carried in link summary message sent by the source end interface of the link to an opposite end interface of the link, and then it is to discover whether the link supports the ODUflex bandwidth hitless resizing capability according to message fed back by the opposite end interface of the link.
- FIG. 1 is a schematic diagram of a system for automatically discovering the ODUflex bandwidth hitless resizing capability according to the example of the present document, and as shown in FIG. 1 , a node in which a source end interface of a link is located and a node in which an opposite end interface of the link is located are included, wherein,
- the node in which the source end interface of the link is located is used to send link summary message to the node in which the opposite end interface of the link is located, wherein the link summary message carries information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability; and it is used to determine whether the link supports the ODUflex bandwidth hitless resizing capability according to message fed back by the node in which the opposite end interface of the link is located;
- the node in which the opposite end interface of the link is located is used to: after receiving the link summary message, feed back the message to the node in which the source end interface of the link is located according to the information or according to the information and whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability.
- the link summary message carrying the information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability is implemented by the following way: a data link object of the link summary message including a subobject (i.e. a Hitless Resize subobject), and the subobject including a field which represents whether the source end interface supports the ODUflex bandwidth hitless resizing capability.
- a data link object of the link summary message including a subobject (i.e. a Hitless Resize subobject)
- the subobject including a field which represents whether the source end interface supports the ODUflex bandwidth hitless resizing capability.
- the node in which the opposite end interface of the link is located in the example can include:
- a reading module configured to: after receiving the link summary message, read the field in the subobject;
- a first judgment module configured to: judge whether the field represents that the source end interface supports the ODUflex bandwidth hitless resizing capability
- a second judgment module configured to: if the first judgment module judges that the field represents that the source end interface supports the ODUflex bandwidth hitless resizing capability, judge whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability;
- a first sending module configured to: if the first judgment module judges that the field represents that the source end interface does not support the ODUflex bandwidth hitless resizing capability or the second judgment module judges that the opposite end interface of the link does not support the ODUflex bandwidth hitless resizing capability, feed back link summary not-acknowledgment message to the node in which the source end interface of the link is located; and
- a second sending module configured to: if the second judgment module judges that the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability, feed back link summary acknowledgment message to the node in which the source end interface of the link is located;
- the link summary not-acknowledgment message includes an object used for describing error causes
- the object used for describing the error causes includes information used for indicating that the error causes are unacceptable non-negotiable link summary parameters.
- the reading module can include a matching unit and a reading unit
- the matching unit is configured to: after receiving the link summary message, perform matching between a local interface mapping relationship or a remote end interface mapping relationship carried in the link summary message and an interface mapping relationship stored in said link opposite end, and if the matching is consistent, trigger the reading unit;
- the reading unit is configured to: after being triggered, read the field in the subobject.
- the ODUflex bandwidth hitless resizing capability in the example is defined through a G.hao protocol. Certainly, the ODUflex bandwidth hitless resizing capability also can be defined through other protocols in other examples.
- FIG. 2 is a flow diagram of automatically discovering the ODUflex bandwidth hitless resizing capability according to the present document, and as shown in FIG. 2 , the following steps are included.
- a source end interface of a link sends link summary message to an opposite end interface of the link, wherein the link summary message carries information of whether the source end interface of the link supports the ODUflex bandwidth hitless resizing capability.
- step S 20 after receiving the link summary message, the opposite end interface of the link feeds back message to the source end interface of the link according to the information or according to the information and whether the opposite end interface of the link supports the ODUflex bandwidth hitless resizing capability, and the source end interface of the link determines whether the link supports the ODUflex bandwidth hitless resizing capability according to the message fed back by the opposite end interface of the link.
- a performance that the link supports the ODUflex bandwidth hitless resizing capability can be discovered automatically in an Optical Transport Network (OTN) by extending the LMP.
- OTN Optical Transport Network
- a Hitless Resize subobject can be added in the object to carry an attribute of whether the interface at the current end of the link supports the bandwidth hitless resizing capability (i.e. the G.hao protocol).
- the interface at one end of the link enables the opposite end interface to obtain an attribute of whether the interface at the current end supports the G.hao protocol through a link summary association program in the LMP extended in the present document, and then the opposite end interface compares whether the interfaces at both ends of the link both support the G.hao protocol, then obtains a conclusion to send the source end interface through messaging, and the conclusion of whether the link supports the G.hao protocol can be obtained.
- the link summary association program is operated at both ends of the link to discover whether the opposite end interface supports the G.hao protocol, and when the interfaces at both ends of the link support the G.hao protocol and flooding is performed in the routing protocol, it can further point out that the entire link supports the G.hao protocol.
- the LMP is extended, a Hitless Resize subobject is added in the existing DATA_LINK object to carry the attribute of whether the interface at the current end of the link supports the ODUflex bandwidth hitless resizing capability (i.e. the G.hao protocol), and the extended DATA_LINK object is carried through LinkSummary message in the link summary association program so as to make the interfaces at both ends of the link perform negotiation and association on the attribute of ODUflex bandwidth hitless resizing capability, such that the LMP automatically discovers the performance of ODUflex bandwidth hitless resizing capability of the link.
- ODUflex bandwidth hitless resizing capability i.e. the G.hao protocol
- Common Header is a generic message header of LMP message
- TE_LINK is used for identifying a TE link between the two interfaces of the link
- DATA_LINK is used for identifying a data link between the two interfaces.
- ERROR_CODE is used for describing error causes.
- the encoding formats of specific definitions of these four objects may refer to the RFC4204.
- FIG. 3 illustrates a format of the Hitless Resize subobject newly defined in the DATA_LINK object after extending the LMP, and as shown in FIG. 3 , wherein:
- a Type field whose length is of 8 bits, represents a type of the subobject, and a value of the Type field is 3;
- a Length field whose length is of 8 bits, represents a total length of the subobject, and a byte (8 bits) is taken as a unit.
- the total length of the subobject includes the length occupied by the Type field and the length occupied by the Length field.
- a value of the Length is at least 4 (bytes) and it must be an integral multiple of 4 (bytes);
- N field whose length is of 1 bit, represents the performance that whether the interface supports the G.hao protocol.
- 2 values are further defined for the field:
- a method for automatically discovering whether the link supports the G.hao protocol includes:
- a source end interface of the link periodically sending LinkSummary message to an opposite end interface of the link, and informing the opposite end interface of the link of whether the source end interface of the link supports the G.hao protocol;
- the opposite end interface of the link after receiving the LinkSummary message, the opposite end interface of the link firstly determining whether a local interface mapping relationship and/or a remote end interface mapping relationship is matched with an interface mapping relationship stored in the current end, and then determining whether the interfaces at both ends of the link support the G.hao protocol.
- the specific content is as follows:
- the opposite end interface sends LinkSummaryAck message to the source end interface, which represents that the interfaces at both ends of the link support the G.hao protocol. That the entire link supports the G.hao protocol is discovered through an auto-discovery process.
- the opposite end interface sends LinkSummaryNack message to the source end interface, according to the definition in the RFC4204, C-Type in the RROR_CODE object contained in the message is equal to 2, which represents that the error code indicates an error of the LinkSummary message (LINK_SUMMARY_ERROR), a value of Value is 0x01, and if it is further pointed out that error causes are Unacceptable non-negotiable LINK_SUMMARY parameters, not all the interfaces at both ends of the link support the G.hao protocol. That the entire link does not support the G.hao protocol is discovered through an auto-discovery process.
- the LinkSummaryNack message is sent to the source end interface, according to the definition in the RFC4204, C-Type in the RROR_CODE object contained in the message is equal to 2, which represents that the error code indicates an error of the LinkSummary message (LINK_SUMMARY_ERROR), a value of Value is 0x01, and if it is further pointed out that error causes are Unacceptable non-negotiable LINK_SUMMARY parameters, not all the interfaces at both ends of the link support the G.hao protocol. That the entire link does not support the G.hao protocol is discovered through an auto-discovery process.
- the attribute of whether the interfaces at both ends of the link support the bandwidth hitless resizing capability (i.e. the G.hao protocol) can be obtained through the above LMP program, that is, the attribute of whether the entire link supports the bandwidth hitless resizing capability (i.e. the G.hao protocol) is discovered through the auto-discovery process.
- the DATA_LINK object contained in the LinkSummary message carries the Hitless Resize subobject defined by the present document, so as to carry the attribute of whether the interface at the current end of the link supports the bandwidth hitless resizing capability (i.e. the G.hao protocol);
- Both a source end (A) interface and an opposite end (B) interface support a G.hao protocol, that is, interfaces at both ends of a link support the G.hao protocol, thus a link between the two interfaces supports the G.hao protocol.
- a process of automatically discovering an attribute of whether the link supports the G.hao protocol according to the example includes the following steps as shown in FIG. 4 .
- step 101 after the link starts, the A interface sends LinkSummary message to the B interface, the LinkSummary message contains a DATA_LINK object, and the DATA_LINK object carries a Hitless Resize subobject newly defined by the example, wherein a value of N is 1, which represents that the A interface supports the G.hao protocol.
- step 102 after receiving the LinkSummary message, the B interface firstly determines whether a local interface mapping relationship and/or a remote end interface mapping relationship carried in the message is matched with an interface mapping relationship stored in the B interface, if matched, step 103 is executed, and if mismatched, step 104 is executed.
- the B interface reads that the value of N in the newly defined Hitless Resize subobject in the LinkSummary message is 1, which represents that the A interface supports the G.hao protocol. Since the B interface also supports the G.hao protocol, which represents that the interfaces at both ends of the link respectively support the G.hao protocol, the B interface sends LinkSummaryAck message to the A interface, which represents that the interfaces at both ends of the link reach an agreement on the attribute of whether supporting the G.hao protocol, that is, the entire link supports the G.hao protocol.
- step 104 after receiving the LinkSummary message, if discovering that the local interface mapping relationship and/or the remote end interface mapping relationship carried in the message is mismatched with the interface mapping relationship stored in the B interface, the B interface sends LinkSummaryNack message to the A interface which points outs that the interface mapping relationships are mismatched.
- a source end (A) interface supports a G.hao protocol and an opposite end (B) interface does not support the G.hao protocol, and not all interfaces at both ends of a link support the G.hao protocol, thus a link between the two interfaces does not support the G.hao protocol.
- a process of automatically discovering an attribute that the link does not support the G.hao protocol includes the following steps as shown in FIG. 5 .
- step 201 the A interface sends LinkSummary message to the B interface, the LinkSummary message contains a DATA_LINK object, and the DATA_LINK object carries a Hitless Resize subobject newly defined by the example, wherein a value of N is 1, which represents that the A interface supports the G.hao protocol.
- step 202 after receiving the LinkSummary message, the B interface firstly determines whether a local interface mapping relationship and/or a remote end interface mapping relationship carried in the message is matched with an interface mapping relationship stored in the B interface, if matched, step 203 is executed, and if mismatched, step 204 is executed.
- step 203 the B interface reads that the value of N in the Hitless Resize subobject newly defined by the example is 1, which represents that the A interface supports the G.hao protocol. Since the B interface does not support the G.hao protocol, which represents that not all the interfaces at both ends of the link support the G.hao protocol, the link does not support the G.hao protocol, and thus the B interface sends LinkSummaryNack message to the A interface.
- C-Type in an ERROR_CODE object carried in the LinkSummaryNack message is equal to 2, which represents that the error code indicates an error of the LinkSummary message (LINK_SUMMARY_ERROR), a value of Value is 0x01, and if it is further pointed out that error causes are Unacceptable non-negotiable LINK_SUMMARY parameters, not all the interfaces at both ends of the link support the G.hao protocol. That the entire link does not support the G.hao protocol is discovered through an auto-discovery process.
- step 204 after receiving the LinkSummary message, if discovering that the local interface mapping relationship and/or the remote end interface mapping relationship carried in the message is mismatched with the interface mapping relationship stored in the B interface, the B interface sends the LinkSummaryNack message to the A interface and points outs that the interface mapping relationships are mismatched.
- a source end (A) interface does not support a G.hao protocol, no matter whether an opposite end (B) interface supports the G.hao protocol or not, not all the interfaces at both ends of the link support the G.hao protocol, thus a link between the two interfaces does not support the G.hao protocol.
- a process of automatically discovering an attribute that the link does not support the G.hao protocol includes the following steps as shown in FIG. 6 .
- step 301 the A interface sends LinkSummary message to the B interface, the LinkSummary message contains a DATA_LINK object, and the DATA_LINK object carries a Hitless Resize subobject newly defined by the example, wherein a value of N is 0, which represents that the A interface does not support the G.hao protocol.
- step 302 after receiving the LinkSummary message, the B interface firstly determines whether a local interface mapping relationship and/or a remote end interface mapping relationship carried in the message is matched with an interface mapping relationship stored in the B interface, if matched, step 303 is executed, and if mismatched, step 304 is executed.
- step 303 the B interface reads that the value of N in the Hitless Resize subobject newly defined by the example is 0, which represents that the A interface does not support the G.hao protocol, since not all the interfaces at both ends of the link support the G.hao protocol, the link does not support the G.hao protocol, and thus the B interface sends LinkSummaryNack message to the A interface.
- C-Type in an ERROR_CODE object carried in the LinkSummaryNack message is equal to 2, which represents that the error code indicates an error of the LinkSummary message (LINK_SUMMARY_ERROR), a value of Value is 0x01, and if it is further pointed out that error causes are Unacceptable non-negotiable LINK_SUMMARY parameters, not all the interfaces at both ends of the link support the G.hao protocol. That the entire link does not support the G.hao protocol is discovered through an auto-discovery process.
- step 304 after receiving the LinkSummary message, if discovering that the local interface mapping relationship and/or the remote end interface mapping relationship carried in the message is mismatched with the interface mapping relationship stored in the B interface, the B interface sends the LinkSummaryNack message to the A interface and points outs that the interface mapping relationships are mismatched.
- the basic LMP program is not changed in the implementation, and it is exclusively used for identifying the attribute of whether the link supports the G.hao protocol by defining the Hitless Resize subobject.
- a method and system for automatically discovering an ODUflex bandwidth hitless resizing capability are provided in the present document, and by extending a DATA_LINK object in the LMP, the LMP is enabled to automatically discover an attribute of whether the link supports the ODUflex bandwidth hitless resizing (i.e. the G.hao protocol).
- the LMP is enabled to automatically discover an attribute of whether the link supports the ODUflex bandwidth hitless resizing (i.e. the G.hao protocol).
- shortages of the control plane are remedied, and functions of the control plane are enhanced.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- Electromagnetism (AREA)
- Communication Control (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
<LinkSummary Message> ::= <Common Header> |
<MESSAGE_ID> | |
<TE_LINK> | |
<DATA_LINK> | |
[<DATA_LINK>...] |
<LinkSummaryNack Message> ::= <Common Header> |
<MESSAGE_ID_ACK> | |
<ERROR_CODE> | |
[<DATA_LINK>...] | |
Claims (8)
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010607730.X | 2010-12-27 | ||
CN201010607730XA CN102546374A (en) | 2010-12-27 | 2010-12-27 | Method and system for automatically discovering ODU (Optical Digital Unit) flex bandwidth lossless regulation capability |
CN201010607730 | 2010-12-27 | ||
PCT/CN2011/081918 WO2012088962A1 (en) | 2010-12-27 | 2011-11-08 | Method and system for automatically discovering oduflex bandwidth lossless adjustment capability |
Publications (2)
Publication Number | Publication Date |
---|---|
US20130279904A1 US20130279904A1 (en) | 2013-10-24 |
US9270367B2 true US9270367B2 (en) | 2016-02-23 |
Family
ID=46352366
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/976,421 Expired - Fee Related US9270367B2 (en) | 2010-12-27 | 2011-11-08 | Method and system for automatically discovering ODUflex bandwith lossless adjustment capability |
Country Status (5)
Country | Link |
---|---|
US (1) | US9270367B2 (en) |
EP (1) | EP2645662A4 (en) |
JP (1) | JP2014507832A (en) |
CN (1) | CN102546374A (en) |
WO (1) | WO2012088962A1 (en) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9136903B2 (en) * | 2012-08-14 | 2015-09-15 | Electronics And Telecommunications Research Institute | Method for resizing network connection in the optical transport network supporting protection switching |
US9136940B2 (en) * | 2012-08-14 | 2015-09-15 | Electronics And Telecommunications Research Institute | Method for resizing network connection in the optical transport network supporting protection switching |
US9722723B2 (en) * | 2012-09-13 | 2017-08-01 | Tejas Networks Ltd. | Dynamic hitless ODUflex resizing in optical transport networks |
JP5987679B2 (en) * | 2012-12-21 | 2016-09-07 | 富士通株式会社 | Optical transmission device including variable bit rate function |
KR102017880B1 (en) * | 2014-07-16 | 2019-09-03 | 한국전자통신연구원 | APPARATUS AND METHOD FOR PROTECTION IN OPTICAL TRANSPORT NETWORK SUPPORTING ODUflex(GFP) |
US9538264B2 (en) | 2014-08-07 | 2017-01-03 | Ciena Corporation | ODUflex resizing systems and methods |
CN109818705B (en) * | 2017-11-22 | 2020-05-19 | 华为技术有限公司 | Method, device and equipment for transmitting and receiving subrate signals |
CN110830142A (en) * | 2018-08-10 | 2020-02-21 | 中兴通讯股份有限公司 | Service switching method, device and storage medium |
CN115801582B (en) * | 2022-09-27 | 2024-05-31 | 海光信息技术股份有限公司 | System link bandwidth improving method, related device and computer equipment |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1897760A (en) | 2006-04-10 | 2007-01-17 | 中国电信股份有限公司 | Method for discovering dynamic band width distributing ability and configuring parameter based on timer |
CN101087238A (en) | 2003-10-21 | 2007-12-12 | 华为技术有限公司 | Dynamic bandwidth allocation device and method of passive optical network |
US20090067838A1 (en) | 2007-09-12 | 2009-03-12 | Verizon Services Corp. | High performance gigabit passive optical network |
WO2010142074A1 (en) | 2009-06-09 | 2010-12-16 | 华为技术有限公司 | Lossless adjustment method of oduflex channel bandwidth and oduflex channel |
WO2011023107A1 (en) * | 2009-08-28 | 2011-03-03 | 华为技术有限公司 | Method, network equipment and communication system for negotiating link capability information |
US20130101292A1 (en) * | 2011-10-20 | 2013-04-25 | Telefonaktiebolaget L M Ericsson (Publ) | Resizing existing traffic flow in optical transport network |
US20130121700A1 (en) * | 2011-11-15 | 2013-05-16 | Huawei Technologies Co., Ltd. | Method, apparatus and system for transmitting service data on optical transport network |
-
2010
- 2010-12-27 CN CN201010607730XA patent/CN102546374A/en active Pending
-
2011
- 2011-11-08 WO PCT/CN2011/081918 patent/WO2012088962A1/en active Application Filing
- 2011-11-08 EP EP11854406.3A patent/EP2645662A4/en not_active Withdrawn
- 2011-11-08 JP JP2013546571A patent/JP2014507832A/en active Pending
- 2011-11-08 US US13/976,421 patent/US9270367B2/en not_active Expired - Fee Related
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101087238A (en) | 2003-10-21 | 2007-12-12 | 华为技术有限公司 | Dynamic bandwidth allocation device and method of passive optical network |
CN1897760A (en) | 2006-04-10 | 2007-01-17 | 中国电信股份有限公司 | Method for discovering dynamic band width distributing ability and configuring parameter based on timer |
US20090067838A1 (en) | 2007-09-12 | 2009-03-12 | Verizon Services Corp. | High performance gigabit passive optical network |
WO2010142074A1 (en) | 2009-06-09 | 2010-12-16 | 华为技术有限公司 | Lossless adjustment method of oduflex channel bandwidth and oduflex channel |
WO2011023107A1 (en) * | 2009-08-28 | 2011-03-03 | 华为技术有限公司 | Method, network equipment and communication system for negotiating link capability information |
US20120155874A1 (en) * | 2009-08-28 | 2012-06-21 | Huawei Technologies Co., Ltd. | Method for negotiating link capability information, network device, and communication system |
US20130101292A1 (en) * | 2011-10-20 | 2013-04-25 | Telefonaktiebolaget L M Ericsson (Publ) | Resizing existing traffic flow in optical transport network |
US20130121700A1 (en) * | 2011-11-15 | 2013-05-16 | Huawei Technologies Co., Ltd. | Method, apparatus and system for transmitting service data on optical transport network |
Non-Patent Citations (3)
Title |
---|
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control"; Fatai Zhang, Huawei et al., Jul. 9, 2010; Network Working Group, Internet Draft, Standards Track; draft-zhang-ccamp-gmpls-evolving-g709-Imp-05.txt; Jan. 2011; see pp. 1-22. |
"Link Management Protocol (LMP) extensions for G.709 Optical Transport Networks"; Fatai Zhang, Huawei et al. May 13, 2010; Network Working Group, Internet Draft, Standards Track; draft-zhang-ccamp-gmpls-g709-Imp-discovery-03.txt; Nov. 2010; see pp. 1-16. |
International Search Report for PCT/CN2011/081918 dated Jan. 18, 2012. |
Also Published As
Publication number | Publication date |
---|---|
EP2645662A1 (en) | 2013-10-02 |
US20130279904A1 (en) | 2013-10-24 |
CN102546374A (en) | 2012-07-04 |
JP2014507832A (en) | 2014-03-27 |
WO2012088962A1 (en) | 2012-07-05 |
EP2645662A4 (en) | 2017-05-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9270367B2 (en) | Method and system for automatically discovering ODUflex bandwith lossless adjustment capability | |
US7633952B2 (en) | Discovery of physically adjacent neighbor devices using a unidirectional in-band process coupled with an out-of-band follow-up process | |
EP2627043B1 (en) | Method, device and system for lossless bandwidth adjustment | |
US9825845B2 (en) | Path computation method, path computation element, node device, and network system | |
US8243619B2 (en) | Smart mechanism for multi-client bidirectional optical channel protection scheme | |
WO2018090856A1 (en) | Method and device for building flexible ethernet group | |
EP1816803B1 (en) | Transmission processing method for data frame and system thereof | |
US7684419B2 (en) | Ethernet encapsulation over optical transport network | |
US20230232139A1 (en) | Service Protection Method and Network Node | |
WO2011009494A1 (en) | Methods and arrangement in a mpls-tp telecommunications network for oam functions | |
WO2011023107A1 (en) | Method, network equipment and communication system for negotiating link capability information | |
US20230254245A1 (en) | Data Frame Sending Method and Network Device | |
EP1983712A1 (en) | An automatic discovering method and device for clinet layer link | |
US8619590B2 (en) | Method for transmitting OAM message and processing error in PON system | |
CN102724599B (en) | A kind of control plane Bandwidth adjustment processing method | |
JP2006135871A (en) | Frame transmission apparatus and frame receiving apparatus | |
US10972309B2 (en) | Method and device for automatically discovering cross-node service topology on transoceanic multiple section shared protection ring | |
US20090297141A1 (en) | Transmission apparatus, path testing method, and storage medium | |
EP4195748A1 (en) | Resource configuration method and communication device | |
US7764630B2 (en) | Method for automatically discovering a bus system in a multipoint transport network, multipoint transport network and network node | |
US9088442B2 (en) | Method, apparatus, and system for sending and receiving service data | |
CN100407641C (en) | Method for treating link fault of multichannel giga ethernet convergent nodes | |
CN115633279B (en) | OSU (open service Unit) cross equipment and data transmission method based on OSU cross equipment | |
US7355984B1 (en) | Method and system for finding network neighbor information | |
CN114339482A (en) | Path switching method, device and system, electronic equipment and storage medium |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ZTE CORPORATION, CHINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TANG, KEXIN;FU, XIHUA;SIGNING DATES FROM 20130606 TO 20130616;REEL/FRAME:030704/0087 |
|
ZAAA | Notice of allowance and fees due |
Free format text: ORIGINAL CODE: NOA |
|
ZAAB | Notice of allowance mailed |
Free format text: ORIGINAL CODE: MN/=. |
|
ZAAA | Notice of allowance and fees due |
Free format text: ORIGINAL CODE: NOA |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: XI'AN ZHONGXING NEW SOFTWARE CO., LTD., CHINA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ZTE CORPORATION;REEL/FRAME:040017/0584 Effective date: 20160905 |
|
FEPP | Fee payment procedure |
Free format text: SURCHARGE FOR LATE PAYMENT, LARGE ENTITY (ORIGINAL EVENT CODE: M1554); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20240223 |