Field of the invention

The present invention relates to channelization of lower order ODU trail inside a higher order ODU in an optical transport network (OTN) communication system.

Background

In an optical transport network, the client data is carried in payload units called optical channel payload units. These payload units are added with overhead bytes that carry specific header information used for transporting it in frames called as lower order Optical Channel Data Units (ODU) (like ODUj, ODU1, ODU2, ODU3, LO ODU in short) and a higher order ODU, like ODUk,(HO ODU in short). A lower order ODU may be multiplexed into a higher order ODU, and encapsulated as an optical channel transport unit (OTU) which is transmitted on a link. In the process of multiplexing, network parameters like, tributary port number (TPN) and time slot (TS) needs to be configured for two adjacent nodes manually in a bi-directional link, for LO ODU trail setup. This whole trail formation based on such matching values of network parameters involves transmitting some values on the overhead bytes of ODUk and associated ODUj and expecting the same in the adaptation function is referred to as lower order ODU trail setup or channelization. For a lower order ODU trail creation (also called as a process of channelization of lower order ODU inside a higher order ODU) on an OTU link spanning two nodes, one has to specify the following (assuming a bidirectional LO ODU trail), Egress (Tx) TPN, Ingress (Rx) TPN, Egress time slot (TxTS) and Ingress time slot (RxTS) list. The Egress (Tx) values at the transmitter must match the Ingress (Rx) values at the receiver. This will be a cumbersome maintenance of the resource usage by the network operator as these value range from 1-80 assuming an OTU4 link.

The disadvantage associated with such manual configuration is that both the adjacent nodes need to be configured with the matching values and hence the onus in on the operator to make sure of the same.

The network management system (NMS) may be of some assistance but this has a cost associated with itself as a separate NMS application is required. Additionally, this may not be possible in low cost equipments / networks. Further in case of NMS failure due to software crash or connectivity failure, such a trail setup becomes the operator responsibility. Also, it might be possible that due to connectivity loss one of the network nodes may not be reachable and the trail setup becomes impossible on that node.
In addition to NMS, assistance from control plane such as GMPLS or PNNI, which may automatically manage the networks, may be an alternative. But once again problems identical to NMS, i.e., cost and failure of such components may crop up. Further a GMPLS / PNNI stack has significant cost associated with it and might not be feasible in low cost equipments with a bare minimum software (for management, APS, etc ) running on it. Control plane assistance for automatically managed networks also requires a dedicated Data Communications Network (DCN) channel. As a control plane always run over some data plane and never works in isolation, the signalling which is done at control plane level introduces additional layers apart from the data plane L1 layer. As an example if an RSVP-TE signalling for time-slot allocation, is run in a naive low cost system, additional requirements for L3 and L2 layers arises, which has an additional cost component associated with additional layer processing overheads. Therefore a new intelligent protocol based channelization process, where the matching resources are figured out using the data plane without involving human effort in tracking the details of time-slots and TPN in HO ODUk is required.

Summary of the Invention

The summary represents the simplified condensed version of the daimed subject matter and it is not an extensive disclosure of the claimed subject matter. The summary neither identifies key or critical elements nor delineates the scope of the claimed subject matter. The summary presents the simplified form of the claimed subject matter and acts as a prelude to the detailed description that is given below.The present invention and its embodiments are made to provide for channelization of lower order ODU trail inside a higher order ODU in an optical transport network (OTN) without any identification of matching network resources by the Network Management System (NMS) or any control plane signaling including Generalised Multi Protocol Label Switching (GMPLS).

An aspect of the invention provides a method for channelization of lower order ODU trail inside a higher order ODU in an optical transport network (OTN) by initiating protocol command messages in the data plane for the agreement of matching network parameters between nodes by the node receiving an indication command and identifying matching network parameters wherein, network parameters includes an unique identification (UID) index, tributary port number (TPN) and time-slots (TS). The method further comprising of initiating protocol message exchanges for identifying and agreeing on an unique identification (UID) between two nodes and for identifying and agreeing on matching egress and ingress Tributary Port Number (TPN), Time-Slots (TS) for both the nodes wherein, UID is an index for uniquely indentifying a lower order ODU inside a higher order ODU.

Another aspect provides for initiating protocol message exchanges for tearing down channelization and relinquishing the matching network parameters used for channelization by both the nodes based on receiving an indication command.

Description of the Drawings
The features, advantages and other aspects of the embodiments of the present invention will be obvious to any person skilled in the art to appreciate the invention when read with the following description taken in conjunction with the accompanying drawings.

Figure 1a illustrates a unidirectional lower order ODU trail creation process spanning two nodes as known in the prior art.

Figure 1 b illustrates a bi-directional lower order ODU trail creation process as known in prior art.

Figure 2a illustrates an aspect of unidirectional channelization embodying exemplary features of the invention.

Figure 2b illustrates another aspect of unidirectional channelization embodying exemplary features of the invention.

Figure 2c illustrates a bi-directional channelization embodying exemplary features of the invention.

Figure 3 shows bidirectional exchange of channelization protocol messages between two nodes for identifying and agreeing a unique identification (UID) index, in accordance with the exemplary embodiments of the invention.

Figure 4 shows bidirectional exchange of channelization protocol messages between two nodes identifying and agreeing on matching egress and ingress TPN of both the nodes, in accordance with the exemplary embodiments of the invention.

Figure 5 shows bidirectional exchange of channelization protocol messages between two nodes for identifying and agreeing on matching egress and ingress time-slots (TS) of both the nodes, in accordance with the exemplary embodiments of the invention.

Figure 6 is the flow chart representing the functionality performed by nodes in executing channelization protocol message exchanges in accordance with the exemplary embodiments of the invention.

Figure 7 shows bidirectional exchange of channelization protocol messages for tearing down the matching egress and ingress network parameters used for channelization at both the nodes in accordance with the embodiments of the invention.

Figure 8 shows contention resolution protocol messages for initiating channelization between nodes in accordance with the exemplary embodiments of the invention.

