Abstract:
A method for managing transport node capability information includes discovering a link end of a local transport node, modelling the local transport node&#39;s capability information as a first set of information structures, discovering a neighbour transport node, establishing a control adjacency link between control elements of the local transport node and neighbour transport node, modelling the neighbour transport node&#39;s capability information as a second set of information structures, exchanging the first and second sets of information structures between the control elements and identifying potential network layer links between the local and neighbour transport nodes, based on correlations in the first and second sets of information structures.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is a continuation-in-part application of U.S. application Ser. No. 11/374,355, filed Mar. 13, 2006, and entitled “METHOD AND SYSTEM FOR MULTI-LAYER NETWORK ROUTING” and, that application is incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention pertains to communications networks. More particularly, the invention pertains to methods and apparatus for exchanging a transport node&#39;s network connectivity and capability information. 
       BACKGROUND OF THE INVENTION 
       [0003]    The Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) has provided a Recommendation G.7714 which describes Transport Entity Capability Exchange (TCE) as a process that follows Layer Adjacency Discovery. A carrier protocol state machine is defined for TCE, and some information included in TCE is listed, but the information content of particular TCE exchanges is not addressed in detail. There are plans for ITU-T Recommendation G.7716 (or related recommendations) to specify initialization of ASON systems. Accordingly, it is useful to develop methods and apparatus to manage the information required to initialize links and protocol relationships which may be included in these recommendations. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0004]      FIG. 1  illustrates a system for exchanging a transport node&#39;s capability information, according to an example embodiment of the invention; 
           [0005]      FIG. 2  illustrates discovery agent system, according to an example embodiment of the invention; 
           [0006]      FIG. 3  is a flow diagram of a method which may be performed by a discovery agent, upon the discovery of a link end on a transport node, according to an example embodiment of the invention; 
           [0007]      FIG. 4  illustrates a G.805 modelling that corresponds to the transport nodes shown in  FIG. 1 , according to an example embodiment of the invention; 
           [0008]      FIG. 5  illustrates a general connectivity block, according to an example embodiment of the invention; 
           [0009]      FIG. 6  illustrates general connectivity blocks which model the transport nodes shown in  FIG. 4 , according to an example embodiment of the invention; and 
           [0010]      FIG. 7  is a flow diagram of method for generating Connectivity Attribute Groups for an interface associated with a discovered adjacency, according to an example embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0011]    Example embodiments of the invention include methods and apparatus for an information model for the exchange of layer network connectivity and adaptation capabilities at the ends of a discovered adjacency. This model allows Transport Entity Capability Exchange (TCE) or other exchange of transport node capability information to be accomplished without requiring that the details of the layer network technologies supported be understood at both ends of the adjacency. 
       Generation and Correlation of Transport Node Capability Information 
       [0012]    A transport node may provide flexibility in more than one layer of network. Accordingly, transport nodes at each end of a layer network adjacency may provide various network connectivity and capabilities (such as for example to cross-connect, terminate, or adapt a signal carried over a link that forms a layer network adjacency). Details of such transport node capabilities can be described as a transport node&#39;s capability information and such information may be transmitted over discovered link connection. It is useful for a control element associated with a transport node to understand the flexibility supported by a transport node in order to operate properly. In an example embodiment of the invention, to develop this awareness, a control element associated with the transport node has a discovery agent that becomes aware of the local (or also referred to as near) transport node&#39;s capabilities; exchanges capability information with the control element of a neighbour (or also referred to as far) transport node; correlates the common capabilities to determine the network layers that potential links exist in; and provides this information to a link resource manager associated with the local transport node. 
         [0013]      FIG. 1  illustrates a system for exchanging a transport node&#39;s network connectivity and capability information, according to an example embodiment of the invention.  FIG. 1  shows two Transport Nodes,  100  and  150 , connected to each other by equipment adjacency link  105 . Connected to Transport Node  100  is corresponding Control Element  140  and connected to Transport Node  190  is corresponding Control Element  190 . Control Elements  140  and  190  are connected to each other by control adjacency link  145 . 
         [0014]    In an example embodiment of the invention, Transport Nodes  100  and  150  flexibly support various different switching layers over the same interface through various switching and adaptation functions in each Transport Node. For instance, Transport Node  100  includes the example embodiment switching and adaptation functions: an Ethernet switching function  130 , an Ethernet to STS3c Adaptation function  122 , an Ethernet to STS1 Adaptation function  112 , an STS3c Termination function  121 , an STS1 Termination function  111 , an STS3c switching function  120 , an STS1 switching function  110 , an STSn to OC48 Adaptation function  104 , an STSn to OC48 Adaptation function  102 , and two OC48 Termination functions  103  and  101 . Transport Node  150  includes the example embodiment switching and adaptation functions: an Ethernet switching function  180 , an Ethernet to STS12c Adaptation function  172 , an Ethernet to STS3c Adaptation function  162 , an STS12c Termination function  171 , an STS3c Termination function  161 , an STS12c switching function  170 , an STS3c switching function  160 , an STSn to OC48 Adaptation function  152 , an STSn to OC48 Adaptation function  154 , and two OC48 Termination functions  151  and  153 . In each of the above listed adaptation functions, a signal can be adapted from one format (e.g. Ethernet) to another format (e.g. STS3c), using methods known to those skilled in the art. Furthermore, it can be understood to those skilled in the art that that other types of switching and adaptation functions may be included in example embodiment transport nodes. 
         [0015]    In an example embodiment of the invention, a Control Element includes a Link Resource Manager ( 143  or  193  in  FIG. 1 ), connected to a Discovery Agent ( 143  or  193  in  FIG. 1 ), which is connected to a Termination/Switch Configuration Manager ( 143  or  193  in  FIG. 1 ). Control Elements  140  and  190  utilize the Discovery Agents  142  and  192  which identify the flexibility that is provided at a link end (a port or other equipment interface at the end of an equipment adjacency link) (such as equipment interfaces  101  and  151 ) as well as further switching capabilities made accessible by adaptation functions (such as adaptation functions  112 ,  122 ,  102 ,  104 ,  172 ,  162 ,  152 , and  154 ). Discovery Agents  142  and  192  access this information from the Termination/Switching Configuration Managers,  141  and  191  respectively. Discovery Agents  142  and  192  further communicate with each other over control adjacency link  145  to determine the useable capabilities of Transport Nodes  100  and  150  (e.g. STS3c and Ethernet) and identify the network layers in which potential links may exist. Discovery Agents  142  and  192  may communicate those potential links to their respective Link Resource Managers  143  and  193 . 
         [0016]    In an example embodiment of the invention, a Discovery Agent is may be made up of a number of subagents, each taking on roles identified by Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) Recommendation G.7714 (hereinafter referred to as “G.7714”). In the example embodiment shown in  FIG. 2 , Discovery Agent  200  is made up of a Transport Capability Correlation function  204 , a Transport Entity Capability Exchange function  203 , a Link Discovery function  202  and a Local Transport Node Capability Discovery function  201 . As a Local Transport Node Capability Discovery function discovers a link end and other resources (e.g. common or shared service functions) on a transport node, the method shown in  FIG. 3  may be invoked, once for each link end. 
         [0017]      FIG. 3  is a flow diagram of a method which may be performed by a discovery agent, upon the discovery of a link end on a local Transport Node, according to an example embodiment of the invention. At  301 , the local Transport Node&#39;s capability information is captured through the generation of multiple Connectivity Attribute Group (CAG) information structures. At  302 , layer adjacency discovery is performed and Discovery Agent agency is established. (This can be accomplished for example by a Link Discovery function (such as  202  of  FIG. 2 ) being notified of the link end and the Link Discovery function attempting to discover transport node adjacencies (or in other words a neighbour Transport Node connected to the local Transport Node by an equipment adjacency link) using the test and/or trace methods described in G.7714. Once a transport node adjacency has been identified, a control adjacency link (e.g.  145  of  FIG. 1 ) is established with the Discovery Agent of the neighbour Transport Node.) (At this time or before the control adjacency link is established, the neighbor Transport Node&#39;s capability information is captured through the generation of multiple Connectivity Attribute Group (CAG) information structures.) At  303  and  304 , the local Transport Node&#39;s capability information is transmitted to the neighbour Transport Node over the established control adjacency link and the neighbour Transport Node&#39;s capability information is transmitted to the local Transport Node over the established control adjacency link. (This can be performed for example by a Transport Entity Capability Exchange function (such as  203  of  FIG. 2 ) at each transport node&#39;s Discovery Agent.). At  305  and  306 , the locally generated CAGs and the CAGs received from the neighbour transport node are examined to correlate the network layers supported and identify network layers with potential links. (This can be performed for example by a Transport Capability Correlation function (such as  204  of  FIG. 2 ) at each transport node&#39;s Discovery Agent.) At  307 , the Discovery Agents at each transport node communicates any potential links to the respective Link Resource Managers. 
         [0018]    The set of CAGs describe the possible forms of flexible connectivity, and may be generated using a general connectivity model as described below. 
       Use of a General Connectivity Model 
       [0019]    In example embodiments of the invention, a General Connectivity Model is used to describe the relationships between International Telecommunication Union Recommendation G.805 (hereinafter referred to as “G.805”) Functional Modelling Components (shown in the legend of  FIG. 4 ) which may exist within a node. 
       G.805 Functional Modelling 
       [0020]    In an example embodiment of the invention, the General Connectivity Model includes a G.805 modelling for each Transport Node for which capability information is sought. An example G.805 modelling that corresponds to the Transport Nodes shown in  FIG. 1  is illustrated in  FIG. 4 . 
         [0000]    Modelling of Flexible Connectivity within a Transport Node, by a General Connectivity Block 
         [0021]    In an example embodiment of the invention, the General Connectivity Model includes a modelling of the flexible connectivity within a Transport Node. This flexible connectivity within a Transport Node can be represented by a general connectivity block with interface points toward (A) client layers, (B) server layers, (C) a switching function in the current layer, and (D) link connections to a neighbour node, according to an example embodiment of the invention. An example embodiment general connectivity block is shown in  FIG. 5 . ( FIG. 5  uses the G.805 Function Modelling Components defined in the legend of  FIG. 4 .) 
         [0022]    An example embodiment of the invention may describe transmit direction connectivity (e.g. from a switching function toward a link) using one or more of the following connectivity types: 
         [0023]    1) C-D: connectivity from a switching function to a link in this layer 
         [0024]    2) C-Bi: connectivity from a switching function to a server layer (Bi represents a particular server type and adaptation type, and there can be multiple server choices and multiple adaptation choices for a given server) 
         [0025]    3) C-A: connectivity from a switching function to a termination sink of this layer (leading to a client layer which may be identified, along with the adaptation type, by association with a Bi point on a connectivity block in the client layer) 
         [0026]    4) A-D: connectivity from a termination source to a link in this layer (the client signal type and adaptation type may be identified, along with the adaptation type, by association with a Bi point on a connectivity block in the client layer) 
         [0027]    5) B-D: connectivity from a server layer to a link in this layer 
         [0028]    6) A-Bix: connectivity from an termination source for this layer to a server layer in the transmit direction (‘x’ indicates transmit direction) 
         [0029]    7) B-Ax: connectivity from a server layer to a termination sink in this layer in the transmit direction 
         [0030]    8) C-C: connectivity from a switching function to the same switching function in this layer (this can be used, for example, for a service function in this layer that creates a new or improved copy, or generation, of the signal to be routed, e.g. a regenerator or retimer) 
         [0031]    9) Bi-Bjx: connectivity from one server layer to another server layer in the transmit direction (i may be the same as j in the case of a service function, as above, or i and j may be different representing a change from one server type to another or one adaptation type to another) 
         [0032]    An example embodiment of the invention may describe receive direction connectivity (e.g. from a link towards a switching function) by using one or more of the following connectivity types: 
         [0033]    10) D-C: connectivity from a link to a switching function in this layer 
         [0034]    11) D-A: connectivity from a link to a termination sink in this layer 
         [0035]    12) D-Bi: connectivity from a link to a server layer 
         [0036]    13) A-C: connectivity from a termination source to a switching function in this layer 
         [0037]    14) B-C: connectivity from a server layer to a switching function in this layer 
         [0038]    15) A-Bir: connectivity from a termination source in this layer to a server layer in the receive direction (‘r’ for receive direction) 
         [0039]    16) B-Ar: connectivity from a server layer to a termination sink in this layer in the receive direction 
         [0040]    17) Bi-Bjr: connectivity from a server layer to a server layer in the receive direction (again may be the same as j for regeneration, or different for a change in server type and/or adaptation type) 
         [0041]    Using these connectivity types, the transport capabilities provided by a node at one end of an adjacency can be described by providing information about available connectivity along with other attributes relevant to the connectivity. Example general connectivity blocks which model the Transport Nodes shown in  FIG. 4 , can be found in  FIG. 6 . ( FIG. 6  uses the G.805 Function Modelling Components defined in the legend of  FIG. 4 .) An example information structure for describing the transport capabilities at one end of an adjacency is described in the next section. 
       Modelling of Transport Capabilities at One End of an Adjacency Link, by a Connectivity Attribute Group 
       [0042]    In an example embodiment of the invention, the General Connectivity Model includes a modelling of transport capabilities at a link end (a port or other equipment interface at the end of an equipment adjacency link). Furthermore, the transport capabilities at each link end can be exchanged (using for example TCE) to enable characterization of the link(s) and other capabilities (e.g., layer transitions) made available by that adjacency. A modelling of transport capabilities can be organized around the general connectivity block concept described in the previous section. This can be done using the concept of a Connectivity Attribute Group (CAG) that contains information about the types of connectivity that a node supports at its end of an adjacency. 
         [0043]    A Connectivity Attribute Group represents a general connectivity block, and can be used to describe at least a portion of the connectivity and related attributes provided by each node at the end of a discovered adjacency.  FIG. 7  provides an example embodiment method for generating Connectivity Attribute Groups for an interface associated with a discovered adjacency. 
         [0044]    TCE (or other exchange of transport node capability information) may use a set of CAGs, each of which represents the connectivity and related attributes available within a given network layer. An example embodiment CAG information structure may include one or more of the following:
       1. Signal Type: identifies a layer. There may be more than one CAG with a given Signal Type in an interface if necessary to properly convey the capabilities available.   2. CAG ID: identifies a CAG in the context of TCE. This ID must be unique within the scope of a link end.   3. CAG Entries: blocks of information, each conveying a connectivity type and associated attributes.       
 
         [0048]    A CAG Entry example embodiment may contain one or more of the following information:
       1. Connectivity Type: one of the seventeen connectivity types listed above in the general connectivity model.   2. Regeneration Flag: indicates whether or not the connectivity includes regeneration, that is, whether a new generation of the signal is created.   3. Routing Cost: (optional) the assigned cost of using this connectivity at this layer in a route. This information can be used in developing link advertisements based on the discovered adjacency. Multiple cost values may be provided for cases in which the cost policy can be selected or affected by routing constraints. Alternatively, the cost can be provided by other means (it is not required to be included in TCE).   4. Available Capacity: (optional) the available capacity of this connectivity. Often available capacity can be calculated based on a physical or TDM adjacency. In some cases, however, policy may dictate a reduction in the capacity allocated to particular types of connectivity. Capacity may be expressed, for example, in bits per second or as a number of predetermined resource partitions (e.g., number of timeslots or channels). To handle unidirectional cases, Available Capacity==0 (to show binding of B point to server CAG in cases in which x-B connectivity is not provided in equipment).   5. Next CAG ID: identifies the next CAG to visit in case of connectivity to an A, or B point. If the connectivity provided is to an A point, any of the B points in the Next CAG that have CAG entries that refer back to this CAG can be considered.   6. Adaptation Type: indicates the type of adaptation to the server layer for this connectivity type. This field applies to connectivity types toward B points. This value may be scoped by the Signal Type of this CAG (client layer) and the Signal Type of the CAG referenced by the Next CAG ID (server layer).   7. Capacity Conversion: (optional) indicates how capacity at this layer is converted to capacity at the server layer specified by this connectivity type. This field applies to connectivity types toward B points.       
 
         [0056]    If an interface is highly flexible (e.g. NPU based hardware designs) but has limits to the number of operations (e.g. layer transitions) that can be supported at any one time or for any particular flow, this constraint can be conveyed by providing the following:
       1. Maximum Operation Credits: the maximum number of operation credits that can be supported in one traversal of the link end. This information would be conveyed once for this end of an adjacency.   2. Operation Cost: the number of operation credits required to use the connectivity type in a given CAG Entry. This information would be included in each CAG Entry.
 
Given this additional information it is possible to determine which combinations of connectivity can be supported at one end of an adjacency for a given connection or flow. An example set of the CAGs generated from the Connectivity Blocks shown in  FIG. 6  can be found in  FIG. 8 .
       
 
       Exchange of a Transport Node&#39;s Capability Information 
       [0059]    Using the information described in the previous section, the two ends of an adjacency can exchange transport capabilities and evaluate the potential links and layer transitions supported by that adjacency. This evaluation can be accomplished without specific knowledge of the technologies involved. Signal type and adaptation type information, along with the CAG IDs, allow a generic algorithm to determine where matching capabilities exist and what transport capabilities can be provided from one end of the adjacency to the other. This generic analysis is possible due to the symbolic nature of functional modelling (that is, exchanging information structured around the general connectivity model which is itself based on G.805 concepts). This analysis can be used to generate alternative proposals during Transport Capability Exchange and to provide a Link Resource Manager with information from which to characterize links and generate link sate advertisements (if, for example, a link state routing protocol is to be used). Example embodiments for the invention may be taken into consideration in ASON transport capability. 
         [0060]    In the foregoing description, the invention is described with reference to specific example embodiments thereof. The specification and drawings are accordingly to be regarded in an illustrative rather than in a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto, in a computer program or software, hardware or any combination thereof, without departing from the broader spirit and scope of the invention. 
         [0061]      FIGS. 3 and 7  are flow diagrams illustrating methods according to example embodiments of the invention. The techniques illustrated in these figures may be performed sequentially, in parallel or in an order other than that which is described. It should be appreciated that not all of the techniques described in the flow diagrams are required to be performed, that additional techniques may be added, and that some of the illustrated techniques may be substituted with other techniques. 
         [0062]    Software embodiments of the invention may include an article of manufacture on a machine accessible or machine readable medium having instructions. The instructions on the machine accessible or machine readable medium may be used to program a computer system or other electronic device. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks or other type of media/machine-readable medium suitable for storing or transmitting electronic instructions. The techniques described herein are not limited to any particular software configuration. They may find applicability in any computing or processing environment. The terms “machine accessible medium” or “machine readable medium” used herein shall include any medium that is capable of storing, encoding or transmitting a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methods described herein. Furthermore, it is common in the art to speak of software, in one form or another (e.g., program, procedure, process, application, module, unit, logic, and so on) as taking an action or causing a result. Such expressions are merely a shorthand way of stating that the execution of the software by a processing system causes the processor to perform an action to produce a result.