WO2015185115A1

WO2015185115A1 - Establishing subnetwork connections

Info

Publication number: WO2015185115A1
Application number: PCT/EP2014/061500
Authority: WO
Inventors: Giulio Ferretti; Roberta MERLO
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-06-03
Filing date: 2014-06-03
Publication date: 2015-12-10

Abstract

A method for requesting a target Operations System to establish a subnetwork connection is disclosed. The subnetwork connection comprises a Connection Termination Point and the method comprises specifying traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point (142), wherein a relation between the traffic flow and the Connection Termination point is fixed. Also disclosed is a method for establishing a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination Point. The method comprises receiving from the requesting Operations System a desired attribute of the Connection Termination Point, the desired attribute comprising traffic flow for the Connection Termination Point (242),and creating the Connection termination point with the received desired attribute, wherein a relation between the traffic flow and the Connection Termination point is fixed. Also disclosed are an apparatus (300) and a computer program product configured to implement the above methods.

Description

Establishing Subnetwork Connections

Technical Field The present invention relates to a method and apparatus for requesting a target Operations System to establish a subnetwork connection comprising a Connection Termination Point. The invention also relates to a method for establishing a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination Point. The invention also relates to a computer program product configured, when run on a computer, to carry out a method for requesting or establishing a subnetwork connection comprising a Connection Termination Point.

Background

Optical Transport Networks (OTNs) provide functionality including transport, multiplexing, switching, and management of optical channels carrying client signals. The governing standard for OTNs is Recommendation G.709 Y.1331 of the Telecommunications Standardisation Section of the International Telecommunications Union (ITU-T). G.709 Y.1331 defines the requirements for the optical transport module of order n (OTM-n) signals of the OTN in terms of optical transport hierarchy (OTH), functionality of the overhead in support of multi-wavelength optical networks, frame structures, bit rates and formats for mapping client signals. The first revision of Recommendation G.709/Y.1331 included Optical Channel Data Unit k (ODUk) virtual concatenation, ODUk multiplexing, backward Incoming Alignment Error (IAE), extension of the physical interface specification, and ODUk Automatic Protection Switching/Protection Communication Channel (APS/PCC) signal definition. The second revision of Recommendation G.709 Y.1331 included an extension of the physical specification for OTM-0.2 and OTM-0.3, definition of ODUk APS/PCC signal and OPUk tributary slot definition.

Amendment 3 of the second revision to Recommendation G.709/Y.1331 extended the recommendation to support: An ODU0 and Optical Channel Payload Unit (OPU)0 and transport of 1000BASE- X (1 GE) signal over ODU0,

An ODU2e and OPU2e and transport of CBR10G3 (10GE) and FC-1200 signals over ODU2e ,

An Optical Channel Transport Unit (OUT)4, ODU4 and OPU4 ,

Multiplexing of two ODU0 signals into an OPU 1

Lower order and higher order ODU concept to align with the "one-stage multiplexing"

Multiplexing of ODU0 signals into an OPU2 or OPU3

Multiplexing of ODU2e signals into an OPU3

Multiplexing of ODUj signals into an OPU4

The third revision of Recommendation G.709/Y.1331 extended the recommendation to support a new value for ODU payload type (in particular 0x21 for ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk).

The TeleManagement Forum (TMF) is a nonprofit industry association and standards organization. The Multi-Technology Network Management (MTNM) program of the TMF provides solutions for the management of multi-technology networks including, inter alia, OTNs. The TMF has produced two interface suites for managing the interface between Operating Systems (OSs) of multi-Technology networks, these interface suites are Multi-Technology Network Management (MTNM) and Multi- Technology Operations System Interface (MTOSI). Both MTNM and MTOSI interfaces reuse the layering concepts set out in ITU-T G.805 (a generalized multi-technology layered model), meaning the TMF model is very closely aligned to the ITU-T G.805 model, particularly concerning the principles of layering, termination, adaptation, and connectivity. The MTNM interface is intended for use between a Network Management System (NMS) and a Element Management System (EMS) where "NMS" refers to any client and "EMS" refers to any server for the interface. An EMS is an OS that exhibits EM Layer functionality, while an NMS is an OS that exhibits NM Layer functionality as defined in the ITU-T TMN model. The MTNM interface can also be used between two OSs that exhibit NML functionality. The MTOSI interface is more generic than MTNM, being defined for use between two OSs: a requesting OS, which may be an NMS, and a target OS, which may be an EMS. The requesting and target roles may be exchanged during the interactions between the OSs.

The MTNM and MTOSI interfaces include mechanisms to allow the requesting

OS/NMS to:

Discover the resources managed by an EMS/target-OS both at start up and during normal operation,

Examine and configure termination points (TPs),

Determine resource usage (via TPs) and connectivity (SubNetwork Connections (SNCs), Topological Links etc) within the network managed by an EMS/target- OS,

Request the EMS/target-OS to establish SNCs, modify SNCs (edit shape and add/remove/adjust route) and delete SNCs,

Request the EMS/target-OS to establish Topological Links and delete Topological Links,

Discover the physical resources (e.g. shelves and cards) present in the EMS/target-OS network,

Configure and retrieve performance measures from the EMS/target-OS network, and

Retrieve and manage alarms including creation and use of Alarm Severity Assignment Profiles.

Neither MTNM nor MTOSI implement the second revision of Recommendation G.709/Y.1331 , Amendment 3 of the second revision, or the third revision of Recommendation G.709/Y.1331. These widely used interface suites cannot therefore be used to manage OTNs implementing the latest version of recommendation G.709/Y.1331. Amendment of the interface suites to accommodate the above discussed revisions would result in both performance and storage size issues for the interfaces and managed OSs, as discussed below.

Both the MTOSI and the MTNM models define three types of Connection Termination Points (CTPs): 1 . An In Use CTP, defined as a CTP that is used by an SNC in any state (including pending) or a CTP that is terminated and mapped. In order to inventory In Use CTPs, the NMS/requesting OS uses the operation getContainedlnUseTPs. 2. A Current CTP is a CTP that is either cross-connectable or cross-connected, in the current mapping configuration. In order to inventory Current CTPs, the NMS/requesting OS uses the operation getContainedCurrentTPs.

3. A Potential CTP, with respect to a given containing TP, is a CTP that can possibly be created for a given channelization of the containing TP; so the containing TP is potentially capable of supporting it in some mapping configuration. The list of "potential" CTPs contained by a given containing TP includes CTPs that need frame- structuring in order to be used (for monitoring, SNC involvement, etc.) by the NMS/requesting-OS. The set of Potential CTPs with respect to a containing TP includes the set of In Use and Current CTPs. In order to inventory Potential CTPs, the NMS/requesting OS uses the operation getContainedPotentialTPs.

For MTNM and MTOSI interfaces, the EMS/target-OS should therefore support the operation getContainedPotentialTPs, which expects as an input parameter a TP (in a worst case scenario a Physical TP which is the object modeling the physical port) and is required to return all Potential contained CTPs for the input TP, including both CTP name and all CTP attributes for each potential contained CTP. This information is then used by the NMS/requesting-OS to discover the potential resources available under the specified TP. With knowledge of the available resources, the NMS/requesting-OS may make use of these resources for example by forming or modifying SNCs.

The above discussed revisions to recommendation G.709/Y.1331 introduce new signals ODU4, ODU2e and ODU0, along with related possible multiplexing combinations. Consequently, the number of potential contained CTPs to be exposed over an MTNM or MTOSI interface in response to getContainedPotentialTPs increases dramatically compared to earlier versions of the G.709/Y.1331 recommendation. Accommodating the G.709/Y.1331 revisions into the TMF interfaces would therefore cause the getContainedPotentialTPs operation to take considerably longer to complete, and hence would impact upon interface performance. Storage within the EMS/target- OS could also become an issue in accommodating the G.709/Y.1331 revisions. In most EMS/target-OS implementations, a database is used to improve performance on the interface. Reporting potential ODU CTPs on getContainedPotentialTPs thus requires the creation of these objects with all of their attributes on the database. Once potential CTPs are reported on the interface (for example via getContainedPotentialTPs), the NMS/requesting-OS has calling provisioning operation on these potential CTPs, which nonetheless may remain local to the EMS/target-OS, and the result of which needs to be stored by the EMS/target-OS. Provisioning the extra storage required to accommodate the G.709/Y.1331 revisions in the TMF interfaces represents an additional challenge to the accommodation of these revisions in the TMF interfaces.

Summary

It is an aim of the present invention to provide a method and apparatus which obviate or reduce at least one or more of the disadvantages mentioned above.

According to a first aspect of the present invention, there is provided a method for requesting a target Operations System to establish a subnetwork connection comprising a Connection Termination Point. The method comprises specifying traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point, wherein a relation between the traffic flow and the Connection Termination point is fixed.

In some examples, the method may be conducted in a requesting operations system which may for example be a network management system and may be an Operations System implementing the ITU-T standard G.709/Y.1331 .

According to embodiments of the invention, the target Operations System may be implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing technology. Examples of such technologies may include Synchronous Digital Hierarchy (SDH), Synchronous Optical Networking (SONET), Dense Wavelength Division Multiplexing (DWDM) or Optical Transport Networks (OTN).

According to some embodiment, the method may further comprise instructing the target Operations System to assign a name to the Connection Termination Point. In such embodiments, the name may not include the traffic flow for the Connection Termination Point. According to some embodiments, instructing the target Operations System to assign a name to the Connection Termination Point may comprise specifying a generic name for the Connection Termination Point, the generic name containing an instruction to the target Operations System to assign a name to the Connection Termination Point. In some examples, the generic name may be "EMSAssigned".

According to some embodiments of the invention, the Connection Termination Point may comprise an Optical Channel Data Unit Connection Termination Point. According to such embodiments, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the time slots of which the Optical Channel Data Unit Connection Termination Point is composed. Alternatively, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

According to some embodiments, specifying traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point may comprise assigning a value to an attribute parameter for the Connection Termination Point, the attribute parameter comprising a dedicated traffic flow attribute parameter. The parameter may for example be a dedicated Layered Parameter which may be allocatedTribSlots.

According to some embodiments, the method may further comprise receiving from the target Operations System an object traffic flow attribute parameter supported by the target Operations System.

According to some embodiments, the target Operations System may comprise an Operations System implementing ITU-T standard G.709/Y.1331 .

According to some embodiments, the target Operations System may comprise one of an Element Management System or a Network Management System, and may be managed by an interface implementing TMF interface suite MTNM or MTOSI. According to another aspect of the present invention, there is provided a method for establishing a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination Point. The method comprises receiving from the requesting Operations System a desired attribute of the Connection Termination Point, the desired attribute comprising traffic flow for the Connection Termination Point, and creating the Connection termination point with the received desired attribute, wherein a relation between the traffic flow and the Connection Termination point is fixed.

In some examples, the method may be conducted in a target operations system which may for example be an Element Management System or a Network Management System and may be an Operations System implementing ITU-T standard G.709/Y.1331 .

According to some embodiments of the invention, the subnetwork connection may be within a network implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing Technology.

