Abstract:
Methods and apparatus for efficiently allowing protection switch information to be communicated on bidirectional lines are disclosed. According to one aspect of the present invention, a method for communicating protection switch information from a first network element to a second network element across bidirectional links that include at least one working line and a protection line involves obtaining a generic framing protocol GFP frame at the first network element. The GFP frame has a payload area with a client payload field. The method also includes defining a command field associated with the GFP frame that is in the payload area but not in the client payload field, and storing protection switch information in the command field.

Description:
BACKGROUND OF THE INVENTION  
       [0001]     1. Field of Invention  
         [0002]     The present invention relates generally to optical networks. More particularly, the present invention relates to a smart management frame in which the payload of the frame is used to transport protection switch information.  
         [0003]     2. Description of the Related Art  
         [0004]     Within Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) transport networks, automatic protection switching (APS) enables working interfaces to be protected by backup interfaces. When a working interface fails, a backup interface assumes the traffic load of the working interface. In other words, APS provides the capability to detect a failure in an interface and to switch the traffic load of the failed interface to another interface.  
         [0005]     Protection switching is typically implemented through the utilization of K1 and K2 bytes in a line overhead of a SONET or SDH signal. When a signal failure is detected or when signal degradation is detected, protection switching may be initiated. K1 and K2 bytes are used to effectively signal a line level protection switch.  
         [0006]     With reference to  FIGS. 1A and 1B , protection switching which uses K1 and K2 bytes in the line overhead of a signal will be described.  FIG. 1A  is a diagrammatic representation of a near end and a far end that are in communication over a plurality of working links and a protection link. That is,  FIG. 1A  depicts a 1:N protection scheme. It should be appreciated that N is generally an integer which has a value between one and fourteen, inclusive. Optical signals are typically sent from a source or a near end  102  to a destination or a far end  106  over working links  110   a ,  110   b . A protection link  114  is generally not used until one of working links  110   a ,  110   b  fails. As shown, working links  110   a ,  110   b  and protection link  114  are bidirectional.  
         [0007]     When working link  110   a  fails, as indicated in  FIG. 1B , far end  106  detects the failure and sends a message using bits of a K1 byte to near end  102  over protection link  114 . Generally, bits five through eight of a K1 byte are used to hold a switch action channel request. Hence, by sending a message in bits five through eight of the K1 byte, far end  106  requests that near end  102  switch from transmitting over working links  110   a ,  110   b  to transmitting over working link  110   b  and protection link  114 . In response to the message sent by far end  106 , near end may switch from transmitting on working links  110   a ,  110   b  to transmitting on working link  110   b  and protection link  114 .  
         [0008]     With reference to  FIG. 2 , the steps associated with implementing protection switching in a 1:N protection architecture will be described. A process  200  of implementing protection switching begins at step  204  in which a far end detects a failure on a working link between a near end and the far end. The working link has an associated protection link. Upon detecting a failure, the far end sends a message in a K1 byte of a frame to the near end in step  208 . The K1 byte generally includes bits that indicate a switching priority and bits that indicate a requested switch action.  
         [0009]     In step  212 , the near end receives the message and switches traffic from the working link with the failure, i.e., the failed working link, to the protection link associated with the failed working link. Then, in step  216 , the near end sends a message using a K1 byte and a K2 byte of a frame to the far end. Bits in the K2 byte are used to indicate a channel number for data traffic sent over the protection link, and bits inn the K1 byte are used to send a reverse request. The reverse request is typically used to initiate a bidirectional switch action.  
         [0010]     The message sent by the near end is received by the far end, and in step  220 , the far end switches to the protection link to receive traffic. After the far end switches to the protected link, the far end switches traffic from the failed working link to the protection link to transmit traffic in step  224 . That is, the far end sets up to transmit packets, as well as to receive packets, using the protection link. Once the far end switches traffic to the protection link, the process of implementing protection switching is completed.  
         [0011]     While the use of K1 and K2 bytes in SONET and SDH signals is generally effective for implementing APS, K1 and K2 bytes each only include one byte. The amount of information which may be transmitted using two bytes may be limiting is situations in which it would be desirable to transmit more information relating to APS. Further, K1 and K2 bytes are not transparent to a SONET or SDH cloud.  
         [0012]     Therefore, what is desired is a method and an apparatus which allows information associated with a protection switch to be transmitted such that the information is not limited to a maximum of two bytes, and such that the information is transparent to a SONET or SDH cloud. That is, what is needed is a system which allows information typically associated with K1 and K2 bytes to be transmitted in bytes other than standard K1 and K2 bytes.  
       SUMMARY OF THE INVENTION  
       [0013]     The present invention relates to transmitting information associated with automatic protection switching in a command field of a generic framing protocol (GFP) frame. According to one aspect of the present invention, a method for communicating protection switch information from a first network element to a second network element across bidirectional links that include at least one working line and a protection line involves obtaining a generic framing protocol GFP frame at the first network element. The GFP frame has a payload area with a client payload field. The method also includes  
         [0014]     defining a command field associated with the GFP frame that is in the payload area but not in the client payload field, and storing protection switch information in the command field.  
         [0015]     In one embodiment, the command field has a size of up to approximately four bytes. In another embodiment, the protection switch information includes channel selection information bits associated with at least one channel of the protection line and protection switch priority bits.  
         [0016]     The inclusion of protection switch information, e.g., information that is generally associated with K1 and K2 bytes of line overhead, in a command field appended at an end of an overall payload area of a GFP frame allows the protection switch information to be substantially transparent to a SONET or SDH cloud. Further, such information may include up to four bytes, which allows a higher level of protection switch information to be transmitted than would be transmitted in standard K1 and K2 bytes.  
         [0017]     According to another aspect of the present invention, a method for processing protection switch information associated with a protection switching arrangement that includes at least one bidirectional primary link and a bidirectional secondary link includes obtaining a GFP frame and reading a protection switch information bit that is stored in a command field of the GFP frame. In one embodiment, the method includes  
         [0018]     storing an additional protection switch information bit in the command field, and sending the GFP frame including the additional protection switch information bit on the bidirectional secondary link.  
         [0019]     In accordance with yet another aspect of the present invention, a GFP data structure includes a core header and a payload area. Included in the payload area are a payload header, a payload field, and a command field. The command field is substantially appended to the payload field and arranged contains protection switch information. In one embodiment, the command field is up to approximately four bytes in size. In another embodiment, the command field contains information associated with K1 and K2 bytes.  
         [0020]     These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0021]     The invention may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:  
         [0022]      FIG. 1A  is a diagrammatic representation of a near end and a far end that are in communication over a plurality of working links and a protection link.  
         [0023]      FIG. 1B  is a diagrammatic representation of a near end and a far end that are in communication over a plurality of working links and a protection link, i.e., near end  102  and far end  106  of  FIG. 1A , in which a working link has failed.  
         [0024]      FIG. 2  is a process flow diagram which illustrates one method of implementing protection switching.  
         [0025]      FIG. 3A  is a diagrammatic representation of a generic framing procedure (GFP) frame.  
         [0026]      FIG. 3B  is a diagrammatic representation of a GFP frame, i.e., GFP frame  300  of  FIG. 3A , with protection switch information in a payload area in accordance with an embodiment of the present invention.  
         [0027]      FIG. 3C  is a diagrammatic representation of a GFP frame, i.e., GFP frame  300  of  FIG. 3A , with protection switch information bits in a protection switch information field of a payload area in accordance with an embodiment of the present invention.  
         [0028]      FIG. 4  is a process flow diagram which illustrates one method of processing a message that includes protection switch information stored in a payload area in accordance with an embodiment of the present invention.  
         [0029]      FIG. 5  is a process flow diagram which illustrates one method of processing a client signal failure indication in accordance with an embodiment of the present invention.  
         [0030]      FIG. 6A  is a diagrammatic representation of a near end and a far end which are associated with a protection scheme in which a working link has failed in accordance with an embodiment of the present invention.  
         [0031]      FIG. 6B  is a diagrammatic representation of a near end, i.e., near end  602  of  FIG. 6A , sending a client signal failure indication to a far end, i.e., far end  606 , in accordance with an embodiment of the present invention.  
         [0032]      FIG. 6C  is a diagrammatic representation of a far end, i.e., far end  606  of  FIG. 6   a , sending a client signal failure indication with protection switch information to a near end, i.e., near end  602 , in accordance with an embodiment of the present invention. 
     
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS  
       [0033]     A generic framing procedure (GFP) provides a framing mechanism that enables a substantially direct mapping of different data traffic types into frames that are compatible with a Synchronous Optical Network (SONET) protocol and a Synchronous Digital Hierarchy (SDH) protocol. GFP effectively defines a framing approach that enables different traffic types to be transported across a SONET or an SDH network. Hence, using GFP, protocols such as Ethernet and Fiber Channel may be carried over SONET and SDH networks.  
         [0034]     Adding protection switch information, e.g., information associated with automatic protection switching (APS), in a command field of an overall payload area of a GFP frame allows the protection switch information to be substantially transparent to a SONET or SDH cloud. Hence, between a near end and a far end of a transmission, protection switch information may be efficiently transmitted and received. In addition, a command field that is added to the end of a client payload field in a GFP frame may include up to four bytes, thereby allowing a higher amount of protection switch information to be transmitted than would be transmitted in standard K1 and K2 bytes in line overhead. The protection switch information is typically control information that may be used to enable protection switching to occur.  
         [0035]      FIG. 3   a  is a diagrammatic representation of a GFP frame. A GFP frame  300  includes a core header  304  and a payload area  308 . Core header  304 , which has approximately four bytes, includes a payload length indicator  312  and header error correction bits  316 . Payload length indicator  312  is typically two bytes that give the length of payload area  308 , while header error correction bits  316  are generally sixteen bits or two bytes that contain information which allows for errors within core header  304  to be corrected. Specifically, header error correction bits  316  allows cyclic redundancy check errors to be detected within payload length indicator  312 .  
         [0036]     In addition to including payload header  320 , payload area  308  also includes a client payload field  324  and a frame checking sequence (FCS) field 328 . Payload header  320  defines a type of information that is being transported, as well as the contents of client payload field  324 . The type of information being transported may be, but is not limited to, client management frames and client information frames. Payload header  320  generally includes a header error correction field  332 , a type field  336 , and an extension field  340 . Header error correction calculation field  332 , which is approximately two bytes in length, may contain cyclic redundancy check codes used to detect and to correct cyclic redundancy check errors in payload header  320 . Type field  336  is typically two bytes that specify an information type for the contents of client payload field  324 . Type field  336  also identifies that FCS  328  is present at the end of frame  300 , specifies a type associated with extension  340 , and also defines the type of data present in the client payload field  324 . Extension field  340 , which may have a length of between approximately zero bytes and approximately sixty bytes, may contain information pertaining to frame  300 .  
         [0037]     Client payload field  324  may include up to approximately 65,541 bytes, and FCS field  328  may include up to approximately four bytes. Client payload field  324  generally contains client data, or native packet information. FCS field  328 , in the described embodiment, contains protection switch information. The protection switch information may include information that is typically contained in K1 and K2 bytes in line overhead. That is, FCS field  328  is effectively a command field that may include, but is not limited to including, switch priority information, a switch action request, and a channel number on which data is to be sent on a protection link. As shown in  FIG. 3B , protection switch information field  328  is effectively appended onto client payload field  324 , and is a part of a payload area within frame  300 .  
         [0038]     Protection switch information field  328  may include substantially any type of information that may be used for APS signaling. As shown in  FIG. 3C , protection switch information field  328  may be divided into any number of sub-fields  328   a - d  which may each contain any number of bits up to a total of approximately four bytes over sub-fields  328   a - d . Although four sub-fields  328   a - d  are shown, it should be appreciated that there may generally be any number of sub-fields  328   a - d . Sub-fields  328   a - d  may contain, as previously mentioned, information that selects a channel to be used by APS messages, information that selects a bridged channel, information that identifies an APS architecture, and information that identifies bidirectional transmission capabilities. Further, sub-fields  328   a - d  may also contain condition information such as switch priority information as mentioned above, and information relating to a type of request, e.g., a reverse request, or a reason for a switch request, e.g., a signal failure or a signal degrade.  
         [0039]     With reference to  FIG. 4 , one method of processing a received client management frame with a command field that contains protection switch information will be described in accordance with an embodiment of the present invention. A method  400  of processing a client management frame begins at step  404  in which a near end or a source receives a message that contains protection switch information. In the described embodiment, the message is a GFP frame with a command field that includes up to approximately four bytes of protection switch information.  
         [0040]     After the near end receives the message, i.e., the current message or frame, the near end compares the contents contained in the command field of the current message to the contents of a command field of a previous message in step  408 . That is, a comparison is made between the current protection switch information and previous protection switch information. A determination is then made in step  412  regarding whether the contents of the command fields are different. If it is determined that the contents of the command fields are the same, i.e., that the current protection switch information is substantially the same as the previous protection switch information, the indication is that no protection switching is requested. Accordingly, the processing of a client management frame with a command field that contains protection switch information is completed.  
         [0041]     Alternatively, if the determination in step  412  that the contents of the command fields are different, the implication is that the far end which sent the message detected a failure on a working link or received a client signal failure indication. That is, if the contents of the command fields are determined to be different, then the indication is that the far end has identified a failure on a working link and has sent a switch action request to the near end in the current message. As such, process flow moves from step  412  to step  416  in which the near end generates an interrupt. Generating an interrupt may include ceasing to send traffic on the working link identified as having failed. When the interrupt is generated, new commands may be acquired, e.g., new commands may be acquired by a microprocessor of the near end from the far end.  
         [0042]     In order for a near end to receive protection switch information from a far end, the far end may add protection switch information in a command field of a frame in which there is a client signal failure indication. Referring next to  FIG. 5 , one process of providing protection switch information from a far end to a near end will be described in accordance with an embodiment of the present invention. A process  500  of providing protection switch information begins at step  504  in which a far end receives a client signal failure indication from a near end. The client signal failure indication is sent to the far end as a part of a client management frame, as will be appreciated by those skilled in the art.  
         [0043]     Once the client signal failure indication is received, the far end performs protection switching in step  508 , i.e., the far end switches to receiving traffic across a protection link. After the protection switching is performed at the far end, the far end builds a client management frame with a command field into which protection switch information is stored in step  512 . As previously discussed, the command field may include up to approximately four bytes. In step  516 , the frame built by the far end is forwarded to the near end, and the process of providing protection switch information to a near end is completed.  
         [0044]     When a far end sends a client management frame with protection switch information to a near end, the far end may send the client management frame on a protection link as well as on any working or primary links which have not been identified as having a failure associated therewith. By way of example, when the far end and the near end are associated with a 1:N protection scheme and one working or primary link is identified as failed, the client management frame with protection switch information is generally sent on the remaining “N−1” non-failed working links and the protection or secondary link.  
         [0045]      FIG. 6A  is a representation of a near end and a far end within a network in which the near end has an associated failure in accordance with an embodiment of the present invention. A near end  602  and a far end  606  are in communication over at least one bidirectional working or primary link  610  and a bidirectional protection or secondary link  614 . It should be appreciated that although only one bidirectional working link  610  is shown, the number of bidirectional working links which may be considered to be included in a cloud between near end  602  and far end  606  may vary widely. Generally, near end  602  and far end  606  may each have components such as processors and memories. In one embodiment, near end  602  and far end  606  may be network elements such as routers, clients, and servers. Further, near end  602  and far end  606  may include muxponders.  
         [0046]     When a failure is associated with near end  602  or, more specifically, when a failure affects working link  610 , a client signal failure indication frame  630  may be sent across failed working link  610  to far end  606  as shown in  FIG. 6B . Client signal failure indication frame  630  may be embodied in a carrier wave signal when sent across failed working link  610 . It should be appreciated that the client signal failure indication frame  630  may be a client management frame that indicates a client signal failure when the client management frame is incomplete. As previously mentioned, a client management frame is generally a GFP frame.  
         [0047]     After far end  606  receives client signal failure indication frame  630 , far end  606  effectively detects a failure associated with working line  610 , and initiates a protection switch. Far end  606  may append up to approximately four bytes onto client signal failure indication frame  630  as a command field. The command field, which is part of a payload area of client signal failure indication frame  630 , is arranged to include at least some protection switch information. The protection switch information may be, in one embodiment, up to a four byte representation of information that is typically contained in the K1 and K2 bytes in line overhead.  FIG. 6C  is a representation of near end  602  and far end  606  after far end  606  sends protection switch information to near end  602 . Once protection switch information is added into a command field in client signal failure frame  630 , client signal failure frame  630 ′, which includes the command field in which protection switch information is contained, is sent to near end  602  over protection line  614 . Near end  602  may process client signal failure frame  630 ′ by using the protection switch information contained therein to switch transmission from failed working line  610  to an appropriate channel on protection line  614 . The information regarding the channel onto which transmissions or data traffic has been switched may be sent to far end  606  by near end  602  in a command field of a subsequent frame.  
         [0048]     Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the present invention. By way of example, although a command field in which protection switch information is contained has been described as being added or otherwise appended to a client management frame that includes a client signal failure indication, a command field may generally be added to any client management frame. That is, protection switch information may be transmitted from a far end to a near end as a part of substantially any client management frame after a far end receives a client signal failure indication.  
         [0049]     A network element that serves as a far end, e.g., network element  606  of  FIG. 6A , may be arranged to include either or both hardware and software code devices that enable protection switch information to be added into a GFP frame. Such a network element, when arranged to support software code devices, may include memory or be arranged to support a computer-readable medium that enables software code devices to be stored thereon, as well as a processor that allows the software code devices to execute. Any hardware devices may be implemented, in one embodiment, as an application specific integrated circuit.  
         [0050]     The steps associated with the methods of the present invention may vary widely. Steps may be added, removed, altered, and reordered without departing from the spirit of the scope of the present invention. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims.