Patent Description:
DCN technologies are currently used to support distributed NE communications related to e.g., Telecommunications Management Network (TMN) and Automatically Switched Optical Network (ASON) applications. The standard DCN architecture and functions for transport networks (e.g., for Optical Transport Network (OTN) networks) are defined in ITU-T Recommendation G. <FIG> (which corresponds to ITU-T Figure <NUM>-<NUM>/G. <NUM>) illustrates example applications, which can be supported via a DCN. Each application can be supported on a separate DCN, or on the same DCN, depending on the network design.

When supporting distributed management communications (e.g., TMN applications), which are described in clause <NUM> of the ITU-T Recommendation G. <NUM>, the DCN provides communication between TMN components defined in the ITU-T Recommendations M. <NUM> and M. <NUM> (e.g., NEs, ADs, OSs, MDs, and WSs containing TMN functions such as OSF, TF, NEF, WSF), in order to transport management messages through a management communication network (MCN).

When supporting distributed signalling communications (e.g., ASON applications), which are described in clause <NUM> of the ITU-T Recommendation G. <NUM>, the DCN provides communication between ASON components defined in ITU-T Recommendation G. <NUM> (e.g., ASON CC and RC components, contained within distributed NEs), in order to transport signalling and routing protocol messages through a signalling communication network (SCN).

ITU-T SG15 is planning to enhance the DCN definitions given in G. <NUM>, in order to support also SDN applications, providing communication between SDN components defined in ITU-T Recommendation G. <NUM>, and, more generally, to support Management-Control Continuum (MCC) applications providing communication between the common control components defined in ITU-T Recommendation G.

In this document, "DCN messages" represent messages that are transported over a DCN, for example, management messages (e.g. in case of TMN applications) and signalling and routing protocol messages (e.g. in case of ASON applications). Further, "DCN components" represent components that are communicating through a DCN, for example, distributed NEs, other TMN components or other ASON components. New types of DCN messages and DCN components may be defined in future extensions of G. <NUM>, for instance, in order to support SDN applications and, more generally, MCC applications. New types of DCN messages could also include support for big data information about the status of the network (e.g., network telemetry).

In clause <NUM> of the ITU-T Recommendation G. <NUM>, the clauses <NUM>. <NUM> and <NUM>. <NUM> provide some examples of MCN and, respectively, SCN topologies, in which distributed NEs communicate using either Embedded Communication Channels (ECC) or Local Communication Network (LCN), such as Ethernet Local Area Networks (LANs). Notably, in all these MCN topologies, some NEs - called Gateway Network Element (GNE) - are attached to the Operations System (OS). Although not explicitly mentioned in the ITU-T Recommendation G. <NUM>, (two) GNEs can be directly connected with the OS using an Ethernet LAN or, as shown in the ITU-T Figure <NUM>-<NUM>/G. <NUM>, through a Wide Area Network (WAN). In the latter case, typically a WAN gateway router is connected to the GNE using an Ethernet LAN. Typically, dual gateways are used to support reliable communication.

In clause <NUM> of ITU-T Recommendation G. <NUM>, some topologies are provided, in which there are no GNEs, because current ASON applications require communication only between distributed NEs. However, this assumption may change in future extensions of G. <NUM>, for example, in order to support centralized ASON components, such as a Path Computation Engine (PCE).

It can be assumed that GNEs are used as gateway nodes toward centralized components, for example, the OS (TMN applications) or a centralized SDN controller (for SDN applications). In all cases, the DCN provides layer-<NUM> connectivity between all the DCN components, including distributed NEs that need to exchange DCN messages such as the management messages (for TMN applications) or the signalling and routing protocol messages (for ASON applications). The layer-<NUM> protocols supported by the ITU-T Recommendation G. <NUM> Edition <NUM> are Internet Protocol (IP) and Open System Interconnection (OSI). The following layer-<NUM> requirements are defined for the distributed NEs to support DCN capabilities:.

It is worth noting that ITU-T Figure <NUM>-<NUM>/G. <NUM> Edition <NUM>. 0describes also the option for an NE to be a layer-<NUM> switching system for DCN messages, which are addressed to other NEs or to other DCN components. However, no further requirements are defined in the other clauses of the ITU-T Recommendation G. <NUM> Edition <NUM>. The ITU-T Recommendation G. <NUM> Edition <NUM> specifies the layer-<NUM>, layer-<NUM> and layer-<NUM> functions for the following interfaces to be used to forward DCN messages:.

The possibility to use external WAN links, e.g. for ASON applications, is also mentioned, but not described in detail within the ITU-T Recommendation G. <NUM> Edition <NUM>.

The layer-<NUM> ECC functions are defined in clause <NUM>. <NUM> of G. <NUM> Edition <NUM>. For Optical Transport Network (OTN) interfaces, the General Communication Channels (GCC) defined in ITU-T Recommendation G. <NUM> Edition <NUM> (GCCO, GCC1 and GCC2) are used to provide a communication channel to transport a bit-stream between two OTN NEs. The layer-<NUM> ECC functions are defined in clause <NUM>. <NUM> of G. <NUM> Edition <NUM>. For OTN interfaces, HDLC frame signal is mapped in a bit-synchronous manner into the GCC channel. The layer-<NUM> ECC functions are defined in clause <NUM>. <NUM> of G. <NUM> Edition <NUM>. IP and/or OSI packets are mapped into HDLC frames using "PPP in HDLC-like framing", as defined in IETF RFC <NUM>, RFC <NUM>, RFC <NUM> and RFC <NUM>.