According to some embodiments, the method may further comprise receiving from the requesting Operations System an instruction to assign a name to the Connection Termination Point and assigning a name to the Connection Termination Point. In such embodiments, the name may not include the traffic flow for the Connection Termination Point.

According to some embodiments, the Connection Termination Point may comprise an Optical Channel Data Unit Connection Termination Point. According to such embodiments, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the time slots of which the Optical Channel Data Unit Connection Termination Point is composed. Alternatively, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

According to some embodiments, receiving from the requesting Operations System a desired attribute of the Connection Termination Point may comprise receiving a value for a traffic flow attribute parameter for the Connection Termination Point. According to some embodiments, the method may further comprise receiving from the requesting Operations System a request for supported attribute parameters and responding to the request with the traffic flow attribute parameter. According to some embodiments, the requesting Operations System may comprise an Operations System implementing ITU-T standard G.709/Y.1331 , and may comprise a Network Management System. According to some embodiments, the requesting Operations System may be managed by an interface implementing TMF interface suite MTNM or MTOSI.

According to another aspect of the present invention, there is provided a computer program product configured, when run on a computer, to carry out a method according to any of the above aspects of the invention. According to another aspect of the present invention, there is provided an Operations System node, configured to request a target Operations System to establish a subnetwork connection comprising a Connection Termination Point, the Operations System node comprising a processor and a memory, the memory containing instructions executable by the processor whereby the Operations System node is operative to specify traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point, wherein a relation between the traffic flow and the Connection Termination point is fixed.

In some examples, the Operations System of the Operations System node may comprise a requesting Operations System which may be a Network Management System and may be an Operations System implementing ITU-T standard G.709/Y.1331 .

According to some embodiments, the target Operations System may be implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing technology.

According to some embodiments, the Operations System node may be further operative to instruct the target Operations System to assign a name to the Connection Termination Point. According to such embodiments, the name may not include the traffic flow for the Connection Termination Point. According to some embodiments, the Connection Termination Point may comprise an Optical Channel Data Unit Connection Termination Point. According to such embodiments, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the time slots of which the Optical Channel Data Unit Connection Termination Point is composed. Alternatively, the traffic flow for the Optical Channel Data Unit Connection Termination Point may comprise the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed. According to some embodiments, the Operations System node may be further operative to specify traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point by assigning a value to an attribute parameter for the Connection Termination Point, the attribute parameter comprising a dedicated traffic flow attribute parameter.

According to some embodiments, the Operations System node may be further operative to receive from the target Operations System an object traffic flow attribute parameter supported by the target Operations System. According to another aspect of the present invention, there is provided an Operations System node configured to establish a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination Point, the Operations System node comprising a processor and a memory, the memory containing instructions executable by the processor whereby the Operations System node is operative to receive from the requesting Operations System a desired attribute of the Connection Termination Point, the desired attribute comprising traffic flow for the Connection Termination Point, and create the Connection termination point with the received desired attribute, wherein a relation between the traffic flow and the Connection Termination point is fixed.

The Operations System of the Operations System node may be a target Operations System which may for example be an Element Management System or Network Management System and may be an Operations System implementing ITU-T standard G.709/Y.1331 According to some embodiments, the subnetwork connection may be within a network implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing Technology. According to some embodiments, the Operation Systems node may be further operative to receive from the requesting Operations System an instruction to assign a name to the Connection Termination Point, and assign a name to the Connection Termination Point. According to such embodiments, the name may not include the traffic flow for the Connection Termination Point.

According to some embodiments, the Operations System node may be further operative to receive from the requesting Operations System a desired attribute of the Connection Termination Point by receiving a value for a traffic flow attribute parameter for the Connection Termination Point.

According to some embodiments, the Operations System node may be further operative to receive from the requesting Operations System a request for supported attribute parameters and to respond to the request with the traffic flow attribute parameter.

According to another aspect of the present invention, there is provided a requesting operations system node comprising a requesting unit configured to request establishment of a subnetwork connection comprising a CTP. The requesting unit comprises a traffic flow sub unit configured to specify traffic flow for the CTP as a CTP attribute, for example by assigning a value to a traffic flow attribute parameter supported by the target OS. In some examples, the requesting unit may additionally comprise a naming sub unit configured to instruct the target OS to assign a name to the CTP, for example by specifying a generic name for the CTP. The requesting OS node may additionally comprise a parameters unit configured to request and receive attribute parameters supported by the target OS.

According to another aspect of the present invention, there is provided a target operations system node comprising a receiving unit configured to receive a request for establishment of a subnetwork connection comprising a CTP. The receiving unit may comprise a traffic flow sub unit configured to receive traffic flow for the CTP as a CTP attribute, for example by receiving a value assigned to a traffic flow attribute parameter supported by the target OS. In some examples, the receiving unit may additionally comprise a naming sub unit configured to receive instructions to assign a name to the CTP, for example by receiving a generic name for the CTP. The target OS node further comprises a CTP unit configured to create the requested CTP with the received traffic flow. The CTP unit may be further configured to assign a name to the created CTP. The target OS node may additionally comprise a parameters unit configured to receive and respond to a request for attribute parameters supported by the target OS.

Brief Description of the Drawings

For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

Figure 1 is a flow chart illustrating process steps in a method for requesting a target Operations System to establish a subnetwork connection;

Figure 2 is a flow chart illustrating process steps in a method for establishing a subnetwork connection requested by a requesting Operations System; and

Figure 3 is a block diagram illustrating functional units in an Operating System node.

Detailed Description

Aspects of the present invention provide a method for requesting the establishment of a subnetwork connection, and establishing a subnetwork connection, in which the traffic flow for a Connection Termination Point (CTP) of the subnetwork connection is decoupled from the name of the CTP, the traffic flow and CTP having a fixed relation for the lifetime of the subnetwork connection. In this manner, a requesting Operations System (OS) may make use of a CTP in a target OS without first having to obtain the CTP from the target OS. In order to achieve this decoupling of CTP traffic flow from CTP name, the methods of the present invention specify traffic flow for the CTP as a desired attribute of the CTP, leaving the target OS free to assign a name for the CTP that does not include the CTP traffic flow. By enabling the requesting OS to make use of a CTP without first needing to obtain the CTP, the methods of the present invention avoid the need to expose all potential CTPs in a target OS to a requesting OS before the requesting OS can make use of the CTPs. This is particularly advantageous for target OSs implementing the latest revisions to G.709/Y.1331 , owing to the large increase in potential CTPs created by the new ODUk signals and multiplexing options introduced in these revisions.

According to one embodiment of the present invention, decoupling of CTP traffic flow from CTP name may be achieved at least in part through the use of a mechanism for EMS assignment of trail end points, currently used only for packet switching technologies. Unlike Time Division Multiplexing (TDM) or Frequency Division Multiplexing (FDM) technologies, in which traffic flows have a fixed position in a frame, packet switching technologies identify traffic flows through labels or tags inserted in the packet header, such as MPLS-TP labels. A CTP of a packet switching technology may change its labels or tags during its lifetime, so changing the traffic flow through the CTP. Consequently, it is not convenient from a management perspective to name packet switching technology CTPs using the traffic flow labels or tags. Instead of using the labels or tags to name the CTPs, a requesting OS instructs the relevant target OS to assign an absolute name to the CTP, and the requesting OS specifies the labels or tags for the CTP as desired attributes of the CTP at the time of requesting the subnetwork connection. This is achieved by the requesting OS specifying, on requesting establishment of a subnetwork connection, a generic end point name for a CTP that has not been inventoried as potential. The generic name "EMS_assigned" is used as the requesting OS specified name for the CTP, as illustrated in the example below where a CTP is addressed under a potential termination point with the name "EMS_assigned". Name Value

CTP EMS SOO Fusion

ME SPO1400

PTP /shelf=X/card=Y/port=Z

CTP /EMS_assigned

Table 1

On completion of the subnetwork creation by the target OS, the requested CTP is created with a name assigned by the target OS, and can then be inventoried by the requesting OS using the getContainedlnUseTPs operation.

According to the present invention, this procedure for packet switching technologies is adapted for use in other technologies. As discussed above, in TDM and FDM technologies, traffic flows have a fixed position in the frame (the time slot or tributary slot), which position is used in the name of a CTP, such that the requesting OS selects the traffic flow to be involved in a subnetwork connection by means of the CTP name itself. The CTP name and traffic flow thus have a fixed relation during the life of the CTP, and potential CTPs must be inventoried by a requesting OS before the requesting OS can make use of any of the potential CTPs in requesting establishment of a subnetwork connection. According to the present invention, in order to avoid the need for such inventory of potential CTPs, the traffic flow information, that is the time slot or tributary slot information, for a CTP is removed from the CTP name and instead specified as an attribute of the CTP, for example using a new attribute parameter. In this manner, traffic flow selection for a CTP, even though fixed during the lifetime of the CTP, may be specified by means of a CTP parameter, with the name of the CTP being assigned by the target OS. The generic name "EMS_assigned" may be used by the requesting OS to specify that the name of the CTP should be assigned by the target OS, with the traffic flow information for the CTP specified as a CTP attribute. With the requesting OS thus able to make use of a CTP without first obtaining knowledge of it, the need for supporting the getContainedPotentialTPs operation is removed, and only Current and In Use CTPs need be inventoried.

Figure 1 illustrates process steps in an example method 100 for requesting a target OS or EMS to establish a subnetwork connection according to an aspect of the present invention. The subnetwork connection comprises a CTP having a traffic flow which has a fixed relation to the CTP. The method may be performed in a requesting OS which may for example be an NMS. Referring to Figure 1 , in a first step 120, the requesting OS/NMS requests supported attribute parameters from the target OS/EMS. The target OS/EMS may respond with a list of supported attribute parameters, received at the requesting OS/EMS at step 130. This exchange may be performed a single time on setup of the interface between the requesting OS/NMS and target OS/EMS. The supported parameters, once received, may be stored in the requesting OS/NMS for future use in all exchanges with the target OS/EMS. Knowledge of the attribute parameters supported by the target OS/EMS enables the requesting OS/NMS to use the appropriate parameters for instructing the target OS/EMS. According to the present example, among the received parameters supported by the target OS/EMS is a traffic flow attribute parameter, which may be used for specifying traffic flow as an attribute of a CTP. At step 140 of the method 100, the requesting OS/NMS requests the target OS/EMS to establish a subnetwork connection comprising a CTP. As part of this requesting step 140, the requesting OS/NMS specifies, at step 142, traffic flow for the CTP as a desired attribute of the CTP. This may be done according to step 142a by assigning a value to the traffic flow attribute parameter supported by the target OS/EMS. In addition to specifying traffic flow for the CTP as an attribute of the CTP at step 142a, step 140 may also comprise, at step 144, instructing the target OS/EMS to assign a name to the CTP. This may be accomplished according to step 144a by the requesting OS/NMS specifying a generic name for the CTP, such as "EMS_assigned". By which the target OS/EMS understands that it is to assign a name to the CTP.

Figure 2 illustrates process steps in a corresponding example method 200 for establishing a subnetwork connection requested by a requesting OS or NMS according to an aspect of the present invention. The subnetwork connection comprises a CTP having a traffic flow which has a fixed relation to the CTP. The method may be performed in a target OS which may for example be an EMS or an NMS but which for the purposes of clarity is referred to below as a target OS/EMS. Referring to Figure 2, in a first step 220, the target OS/EMS receives a request for supported attribute parameters from the requesting OS/NMS. The target OS/EMS responds at step 230 with a list of attribute parameters supported by the target OS/EMS. According to the present example, the list includes a traffic flow attribute parameter which is supported by the target OS/EMS. As mentioned above with respect to the method 100, this provision of supported attribute parameters may take place on a single occasion which may be separated in time from the subsequent establishment of subnetwork connections. The target OS/EMS receives, at step 240, a request to establish a subnetwork connection comprising a CTP. Step 240 may comprise receiving, at step 242 a traffic flow for the CTP of the subnetwork connection as an attribute of the CTP, for example via a value assigned to a traffic flow attribute parameter for the CTP. Step 240 may also comprise receiving, at step 244, an instruction to assign a name to the CTP, for example by receiving from the requesting OS/NMS a generic name for the CTP such as EMS_assigned. On receipt of the request to establish a subnetwork connection comprising a CTP at step 240, the target OS/EMS creates the specified CTP having a traffic flow as specified in the received traffic flow attribute parameter at step 250 and at step 260 assigns a name to the created CTP.

According to examples of the present invention, the target OS/EMS and/or requesting OS/NMS of the above methods may be implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing technology, such as SDH, SONET or DWDM. In a particular example, the target OS/EMS and/or requesting OS/NMS may be implementing an OTN, and the CTP of the subnetwork connection may comprise an Optical Channel Data Unit (ODU) CTP. The traffic flow specified as an attribute parameter may therefore be the time slots or tributary slots of which the ODU CTP is composed. In another particular example of the invention, the target OS/EMS and/or requesting OS/NMS may comprise an OS implementing ITU-T standard G.709/Y.1331 and may be managed by an interface implementing TMF interface suite MTNM or MTOSI.

The example methods of Figures 1 and 2 may be conducted by an operations system node, embodied in a requesting or target OS. Apparatus for conducting the methods described above, for example on receipt of suitable computer readable instructions from a computer program, may be incorporated within any suitable OS node. Figure 3 illustrates an example OS node 300 which may be configured to conduct the method of Figures 1 or 2. The OS node 300 comprises a processor 370 and a memory 380. The memory 380 contains instructions executable by the processor 370 such that the OS node 300 is operative to conduct the steps of either of the methods of Figures 1 or 2, described above. An operations system node configured to implement the above described methods may also be implemented via a series of functional units, which may be realised in any appropriate combination of hardware and/or software. For example, an OS node of a requesting OS may comprise a requesting unit configured to request establishment of a subnetwork connection comprising a CTP. The requesting unit may comprise a traffic flow sub unit configured to specify traffic flow for the CTP as a CTP attribute, for example by assigning a value to a traffic flow attribute parameter supported by the target OS. The requesting unit may additionally comprise a naming sub unit configured to instruct the target OS to assign a name to the CTP, for example by specifying a generic name for the CTP. The requesting OS node may additionally comprise a parameters unit configured to request and receive attribute parameters supported by the target OS. An OS node of a target OS may comprise a receiving unit configured to receive a request for establishment of a subnetwork connection comprising a CTP. The receiving unit may comprise a traffic flow sub unit configured to receive traffic flow for the CTP as a CTP attribute, for example by receiving a value assigned to a traffic flow attribute parameter supported by the target OS. The receiving unit may additionally comprise a naming sub unit configured to receive instructions to assign a name to the CTP, for example by receiving a generic name for the CTP. The target OS node may additionally comprise a CTP unit configured to create the requested CTP with the received traffic flow and to assign a name to the created CTP. The target OS node may additionally comprise a parameters unit configured to receive and respond to a request for attribute parameters supported by the target OS.

The above discussed methods for requesting and establishing a subnetwork connection may be implemented within the TMF interfaces MTNM and MTOSI via the following revisions to the documents governing the two interface suites.

1 ) Amend Use Case UC_TMF518_RP_0003 (The requesting OS creates and activates a Subnetwork Connection - but it's valid also for "create" as well), reported in TMF518, as follows: Add to the UC Description the following note: For scenarios where the OS specifies TP name with the conventional fixed value "EMS assignedTTarget OS assigned", refer to UC_ TMF518_RP_0xyz

2) Create new Use Case UC_ TMF518_RP_0xyz in TMF518 as follows:

The requesting OS creates and activates a Subnetwork Connection (SNC) specifying TP names with the conventional fixed value "EMS assigned'V'Target OS assigned"

Use Case Id UC_ TMF518_RP_0xyz

Use Case Name The requesting OS creates and activates a Subnetwork Connection

(SNC) specifying TP names with the conventional fixed value "EMS assignedTTarget OS assigned"

Summary The requesting OS sets up a Subnetwork Connection on a target

OS Subnetwork. The requesting OS supplies the names of some TPs that can be end or internal SNC points.

This use case extends the Use Case UC_TMF518_RP_0003: The requesting OS creates and activates a Subnetwork Connection (SNC). The only differences with respect to these use cases are specified here.

Actor(s) The requesting OS

Pre-Conditions The requesting OS and target OS have successfully executed the

Use Case 0001 OS (Re) Starts as defined in the TMF518_FMW BA document

Begins When The requesting OS sends the Create and Activate SNC request to the target OS.

Description 1 ) In case flexibility between Termination Connection Point and

Connection Point functions is available, then the SNC creation can be performed specifying the conventional FTP name "EMS assignedTTarget OS assigned", optionally indicating the local CTP(s) in the routing constraint input parameters. (^*)

2) In case no flexibility is available between Termination Connection Point and Connection Point functions, then the SNC creation can be performed specifying mapping mode of CTP end points. (^*)

(^*) The name of CTP (local) endpoints may be unknown at this stage, because:

a. no naming rules are available for candidate CTPs (e.g. T- MPLS, MPLS TP, etc.), or

b. naming rules are available (potential CTPs can be addressed) but requesting OS anyway delegates to target OS/Control Plane the final choice of potential CTP to be selected/created

c. naming rules are available but target OS does not support potential state

d. naming rules are available but target OS decides not to expose potential TPs for performance and scalability reasons. In this case, it is mandatory that target OS gives the possibility to the requesting OS of selecting the traffic flow associated to that CTP (depending on the technology) by mean of CTP attributes (e.g. tributary slots of ODU CTP in case of OTN technology)

In this case, these CTPs can be generically specified by the name of server layer TP, completed with the "EMS_assigned" / "Target OS assigned" conventional value of client CTP relative distinguished name. This allows requesting OS to unambiguously indicate to target OS:

• the proper server TP (which must exist as managed object instance),

• the desired traffic flow associated to the TP, if allowed by the technology

leaving to the target OS the freedom to select (or create, if the case as in point d. above) the proper CTP instance.

In case one or more generic CTP names have been specified, and target OS is unable to make available the CTP instance, an Unable To Comply exception is raised.

3) The target OS sends CTP/FTP object creation notifications to the notification service, if the case.

Ends When Refer to Use Case UC_TMF518_RP_0003: requesting OS creates and activates a Subnetwork Connection (SNC).

plus, in case of success:

o The target OS has created the requested CTP/FTP object instances.

o The target OS has sent CTP/FTP object creation notifications to the notification service.

plus, in case of failure:

o The target OS has failed the CTP/FTP instance(s) selection or creation, in case of generic TP names were specified as input parameters.

Post-Conditions Refer to Use Case UC_TMF518_RP_0003: requesting OS creates and activates a Subnetwork Connection (SNC).

Exceptions 1 . See exception list from UC_TMF518_RP_0001.

2. See exception list from UC_TMF518_RP_0002.

Traceability R TMF518 RP II 0009, R TMF518 RP II 0010

3) Amend Use Case UC_TMF518_RP_0009 (The requesting OS deactivates and deletes a Subnetwork Connection - but is valid for "delete" as well, because this last UC points to RP_0008 for the Post-Conditions), reported in TMF518, as follows:

Add to the UC Post-Conditions, in case of success, the following note:

The network resources (CTPs) which had been used in the SNC are freed in the managed subnetwork (really, are no longer in active use by the SNC). In some cases the CTPs are removed from the interface. In general this may occur when requesting OS has delegated target OS the choice / creation of CTP instances involved in the SNC (end points, intermediate points) because e.g. potential state is not supported 4) Amend Use Case 7.7.3 (NMS creates and activates a Subnetwork Connection (SNC) - but it's valid also for "create" as well), reported in TMF513_v3.1_070314, as follows:

Add to the UC Description the following note:

For scenarios where the NMS specifies TP name with the conventional fixed value "EMS assigned Target OS assigned", refer to Use Case a.b.c

5) Create new Use Case a.b.c in TMF513_v3.1_070314 as follows:

The NMS creates and activates a Subnetwork Connection (SNC) specifying TP names with the conventional fixed value "EMS assigned'V'Target OS assigned"

Use Case Id a.b.c

Use Case Name NMS creates and activates a Subnetwork Connection (SNC) specifying TP names with the conventional fixed value "EMS assigned'V'Target OS assigned"

Summary The NMS sets up a Subnetwork Connection on the EMS. NMS supplies the names of some TPs that can be end or internal SNC points.

This use case extends the Use Case 7.7.3: NMS creates and activates a Subnetwork Connection (SNC). The only differences with respect to these use cases are specified here.

Actor(s) NMS

Pre-Conditions The NMS and the EMS have successfully executed the Use

Case 7.2.1 EMS (Re)starts as defined in the TMF513_v3.1_070314 document.

Begins When The NMS sends the Create and Activate SNC request to the

EMS.

Description 1 ) In case flexibility between Termination Connection Point and

2) In case no flexibility is available between Termination Connection Point and Connection Point functions, then the SNC creation can be performed specifying mapping mode of CTP end points.f)

(^*) The name of CTP (local) endpoints may be unknown at this stage, because:

a. no naming rules are available for candidate CTPs (e.q.

T-MPLS, MPLS TP, etc.), or

b. naming rules are available (potential CTPs can be addressed) but the NMS anyway delegates to the EMS/Control Plane the final choice of potential CTP to be selected/created

c. naming rules are available but the EMS does not support potential state

d. naming rules are available but the EMS decides not to expose potential TPs for performance and scalability reasons. In this case, it is mandatory that the EMS gives the possibility to the NMS of selecting the traffic flow associated to that CTP (depending on the technology) by mean of CTP attributes (e.g. tributary slots of ODU

CTP in case of OTN technology)

In this case, these CTPs can be generically specified by the name of server layer TP, completed with the "EMS_assigned" / "Target OS assigned" conventional value of client CTP relative distinguished name. This allows the NMS to unambiguously indicate to EMS:

• the proper server TP (which must exist as managed object instance),

• the desired traffic flow associated to the TP, if allowed by the technology

leaving to the EMS the freedom to select (or create, if the case as in point d. above) the proper CTP instance.

In case one or more generic CTP names have been specified, and EMS is unable to make available the CTP instance, an Unable To Comply exception is raised.

