Method and system of providing improved network management data between a plurality of network elements and a management system for increasing a flow and decreasing an amount of data transfer6477566Abstract In a management system of a communications network comprising a plurality of network elements, capacity and capability of one or more individual network elements is represented by a set of data templates. A first set of data templates represent internal construction and physical resources of a network element. A second set of templates represent connectivity capabilities of the physical resources. The data templates are stored at an element controller, controlling a plurality of network elements. The element controller learns about the capacity and capabilities of the network elements, by receiving a set of reference messages generated by the network elements, over an operations, administration and maintenance channel. The reference messages point to the data templates stored at the element controller thereby enabling efficient enrollment of network elements by transmission of compressed messages over the operations, administration and maintenance channel. Claims What is claimed is: Description FIELD OF THE INVENTION
struct xdr_tmcom_tp_details (
xdr_tmcom_tp_type tp_type;
xdr_tmcom_tp_type_qualifier tp_qualifier;
xdr_tmcom_tp_sub_type tp_sub_type_list< >;
);
struct xdr_tmcom_ttp_template (
xdr_tmcom_tp_details
ttp_details;
xdr_tmcom_directionality
Trail Termination Point (TTP) Template Referring to FIG. 9 herein there is illustrated terminology for describing a trail termination point at a layer of a synchronous digital hierarchy network. An end to end trail may be described by assembling a plurality of such trail termination points. Although the example of FIG. 9 herein is described specifically with respect to a SDH environment, the naming scheme illustrated by FIG. 9 is applicable more generally to ports operating other protocols having terminations and layers. For example the North American Synchronous Optical Network (SONET) protocol, or the asynchronous transfer mode (ATM) protocol in which there are adaptation layers, virtual circuits and virtual paths. In a naming scheme according to a specific method of the present invention, internal capabilities of physical resources of a communications network are described by way of a trail termination point template 900. A naming scheme for such a template is as follows: Triangle symbol 901 represents a trail termination point, either bi-directional or uni-directional. Quadrilateral symbol 902 represents an adaptation layer, either bi-directional or uni-directional. Symbol 903, an irreducible composite of symbols 901 and 902, represents that an adaptation is always associated with a termination point. Inverted semi-ellipse symbol 904 represents an entry connection function from a client layer into an adaptation represented by symbol 901. Semi-ellipse symbol 905 represents an exit connection function from trail termination point 902. The trail termination point template illustrated in FIG. 9 herein comprises an irreducable segment for describing a trail termination point within a port. The assembly of entry connection function 904, adaptation layer 901, trail termination point 902 and exit connection function 905 in the specific implementation herein recognizes a strict binding of functions represented by those symbols in a transport entity. In practice, these elements are always associated with each other and are never separate. A plurality of trail termination point templates 900 as illustrated in FIG. 9 may be assembled together to provide a comprehensive definition of internal structure and capability of a network element. A plurality of trail termination point templates are assembled into an end point template as described previously herein for describing a port type. The end point templates are reusable, and may be referenced by a plurality of ports of a same type within a network element. Elements represented by symbols 901-905 in FIG. 9 are further detailed as follows: In the following, description of the elements 901-905 is made with reference to the XDR language in which the templates are carried in the specific implementation herein. A trail comprises any circuit, line, path or section into which, at a first end, is inserted a data stream, and at a second end, is output the data stream. Within the trail, a data stream may be packaged into one or a plurality of frames or protocols, eg an STM frame, an ATM frame or a SONET frame. According to ITU-T recommendation G.803 a trail is defined as a "transport entity" in a server layer responsible for the integrity of transfer of "characteristic information" from one or more client network layers between server layer "access points". It defines the association between "access points" in the same "transport network layer". It is formed by combining a near end "trail termination" function, a "network connection" and a far end "trail termination" function. A trail termination point comprises an end point of a trail. According to ITU-T recommendation G.803 a trail termination is defined as a "transport processing function" which generates the "characteristic information" of a layer network and ensures integrity of that "characteristic information". The "trail termination" defines the association between the "access point" and "termination connection point" and these points therefore delimit the "trail termination". According to ITU-T recommendation G.805 a "trail" is defined as "a "transport entity" which consists of an associated pair of uni-directional trails" capable of simultaneously transferring information". A unidirectional trail is defined as "a "transport entity" responsible for the transfer of information from the input of a trail termination source to the output of a trail termination sink. The integrity of the information transfer is monitored. It is formed by combining trail termination functions and a network function. According to ITU-T recommendation G.805, a trail termination is defined as "a "transport processing function" that consists of a co-located trail termination source and synch pair". For example, a VC-12 trail comprises a route over which a VC-12 container envelope passes from source to destination, for example on entry to the VC-12 trail, the incoming data stream is packaged into a VC-12 envelope, and at the destination of the VC-12 trail, the data is recovered from the VC-12 container. A trail may traverse a plurality of physical or logical resources. A trail termination point 901 is represented as an object. Attributes of such an object comprise: termination point type (tp_type)--this attribute defines the type of trail termination point, for example a physical media section termination point, a regenerator section termination point, an optical section termination point, a multiplex section termination point, or a higher order path termination point, layer; a termination point qualifier (tp_qualifier)--data which qualifies the "type" data. For example where the type of termination point is a physical media section termination point, this may be qualified by further specifying that the transmission medium is fiber. In other cases, there may be no qualifiers, in which case a null value is entered as a tp_qualifier attribute. In other cases, for example where the type is a higher path (HP) the qualifier may specify a VC4 layer; a termination point sub-type list (tp_sub_type<0>)--an attribute comprising an ASCII text field describing further subsidiary details about the type of termination point. This attribute is optionally filled, and a null value may be entered. Adaptation element 902 comprises a set of adaptation rules describing adaptation between a self layer of a trail termination point and a client layer of the trail termination point. Adaptation as represented by quadrilateral symbol 902 is defined generically in ITU-T recommendation G.805 as "a "transport processing function" that consists of a co-located adaptation source and synch pair". Adaptation is defined in recommendation G.803 as "a "transport processing function" which adapts a server layer to the needs of a client layer. The "adaptation" function defines the server/client association between the "connection point" and "access point" and these points therefore delimit the "adaptation" function. "Adaptation" functions have been defined for many "client/server" interactions". Adaptation Rules The layer tree in each end point template specifies the types of trail termination point associated with a specific end point. Each layer of the tree adapts to the other layers by means of a set of adaptation rules. In the specific implementation herein, an example of a set of adaptation rules is represented by a set of parameters as follows:
struct xdr_tmcom_adaptation_rules (
xdr_tmcom_mapping_group_id mapping_group_id< >;
xdr_tmcom_adapta- adaptation_logic_list< >;
tion_rules_logic_list
);
Parameter Legal Range
ctp_group< > 0 for no parameter of default
1 or more ctp groups where rule
requires this parameter
type_of_connections_allowed 0 for no connection type or default
1 or more connection type where
rule requires this parameter
specific_cp_name< > 0 for no ctp or default
1 or more ctp where rules requires
this parameter
list_of_valid_points< > 0 where rule does not require
points
1 or more where rule requires this
parameter
specific_ttp_type< > 0 for no ttp of default
1 or more ttp where rule requires
this parameter
allowed_directionality where it differs from the TTP
broadcast_limit 1 where no broadcast
struct xdr_tmcom_adaptation_rules_logic_list (
unsigned long instances_of_mapping_com-
ponent;
unsigned long capacity< >;
xdr_tmcom_mapping_group_id mapping_component_structure;
xdr_tmcom_tp_details mapping-component_tp;
xdr_tmcom_adapter_rule_operator
relationship_to_next_rule)-
in_logic_list;
);
instances_of_mapping_component number of instances of the
mapping component
currently being defined.
mapping_component_structure describes the id of the
mapping group which this
layer adapts to.
capacity This value should be set to
NULL (empty list) for
SDH.
mapping_component_tp tp_details for this mapping
component.
Relationship_to_next_rule_in_logic_list logic operator describing
the relationship between
the current adaptor rule in
this layer and the next (if
any) adaptor rules in this
layer.
Enum xdr_tmcom_mapping_group_id (
xdr_tmcom_null_mapping_group_id,
xdr_tmcom_HP_VC4_TUGmap,
xdr_tmcom_HP_VC3_TUGmap,
xdr_tmcom_MS_AUGmap,
xdr_tmcom_TUG2,
xdr_tmcom_TUG3,
xdr_tmcom_ATM_VPmap,
xdr_tmcom_AUG
);
Value Description
0 Null mapping group
1 HP_VC4_TUGmap
2 HP_VC3_TUGmap
3 MS_AUGmap
4 TUG2
5 TUG3
6 ATM-VPmap
enum xdr_tmcom_adapter_rule_operator (
xdr_tmcom_null_adapter_rule_operator
xdr_tmcom_OR
xdr_tmcom_AND
;
A set of ends points referencing to a network element describe all the physical and logical ports available within that network element, ie the physical and logical resource capacity available in that network element, and for each end point, and end point template describes the vertical connectivity constraints of termination points of the corresponding port. End point templates describe intra-port connectivity and model inherent connectivity constraints within a port, eg as limited by hardware. Horizontal connectivity capabilities between different ports, at various different protocol levels is described by a set of inter end point connection rules specific to the network element. Such connection rules are referred to herein as CTP group templates. CTP Group Templates CTP group templates describe how end point templates are interconnected in terms of a set of connection rules. A set of end point templates, end point data and CTP group templates corresponding to a network element inter-relate with each other to give a detailed description of resources available within a network element, and the capabilities which they provide. The end point data, end point templates and CTP group templates describe all ports, including trail termination points at all layers within the ports. A single network element has one or a plurality of CTP groups. Each individual CTP group is represented as an instance of a CTP group template. A CTP group template comprises the following elements: A CTP group identifier which is unique to a specific CTP group template and describes the type and version of the CTP group template. The identifier comprises a group_number parameter and a group_name parameter. The group_number and group_name parameters are unique to a particular CTP group template and are not changed once allocated to that template. If a new CTP group template is created, then a new template identifier is allocated to that template. The group_name parameter provides a meaningful description of the template, for example "TN4x-STM4_all endpoints_vers.sub.-- 1.sub.-- 1". Additionally, the template identifier comprises a vintage parameter (ctp_group_parser_vintage) which identifies the version of parser for which the CTP group template was written. The inter end point connection rules describe: connections between termination points of different ports at a same layer. Each connection termination point group comprises connection rules specifying connectivity of termination points at a same layer between different ports; and connections between groups of termination points at one layer and groups of termination points at other layers. Connections between termination points at one layer and termination points at other layers are described as a set of connection rules between groups of termination points. Connection rules are used at the connection termination points to describe which layer(s) a current layer may connect to. The connection rule express relationships between adapted trail termination points, and other trail termination points of a compatible layer, both inside the end point template and outside the end point template as appropriate. An example of a set of connection rules used in the specific implementation herein, various ones of which may be used internally within end point templates, and various ones of which may be used in CTP groups, externally of end point templates is as follows:
Parameter Comments
connection_rule Rule for connectivity
rule_parameter_list 0 for entries with no parameters, 1 for entries with
parameters
enum xdr_tmcom_connection_rule_name (
xdr_tmcom_must_not_connect_to_
ctp_in_group,
xdr_tmcom_may_connect_to_any_
ctp_in_group,
xdr_tmcom_may_connect_to_any_
ctp_on_one_to_one_basis_in_group,
xdr_tmcom_use_ctp_group_rules,
xdr_tmcom_must_connect_to,
xdr_tmcom_must_not_connect_to,
xdr_tmcom_may_connect_to,
xdr_tmcom_must_be_connected,
xdr_tmcom_may_connect_to_self,
xdr_tmcom_broadcast_limit,
xdr_tmcom_connects_externally,
xdr_tmcom_reversion_supported,
xdr_tmcom_reversion_always_enabled,
xdr_tmcom_protection_switch_state_not_controllable,
xdr_tmcom_protection_switch_always_auto,
xdr_tmcom_protection_switch_always_manual,
xdr_tmcom_supports_only_subnetwork_protection,
xdr_tmcom_supports_only_path_protection,
xdr_tmcom_supports_path_and_subnetwork_protection,
);
parameter(s)
from
xdr_tmcom_rule.sub.--
connection rule name parameter comments
xdr_tmcom_must.sub.-- one or more If no group name then it
not_connect_to.sub.-- ctp_group assumes all groups that
ctp_in_group the end point belongs to
xdr_tmcom_may.sub.-- one or more If no group name then it
connect_to_any.sub.-- ctp_group assumes all groups that
ctp_in_group one or more the end point belongs to
specific_ctp_name
AND/OR
list_of_valid_points
AND/OR
type_of_connection
s_allowed
xdr_tmcom_may.sub.-- one or more If no group name then it
connect_to_any.sub.-- ctp_group assumes all groups that
ctp_on_one_to.sub.-- one or more the end point belongs to
one_basis_in_group, specific_ctp_name
AND/OR
one or more
specific_ttp_type
AND/OR
list_of_valid_points
AND/OR
type_of_connection
s_allowed
xdr_tmcom_use.sub.-- -- Used in end point
ctp_group_rules templates. Assumes that
all ctp groups identified
in the end point
(template)
should be used. If this
rule is not states then the
ctp group rules d not
apply and connectivity is
only possible in the end
point.
xdr_tmcom_must.sub.-- one or more Assumes that connection
connect_to, specific_ctp_name is a 1:1 for all payload
AND/OR elements adapted from
one or more the layer unless stated (ie
specific ttp_type may be stated in bulk at
AND/OR the layer or in detail in
list_of_valid_points client layer terminology
AND/OR if in detail then all
type_of_connection connections must be
s_allowed stated). More than one
ctp can be stated for
protected connections.
Can be used between
end points in special
cases but normally used
within end point
templates. Valid points
indicated to force
specific connection
orientation.
xdr_tmcom_must.sub.-- one or more
not_connect_to specific_ctp_name
AND/OR
one or more
specific_ttp_type
AND/OR
type_of_connection
s_allowed
xdr_tmcom_may.sub.-- one or more Assumes that connection
connect_to specific_ctp_name is a 1:1 for all payload
AND/OR elements adapted from
one or more the layer unless sated (ie
specific_ttp_type may be stated in bulk at
AND/OR the layer or in detail in
list_of_valid_points the client layer term-
AND/OR inology). Can be used
type_of_connection between end points in
s_allowed special cases but
normally used
within end point
templates
xdr_tmcom_must.sub.-- -- If several choices of
be_connected connection (via other
rules but one of the
choices must be used).
xdr_tmcom_may.sub.-- -- Allows for uni-direct-
connect_to_self ional restrictions.
Would be stated if a uni-
directional connection
could be performed
between rx and tx of the
same Connection
Termination Point
xdr_tmcom.sub.-- broadcast_limit If unidirectional
broadcast_limit connctiona then should
be 1 unless broadcast is
allowed in which case
this will be limit unless
no limit in which case
should be set to
maximum value
xdr_tmcom.sub.-- -- Goes outside this NE
connects_externally (only for PMS).
xdr_tmcom.sub.-- connection type, allows the MOA to
reversion_supported connection points, indicate that a particular
directionally CTP group or end point
can support revertive
connections. Connection
points parameter used to
distinguish between a
switch and b switch if
necessary.
xdr_tmcom.sub.-- connection type, only used in conjunction
reversion_always.sub.-- connection points, with reversion_sup-
enabled directionality ported, allows the MOA
to indicate that a
particular CTP group or
end point can
support revertive
connections. Connection
points parameter used to
distinguish between a
switch and b switch if
necessary.
xdr_tmcom.sub.-- connection type, allows the MOA to
protection_switch.sub.-- connection points, indicate that a particular
state_not.sub.-- directionality CTP group or end point
controllable does not support control
of a protection switch
position. Only used
where connection type
could support protection.
Connection points
parameter used to
distinguish between a
switch and b switch if
necessary.
xdr_tmcom.sub.-- connection type, allows the MOA to
protection_switch.sub.-- connection points, indicate that a particular
always_auto directionality CTP group or end point
only supports automatic
protection switching (not
manual). Only used
where connection type
could support protection.
Connection points
parameter used to
distinguish between a
switch and b switch if
necessary.
xdr_tmcom.sub.-- connection type, allows to MOA to in-
protection_switch.sub.-- connection points, dicate that a particular
always_manual directionality CTP group or end point
only supports manual
protection switching (not
auto). Only used where
connection type could
support protection.
Connection points
parameter used to
distinguish between a
switch and b switch if
necessary.
xdr_tmcom.sub.-- --
supports_only_sub
network_protection
xdr_tmcom.sub.-- --
supports_only_path.sub.--
protection
xdr_tmcom.sub.-- --
supports_path_and.sub.--
subnetwork.sub.--
protection
struct xdr_tmcom_rule_parameter (
xdr_tmcom_ctp_group_id ctp_group< >;
xdr_tmcom_connection_type type_of_connections.sub.--
allowed< >;
xdr_tmcom_universal_location specific_ctp_name< >;
xdr_tmcom_connection_points list_of_valid_points< >;
xdr_tmcom_tp_details specific_ttp_types< >;
xdr_tmcom_directionality allowed_directionality< >;
long broadcast_limit;
);
An example of parameters describing a list of CTP groups may be as follows:
struct xdr_tmcom_ctp_group_list (
xdr_tmcom_ctp_group_id ctp_group;
unsigned short instance_of_ctp_group;
);
The template set of the specific implementation herein may have a number of advantages over prior art ways of describing network elements as follows: Firstly, within recommendation G.774, individual transport layers tend to be floated, so that they are not specifically numbered to any particular port in a network element. However, the specific implementation herein provides a method of linking transport layers. Secondly, in the abstract syntax notation one (ASN1) model relationship in ITU-T recommendation X.208, models are described by data specification. In contrast, in the present specific implementation, models are prescribed by way of specific inheritance. Referring to FIG. 10 herein, there is illustrated a simple example of how a first port 1000 of a first network element is represented by a first end point template 1001, and second and third ports of a second network element 1002 are represented by second and third end point templates 1003, 1004 respectively and how connectivities between the three ports are represented. Connection termination points 1005, 1006 at each of respective second and third end points 1003, 1004 are illustrate. Each of the end point templates 1001, 1003, 1004 comprise assemblies of trail termination point templates at different layers within a port as described with reference to FIG. 9. Each end point template type describes a different type of pre-configured structure within a network element, eg a physical port type, or a particular logical port type. Interconnectivity between different network elements is catered for by an external connection rule identified schematically as link 1007 in FIG. 10. Referring to FIG. 11 herein, there is illustrated schematically a relationship between connection termination point groups and end point templates for a plurality of ports of a single network element. FIG. 11 shows a relationship between 4 individual ports. In practice, a network element may have many more ports. The network element comprises first and second aggregate ports AggA, AggB respectively, each of which are represented by a separate instance of a common aggregate template 1100, an STM-1 tributary port represented by an STM-1 tributary end point template 1101, and a 2 Mbits/s tributary port represented by 2 Mbits/s tributary end point template 1102. The representation of FIG. 11 of the AggA and AggB end point template represent instances of enrolment of ports AggA and AggB. Ports AggA and AggB share a common single aggregate end point template 1100. The STM tributary port enrols with STM-1 tributary end point template 1101 and the 2 Mbits/s tributary port enrols at element controller 606 with 2 Mbits/s tributary end point template 1102. End point data representing ports AggA and AggB also include a reference identifier to a first CTP group template (Agg CTP group) 1103. End point data referring to the STM-1 tributary port and the 2 Mbits/s tributary port include reference identifiers pointing to a second CTP group template 1104 (trib CTP group). In this example, the trib CTP group 1104 may include a connection rule which specifies that no port enrolled with the trib CTP group 1104 can connect to any other port also enrolled with the trib CTP group 1104, and contains a second rule specifying that any port enrolled with trib CTP group 1104 may connect with any port enrolled with Agg CTP group 1103. This connection rule is indicated by single-ended arrow 1105 in FIG. 11. Agg CTP group 1103 includes a connection rule within the group indicating that a 1:1 connection between any ports within the Agg CTP group is permissable. Also, Agg CTP group 1103 contains a connection rule specifying that any port enrolled with Agg CTP group 1103 can connect on a 1:1 basis with any port enrolled in trib CTP group 1004 (indicated by arrow 1106). Thus, for the example shown in FIG. 11 no connections are available between ports enrolled with the trib CTP group, 1:1 connections are available for ports enrolled with the Agg CTP group 1103, and any port enrolled with the Agg CTP group 1103 can connect with any port enrolled with the trib CTP group 1104. This combination of end point templates and CTP group templates represents the multiplexer network elements connectivity within the network management system. Thus, an external application, eg an auto router may use the template representation stored in the network management system to learn about the capabilities of the multiplexer network element having AggA, AggB, STM-1 tributary and 2 Mbits/s tributary ports. Referring to FIGS. 12 to 18 herein, there will now be described an example of a single end point template for a STM-4 tributary port for a type TN4X multiplexer network element. The STM-4 tributary port comprises one of a plurality of ports within a multiplexer. In FIG. 12, an end point template comprises a plurality of trail termination point templates connected to each other in accordance with connection rules as hereinbefore described. Each trail termination point template represents an instance of a termination point within a layer of a protocol. Capabilities of a port are represented by representing the trail termination points at different layers in that port by an assembly of TTP templates. One TTP template represents an instance of a trail termination point within a port. In FIG. 12, a first end point 1200 represents a connection to a physical media section layer in an SDH environment. A second end point 1201 represents a connection termination point to a higher path virtual container for (HP VC4) layer. Trail termination points are represented by triangles, layer adapters are represented by quadrilaterals, and connection termination points between layers are represented by semi-ellipses as described with reference to FIG. 9 herein. A trail termination point to a VC4 layer is described by connection rules represented by a semi-ellipse 1202 as shown in FIG. 12, and access to a 2 MHz clock is described by connection rules represented by inverted semi-ellipse symbol 1203. Trail termination points at the physical media section, optical section, regenerator section STM-4 level, multiplex section STM-4 layer and higher path VC4 layer are represented by corresponding respective trail termination point templates 1204-209. The optical section 1205 may access a tributary section 1209 via connection rules 1210, allowing access to the optical section by a 2 Mbits/s tributary. In FIGS. 13 to 18, there is illustrated a set of TTP templates comprising the end point template of FIG. 12 coded in external data representation (XDR) language. In the best mode herein, XDR allows platform independence of data templates as between the network manager and the element controller. Referring to FIG. 13 herein, there is illustrated an example of a trail termination point template of a trail termination point of a port at a physical media section layer. Connection rules represented by semi-ellipse 1300 comprise rules describing external connection of the physical media section to other ports in a same layer, ie in the physical media section layer. A trail termination point of the port at the physical media section, represented by triangle symbol 1301 is described by trail termination point data parameters 1302. Detail parameters specify a layer of the termination point as a physical media section layer and that the termination point is connected to fiber transmission medium. Adaptation between the physical media section layer and a higher client layer as represented by adaptation quadrilateral symbol 1303, is described by a set of adaptation rules 1304. Connection rules represented by inverted semi ellipse 1305 comprise rules specifying connection to other termination points in a client layer, other than the own layer of the termination point represented by triangle symbol 1301. A connect_extemally rule within connection rules 1300 represents a special case connection rule which extends outside the end point template and represents a connection between a port represented by the data template and one or more other ports. Termination point data 1302 includes an sub_type_list field comprising a set of ASCII characters for containing additional parameters and type details of the termination point. Such additional characters may describe that the termination point supports a path trace capability. This may be included as for example path_type=pathtrace and parameter_value=supported.sub.-- 16 bytes or similar parameters. Trail termination point data 1302 comprises a complete definition of the trail termination point. Any special characteristics of the trail termination point other than its layer are described in the sub_type field. The data describing the termination point stored in the sub_type field represents features of the port which describe its capabilities. For example a capability may be supporting the path trace functionality. An external application using the termination point data 1302 for planning a service may use the capability information described in the trail termination point data to check for compatibility of connectivity between different ports. For example if a first end point template type shows a trail termination point supporting a path trace function, but a second end point template type shows a termination point not supporting path trace, then an external management application may be able to determine that the first and second end point template types are incompatible with each other in respect of the path trace capabilities supported by one end point template, but not the other. Adaptation rules 1304 describe which other termination points the trail termination point (physical media section fiber trail termination point) is capable of mapping to. In the specific implementation described herein, using an XDR message set, adaptation rules 1304 comprise a logic list (adaptation_logic_list), the function of which is described with reference to FIGS. 17 and 18 herein. Whilst in the specific implementation shown herein the message set used is UNIX XDR, the termination point data 1302, own layer connection rule data 1301, client layer connection rule data 1306 and adaptation rule data 1304 are independent of the message set used, and in other implementations may be encoded in the known CORBA interface description language (IDL) or the known ASN1-GDMO message set. Client layer connection rules 1306 provide a set of rules describing connection of the termination point to a client layer. Client layer connection rules 1306 are arranged in a similar structure to own layer connection rules 1301 in layout, and specify connection termination point groups to which the termination point may belong (ctp_group), (specific_ctp_name). Within the same end point template as shown in FIG. 12, there are own layer connection rules of a higher trail termination point template (optical section trail point template 1205) which correspond with the client layer connection rules 1306 of the physical media section trail termination point template of FIG. 13. Referring to FIGS. 17 and 18, there is illustrated adaptation rule data 1800 for a higher order path VC-4 layer trail termination point template (FIG. 17) which illustrates a complex set of adaptation rules describing an SDH payload 1801. The SDH payload has tributary unit groups (TUG-3) as shown in FIG. 5 herein which map to seven TUG-2's or a VC-3, and each TUG-2 maps to three VC-12's, or a VC-2. Since not all multiplexers support the full mapping, restrictions within the multiplexer may be described by the adaptation rules 1800. Further, although in this implementation adaptation rules 1800 are shown as supporting an SDH payload, the adaptation rules may be altered to support 64 Kbits/s where thirty 64 Kbits/s map into a 2 Mbits/s tributary. The adaptation rules comprise a means of specifying an adaptation tree structure, for example as shown in FIG. 5 herein, supported by a port. The adaptation rules comprise an adaptation logic list which sets out a tree structure of possible adaptations between layers in a protocol, for example the SDH protocol as shown in FIG. 18 herein. Mapping groups, eg TUG-2, TUG-3) are listed with corresponding respective instances of mapping components and identifications of mapping groups (mapping_group_id) and mapping component termination points (mapping_component_tp). This adaptation rule structure may be used to describe adaptations of other protocols, eg SONET or ATM. Referring to FIGS. 6 to 8 herein, there will now be illustrated in general overview an example of a mode of operation of initialization of a managed object base of network manager 607, eg on first installation of one or a plurality of network elements, or following a fault condition. Element controller 606 controlling network elements 600-605, on initialization or re-initialization of a network, reports to network manager 607 all of the network elements 600-605 under its control. The following simplified example assumes that a set of end point templates and CTP group templates have been installed during manufacture on each of the newly introduced network elements 600-605 in the network, and that initially the templates are not separately loaded into the element controller 606. For example, supposing network element 604 comprises a TN-1X type multiplexer, storing a first end point template A describing a first port type, and second network element 605 comprises a further TN-1X multiplexer storing a second end point template B describing a second type of port, and third network element 601 comprises a TN-16X multiplexer storing a third end point template type C describing a third port type, the first time that the network elements are introduced into the network, they transmit by way of a message signal over the operations administration and maintenance channel to element controller 606 the full end point templates, ie end point templates A, B and C, by way of enrol messages between the network elements 601, 604, 605 and the element controller 606. Element controller 606 stores the three different types of end point template, A, B, C. Since in an SDH environment each of network elements 601, 604, 605 are configured in a layered manner, each end point template type describes the number of termination points at a corresponding port type at different layers which are mandatorily bound together. This information is sent from the network elements to the element controller once only, on first introduction of the network element to the element controller as end point templates A, B, C. These end point templates may be arbitrarily assigned numbers, for example 1001, 1002, 1003 when stored in the element controller 606. Similarly, CTP group data describing the inter-connections between ports are each of the layers is transmitted from the network elements to the element controller once only, on first introduction of the network elements to the element controller. Each port of the network element then enrols at the element controller by sending a corresponding respective end point data to the element controller. Within a single end point message from the network element, is contained all the end point data for each of a plurality of ports on a card. Each card of a network element may enrol with a separate end point message. An end point data indicates which template type the port corresponds to, and data describing the location of the port, ie on which network element it resides. Within the element controller, there is then instantiated each of the objects within the indicated end point template type for that particular enrolled port. There will now be described communications between network manager 607 and element controller 606 on initialization of the network management system. On initialization of the network management system, the network manager interrogates each element controller in order to discover the capabilities of the network elements comprising the network. The end point templates are transmitted from the network elements to the element controller once only. Communication between the network manager and the element controller in the best mode implementation herein is by way of XDR messages across TCP/IP communication link. Although communications between a network manager and a single element controller are described herein, it will be understood that in the network having a plurality of element controllers, similar communications occur between the network manager and a plurality of other element controllers. Although the sequence of communications between the network manager and the element controller are described in this specific example in an initialization operation, during general operation of the network management system, the messages described hereafter may be generated at any time by a network operator at the network manager, or by a network operator at the element controller. Referring to FIG. 19 herein, the network manager obtains a list of network elements connected to a particular element controller by sending a request message to the element controller over the XDR interface. An example of such a message is xdr_tmmoa_get_any_list_t. The element controller responds by sending a separate message for each individual network element connected to the element controller, back over the XDR interface to the network manager. Such messages may take the form as follows: xdr_moatm_list_of_nes_t . . . xdr_moatm_list_of_nes_t(last), these being messages describing each network element connected to the element controller. Having learnt of the network elements by interrogating the element controller, the network manager may then send an end point request message over the XDR interface in order to obtain a list of the end points corresponding to each physical and logical port within each network element connected to the element controller. One end point per individual physical or logical port is transmitted from the element controller to the network manager. Using the XDR interface, a sequence of messages between the network manager and element controller in the specific implementations herein is illustrated with reference to FIG. 20 herein. The network manager issues an end point request signal in the form xdr_tmmo_get_endpoints_t. On receipt of this message, the element controller interprets this message as a request to transmit end points to the network manager, and proceeds to transmit a separate end point message for each end point of each network element connected to the element controller. All of the end points relating to a single element controller may be sent within a single XDR message from the element controller to the network manager. A format for an end point message over the XDR interface may take the following form: xdr_moatm_list_of_endpoints_t . . . xdr_moatm_list_of_endpoints_t(last) which contains information describing all end points of all network elements connected to the element controller. An example of a communication of end point data between the element controller and the network manager may be summarized as follows:
struct xdr_tmcom_endpoint_info (
xdr_tmcom_universal_location location< >;
xdr_tmcom_endpoint_template_id endpoint_template_id;
xdr_tmcom_ctp_group_list list_of_ctp_groups< >;
string ec_location< >;
string user_label< >;
);
Parameter Content
location location of the endpoint.
endpoint_template_id endpoint template identifier signifying which
template this endpoint belongs to.
list_of_ctp_groups list of CTP groups that this endpoint belongs to. If
the CTP groups have been defined in the endpoint
template then this parameter should be set to
NULL using a zero length list.
ec_location string identifier for the endpoint as described
above.
user_label user label for this endpoint.
Network manager 607 may learn about capabilities of network elements connected to element controller 606 by sending a message requesting end point templates from the element controller, over the XDR interface. An example of such a message is shown in FIG. 21 herein. Normally the network manager receives end point messages from the element controller. If it receives an end point message using an end point template reference identifier which it does not recognize, the network manager will request the corresponding end plate template from the managed object agent, to gain knowledge of the capabilities and capacities of those end points. Such a message may take the form xdr_tmmoa_get_endpoint_templates_t. Element controller 606 responds by sending data describing all end points relating to network elements to which it is connected back over the XDR interface to network manager 607. Such messages may take the form xdr_moatm_list_of_endpoint_templates_t . . . xdr_moatm_list_of_endpoint_templates_t(last). An example of a message between the network manager and the element controller, describing an end point template is as follows:
struct xdr_tmcom_endpoint_template (
xdr_tmcom_endpoint_template_id endpoint_template_id;
xdr_tmcom_directionality directionality
xdr_tmcom_ctp_group_list list_of_ctp_groups< >;
unsigned long number_of_instances.sub.--
of_ctp;
xdr_tmcom_ttp_template list_of_ttp_templates< >;
);
An example of an identification parameter of the message is as follows:
struct xdr_tmcom_endpoint_template_id (
unsigned long xdr_tmcom_endpoint_template_number;
string xdr_tmcom_endpoint_template_name < >;
unsigned long xdr_tmcom_endpoint_template_parser_vintage;
);
An example of an XDR message transmitted between the network manager and the element controller describing directionality may be as follows:
enum xdr_tmcom_directionality (
xdr_tmcom_direction_not_applicable,
xdr_tmcom_bidirectional,
xdr_tmcom_unidirectional,
xdr_tmcom_unidirectional_tx
xdr_tmcom_unidirectional_rx
);
Similarly, to obtain data describing the CTP groups connecting ports within network elements, network manager issues a CTP template request message over the XDR interface. Element controller responds to the CTP group template request signal by forwarding XDR messages containing data describing the CTP group templates. Such messages may take the form xdr_moatm_list_of_ctp_group_templates_t . . . xdr_moatm_list_of_ctp_group_templates_t(last) as illustrated in FIG. 22 herein. An example of the CTP group template identifier in an XDR message may be as follows:
struct xdr_tmcom_ctp_group_id (
unsigned long xdr_tmcom_ctp_group_number;
string xdr_tmcom_ctp_group_name< >;
unsigned long xdr_tmcom_ctp_group_parser_vintage;
);
There now follows a further example of operation of the network management system of FIG. 6, under conditions of introduction of a new port card into each of first and second network elements 601, 604. For example where network element 601 has an STM-1 port card, corresponding with another STM-1 port card on network element 604, there being an optical link 611 therebetween, each STM-1 port card always has the following layered termination point structure: a VC-4 termination point a multiplex section termination point a regenerator section termination point an optical section termination point a physical media section terminal point In the prior art network management system, when a new STM-1 port card is installed in a network element, the above list of termination points are enrolled individually for each port, each as individual objects by transmitting those objects from the port card to the element controller. This occurs for each time a new port card is installed in a network element, ie the same set of objects is transmitted from the new STM-1 port card to the element controller. A network element transmits separate report messages describing the physical media section termination point, optical section termination point, regenerator section termination point, multiplex section termination point, VC-4 termination point, reports describing adaptation between the physical media section termination point and optical section termination point, reports describing adaptation between the optical section termination point and regenerator section termination point, a report describing adaptation between the regenerator section termination point and multiplex termination point, and a report describing adaptation between the multiplex section termination point and the VC-4 termination point. There are also transmitted a plurality of reference identifiers relating those termination points and adaptation points together. This information is exactly the same as the information transmitted by first network element 601 when it enrolled its STM-1 port card. Further under conditions of fault when the element controller loses information describing the network elements, in the prior art case, each port card enrols individually, causing duplication of the data transmitted between the network elements and the element controller but sending the same information. For example, where there are eight STM-1 port cards in a network, there will be eight sets of objects, each describing the corresponding respective STM-1 ports in different network elements. In the best mode specific implementation herein, once a set of an STM-1 port card end point templates have been transmitted from the network element to the element controller, each time a new STM-1 port card of the same type is installed in the network, a set of end points is transmitted in the form of a short message across the OAM channel from the network element to the element controller. Since details describing an STM-1 port card are already stored in the end point template describing the STM-1 port card at the element controller, it is not necessary for the newly introduced STM-1 port card to transmit data describing each of its termination points, since this information is already installed at the element controller within the existing STM-1 end point template. Instead, the network element transmits the end points corresponding to the new ports, which is much shorter in terms of bytes of data than the full STM-1 port card end point templates. Thus, transmission of the end point message represents a significant data compression over the prior art case. Further, under conditions of faults in the network, if the information describing the network elements is lost from the element controller, and the network elements need to re-enrol at the element controller, the relatively short end point data types are transmitted from the network elements to the element controller, referencing the end point templates corresponding to the particular ports contained within those network elements. Upon enrollment of a port, an end point may be notified to the network manager via the XDR interface upon initiation of the element controller. The element controller can notify the network manager of enrollment or of de-enrollment of an end point by XDR messages across the XDR interface. Examples of enrollment and de-enrollment messages are illustrated in FIG. 23 herein. In the specific implementation herein, element controller 601 recognizes that first and second multiplexers 604, 605, are of the same type and recognizes that STM-1 ports at each of first and second multiplexers 604, 605 are of a same type and therefore each have a same relationship of termination points and adaptations as each other.
|
Same subclass Same class Consider this | ||||||||||