The layer-<NUM> and layer-<NUM> Ethernet LAN functions are defined in clause <NUM>. <NUM> of G. <NUM> Edition. <NUM> Even if not explicitly stated, it is assumed that these functions are defined in IEEE <NUM> specification. The layer-<NUM> Ethernet LAN functions are defined in clause <NUM>. <NUM> of G. <NUM> Edition <NUM>. IP and/or OSI packets are mapped into Ethernet MAC frames, as defined in ITU-T Q. <NUM>, IETF RFC <NUM> and RFC <NUM>.

Other layer-<NUM> functions, such as those required to implement the OSI intermediate-system or IP router capabilities, are also defined in the ITU-T Recommendation G. <NUM> Edition <NUM>.

<FIG> shows an exemplary DCN, in particular based on OTN NE implementation, in which multiple NEs are provided and a controller (e.g. SDN controller) is further provided to provide, for instance exchange, traffic over the DCN. As is shown in <FIG>, DCN functions of a NE are implemented in software within a dedicated Control Card (CC), in which DCN messages addressed to that NE are terminated, while other DCN messages (not addressed to that NE) are forwarded. It is also worth noting that the Ethernet LAN interfaces of a GNE are usually low-rate Ethernet interfaces (up to <NUM> Mbit/s, as reported in clause <NUM>. <NUM>) attached to the Control Card (CC) dedicated to carry DCN traffic.

The implementation shown in <FIG> has some drawbacks, which need to be resolved to support emerging DCN applications such as the SDN applications:.

<FIG> shows an exemplary DCN, in particular an approach to increase the DCN throughput and to reduce the DCN latency. The approach has been proposed to ITU-T Q12&Q14/<NUM> interim meeting in December <NUM> by ITU-T contribution WD08. The main idea of this ITU-T contribution WD08 is to setup a set of Optical Data Unit-k (ODUk), e.g., ODU0, connections between the SDN controller and each OTN NE to be controlled. Each OTN NE then terminates the ODUk connection carrying DCN messages addressed to itself, and forwards all other ODUk connections carrying DCN messages addressed to other NEs or other DCN components. This approach provides:.

However, while addressing some technical issues of existing DCN technologies (e.g. as shown in <FIG>), the approach shown in <FIG> has also some drawbacks:.

The DCN bandwidth efficiency issue could be resolved by setting up sub-<NUM> OTN connections re-using the sub-<NUM> OTN frame structures which are currently under definition by ITU-T G. Sup_sub1G work item. However, this approach would require that each OTN NE within the network is capable of switching these sub-<NUM> OTN frames.

<CIT> discloses a data communication network message forwarding method base on a packet optical transport network device. Entire network routes at a PTN port side and an OTN port side in a P-OTN device are integrated to establish a DCN routing list. A three-layer conversion device receives DCN messages packaged in an Ethernet format of the P-OTN device, and the changing packaging is carried out on the DCN messages formats according to the types of a designation port, so that differences of concrete packaging formats between the PTN port and the OTN port are shielded, and DCN message forwarding between the PTN port and the OTN port in the P-OTN device is realized.

<CIT> discloses a network include determining an opportunity cost metric for each of a plurality of links in a network including a plurality of nodes, wherein the opportunity cost metric comprises a future constraint reflecting expectations for growth on currently established connections on each link of the plurality of links; receiving a request for a new connection between two nodes of the plurality of nodes in the network; and utilizing a constraint-based routing algorithm to determine a path for the new connection between the two nodes.

In view of the above-mentioned disadvantages, embodiments of the present invention aim to improve the current DCN implementations and approaches. An objective is to enhance DCN technologies, in order to provide higher throughput and lower latency, in particular, for the use of SDN applications. Also a high DCN reliability is desired. Thereby, a high bandwidth efficiency should be maintained, and the number of interfaces to be managed on a controller should be low.

The objective is achieved by the embodiments of the invention described in the enclosed independent claims.

In particular, the embodiments of the invention focus on exploiting multi-service Optical Transport Network (MS-OTN) NE capabilities, in order to enhance the DCN to provide higher throughput and lower latency for SDN applications.

Amain idea for the embodiments of the invention is to carry DCN messages over TDM connections (e.g. over ODUk connections), and to switch packets carrying the DCN messages within network nodes (e.g. MS-OTN NE) of the DCN, for instance, by using a packet matrix. To this end, a packet-based VPN (called DCN VPN) may be configured within the network node and may be used to carry DCN messages, requiring high-throughput/low-latency forwarding, over the TDM connections. Within the network node, DCN messages addressed to that network node may be terminated. All the other DCN messages may be forwarded by the network node, e.g. using the matrix in the packet layer (hardware-based forwarding) toward other TDM (e.g. ODUk) connections or Ethernet LAN interfaces DCN messages can also be carried over the Ethernet LAN interfaces on line cards. These interfaces can be used to connect network nodes functioning as GNE with e.g. the SDN controller (or some WAN gateway router).

The network node may be any type of NE in the DCN, e.g. also a GNE. ADCN message is, as already defined above, any message that is exchanged on/over the DCN. The determined network node may not necessarily be the destination/target node to which the DCN message is addressed The determined network node may still decide to forward again the packet to a further node in the DCN.

Packets, which are addressed to different network nodes are forwarded in particular over the same TDM connection. Thus, a controller does not have to maintain a large number of IP interfaces but can send all the DCN messages addressed to different network nodes over a single Ethernet LAN interface to a GNE. This reduces the complexity of the system. Further, the network node of the first aspect supports enhancing DCN technologies, in order to provide higher throughput and lower latency forwarding, in particular, for SDN applications. Higher throughput is enabled, because high bandwidth TDM connections (e.g. multi-Gbps ODU0/ODUflex) are used. Lower latency is enabled, because hardware-based packet forwarding can be implemented within e.g. the MS-OTN matrix Further, DCN reliability is improved, since packet and/or ODUk protection mechanisms can be used to protect the DCN traffic carried by the ODUk connections with short traffic interruption (e.g., <NUM> switching time).

Optionally, the network node is further configured to: determine and forward a set of packets using a packet matrix.

The packet matrix can particularly be used to forward the above-described first set of packets and/or second set of packets. The packet matrix is a hardware implementation providing the switching of the packets, carrying DCN messages, based on information provided in the packet overhead (e. g, their addressing). The hardware-based switching can be fast, in particular compared to software-based switching, such that low latency can be achieved.

Optionally, the packet-based VPN includes a flow-based VPN, in particular a layer-<NUM> VPN or a layer-<NUM> VPN. The packet based VPN provides an efficient implementation with low latency.

<FIG> shows a network node <NUM> according to an embodiment of the invention. The network node <NUM> is configured for a DCN network. The network node <NUM> may be a NE or a GNE in the DCN network.

The network node <NUM> is configured to receive a plurality of packets <NUM> carrying DCN messages, i.e. each packet <NUM> carries one DCN message. The packets/DCN messages may be addressed to the network node <NUM> or to another network node or component in the DCN. The packets <NUM> may be received from another network node or from an external network device (like the one shown in <FIG>), e.g. a network device/controller <NUM>.

Further, the network node <NUM> is configured to determine, from the received packets <NUM>, a first set <NUM> of packets <NUM>, which are addressed to other network nodes of the DCN (or other components), i.e. are not addressed to the network node <NUM>. Further, the network node <NUM> is configured to forward, e.g. using a packet matrix or other hardware-based packet switching mechanism, the first set <NUM> of packets <NUM> over a TDM connection <NUM>, e.g. over an ODUk connection, to a determined (other) network node <NUM> of the DCN. The determined network node <NUM> may be a network node to which packets <NUM> of the first set <NUM> of packets <NUM> are addressed, but may also be simply a predetermined "next" network node in a chain of network nodes. The determined network node <NUM> may be another network node <NUM> according to an embodiment of the invention, but can also be a network node <NUM> not according to an embodiment of the invention. For instance, with respect to <FIG> it will be explained that a network node <NUM> may be a MS-OTN NE, and a network node <NUM> may be an OTN NE.

<FIG> shows a network device <NUM> according to an embodiment of the invention. The network device <NUM> is configured to provide, for instance exchange, DCN traffic over a DCN, e.g. the DCN including the network node <NUM>. The network device <NUM> may be an external network controller, like an SDN controller.

The network device <NUM> is configured to separate packets <NUM> carrying DCN messages into first packets 201a carrying DCN messages requiring high throughput and/or low latency forwarding, and second packets 201b carrying other DCN messages (e.g. allowing lower throughput and/or higher latency forwarding). Further, the network device <NUM> is configured to provide the first packets 201a over a higher-speed connection 202a, in particular over an Ethernet connection, to a determined network node <NUM> of the DCN, and to provide the second packets 201b over a lower-speed connection 202b, in particular over an Ethernet connection, to the determined network node <NUM> of the DCN. Optionally the second packets 201b can also be sent over the higher-speed connection 202a.

The determined network node <NUM> of the DCN, to which the network device <NUM> provides the packets <NUM>, may be implemented according to the network node <NUM> shown in <FIG>. That is, the network node <NUM> may be a GNE that receives packets <NUM> (e.g. the packets <NUM> described with respect to <FIG>) from the network device <NUM>.

<FIG> shows a DCN network according to an embodiment of the invention, which includes network nodes <NUM> that build on the network node <NUM> shown in <FIG>, and includes a network device <NUM> that builds on the network device <NUM> shown in <FIG>.

It can be seen in <FIG>, that each network node <NUM> according to an embodiment of the invention (also referred to as MS-OTN NE in this implementation) may be provided with a DCN VPN <NUM>. In particular, this DCN VPN <NUM> may be configured within the MS-OTN data plane network, and may be used to carry DCN messages, requiring high-throughput/low-latency forwarding, over high-bandwidth TDM, specifically ODUk, connections <NUM>. Within each network node <NUM>, packets/DCN messages addressed to that network node <NUM> may be terminated (forwarded to a CC card and then terminated). All other packets/DCN messages may be forwarded, e.g. by a matrix in the packet layer (i.e. generally by a hardware-based forwarding), e.g. toward another ODUk connection <NUM> (e.g. to another network node) or an Ethernet LAN interface <NUM> (e.g. to the SDN controller <NUM>). The packets/DCN messages can also be carried over the Ethernet LAN interface <NUM> on one or more line cards. These interfaces can particularly be used to connect network nodes <NUM> being GNEs with e.g. the SDN controller <NUM> (or with a WAN gateway router).

For example, with reference to <FIG>, the GNE A (a network node <NUM> as shown in <FIG>) receives from the SDN controller <NUM> (the network device <NUM> shown in <FIG>) through a high-speed local Ethernet interface <NUM> (i.e. a hard control channel), packets/DCN traffic (i.e. e.g. the plurality of packets <NUM> of <FIG>, and/or the packets <NUM> of <FIG>), which are addressed either to itself and/or to NEs B, C and D (i.e. to further network nodes <NUM> as shown in <FIG>). GNE A may process the packets/DCN messages addressed to itself (second set of packets <NUM>), and may forward all other packets/DNC messages (first set <NUM> of packets <NUM>) to NE B using the ODUk connection <NUM> setup between NE A and NE B. Then, NE B may process the packets/DCN messages addressed to itself, and may forward all other packets/DCN messages to NE C using the ODUk connection <NUM> setup between NE B and NE C.

The DCN shown in <FIG> achieves the following advantages:.

In addition, the DCN shown in <FIG> also provides the following advantages, which resolve the issues of the approach proposed in the ITU-T contribution WD08 (see <FIG>):.

Notably, with respect to the above, the OTN technology is generally a switching technology, which encompasses both the photonic and the electrical domain. Within the electrical domain (TDM switching) it provides high-bandwidth (multi-Gbps) connectivity between any pair of remote access points connected to the OTN network.

OTN switching may be performed by switching ODUk frames. An ODUk frame contains a payload, Optical Payload Unit (OPUk), and an overhead, as shown in <FIG> (which corresponds to ITU-T Figure <NUM>-<NUM>/G. <NUM> Edition <NUM>). An ODUk connection is setup between the two remote access points connected to the OTN network. The user traffic received from the remote access points is carried by the OPUk, and transparently carried by the intermediate OTN NEs, which switches the ODUk frame. The ODUk overhead contains two General Communication Channel (GCC) overhead bytes, called GCC1 and GCC2, which are used to carry DCN messages between the two nodes terminating the ODUk connection. One or more ODUk frames can be mapped over an Optical Transport Unit-k (OTUk) for transmission over an OTN interface between two adjacent OTN nodes. The OTUk frame contains an overhead, a payload and a Forward Error Correction (FEC), as shown in <FIG>.

The OTUk overhead contains one General Communication Channel (GCC) overhead byte, called GCCO, which is used to carry DCN messages between the two adjacent OTN NEs
ITU-T Recommendation G. <NUM> has been recently updated to define also ODUCn and OTUCn frames to support OTN rate of <NUM> Gbps and beyond. These frames also support GCC0 (OTUCn) and GCC1/GCC2 (ODUCn). <FIG> (which corresponds to ITU-T Figure <NUM>-<NUM>/G. <NUM> Edition <NUM>) shows an OTUk frame structure, frame alignment and OTUk overhead, containing the GCC0 overhead bytes.

ITU-T has recently started a new G. Sup_sub1G work item to describe mechanisms to channelize the payload of an existing ODUk/flex to carry sub-<NUM> TDM connections. The main application scenario is to carry multiple sub-<NUM> TDM services over one ODUk/flex with high bandwidth efficiency. These mechanisms would include SDH and packet-based circuit emulation over OTN as well as sub-<NUM> OTN frame structures. These standard sub-<NUM> OTN frame structures are currently not intended to be defined as a switching layer but only to be used to map and multiplex multiple sub-<NUM> TDM connections within existing ODUk connections. However, it is expected that some proprietary extensions will be implemented to allow switching sub-<NUM> OTN connections within the network to further improve the bandwidth efficiency.

The term "multi-service OTN" (MS-OTN) is used to represent an OTN NE which, in addition to support line cards with OTN interfaces and matrix cards being capable to switch at the ODUk layer (TDM switching), can also support line cards with other interfaces, in particular Ethernet LAN interfaces and matrix cards being capable to switch packets/frames (packet switching). Both TDM and packet switching are implemented in hardware within the central matrix. Packets received from Ethernet LAN interfaces can be switched at the packet layer toward other Ethernet LAN interfaces or toward OTN interfaces. In the latter case, these packets are mapped into an ODUk for transmission over OTN interfaces. Alternatively, packets received from Ethernet LAN interfaces can be mapped into an ODUk and switched at the ODUk layer toward OTN interfaces. It is worth noting that the Ethernet LAN interfaces attached to MS-OTN line cards are usually high-speed Ethernet interfaces (from <NUM> Gbit/s up to hundreds of Gbit/s) intended to carry user traffic.

In the embodiments of the invention (e.g. shown in <FIG>), DCN messages that require high throughput and/or low latency forwarding, e.g., to support SDN applications, can be carried over either:.

The network nodes <NUM> can forward packets/DCN traffic between these interfaces using e.g. the packet matrix (hardware-based forwarding):.

The packet-based VPN (DCN VPN) <NUM> may be configured within the MS-OTN data plane network to carry the packets/DCN messages, requiring high-throughput/low-latency forwarding, over these new types of DCN channels (in particular, over ODUk connections <NUM>). One or more DCN VPN <NUM> instances can be configured within the MS-OTN data plane network depending on the DCN architecture and isolation requirements.

Transmission of DCN traffic over OTN ODUk connections is not supported by the ITU-T Recommendation G. Extensions are thus needed to G. <NUM> to support these new type of interfaces.

An implementation supporting only the current standard solution in G. <NUM> will not be capable to carry DCN traffic over ODUk connections. Since the DCN messages carried within the same ODUk connection are switched in the packet layer, the ODUk connections <NUM> can be setup between any pair of remote network nodes <NUM> (e.g., NEs A and B in <FIG>), and used to carry packets/DCN messages addressed to different network nodes (e.g., the ODUk connection <NUM> between NEs A and B in <FIG> can carry DCN traffic addressed to NE B, C and D).

Different types of packet-based VPN could be configured, depending on the MS-OTN network capabilities and/or operator's preference, to carry the DCN traffic requiring high-throughput and/or low latency forwarding.

One possibility is to configure a L2VPN instance within the MS-OTN, in order to carry the packets/DCN traffic. In this case the SDN controller <NUM> (or the WAN gateway router, if present) and all the network nodes <NUM> control cards reachable through the same GNEs belong to the same layer-<NUM> subnetwork and use standard layer-<NUM> mechanisms to exchange layer-<NUM> packets (e.g., IP packets or OSI CLNP packets) over the same Ethernet LAN.

Network nodes <NUM> forward the DCN messages using layer-<NUM> switching (as shown e.g. in ITU-T Figure <NUM>-<NUM>/G. <NUM>) based on the MAC Destination Address (MAC DA) field of the Ethernet frames. For example, with reference to <FIG>, the GNE A receives Ethernet frames carrying DCN messages from the SDN controller <NUM> and it would process (within the control card) those with the MAC DA matching its control card MAC address and forward to the NE B, through the ODUk connection <NUM>, all the other Ethernet frames.

There are multiple way to implement L2VPN over MS-OTN networks, such as using Ethernet Bridging (IEEE <NUM>. 1Q) or MPLS-TP L2VPN. Any option can be used depending on the MS-OTN network capabilities and/or operator's preference. When using the Ethernet Bridging (IEEE <NUM>. 1Q) solution, an S-VLAN may be allocated to carry the DCN traffic of one DCN VPN instance. The high-speed local Ethernet interfaces as well as the ODUk connections <NUM> setup for packets/DCN traffic may be registered as ports belonging to this S-VLAN to ensure DCN VPN traffic separation. Standard IEEE <NUM>. 1Q MAC address learning and forwarding procedures may be used to forward the Ethernet frames carrying packets/DCN messages among these ports. The S-VLAN tag can be or not carried by forwarded Ethernet frames depending on standard <NUM>. 1Q Port VLAN ID (PVID) and untagged set configuration.

For example, with a reference to <FIG>, the GNE A receives untagged Ethernet frames carrying DCN messages from the high-speed local Ethernet interfaces. It may associate these frames to the S-VLAN assigned to the DCN VPN (based on the PVID configuration), may learn that the MAC SA is reachable through that interface, and may forwards the frames based on their MAC DA. Frames with the MAC DA equal to the GNE A control card MAC address may be passed to the control card (CC) for local processing. All the other frames may be transmitted to the ODUk connection <NUM> setup between NE A and NE B either because the MAC DA has been learnt as reachable through that port or as part of the standard <NUM>. 1Q flooding process for frames with unknown MAC DA. If the ODUk connection <NUM> is configured to be part of the untagged set for the S-VLAN, the forwarded Ethernet frames are transmitted as untagged frames, otherwise they are transmitted with the S-VLAN tag.

NE B then receives either untagged or S-VLAN tagged Ethernet frames carrying DCN messages from that ODUk connection. In the former case (untagged Ethernet frames), it may associate these frames to the S-VLAN assigned to the DCN VPN (based on the PVID configuration), while in the latter case (S-VLAN tagged Ethernet frames), it may just check that the VLAN ID (VID) carried in the S-VLAN tag matches the S-VLAN assigned to the DCN VPN. In both cases, it may learn that the MAC SA is reachable through that ODUk connection <NUM> and may forward the frames based on their MAC DA. Frames with the MAC DA equal to the NE B control card MAC address may be passed to the control card (CC) for local processing. All the other frames may be transmitted to the ODUk connection <NUM> setup between NE B and NE C either because the MAC DA has been learnt as reachable through that port or as part of the standard <NUM>. 1Q flooding process for frames with unknown MAC DA.