3) The EMS sends CTP/FTP object creation notifications to the notification service, if the case.

Ends When Refer to Use Case 7.7.3: NMS creates and activates a

Subnetwork Connection (SNC).

plus, in case of success:

o The EMS has created the requested CTP/FTP object instances.

o The EMS has sent CTP/FTP object creation notifications to the notification service,

plus, in case of failure:

o The EMS has failed the CTP/FTP instance(s) selection or creation, in case of generic TP names were specified as input parameters.

Post-Conditions Refer to Use Case 7.7.3: NMS creates and activates a

Subnetwork Connection (SNC)

Exceptions 1 . See exception list from Use Case 7.7.1 : NMS creates a

Subnetwork Connection (SNC)

2. See exception list from Use Case 7.7.2: NMS activates a Subnetwork Connection (SNC)

Traceability {Requirement II. 088}, {Requirement II. 089}

6) Amend Use Case 7.7.9 (NMS deactivates and deletes a Subnetwork Connection (SNC) - but is valid for "delete" as well, because this Use Case points to Use Case 7.7.8: NMS deletes a Subnetwork Connection (SNC) for the Post-Conditions) reported in TMF513_v3.1_070314, as follows: Add to the UC Post-Conditions, in case of success, the following note:

The network resources (CTPs) which had been used in the SNC are freed in the managed subnetwork (really, are no longer in active use by the SNC). In some cases the CTPs are removed from the interface. In general this may occur when NMS has delegated EMS the choice / creation of CTP instances involved in the SNC (end points, intermediate points) because e.g. potential state is not supported. 7) The TMF interfaces may be extended to accommodate the new signals introduced in G.709 Y1331 Revision 2, Amendment 3, by amending the TMF Supporting Document SD1 -17 "Layer Rates" to introduce the following new Layer Rates:

8) Extend the TMF interfaces to introduce new Layered Parameters for communicating CTP traffic flow as a CTP attribute, for managing the new OPUk structures added by G.709 Y.1331 Revision 2 and for managing the new Payload Type introduced by G.709 Y.1331 Revision 3 Amendments. The amendments may be implemented by amending the TMF Supporting Document SD1 -16 "Layered Parameters" to include the following new Layered Parameters: Parameter Layer Objects Values AVC Settabl Source Comment/ How/If to manage Name s / Terms e from Standard Example

supportedP ODU FTP,CT Possible no EMS Proprietary To be set on each ODU ayloadType layers P values parameter Layer, based on the s semicol showing information reported in on the possible I36 supportedOduPayloadT separat Payload ypes field. ODU1 channels ed: "0x2 types supported cannot manage PT=0x20 0" and by a given ODU so ODU1 layer will not "0x21 " TP contain this information

PayloadTy ODU FTP,CT "0x20" yes NMS, ITU-T Proprietary

pe layers P or EMS G.709/Y.1 parameter

"0x21 " 331 showing

(12/2009) the actual

Payload types

of the ODU TP

allocatedTri ODU FTP,CT "integer yes NMS, ITU-T Proprietary

bSlots layers P value" EMS G.709/Y.1 parameter

comma 331 indicating the

separat (12/2009) list of tributary

ed slots the ODU

values CTP is

composed of. It

only applies to

ODU channels

contained in a

higher order

ODU

Aspects of the present invention provide method by which a requesting OS may request establishment of a subnetwork connection involving a CTP in a target OS without first obtaining the CTP from the target OS via the getContainedPotentialTPs operation, the target OS managing a network technology in which a relation between a

CTP and its traffic flow is fixed for the lifetime of the CTP. By avoiding the need to expose all potential CTPs to a requesting OS before a subnetwork connection can be established, the methods of the present invention provide improved performance and enable reduced storage provision, so improving the scalability of target OS applications. The methods are particularly advantageous for OSs managing OTNs implementing the latest revisions to the G.709/Y.1331 Recommendation.

The methods of the present invention may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present invention also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the invention may be stored on a computer-readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form. It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A method for requesting a target Operations System to establish a subnetwork connection comprising a Connection Termination Point, the method comprising:

specifying traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point;

wherein a relation between the traffic flow and the Connection Termination point is fixed.

2. A method as claimed in claim 1 , wherein the target Operations System is implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing technology.

3. A method as claimed in claim 1 or 2, further comprising instructing the target Operations System to assign a name to the Connection Termination Point.

4. A method as claimed in claim 3, wherein the name does not include the traffic flow for the Connection Termination Point.

5. A method as claimed in claim 3 or 4, wherein instructing the target Operations System to assign a name to the Connection Termination Point comprises specifying a generic name for the Connection Termination Point, the generic name containing an instruction to the target Operations System to assign a name to the Connection Termination Point.

6. A method as claimed in any one of the preceding claims, wherein the Connection Termination Point comprises an Optical Channel Data Unit Connection Termination Point.

7. A method as claimed in claim 6, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the time slots of which the Optical Channel Data Unit Connection Termination Point is composed.

8. A method as claimed in claim 6, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

9. A method as claimed in any one of the preceding claims, wherein specifying traffic flow for the Connection Termination Point as a desired attribute of the

Connection Termination Point comprises assigning a value to an attribute parameter for the Connection Termination Point, the attribute parameter comprising a dedicated traffic flow attribute parameter.

10. A method as claimed in claim 9, further comprising receiving from the target Operations System an object traffic flow attribute parameter supported by the target Operations System.

1 1 . A method as claimed in any one of the preceding claims, wherein the target Operations System comprises an Operations System implementing ITU-T standard G.709/Y.1331 .

12. A method as claimed in any one of the preceding claims, wherein the target Operations System comprises one of an Element Management System or a Network Management System.