Figure 9 shows the bit format for the Type 1 (T1) channelization protocol command messages in accordance with the exemplary embodiments of the invention.

Figure 10 shows the bit format for the Type 2 (T2) channelization protocol command messages in accordance with the exemplary embodiments of the invention.

The figures are not drawn to scale and are illustrated for simplicity and clarity to help understand the various embodiments of the present invention. Throughout the drawings it should be noted that like reference numbers are used to depict the same or similar elements, features and structures.

Detailed Description
The following descriptions with reference to the accompanying drawings are provided to assist in a comprehensive understanding of exemplary embodiments of the invention as defined by the claims and their equivalents. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention.

The terms and words used in the following description and claims are not limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the invention. Accordingly, it should be apparent to those skilled in the art that the following description of exemplary embodiments of the present invention are provided for illustration purpose only and not for the purpose of limiting the invention as defined by the appended claims and their equivalents.

The term 'electronic component' is intended to refer to an entity or entities within a communication network node comprising of; hardware, software, a combination of hardware and software. For e.g., an electronic component may be, but not limited to being, a process running on a processor, a processor, an integrated circuit, or a computer. Both an application running on a computing device and the computing device can be an electronic component. The electronic components may communicate by way of local and/or remote processes. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged systems. The terms used to describe various embodiments are exemplary. It should be understood that these are provided to merely aid the understanding of the description, and that their use and definitions in no way limit the scope of the invention.

The present invention and its embodiments are mainly described in relation to Optical Transport
Network (OTN) specifications and standards for applicability of certain exemplary embodiments. The terminology used is therefore related thereto. Such terminology is used in the context of describing the embodiments of the invention and it does not limit the invention in any way. Any other network architecture or system deployment, etc., may also be utilized as long as it is compliant with the features described herein. The terms 'lower order ODU trail setup', 'lower order ODU trail creation' or 'channelization' are used interchangeably throughout the description to refer and convey the same meaning. '

In particular, embodiments of the present invention may be applicable in any OTN communication network without a need for setting up Lower Order (LO) ODU trail, either manually or automatically through Network Management System (NMS) or any Control Plane Signaling including GMPLS. Embodiments of the invention may also be applicable in OTN communication network enabled by a NMS or GMPLS as a backup in case of NMS or GMPLS failing in channelization. Embodiments of the present invention may be applicable for/in any kind of modern and future communication in an optical transport network.

Node used in the following description denotes a communication entity in an optical transport network, used by various terminologies like a network node, network element, routers, network device, network terminal, node etc. Network, communication network, used in the description refers to optical transport networks. Ends, ends, end points functioning in initiator mode or receptor mode, refer to individual port or ports, providing access to the services offered by a node.

Figure 1a illustrates a unidirectional lower order ODU trail creation process spanning two nodes 103 and 104 as known in the prior art. For a lower order ODU trail creation (also called as a process of channelization of lower order ODU inside a higher order ODU) on an Optical Channel Transport Unit (OTU) link spanning two nodes (for e.g., 103 and 104), network parameters like Tributary Port Number (TPN) and Time Slot (TS) at the egress (Tx) end i.e., 103 should match with the ingress (Rx) end i.e., 104. As OTN is a time division multiplexed technology, for a lower order ODU trail setup the values of Tx and Rx parameters at both ends should match. It has to be made sure by the operator configuring such a trail that such a matching value is configured at both the nodes (103 and 104) for the lower order ODU trail in question.

Figure 1b illustrates a bi-directional lower order ODU trail creation process as known in prior art. The network parameters TPN and TS for e.g., egress TPN (Tx) at node 103 should match the ingress TPN (Rx) at node 104 and the egress TPN (Tx) at node 104 should match the ingress TPN (Rx) at node 103. Similarly egress (Tx) and ingress (Rx) time slots at both the nodes should match for a successful channelization. It has to be made sure by the operator configuring such a trail that such a matching value is configured at both the nodes (103 and 104) for the lower order ODU trail in question. This often turns out to be a cumbersome maintenance of the resource usage by the network operator as the values of time-slots may range from 1 to 80 (assuming an OTU4 link). In case of some assistance from the NMS or intelligent control plane, the operator is relieved to an extent but, such a NMS or intelligent control plane has a cost associated with itself as a separate application is required additionally. Further, during a software crash or connectivity failure of NMS or control plane, such a trail setup once again becomes the operator responsibility.

Figure 2a, 2b illustrate a unidirectional and figure 2c a bi-directional channelization embodying exemplary features of the invention. As seen in figure 2a, lower order ODU trail setup between two nodes 103 and 104 can be accomplished by configuring only one node 103. The operator needs to specify the LO ODU type (ODU1, ODU2, ODU2e, and ODU3) or the number of time-slots for an ODUflex, as an 'indication command' to the node 103 alone. The 'indication command' may comprise of instructions to the node 103 to 'configure the LO ODU type or egress number of time-slots for the LO ODUflex'. Similar 'indication command' may be given for node 103 alone for configuring the LO ODU type or ingress number of time-slots for the LO ODUflex as illustrated in figure 2b.

In case of bi-directional LO ODU trail creation as illustrated in figure 2c an 'indication command' may be given for node 103 alone for configuring the LO ODU type or egress and ingress number of time-slots for the LO ODU flex. On receiving the 'indication command' node 103 initiates the channelization protocol message exchange with the node 104. Through the channelization protocol run on the data plane layer itself, the trail on the other end is automatically created on completion of the protocol and the agreement of parameters. On successful setup of the trail the network operator is returned a Unique identification (UID) index for the trail which can be used for future configurations in the networks (say for ODU connection setup) or collection of performance data, etc. The network resources comprising of TPN and TS are absolutely hidden to the operator. Hence, the user knows only about UID which identifies that trail.
In the entire prior art methods the network parameters (TPN and TS) allocation is done manually at both the ends or through NMS or automatically through the control plane signalling. The problem associated with the above method of provisioning is that at a later point of time the network operator has to identify the LO ODUj using the TS list or TPN. Such identification might be required in case of manual operations of tracking the network behaviour, for example collection of performance data or setup of ODU connections. Due to this the network operator may not be agnostic to network resources (TPN and TS). Subsequently there may arise a necessity to provision the LO ODUj manually, the network operator will have to track these resources and try to use the free ones which are not used by any other LO ODUj.

This inevitably is a cumbersome process as the TS resource can be a large list of numbers.

The TPN is of egress and ingress type as the LO ODUj can be unidirectional too. Hence, the user has to track both the egress and ingress TPNs which are free. With the UID this bidirectional tracking can be dispensed with as the UID has no direction associated with it. Each LO ODUj inside a HO ODUk be it unidirectional or bidirectional is uniquely identified using the UID. Due to this concept of UID the network resources which have direction associated with them become hidden. Added to it the UID is also automatically assigned and operator need not track the same.

The method for initiating bidirectional channelization process begins with the receipt of an 'indication command' by the node 103. The 'indication command' comprising of instructions to a specific node to configure the LO ODU Type or egress and ingress number of time-slots for the LO ODUflex may be issued manually by a network operator or may be done automatically by a mechanism which senses the channelization requirements at the desired node which is reachable for such a trail setup. The 'indication command' further includes command for tearing down the established LO ODU trail between two nodes.

The automatic mechanism which senses the channelization requirements may be a centralized Network Management Entity, a Computer controlled system, a network management server, GMPLS etc.

Embodiments of the invention provide for a node, which receives an 'indication command' for initiating channelization protocol messages as a 'initiator" node and the node which responds to the received channelization protocol command messages function as a receptor' node. The 'indication command' in addition may further comprise of instructions from a node to another node for instructing the other node to swap the functional roles of 'initiator' and 'receptor' in the execution of channelization between the nodes.
Figure 3 shows bidirectional exchange of channelization protocol messages between two nodes for identifying and agreeing on an UID, embodying exemplary features of the invention. Channelization protocol message exchange embodying exemplary features of the invention begins with the identifying and agreeing on UID between the nodes 103 and 104. Based on an 'indication command' received by the node 103, the node 103 functions as an 'initiator' (hereinafter referred to as initiator) and from its end point 15 generates and sends a UID request protocol command message Tl [UID=x, UID REQ, NACK, TPN=0] to the node 104 (hereinafter referred to as 'receptor') (Step 1). Tl is a 4 bit control word, representing type 1 protocol command messages for identifying and agreeing UID, TPN and for TEARDOWN, ABORT, REMOTE TS SETUP in accordance with the embodiments of the invention and are as shown in figure 9. 'Receptor' receives the protocol command message at its end point 10 and if the demanded 'UID=x' is available a protocol acknowledgment message is sent to 'initiator'. In case the demanded 'UID=x' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message (Step 2)., here, NACK signifies negative acknowledgment. 'Initiator' upon receiving at its end point 15, a negative acknowledgment for the demanded 'UID=x' from receptor, generates and sends successive demand for UID index request, until the required matching UID index is achieved if a negative protocol acknowledgment message for the demanded matching UID index is received from the receptor node.

'Initiator' generates and sends a successive UID request protocol command message Tl [UID=y, UID REQ, NACK, TPN=0] to the 'receptor' (Step 3). 'Receptor' receives the protocol command message at its end point 10 and if the demanded 'UID=y' is available a protocol acknowledgment message is sent to 'initiator'. In case the demanded 'UID=y' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message (Step 4)., here, NACK signifies negative acknowledgment. 'Initiator" upon receiving at its end point 15, a negative acknowledgment for the demanded 'UID=y' from receptor, generates and sends successive UID request protocol command message T1 [UID=z, UID REQ, NACK, TPN=0] to the 'receptor' (Step 5). 'Receptor' receives the protocol command message at its end point 10 and if the demanded 'UID=z' is available a protocol acknowledgment message is sent to 'initiator'. Here, ACK signifies 'UID=z' is available at the 'receptor' and so a protocol acknowledgement message is sent to 'initiator' (Step 6). 'Initiator receives the protocol acknowledgement message and generates and sends a UID final protocol command message to the 'receptor' (Step 7). 'Receptor' receives the message and generates and sends a UID index final protocol acknowledgment message to the 'initiator' (Step 8). The UID 'z' thus identified and agreed by the 'initiator' and the 'receptor' by protocol message exchanges is reserved as unique identification index by the 'initiator' and 'receptor' respectively.

Figure 4 shows bidirectional exchange of channelization protocol messages between two nodes 103 and 104 for identifying and agreeing on matching egress and ingress TPN of both the nodes, embodying exemplary features of the invention. Channelization protocol message exchange for identifying and agreeing on matching egress and ingress TPN of both nodes i.e., 103 and 104 embodying the exemplary features of the invention follows with the identified and agreed UID 'z'. Once the UID 'z' is established between the nodes 103 and 104, the 'initiator' from its end point 15 generates and sends a egress TPN request protocol command message T1 [UID=z, ETPN REQ, NACK, TPN=a] to the 'receptor' (Step 1).

'Receptor" receives the protocol command message at its end point 10 and if the demanded TPN=a' is available a protocol acknowledgment message is sent to 'initiator'. In case the demanded TPN=a' is unavailable, its non-availability is conveyed from 'receptor1 at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message (Step 2)., here, NACK signifies negative acknowledgment. 'Initiator1 upon receiving at its end point 15, a negative acknowledgment for the demanded TPN=a' from receptor, generates and sends successive demand for egress TPN request, until the required matching egress TPN is achieved, if a negative protocol acknowledgment message for the demanded matching egress TPN is received from the 'receptor'.

'Initiator' generates and sends a successive egress TPN request protocol command message T1 [UID=z, ETPN REQ, NACK, TPN=b] to the 'receptor' (Step 3). 'Receptor' receives the protocol command message at its end point 10 and if the demanded TPN=b' is available a protocol acknowledgment message is sent to 'initiator'. In case the demanded TPN=b' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message (Step 4)., here, NACK signifies negative acknowledgment. 'Initiator' upon receiving at its end point 15, a negative acknowledgment for the demanded TPN=b' from receptor, generates and sends successive egress TPN request protocol command message T1 [UID=z, ETPN REQ, NACK, TPN=c] to the 'receptor' (Step 5). 'Receptor' receives the protocol command message at its end point 10 and if the demanded TPN=c' is available a protocol acknowledgment message is sent to 'initiator'. Here, ACK signifies TPN=c' is available at the 'receptor' and so a protocol acknowledgement message is sent to 'initiator' (Step 6).

'Initiator receives the protocol acknowledgement message and generates and sends 'egress TPN final protocol command message' to the 'receptor' (Step 7). 'Receptor' receives the message and generates and sends 'egress TPN final protocol acknowledgment message' to the 'initiator' (Step 8). The TPN 'c' thus identified and agreed by the 'initiator' and the 'receptor' by protocol message exchanges is reserved as egress TPN and ingress TPN by the 'initiator' and 'receptor' respectively. It is to be noted that if all the egress TPN resource available on 'initiator' are exhausted and the matching TPN for placing any successive egress TPN request could not be found, 'initiator' sends an ABORT message to the 'receptor' to abort the entire protocol request messages (not shown in figure 4).

Once the egress and ingress TPN for 'initiator' 103 and 'receptor' 104 is established between the nodes
103 and 104, the 'initiator' from its end point 15 generates and sends an ingress TPN request protocol command message T1 [UID=z, ITPN REQ, NACK, TPN=a] to the 'receptor' (Step 9). 'Receptor" receives the protocol command message at its end point 10 and if the demanded TPN=a' is available a protocol acknowledgment message is sent to 'initiator'. In case the demanded TPN=a' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator1 by sending a protocol negative acknowledgement message (Step 10)., here, NACK signifies negative acknowledgment. 'Initiator' upon receiving at its end point 15, a negative acknowledgment for the demanded TPN=a' from receptor, generates and sends successive demand for ingress TPN request, until the required matching ingress TPN is achieved, if a negative protocol acknowledgment message for the demanded matching ingress TPN is received from the 'receptor1.

'Initiator1 generates and sends a successive ingress TPN request protocol command message T1 [UID=z, ITPN REQ, NACK, TPN=b] to the 'receptor' (Step 11). 'Receptor1 receives the protocol command message at its end point 10 and if the demanded TPN=b' is available a protocol acknowledgment message is sent to 'initiator1. Here, ACK signifies TPN=b' is available at the 'receptor1 and so a protocol acknowledgement message is sent to 'initiator1 (Step 12). 'Initiator receives the protocol acknowledgement message and generates and sends 'ingress TPN final protocol command message1 to the 'receptor1 (Step 13). 'Receptor" receives the message and generates and sends 'ingress TPN final protocol acknowledgment message' to the 'initiator1 (Step 14). The TPN 'b' thus identified and agreed by the 'initiator' and the 'receptor1 by protocol message exchanges is reserved as ingress TPN and egress TPN by the 'initiator' and 'receptor1 respectively. It is to be noted that if all the ingress TPN resource available at 'initiator' are exhausted and the matching TPN for placing any successive ingress TPN request could not be found, 'initiator1 sends an ABORT message to the 'receptor1 to abort the entire protocol request messages (not shown in figure 4).

Figure 5 shows bidirectional exchange of channelization protocol messages between two nodes for identifying and agreeing on matching egress and ingress time-slots (TS) of both nodes, embodying exemplary features of the invention. Channelization protocol message exchange for identifying and agreeing on matching egress and ingress TS of both nodes i.e., 103 and 104 embodying exemplary features of the invention follows with the identified and agreed egress and ingress TPN of both the nodes 103 and 104. Once the egress TPN 'c' ingress TPN 'b' is established for the 'initiator' 103 and egress TPN 'b', ingress TPN 'c' is established for the 'receptor' 104, the 'initiator' 103 from its end point 15 generates and sends egress TS request protocol command message (for e.g., assuming two time-slots are required for the LO ODU in this example) T2 A [UID=z, SETUP, NACK], T2 B [UID=z, SETUP, NACK] to the 'receptor' (Step 1). T2 is a 3 bit control word, representing type 2 protocol command messages for identifying and agreeing on time-slots (TS) in accordance with the exemplary features of the invention and are as shown in figure 10. 'Receptor' receives the protocol command message at its end point 10 and if the demanded time-slots 'A and B' are available a protocol acknowledgment message is sent to
'initiator'. In case the demanded time-slots 'A and B' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message (Step 2)., here, NACK signifies negative acknowledgment. Initiator" upon receiving at its end point 15, a negative acknowledgment for the demanded time-slots 'A and B' from receptor, generates and sends successive demand for egress TS request, until the required matching egress TS is achieved, if a negative protocol acknowledgment message for the demanded matching egress TS is received from the 'receptor'.

Initiator' generates and sends a successive egress TS request protocol command message T2 A [UID=z, NO REQ, NACK], T2 B [UID=z, NO REQ, NACK], T2 C [UID=z, SETUP, NACK], T2 D [UID=z, SETUP, NACK] to the 'receptor' (Step 3). 'Receptor' receives the protocol command message at its end point 10 and if the demanded time-slots 'C and D' are available a protocol acknowledgment message is sent to 'initiator'. In case the demanded time-slots 'C and D' are unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message. 'Receptor' identifies that demanded time-slot 'C is available and the demanded time-slot 'D' is unavailable at its end. Here, NACK signifies negative acknowledgment and ACK signifies the availability of time-slot 'C. The availability of time-slot 'C and the unavailability of time-slot 'D' is conveyed to the 'initiator' by generating and sending a protocol acknowledgement message and a protocol negative acknowledgment respectively by the 'receptor' (Step 4).

'Initiator' upon receiving at its end point 15, a negative acknowledgment for the demanded time-slot 'D' generates and sends successive (for e.g., E) egress TS request protocol command message for compensating the deficiency of matching time slot that has been demanded for. 'Initiator1 generates and sends successive egress TS request protocol command message T2 C [UID=z, SETUP, ACK], T2 D [UID=z, NO REQ, NACK], T2 E [UID=z, SETUP, NACK] to the 'receptor1 (Step 5). 'Receptor1 receives the protocol command message at its end point 10 and if the demanded time-slot 'E' is available a protocol acknowledgment message is sent to 'initiator'. Here, ACK signifies time-slot 'E' is available at the 'receptor1 and so a protocol acknowledgement message is sent to 'initiator' (Step 6). 'Initiator receives the protocol acknowledgement message and generates and sends 'egress TS final protocol command message for the time-slots 'C and 'E' to the 'receptor' (Step 7). 'Receptor' receives the message and generates and sends 'egress TS final protocol acknowledgment message for the time-slots 'C and 'E' to the 'initiator1 (Step 8). The time-slots 'C and 'E' thus identified and agreed by the 'initiator' and the 'receptor' by protocol message exchanges is reserved as egress TS and ingress TS by the 'initiator' and 'receptor' respectively. It is to be noted that if all the TS resource available on 'initiator' are exhausted and the required number of matching TS for placing any successive egress TS request could not be found, 'initiator' sends an ABORT message to the 'receptor' to abort the entire protocol request messages (not shown in figure 5).

Once the egress and ingress time-slots for 'initiator' 103 and 'receptor' 104 respectively is established between the nodes 103 and 104, the 'initiator' from its end point 15 generates and sends an 'indication command' for swapping the respective functional roles of Initiator' and 'receptor' wherein, 'indication command' includes a remote time-slot setup request protocol command message for placing a matching time-slot request protocol command message to the new 'receptor' 103. Assuming the new functionality of an 'initiator' on receiving the 'indication command' the node 104 generates and sends an egress TS request protocol command message T2 A [UID=z, SETUP, NACK], T2 B [UID=z, SETUP, NACK] to the 'receptor' 103 (Step 9). 'Receptor' receives the protocol command message at its end point 10 and if the demanded time-slots 'A' and 'B' is available a protocol acknowledgment message is sent to 'initiator' 104. In case the demanded time-slots 'A' and 'B' is unavailable, its non-availability is conveyed from 'receptor' at its end point 10 to 'initiator' by sending a protocol negative acknowledgement message. 'Receptor'103 identifies that demanded time-slot 'B' is available and the demanded time-slot 'A' is unavailable at its end. Here, NACK signifies negative acknowledgment and ACK signifies the availability of time-slot . The availability of time-slot 'B' and the unavailability of time-slot 'A' is conveyed to the 'initiator' 104 by generating and sending a protocol acknowledgement message and a protocol negative acknowledgment respectively by the 'receptor' (Step 10).

'Initiator' upon receiving at its end point 15, a negative acknowledgment for the demanded time-slot 'A' generates and sends successive (for e.g., C) egress TS request protocol command message for compensating the deficiency of matching time slot that has been demanded for. 'Initiator' generates and sends successive egress TS request protocol command message T2 A [UID=z, NO REQ, NACK], T2 B [UID=z, SETUP, NACK], T2 C [UID=z, SETUP, NACK] to the 'receptor' 103 (Step 11). 'Receptor' 103 receives the protocol command message at its end point 10 and if the demanded time-slot 'C is available a protocol acknowledgment message is sent to 'initiator'. Here, ACK signifies time-slot 'C is available at the 'receptor' and so a protocol acknowledgement message is sent to 'initiator' (Step 12). 'Initiator' 104 receives the protocol acknowledgement message and generates and sends 'egress TS final protocol command message for the time-slots 'B' and 'C to the 'receptor' 103 (Step 13). 'Receptor' 103 receives the message and generates and sends 'egress TS final protocol acknowledgment message for the time-slots 'B' and 'C to the 'initiator1 104 (Step 14). The time-slots 'B' and 'C thus identified and agreed by the 'initiator' 104 and the 'receptor' 103 by protocol message exchanges is reserved as egress TS and ingress TS by the 'initiator' 104 and 'receptor' 103 respectively. It is to be noted that if all the TS resource available on 'initiator' 104 are exhausted and the required number of matching TS for placing any successive egress TS request could not be found, 'initiator1 104 sends an ABORT message to the 'receptor' 103 to abort the entire protocol request messages (not shown in figure 5).

At the end of the channelization protocol message exchange on both the nodes 103 and 104 an ODU trail is setup. The ODU trail at node 103 has following values: Egress (Tx) TPN=c, Ingress (Rx) TPN=b, Egress TS list = C, E, Ingress TS list = B,C. Similarly the ODU trail at node 104 has following values:

Egress (Tx)

TPN=b, Ingress (Rx) TPN=c, Egress TS list = B,C, Ingress TS list = C, E. It should be noted that an ODU1 has been taken as an example which requires 2 time-slots. The user is returned a Unique Identification Index Z (UID=z) after the successful LO ODU setup which the user may use in future for identification purpose.

Figure 6 is the flow chart representing the functionality 300 performed by nodes 103 and 104 in accordance with the exemplary embodiments of the invention. The embodied functionality of a node begins at 301, wherein it receives an 'indication command' for initiating channelization between the nodes. On receipt of the 'indication command', the receiving node functions as an 'initiator' for demanding network resources like UID, TPN and TS with the other node functioning as a 'receptor'. An 'indication command' may be issued manually by a network operator or may be done automatically by a mechanism which senses the channelization requirements at the desired node which is reachable for such a trail setup. It is to be understood that an 'indication command' may be simultaneously issued to both the nodes and a contention can occur as to the determination of 'initiator' node if both the nodes are simultaneously issued indication commands. In case of such contention, a contention resolution mechanism is used to make one of these nodes a receptor. At 302, the 'initiator' generates and sends to the 'receptor' channelization protocol command messages for the list of network resources on its end to the 'receptor'.

At 303, the 'initiator' either receives protocol acknowledgement message (ACK) or protocol negative acknowledgment message (NACK) from the 'receptor' on the demanded list of network resources. If a protocol acknowledgement message (ACK) is received for the demanded list of network resources at 303 then at 304, the 'initiator' decides to send final protocol message on the list of matching resources. At 305, final protocol message is sent to the 'receptor'. Subsequently final protocol acknowledgment message is received from the 'receptor' at 306. The matching resources thus identified and agreed by channelization protocol message exchanges between 'initiator' and receptor' nodes are reserved at 307. If the required numbers of demanded network resources are not positively acknowledged at 303 then at 304, the 'initiator' decides to send successive demand for matching resources for compensating the deficiency of the demanded network resources that is required for channelization. At 308, the initiator' checks for the availability of more resources at its end and if available places successive demand for network resources to the 'receptor' at 302. If sufficient network resources are unavailable at 308, the 'initiator' sends a protocol command message to abort the entire protocol request messages demanding network resources at 309.

At 301, a node functions as a 'receptor' if it receives a channelization protocol command message and does not receive an 'indication command' or has been resolved by a contention resolution means to function as a 'receptor'. At 310, the 'receptor' receives channelization protocol command messages demanding request for the list of matching resources from the 'initiator' end. At 311, the 'receptor' sends protocol acknowledgement message (ACK) for the available demanded network resources and a protocol negative acknowledgment message (NACK) for the demanded unavailable network resources. At 312, the 'receptor" checks for the receipt of successive demand for network resources from the 'initiator' if a protocol negative acknowledgement was sent by the 'receptor1 to the 'initiator' for the demanded at least a network resource at 311. If successive demand for network resources from the 'initiator' is received at 312, the 'receptor* at 311 repeats the process of sending protocol acknowledgement message (ACK) for the available successively demanded network resources and a protocol negative acknowledgment message (NACK) for the successively demanded unavailable network resources.

If successive demand for network resources from the 'initiator' node is not received at 312, the 'receptor' checks for the receipt of final protocol messages from the 'initiator' and if final protocol message is received, at 313, the matching network resources thus identified and agreed by channelization protocol message exchanges between 'initiator' and 'receptor' nodes are reserved at 307. If final protocol message is not received at 313, the receptor receives a protocol command message to abort the entire protocol request messages demanding network resources at 314.

Figure 7 shows bidirectional exchange of channelization protocol messages for tearing down the matching egress and ingress parameters used for channelization at both the nodes in accordance with the embodiments of the invention, thereby relinquishing all the resources reserved as matching parameters comprising of unique identification (UID) index, egress and ingress TPN, egress and ingress time slot (TS) by the 'initiator' and 'receptor' respectively. The established LO ODU trail between the nodes 103 and 104 may be reversed thereby releasing the network resources, by exchange of teardown protocol message exchanges. Upon receiving the 'indication command' to tear down the LO ODU trail, the 'initiator' 103, from its end point 15 generates and sends a teardown request protocol command message, to the 'receptor' 104 to relinquish the matching parameters used for channelization (Step 1). 'Receptor' receives the message at its end 10 and sends a teardown protocol acknowledgment message for relinquishing the matching parameters (Step 2). On receipt of the teardown acknowledgment message, the 'initiator' generates and sends a final teardown protocol command message from its end point 15 for relinquishing the matching egress and ingress parameters used for channelization (Step 3). 'Receptor' receives the teardown final protocol command message for relinquishing the matching egress and ingress parameters and from its end 10 generates and sends a teardown final protocol acknowledgement message (Step 4). At the end of teardown protocol message exchanges, the LO ODU trail is bi-directionally torn down and the network resources UID, TPN and TS are freed up by both the nodes 103 and 104.

The signaling and message format as shown with respect to figures 2a to 5 based on UID are exemplary.

The inventor further envisages achieving the signaling used for channelization with other signalling protocols which may be more optimal with respect to time consumption. As an example if the value of UID ranges from 1-80 similar to the range of values for TPN and Time-slots, an 80 bit message format can be used to do a more optimized signaling with lesser message exchanges. The 'initiator' node may send to the 'receptor' node an 80 bit message format where each bit represents the UID/TPN/TS i.e. the matching parameter to be agreed upon in that protocol session - UID or TPN or TS). A '0' bit value may mean that the parameter is available and a '1' value may mean that the parameter is not available. So, based on sending a single 80 bitmap message the 'initiator' publishes to the 'receptor' the available matching network parameters.

The 'receptor' based on the received bit map compares this available list with the list of values (network parameters) which are free at its own end. Hence, the 'receptor' will choose the values which are free at 'initiator' end and 'receptor' end and finally will send an 'ACK' value for these matching values. The 'initiator' responds 'ACK' for the matching values and hence based on the same, send a 'FINAL' message for agreement. In case, the receptor finds disagreement with the matching values sent by 'initiator; an 'ABORT' message is sent to the 'initiator' to end the entire process.

Figure 8 shows an exemplary embodiment of contention resolution mechanism for initiating channelization between nodes in accordance with the embodiments of the invention. An 'indication command' may be issued manually by a network operator or may be done automatically by a mechanism which senses the channelization requirements at the desired node which is reachable for such a trail setup. It is to be understood that an 'indication command' may be simultaneously issued to both the nodes (for e.g., 103 and 104) for initiating channelization.. In such cases it may happen that both the nodes (103 and 104) may simultaneously receive the 'indication command'. In such circumstances, both the nodes 103 and 104 function as 'initiator' and issue UID request protocol command message. Both the transmitted messages may either reach simultaneously for the respective nodes or may reach with a time lag. On a collision within each node, a 'random time back-off is triggered' which means that beyond a random threshold time limit (i.e, time-out) each node may subsequently issue UID request protocol command message if neither response to the already issued UID request protocol command message is received nor UID request protocol command message from other node is received within the threshold time. Random back-off time triggering may be different for each node, thus facilitating, one of the nodes to eventually receive UID request protocol command message before the time-out happens. The node that had received a UID request protocol command message from the other node before its 'time-out' functions as a 'receptor' and backs-off fully and aborts its further initiation of UID request protocol command message. The node whose UID request protocol command message reached the other node within the other nodes threshold timing (i.e., before time-out) functions as 'initiator'. The above explained contention resolution mechanism is exemplary and other possible means of resolving the choice of initiator node may be accomplished by identification of one parameter which makes a node superior over other node.

The bit format for the Type 1 (T1) channelization protocol command messages in accordance with the embodiments of the invention are shown in figure 9. Type 1 protocol control message for identifying and agreeing, UID, TPN and forTEARDOWN, ABORT, REMOTE TS SETUP, is a 4 bit control word as shown in the figure . Type 1 protocol command messages is carried in bytes corresponding to overhead row 4, columns 9, 10, 11, 12, 13, and 14 of an OTU frame. The other supporting messages apart from the control message i.e. -the UID value, TPN or NTs (number of time-slots in case the control word is REM SETUP TS REQ), ACK/NACK and CRC are carried in other bits as shown in the figure.

The bit format for Type 2 (T2) channelization protocol command messages in accordance with the embodiments of the invention are shown in figure 10. Type 2 protocol control message for identifying and agreeing on time-slots (TS) is a 3 bit control word as shown in the figure . Type 2 protocol command messages is carried in bytes corresponding to HO OPUk (K=2, 3, 4) overhead rows 1, 2 and 3 column 15 in an OTU frame. The other supporting messages apart from the control message i.e - the UID value, ACK/NACK and CRC are carried in other locations as shown in the figure. It must be noted that the time-slot value corresponding to the T2 protocol command messages in represented by the MFAS (multi-frame alignment signal) value carried in the OTU overhead.

Another embodiment of the invention relates to the implementation of the above described various embodiments using hardware and software. It is recognized that the various embodiments of the invention may be implemented or performed using computing devices (processors). A computing device or processor may for e.g., be general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, etc. The various embodiments of the invention may also be performed or embodied by a combination of these devices.

Further, the various embodiments of the invention may also be implemented by means of software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

It should be further noted that the individual features of the different embodiments of the invention may individually or in arbitrary combination be subject matter to another invention. It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.

We claim:

1. A method for channelization of lower order ODU trail inside a higher order ODU in an optical transport network (OTN) by steps comprising of:

Initiating protocol command messages in the data plane for the agreement of matching network parameters between nodes by the node receiving an indication command; and

Identifying matching network parameters wherein, network parameters include a unique identification
(UID) index, tributary port number (TPN) and time-slots (TS).

2. The method of claim 1 wherein, the node receiving an indication command functions as an initiator node and the other node functions as a receptor node and wherein the election of initiator node is based on contention resolution protocol message exchanges between nodes in case of simultaneous reception of indication command by both the nodes.

3. A method for tearing down channelization of lower order ODU trail inside a higher order ODU in an optical transport network (OTN) by steps comprising of;

Initiating protocol message exchanges for tearing down lower order ODU trail by the node receiving an indication command; and

Relinquishing the matching network parameters used for channelization, by the initiator and receptor node.

4. The method of claim 3 wherein, the node receiving an indication command functions as an initiator node and the other node functions as a receptor node and wherein the election of initiator node is based on contention resolution protocol message exchanges between nodes in case of simultaneous reception of indication command by both the nodes.

5. The method of claim 1 wherein, identifying matching network parameters further comprises of: Initiating protocol message exchanges for identifying and agreeing on a unique identification (UID) index between two nodes wherein, UID is an index for uniquely identifying a lower order ODU inside a higher order ODU;

Generating and sending out by the initiator node receiving the indication command, a UID request protocol command message to the receptor node;

Receiving the UID request protocol command message by the receptor node and sending out a protocol acknowledgment message, if the demanded UID is available at its end and sending out a protocol negative acknowledgment message by the receptor node, if the demanded UID is unavailable at its end;

Generating and sending out by the initiator node receiving the indication command, successive demand for UID request, until the required matching UID is achieved if a negative protocol acknowledgment message for the demanded matching UID is received from the receptor node;

Generating and sending out by the initiator node a UID final protocol command message, if protocol acknowledgment message for the demanded UID request is received from the receptor node;

Generating and sending out by the receptor node a UID final protocol acknowledgment message, if UID final protocol command message is received from the initiator node; and

Reserving the UID, identified by protocol message exchanges as unique identification index by both the initiator and the receptor nodes.

6. The method of claim 1 wherein identifying matching network parameters further comprises of:

Identifying and agreeing on matching egress and ingress Tributary Port Number (TPN) for the initiator node;

Identifying and agreeing on matching egress and ingress Tributary Port Number (TPN) for the receptor node;

Identifying and agreeing on egress and ingress matching time-slots for the initiator node; and

Identifying and agreeing on egress and ingress matching time-slots for the receptor node.

7. The method of claim 6 wherein identifying and agreeing on matching egress and ingress TPN further comprises of:

Generating and sending out by the initiator node receiving the indication command, an egress TPN request protocol command message to the receptor node;

Receiving the egress TPN request protocol command message by the receptor node and sending out a protocol acknowledgment message, if the demanded matching TPN is available at its end and sending out a protocol negative acknowledgment message by the receptor node, if the demanded matching TPN is unavailable at its end;

Generating and sending out by the initiator node receiving the indication command, successive demand for egress TPN request, until the required matching TPN is achieved if a negative protocol acknowledgment message for the demanded matching TPN is received from the receptor node;

Generating and sending out by the initiator node an egress TPN final protocol command message, if protocol acknowledgment message for the demanded egress TPN request is received from the receptor node;

Generating and sending out by the receptor node an egress TPN final protocol acknowledgment message, if egress TPN final protocol command message is received from the initiator node; Reserving the TPN thus identified by protocol message exchanges, as egress and ingress TPN by the initiator and the receptor nodes respectively; and

Generating and sending out by the initiator node a protocol command message to abort the entire protocol message requests, to its receptor node, if all the successive demand for egress TPN at its end is exhausted.

8. The method of claim 6 wherein identifying matching ingress and egress TPN further comprises of:

Generating and sending out by the initiator node receiving the indication command, an ingress TPN request protocol command message to the receptor node;

Receiving the ingress TPN request protocol command message by the receptor node and sending out a protocol acknowledgment message, if the demanded matching TPN is available at its end and sending out a protocol negative acknowledgment message by the receptor node, if the demanded matching TPN index is unavailable at its end;

Generating and sending out by the initiator node receiving the indication command, successive demand for ingress TPN request, until the required matching TPN is achieved, if a negative protocol acknowledgment message for the demanded matching TPN is received from the receptor node;

Generating and sending out by the initiator node an ingress TPN final protocol command message, if protocol acknowledgment message for the demanded ingress TPN request is received from the receptor node;

Generating and sending out by the receptor node an ingress TPN final protocol acknowledgment message, if ingress TPN final protocol command message is received from the initiator node;

Reserving the TPN, identified by protocol message exchanges, as ingress and egress TPN by the initiator and the receptor nodes respectively; and

Generating and sending out by the initiator node a protocol command message to abort the entire protocol message requests, to its receptor node, if all the successive demand for ingress TPN at its end is exhausted.

9. The method of claim 6 wherein identifying matching egress and ingress time-slots further comprises of:

Generating and sending out by the initiator node receiving the indication command, at least one matching time-slot request protocol command message to the receptor node;

Receiving the matching time-slot request protocol command message by the receptor node and sending out a protocol acknowledgment message, if the demanded at least one matching time-slot is available at its end and sending out a protocol negative acknowledgment message by the receptor node, if the demanded at least one matching time-slot is unavailable at its end;

Generating and sending out by the initiator node receiving the indication command, successive demand for matching time-slots request, until the required matching time-slots is achieved, if a negative protocol acknowledgment message for the demanded at least one matching time-slots is received from the receptor node;

Generating and sending out by the initiator node a final protocol command message, if protocol acknowledgment message for the demanded matching time-slots is received from the receptor node;

Generating and sending out by the receptor node a final protocol acknowledgment message, if final protocol command message is received from the initiator node;

Reserving the matching time-slots thus identified by protocol message exchanges, as egress and ingress time-slots by the initiator and the receptor nodes respectively; and

Generating and sending out by the initiator node a protocol command message to abort the entire protocol message requests, to its receptor node, if all the successive demand for time-slots available at its end is exhausted.

10. The method of claim 6 wherein identifying matching ingress and egress time-slots further comprises of:

Generating and sending out by the initiator node to the receptor node an 'indication command' for swapping the respective functional roles of initiator and receptor wherein, 'indication command' includes a remote time-slot setup request protocol command message for sending a matching time-slot request protocol command message;

Assuming the functionality of an initiator node on receiving the 'indication command' and generating and sending to the receptor node, at least one matching time-slot request protocol command message;

Receiving the matching time-slot request protocol command message by the receptor node and sending out a protocol acknowledgment message, if the demanded at least one matching time-slot is available at its end and sending out a protocol negative acknowledgment message by the receptor node, if the demanded at least one matching time-slot is unavailable at its end;

Generating and sending out by the initiator node, successive demand for matching time-slots request, until the required matching time-slots is achieved, if a negative protocol acknowledgment message for the demanded at least one matching time-slots is received from the receptor node;

Generating and sending out by the initiator node a final protocol command message, if protocol acknowledgment message for the demanded matching time-slots is received from the receptor node;

Generating and sending out by the receptor node a final protocol acknowledgment message, if final protocol command message is received from the initiator node;

Reserving the matching time-slots thus identified by protocol message exchanges, as ingress and egress time-slots by the receptor and the initiator nodes respectively; and

Generating and sending out by the initiator node a protocol command message to abort the entire protocol message requests, to its receptor node, if all the successive demand for time-slots available at its end is exhausted.

11. The method of claim 3 wherein, initiating protocol message exchanges for tearing down the lower order ODU trail and relinquishing the matching network parameters used for channelization as an initiator node further comprises of:

Generating and sending out by the initiator node a teardown request protocol command message to relinquish the matching network parameters used for channelization;

Receiving the teardown request protocol command message by the receptor node and sending out a protocol acknowledgment message for relinquishing the matching network parameters;

Generating and sending out by the initiator node a final teardown protocol command message for
relinquishing the matching egress and ingress network parameters used for channelization at its end;

Receiving the teardown final protocol command message by the receptor node and sending out a final protocol acknowledgement for relinquishing the matching egress and ingress network parameters used for channelization at its end; and

Relinquishing all the network resources reserved as matching parameters comprising of unique
identification (UID) index, egress and ingress TPN, egress and ingress time slot (TS) by the initiator and receptor nodes respectively.

12. An OTN node comprising of:

An electronic component for configuring the node, upon its receiving an indication command for performing the functions of identifying and agreeing on matching network parameters, remote setup and teardown protocol command message as an initiator node;

An electronic component for configuring the node, as a receptor node for performing the functions of responding to protocol command messages from the initiator node for identifying and agreeing on matching network parameters, remote setup and teardown as a receptor node;

A transceiver for communicating protocol command messages for identifying and agreeing on matching network parameters, remote setup and teardown as an initiator node and for performing the functions of responding to protocol command messages from the initiator node for identifying and agreeing on matching network parameters, remote setup and teardown as a receptor node; and

A memory for retaining instructions for executing functions associated with the transceiver and the electronic component, as well as measured or computed data that may be generated during executing such functions.