When using the MPLS-TP L2VPN solution, a Virtual Switch Instance (VSI), as defined in RFC <NUM>, may be created in each MS-OTN NE for the DCN VPN instance, and a full mesh of PWs may be setup to connect these VSIs. For example, with reference to <FIG>, the GNE A receives untagged Ethernet frames carrying DCN messages from the high-speed local Ethernet interfaces. It may associate these frames to the VSI assigned to the DCN VPN, may learn that the MAC SA is reachable through that interface and may forward the frames based on their MAC DA:.

The MPLS-TP packets of the LSPs setup between GNE A and NEs B, C and D may then be forwarded to NE B using the ODUk connection <NUM> setup between GNE A and NE B. NE B then receives MPLS-TP packets for all these LSPs and takes forwarding decision based on the LSP label at the top of the label stack:.

Another possibility is to configure a L3VPN instance within the MS-OTN to carry the packets/DCN traffic. In this case the SDN controller <NUM> and all the network nodes <NUM> (MS-OTN NE) control cards reachable through the same GNEs belong to the same layer-<NUM> network (e.g., IP or OSI CLNP) and use standard layer-<NUM> IP forwarding mechanisms to exchange layer-<NUM> packets. MS-OTN NEs forward the DCN messages using layer-<NUM> switching, as shown in ITU-T Figure <NUM>-<NUM>/G. <NUM>, based on the layer-<NUM> Destination Address (e.g., the IP DA) field of the layer-<NUM> packets (e.g. the IP packets).

For example, with reference to <FIG>, GNE A receives IP packets carrying DCN traffic from the SDN controller <NUM> and it may process (within the control card) those with the IP DA matching its control card IP address and forward to NE B, through the ODUk connection <NUM>, all the other IP packets.

There are multiple ways to implement L3VPN over MS-OTN networks. Any option can be used depending on the MS-OTN network capabilities and/or operator's preference. One option is similar to the Ethernet Bridging (IEEE <NUM>. 1Q) solution described above where each MS-OTN NE performs L3 forwarding instead of L2 bridging. Standard IP forwarding procedures are used to forward the IP packets carrying DCN messages among these IP interfaces. The VLAN tag (either a C-VLAN or an S-VLAN) can be or not used on the high-speed local Ethernet interfaces as well as the ODUk connections setup for DCN traffic depending on whether the IP interfaces are or not channelized.

For example, with reference to <FIG>, the GNE A receives untagged Ethernet frames encapsulating IP packets carrying DCN messages from the high-speed local Ethernet interfaces. It may terminate these Ethernet frames and may associate the encapsulated IP packets to the DCN VPN and may forward the packets based on their IP DA. Packets with the IP DA equal to the GNE A control card IP address will be passed to the control card (CC) for local processing. All the other packets are transmitted to the ODUk connection <NUM> setup between NE A and NE B, either because the IP DA is known (either from dynamic routing information or by static routing configuration) to be reachable through that port or because of default routing configuration. If the ODUk connection <NUM> is configured as a channelized IP interface, the forwarding IP packets are encapsulated into VLAN tagged Ethernet frames, otherwise they are encapsulated into untagged Ethernet frames.

NE B then receives either untagged or VLAN tagged Ethernet frames encapsulating IP packets carrying DCN messages from that ODUk connection. It may terminate these Ethernet frames and may associate the encapsulated IP packets to the DCN VPN either based on the ODUk connection (in case of untagged Ethernet frames) or based on the VLAN ID (VID) carried in the VLAN tag (in case of VLAN tagged Ethernet frames). In both cases, it may forward the packets based on their IP DA. Packets with the IP DA equal to the NE B control card IP address may be passed to the control card (CC) for local processing. All the other packets are transmitted to the ODUk connection <NUM> setup between NE B and NE C either because the IP DA is known (either from dynamic routing information or by static routing configuration) to be reachable through that port or because of default routing configuration.

Another option is the L3 VPN over MPLS-TP which is similar to the L2VPN over MPLS-TP solution described above where each MS-OTN NE instantiates a Virtual Routing Function (VRF), performing L3 forwarding, instead of a VSI, performing L2 forwarding. When using the MPLS-TP L3VPN solution, a VRF, as defined in RFC <NUM>, is created in each MS-OTN NE for the DCN VPN instance and a full mesh of MPLS-TP LSPs is setup to connect these VRFs.

For example, with reference to <FIG>, the GNE A receives untagged Ethernet frames encapsulating IP packets carrying DCN messages from the high-speed local Ethernet interfaces. It terminates these Ethernet frames and associates the encapsulated IP packets to the VRF assigned to the DCN VPN and forwards the packets based on their IP DA:.

The MPLS-TP packets of the LSPs setup between GNE A and NEs B, C and D are then forwarded to NE B using the ODUk connection setup between GNE A and NE B. NE B then receives MPLS-TP packets for all these LSPs and takes forwarding decision based on the LSP label at the top of the label stack:.