13. A method as claimed in any one of the preceding claims, wherein the target Operations System is managed by an interface implementing TMF interface suite MTNM or MTOSI.

14. A method for establishing a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination

Point, the method comprising:

receiving from the requesting Operations System a desired attribute of the Connection Termination Point, the desired attribute comprising traffic flow for the Connection Termination Point; and

creating the Connection termination point with the received desired attribute; wherein a relation between the traffic flow and the Connection Termination point is fixed.

15. A method as claimed in claim 14, wherein the subnetwork connection is within a network implementing at least one of a Time Division Multiplexing or a Frequency

Division Multiplexing Technology.

16. A method as claimed in claim 14 or 15, further comprising:

receiving from the requesting Operations System an instruction to assign a name to the Connection Termination Point, and

assigning a name to the Connection Termination Point.

17. A method as claimed in claim 16, wherein the name does not include the traffic flow for the Connection Termination Point.

18. A method as claimed in any one of claims 14 to 17, wherein the Connection Termination Point comprises an Optical Channel Data Unit Connection Termination Point.

19. A method as claimed in claim 18, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the time slots of which the Optical

Channel Data Unit Connection Termination Point is composed.

20. A method as claimed in claim 18, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

21 . A method as claimed in any one of claims 14 to 20, wherein receiving from the requesting Operations System a desired attribute of the Connection Termination Point comprises receiving a value for a traffic flow attribute parameter for the Connection Termination Point.

22. A method as claimed in claim 21 , further comprising receiving from the requesting Operations System a request for supported attribute parameters and responding to the request with the traffic flow attribute parameter.

23. A method as claimed in any one of claims 14 to 22, wherein the requesting Operations System comprises an Operations System implementing ITU-T standard G.709/Y.1331 .

24. A method as claimed in any one of claims 14 to 23, wherein the requesting Operations System comprises a Network Management System.

25. A method as claimed in any one of claims 14 to 24, wherein the requesting Operations System is managed by an interface implementing TMF interface suite MTNM or MTOSI.

26. A computer program product configured, when run on a computer, to carry out a method as claimed in any one of the preceding claims.

27. An Operations System node, configured to request a target Operations System to establish a subnetwork connection comprising a Connection Termination Point, the

Operations System node comprising a processor and a memory, the memory containing instructions executable by the processor whereby the Operations System node is operative to:

specify traffic flow for the Connection Termination Point as a desired attribute of the Connection Termination Point;

28. An Operations System node as claimed in claim 27, wherein the target

Operations System is implementing at least one of a Time Division Multiplexing or a Frequency Division Multiplexing technology.

29. An Operations System node as claimed in claim 27 or 28, wherein the

Operations System node is further operative to instruct the target Operations System to assign a name to the Connection Termination Point.

30. An Operations System node as claimed in claim 29, wherein the name does not include the traffic flow for the Connection Termination Point.

31 . An Operations System node as claimed in any one of claims 27 to 30, wherein the Connection Termination Point comprises an Optical Channel Data Unit Connection Termination Point.

32. An Operations System node as claimed in claim 31 , wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the time slots of which the Optical Channel Data Unit Connection Termination Point is composed.

33. An Operations System node as claimed in claim 31 , wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

34. An Operations System node as claimed in any one of claims 27 to 33, wherein the Operations System node is further operative to specify traffic flow for the

Connection Termination Point as a desired attribute of the Connection Termination Point by assigning a value to an attribute parameter for the Connection Termination Point, the attribute parameter comprising a dedicated traffic flow attribute parameter.

35 An Operations System node as claimed in claim 34, wherein the Operations System node is further operative to receive from the target Operations System an object traffic flow attribute parameter supported by the target Operations System.

36. An Operations System node configured to establish a subnetwork connection requested by a requesting Operations System, the subnetwork connection comprising a Connection Termination Point, the Operations System node comprising a processor and a memory, the memory containing instructions executable by the processor whereby the Operations System node is operative to:

receive from the requesting Operations System a desired attribute of the Connection Termination Point, the desired attribute comprising traffic flow for the Connection Termination Point; and

create the Connection termination point with the received desired attribute; wherein a relation between the traffic flow and the Connection Termination point is fixed.

37. An Operations System node as claimed in claim 36, wherein the subnetwork connection is within a network implementing at least one of a Time Division

Multiplexing or a Frequency Division Multiplexing Technology.

38. An Operations System node as claimed in claim 36 or 37, wherein the Operation Systems node is further operative to:

receive from the requesting Operations System an instruction to assign a name to the Connection Termination Point, and assign a name to the Connection Termination Point.

39. An Operations System node as claimed in claim 38, wherein the name does not include the traffic flow for the Connection Termination Point.

40. An Operations System node as claimed in any one of claims 36 to 39, wherein the Connection Termination Point comprises an Optical Channel Data Unit Connection Termination Point.

41 . An Operations System node as claimed in claim 40, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the time slots of which the Optical Channel Data Unit Connection Termination Point is composed.

42. An Operations System node as claimed in claim 40, wherein the traffic flow for the Optical Channel Data Unit Connection Termination Point comprises the tributary slots of which the Optical Channel Data Unit Connection Termination Point is composed.

43. An Operations System node as claimed in any one of claims 36 to 42, wherein the Operations System node is further operative to receive from the requesting

Operations System a desired attribute of the Connection Termination Point by receiving a value for a traffic flow attribute parameter for the Connection Termination Point.

44. An Operations System node as claimed in claim 43, wherein the Operations System node is further operative to receive from the requesting Operations System a request for supported attribute parameters and to respond to the request with the traffic flow attribute parameter.