This application notably assumes that interworking functions, if any, between different layer-<NUM> protocols (e.g., interworking between OSI and IP) are implemented outside the MS-OTN DCN although nothing precludes implementing these functions also within the MS-OTN NEs.

Another possibility is to configure a packet-based VPN <NUM> instance within the MS-OTN to carry the DCN traffic with more flexibility in defining the rules to be used for packet-based forwarding, such as those defined in the Open Flow specification (ONF TS-<NUM>). In this case the SDN controller <NUM> and all the MS-OTN NE (network nodes <NUM>) control cards reachable through the same GNEs belong to the same layer-<NUM> network (e.g., IP or OSI CLNP) and use flexible packet forwarding mechanisms to exchange layer-<NUM> packets at least between the MS-OTN NEs. MS-OTN NEs forward the packets/DCN messages based on flexible and configurable flow classification rules, which should at least include the layer-<NUM> Destination Address (e.g., the IP DA) field of the layer-<NUM> packets (e.g., IP packets).

For example, with reference to <FIG>, GNE A receives IP packets carrying DCN traffic from the SDN controller and it would process (within the control card) those with the IP DA matching its control card IP address; forward to NE B, through the ODUk connection <NUM>, all the other IP packets which matches some classification rules used to identify DCN traffic, with high throughput and/or low latency requirements, and forward to NE B, through the existing GCC channels, all the other IP packets. There are multiple ways to implement this option over MS-OTN networks. Any option can be used depending on the MS-OTN network capabilities and/or operator's preference.

DCN VPNs <NUM> need to be configured by a network management application which setup the ODUk connections <NUM> used to carry the DCN messages as well as the DCN VPN <NUM> and its forwarding rules. Since this application does not require high-throughput nor low-latency DCN forwarding, the existing DCN channels defined by current ITU-T Recommendation G. <NUM> (called soft control channels) can be used. Therefore, MS-OTN NEs shall support existing DCN channels (soft control channels) in addition to the new DCN channels (hard control channels) and care should be taken to avoid forwarding DCN traffic with high bandwidth and/or low latency requirements through the control card (e.g., via the GCC channels).

One possibility is to instantiate a separated DCN instance (i.e., a separated layer-<NUM> network instance) for the applications requiring high bandwidth and/or low latency. Since the layer-<NUM> networks are separated, all the options described above (e.g., L2VPN or L3VPN) could be used to forward DCN traffic with high-throughput and/or low-latency requirements between MS-OTN NEs.

Another possibility is to setup a shared DCN instance (i.e., a single layer-<NUM> network instance) and to allocate different IP addresses to the functional components requiring high bandwidth and/or low latency: IP routing protocols should be properly configured to ensure traffic separation. Since the IP addresses are separated, all the option described above (e.g., L2VPN or L3VPN) could be used to forward DCN traffic with high-throughput and/or low-latency requirements between MS-OTN NEs. In case a L2VPN solution is used, the IP addresses of the functional components requiring high bandwidth and/or low latency should belong to a different IP sub-network than the IP addresses assigned to other DCN components.

Another possibility is to have both a shared DCN instance (i.e., a single layer-<NUM> network) and shared IP addresses and to separate the different type of DCN traffic based on some flexible and configurable flow classification rules: in this case, flow forwarding rules should be properly configured to ensure traffic separation. Since the IP addresses are shared, only the latter solution based on flow-forwarding could work in this case.

All the MS-OTN NEs which are not GNE should ensure that:.

On the GNE, the DCN traffic with high-throughput and/or low-latency requirements can be received from the SDN controller <NUM> either via dedicated high-speed Ethernet interfaces attached to the MS-OTN line card (while all the other DCN traffic is received via low-speed Ethernet interfaces attached to the control card) or via shared Ethernet LAN interfaces (usually the high-speed interfaces attached to the MS-OTN line cards) together with other DCN traffic. In the former case (separated Ethernet LAN interfaces), the different types of DCN traffic are separated by the SDN controller <NUM> (or by the WAN gateway router, if present) and the MS-OTN GNEs should only maintain traffic separation following the rules defined above for all the other MS-OTN NEs. In the latter case (shared Ethernet LAN interfaces), the MS-OTN GNE should also separate the different types of DCN traffic:.

<FIG> shows another DCN network including network nodes <NUM> and a network a device <NUM> according to embodiments of the invention, similar as shown in <FIG>. However, the DCN network shown in <FIG> includes network nodes <NUM> according to embodiments of the invention and other network nodes <NUM>. In this case, where there are both network nodes <NUM> (here MS-OTN NEs) and network nodes <NUM> (OTN NEs, not being capable of forwarding DCN messages in the packet layer), it is possible to apply multi-layer DCN network design (in addition to the optional multi-layer optimization) such that:.

OTN NEs can also terminate the packets/DCN traffic addressed to their control card and carried within terminated ODUk or sub-<NUM> OTN frames. Therefore, it is also possible to design the network with MS-OTN GNEs implementing a DCN VPN <NUM> to forward packets/DCN messages between the high-speed local Ethernet interfaces, the GNE control card (CC) and a set of OTN connections (either ODUk or sub-<NUM> OTN) between the GNE and each other OTN NEs to be controller <NUM>.

<FIG> describes an example of an MS-OTN NE implementation, i.e. an exemplary implementation of a network node <NUM> according to an embodiment of the invention, as e.g. described with respect to <FIG>.

The following elements of the MS-OTN NE implementation are relevant. A switch matrix card, which is capable to switch both ODUk and packets. It can be implemented as either universal switch <NUM> (as shown in <FIG>) or as two matrices on the same card: the difference is usually not visible externally to the box.

A control card <NUM>, which is used to terminate packets/DCN messages addressed to this network node <NUM> and to forward other packets/DCN messages between GCC channels and/or Ethernet LAN interfaces attached to this card (soft control channels).

Line cards <NUM>, which support OTN and Ethernet LAN interfaces. MS-OTN can support universal line cards (where both OTN and Ethernet LAN interfaces can be attached) and/or a mix of dedicated packet line cards (where only Ethernet LAN interfaces can be attached) and OTN line cards (where only OTN interfaces can be attached).

A key characteristics is that the network node <NUM> can support both OTN and Ethernet LAN interfaces and can switch the traffic between these interfaces at either ODUk or packet layers. In this example, an implementation based on a universal line card <NUM> and a universal switch <NUM> is explained.

<FIG> describes examples of the components of a universal line card <NUM>. The Line Interface <NUM> component terminates OTN and/or Ethernet LAN interfaces. The traffic for the interfaces attached to the same line card <NUM> is processed by the same Processing Unit <NUM>. The Processing Unit <NUM> will process the traffic (e.g., Ethernet and/or ODUk frames) received from the line, as specified in relevant standards, understand to which connection (packet-based or ODUk) the traffic belongs to and decide how it has to be further processed. The traffic to be forwarded will be passed to either the Packet or the ODUk Switching Unit (Universal Switch <NUM>), together with the information needed to properly forward it toward the egress: the packet traffic is passed to the Packet Switching Unit <NUM> while ODUk traffic is passed to the ODUk Switching Unit <NUM>. The Processing Unit <NUM> also extracts the DCN traffic from the ODUk GCC channels and send it to the Control Card. The Processing Unit <NUM> is also responsible to properly formatting the egress traffic, received from the Switching Units, for being transmitted toward the line. The Processing Unit <NUM> also forwards the DCN traffic received from the Control Card within the GCC channels.

In order to implement the network node <NUM>, the Processing Unit <NUM> should be configured to understand which packets <NUM> received from the line (either from the Ethernet LAN interfaces or from a terminated ODUk connection within an OTN interface) carry DCN traffic and either based on the MAC DA field (L2VPN implementation option) or on the IP DAfield (L3 VPN implementation option) or on flexible flow classification rules (flow-based VPN option). These packets <NUM> are sent to the Packet Switching Unit, together with the information needed to properly forward it toward the egress, as if they were user packets. The terminated DCN messages can be forwarded to the control card either by the universal switch or by the Processing Unit. This is an internal implementation decision not visible from the outside of the network node <NUM>.

Within the control card, the "DCN Application" is responsible to process the terminated DCN messages while the "DCN Forwarding" component is responsible to send terminated DCN messages to the "DCN Application" component and to forward pass-through DCN messages towards other GCC channels and/or Ethernet LAN interfaces attached to the Control Card. <FIG> describes all the possible ways packets/DCN traffic can be forwarded through an MS-OTN NE (network node <NUM>) according to an embodiment of the invention.

<FIG> shows a method <NUM> according to an embodiment of the invention. The method <NUM> can be performed at a network node <NUM>, e.g. the network node <NUM> shown in <FIG>, <FIG> or <FIG>. The method <NUM> includes: a step <NUM> of receiving a plurality of packets <NUM> carrying DCN messages, a step <NUM> of determining <NUM>, from the received packets <NUM>, a first set <NUM> of packets <NUM> addressed to other network nodes of the DCN, and step <NUM> of forwarding the first set <NUM> of packets <NUM> over a TDM, connection <NUM> to a determined network node <NUM> of the DCN.

Claim 1:
Network node (<NUM>) for a Data Communication Network, DCN, providing communication between telecommunications management network components, characterized in that the network node (<NUM>) is configured to:
receive a plurality of packets (<NUM>) carrying DCN messages, wherein the DCN messages are messages transported over the DCN and comprise management messages, or signaling and routing protocol messages, or big data information on network status;
determine, from the received packets (<NUM>), a first set (<NUM>) of packets (<NUM>) addressed to other network nodes of the DCN, and
forward the first set (<NUM>) of packets (<NUM>) over a Time-Division-Multiplexing, TDM, connection (<NUM>) to a determined network node (<NUM>) of the DCN,
wherein the TDM connection (<NUM>) is an Optical Data Unit-k, ODUk, connection,
wherein for determining and forwarding the first set of packets, the network node (<NUM>) is configured to determine and forward the first set of packets based on a packet-based Virtual Private Network, VPN (<NUM>).