HK1170607B - Methods and arrangement in a mpls-tp telecommunications network for oam functions - Google Patents

Abstract

Extensions to a Multi-Protocol Label Switching (MPLS) frame forwarding procedure in an MPLS node are described. A context descriptor is defined for each frame received on a connection terminated at that node, and where this context descriptor is provided together with the frame to a corresponding function (e.g. Operations, Administration and Maintenance, OAM) if needed. The context descriptor is constructed based on key attributes characterizing the terminated connection, over which the frame is received, and addresses a particular function endpoint (Maintenance Endpoints (MEPs), Selector Bridge of a protection instance etc.) of a corresponding function (OAM, protection, etc.). In one embodiment, a Multi-Protocol Label Switching (MPLS) node is directed to check not only the first but also the second label, and not to drop the first label (and the label space if relevant) when the second label is the Generic Association Channel Label (GAL). In this way, the original context of the packet is kept (i.e. the information relating to the connection over which the packet was received), and can be used for de-multiplexing to the corresponding MEP. Then the identifiers within the OAM payload can be used for verification of the connectivity. Other embodiments describe alternative solutions.

Description

Method and apparatus for OAM function in MPLS-TP communication network

Technical Field

The present invention relates to communications networks and in particular, but not exclusively, to a method and apparatus for addressing maintenance points in nodes of a packet switched transport network.

Background

Multiprotocol label switching (MPLS) is a mechanism in a communication network that directs and carries data packets from one node to other nodes. Each data packet includes a label stack based on which forwarding decisions are made without regard to the remainder of the packet.

Based on the existing MPLS forwarding plane, the multi-protocol label switching transport plane (MPLS-TP) aims to provide a framework that meets transport network requirements. One key area is to have a well-defined set of operations, administration and maintenance (OAM) functions. The OAM function set is standardized by the Internet Engineering Task Force (IETF). The OAM framework and requirements define several functions (continuity check (CC), Connectivity Verification (CV), management signals, etc.) that the developed OAM solution should support.

The operation of OAM for MPLS-TP is to encode the necessary OAM attributes (identifiers, timers, counters, etc.) in so-called OAM frames multiplexed into the data stream. In this way, an ad hoc sharing of the OAM frame and the data flow is guaranteed, i.e. the OAM frame and the data flow undergo the same forwarding process from one node to another. OAM frames are generated and received by Maintenance Endpoints (MEPs) residing at the endpoints of the connection.

Currently, the MPLS-TP architecture includes three layers: a Pseudowire (PW) layer, a Label Switched Path (LSP) tunnel (connection) layer, and a segment (data link) layer. MPLS-TP OAM is set to support all three layers.

Currently, several competitive solutions for encoding OAM parameters are proposed. However, these schemes are based on the same approach of multiplexing OAM frames into a data stream. The method defines an associated channel for carrying OAM frames and other control/management frames. In the case of PW, these channels are identified and demultiplexed using only the generic associated channel header (G-ACH). In the case of LSP tunnels and segments, additional labels are defined to indicate the associated channels. This label is called the generic associated channel label (GAL). The egress side (i.e., the destination side) detects and demultiplexes the OAM frame based on these labels.

However, these solutions relying on the transport of OAM frames within G-ACH have the following problems in MPLS and MPLS-TP: in the case of LSP tunnel and segment layers, standard MPLS data forwarding mechanisms do not provide an adequate way to address MEPs from the data plane using identifiers that are also used for data plane forwarding.

The standard MPLS forwarding behavior at a particular node is as follows. Based on the first label (tunnel label) in the stack, the node looks up the Next Hop Label Forwarding Entry (NHLFE). This entry instructs the node what to do with the label stack (pop the first label, change the value of the first label, push the new label on top of the stack) and to which to forward the packet (next hop node).

If the node is the egress node of the terminating connection, the NHLFE is encoded to instruct the node to remove (i.e., pop) the tunnel label from the stack and perform a lookup for the remaining packets. If there are any other labels in the stack, a second independent lookup for the next label is performed on the stack. For example, the second tag may be a GAL, indicating that the packet should be passed to a control function of the local node, and removing the GAL from the frame. The control function of the node may then process the frame and send the OAM packet to the correct MEP.

Fig. 1 shows an MPLS packet structure that may be used in the forwarding mechanism described above. The label stack comprises, for example, the outermost label, which is the LSP tunnel label. This may take the form of a label that explicitly identifies the egress node or a time-to-live (TTL) label that determines the egress node based on the hop count. The associated channel header contains information processed by the G-ACH demultiplexing process, while the G-ACH message payload contains the packet's payload, e.g., the OEM payload to be sent to the MEP.

Thus, it should be understood that the MPLS data plane does not allow for the use of data plane attributes (e.g., labels in the data plane) to address a particular MEP. Instead, MEPs can only be addressed by demultiplexing the OAM payload and using an identifier (i.e., routing information) within the OAM payload for addressing the appropriate MEP.

After demultiplexing to the corresponding MEP, the identifiers contained in the OAM payload should be used to verify correct connectivity. Although these identifiers are unique at the node or network level, it is not possible to identify on which connection a packet is received, i.e. if there are multiple parallel connections between ingress and egress nodes, it is not possible to identify an incoming (incoming) connection. Furthermore, as described above, neither the tunnel label (first label) nor the ingress interface is available after the OAM payload has been demultiplexed. This means that it is not possible to verify correct connectivity, i.e. to perform a complete Connectivity Verification (CV) operation.

A known solution proposed for MPLS-TP OAM connectivity verification is a link trace based approach. However, this solution involves complex processing on the end points of the connection and on all intermediate nodes of the forwarding connection, since the method is originally designed for different functions. The disadvantages are that: consuming an undesirable amount of processing resources. This link tracking based approach also has the disadvantage of being not easily scalable.

Disclosure of Invention

The present invention proposes an extension to the existing multi-protocol label switching (MPLS) frame forwarding process in an MPLS node, wherein a context descriptor is defined for each frame received on a connection terminated at the node, and wherein the context descriptor is provided with the frame to the corresponding function (e.g., operations, administration and maintenance, OAM) as needed. The context descriptor is constructed based on key attributes characterizing the terminated connection on which the frame is received and addresses the specific function end-point (maintenance end-point (MEP), selector bridge protecting instance, etc.) of the corresponding function (OAM, protection, etc.). As such, the context descriptor will contain some key attributes that characterize (i.e., identify) the terminated connection (e.g., the connection on which the frame was received).

In one embodiment, a multi-protocol label switching (MPLS) node is directed to examine not only a first label but also a second label, and not to discard the first label (and associated label space) when the second label is a generic associated channel label (GAL). In this way, the original context of the packet is preserved (i.e., information about the connection over which the packet was received) and can be used for demultiplexing to the corresponding MEP. The identifier within the OAM payload may then be used to verify connectivity.

For example, in one embodiment, the present invention provides a method in a node of a multiprotocol label switching (MPLS) communication network. The method comprises the following steps: receiving an MPLS frame having a label stack comprising one or more labels; and determining whether the frame has reached its terminating node. If the frame has reached its terminating node, a second tag in the tag stack is examined to determine if the second tag is related to a generic associated channel tag (GAL). If the second label is related to a generic associated channel label GAL, a context descriptor is obtained for use during further processing of the frame and the frame is routed for generic associated channel header (G-ACH) processing.

In another embodiment, expiration of a time-to-live (TTL) value is used. Here, the source MEP knows (by configuration or by measurement) the hop (hop) distance of the destination MEP. The TTL value of the resulting frame containing the OAM information will be set accordingly. These frames will therefore experience TTL expiry at the destination node, resulting in forwarding of all frames containing OAM packets to the control function of the destination node. Thus, the full context (including the tag) of the frame exists and can be used to address the corresponding MEP.

In yet another embodiment, a dedicated label space is specified for each monitored connection and used to address MEPs.

According to another embodiment of the present invention, a node of a multiprotocol label switching (MPLS) communication network is provided. The node comprises: receiving means for receiving an MPLS frame having a label stack comprising one or more labels. The node is configured to determine whether the frame has reached its terminating node, and if the frame has reached its terminating node, to check a second label in the label stack to determine whether the second label is related to a generic associated channel label (GAL). If the second label is related to a generic associated channel label, the node is configured to obtain a context descriptor for use during further processing of the frame and to route the frame for generic associated channel header (G-ACH) processing.

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:

fig. 1 illustrates an MPLS packet structure;

figure 2 illustrates part of a packet switched network;

FIG. 3 is a flow chart describing steps of a method according to an embodiment of the invention;

FIG. 4 is a flow chart describing steps of a method according to another embodiment of the invention;

FIG. 5 is a flow chart describing steps of a method according to another embodiment of the invention;

FIG. 6 is a flow chart describing steps of a method according to another embodiment of the invention;

FIG. 7 is a flow chart describing steps of a method according to another embodiment of the invention; and

fig. 8 is a schematic diagram of a node according to an embodiment of the present invention.

Detailed Description

Embodiments will be described below in the context of performing operations, administration and maintenance (OAM) functions at a node and using identifiers in an OAM payload to enable connection verification to be performed. It should be noted, however, that the application of the present invention may be broader than performing only OAM functions, and may also be broader than merely verifying the connection over which the frame is received.

Fig. 2 shows part of a packet-switched network 10.

An MPLS-capable ingress node 12 (acting as a label edge router ("LER")) sends a label-switched flow of packet traffic (e.g., Internet Protocol (IP) traffic) through intermediate nodes 14, 16 to an egress node 18, each node 14, 16 acting as a label-switched router ("LSR").

Each traffic flow between successive nodes 12, 14, 16, 18 is labeled or tagged with a unique label that identifies each flow between two adjacent nodes as being a member of a particular "forwarding equivalence class" (FEC) that points to a particular subsequent (or "downstream") LSR. The label forms part of a "label stack" that may have one or more labels. Each downstream LSR receives the traffic and reads the first label in the label stack. The label is then matched against its own entry in the Incoming Label Mapping (ILM) table indicating which NHLFE to apply, and the referenced entry is read from the Next Hop Label Forwarding Entry (NHLFE) table, subject to the forwarding direction in the table associated with the entry. Thus, the NHLFE table describes the manner in which the frame is treated (e.g., forwarded, outer label removed, sent to node Y, etc.), and for the intermediate LSR node 14, 16, will include at least the next hop for the packet, and the operations to be performed on the label stack.

The nodes 12, 14, 16, 18 may define Label Switched Path (LSP) tunnels. In such a case, the first label on each packet forwarded between ingress node 12 and egress node 18 is a tunnel label identifying tunnel path 12- >14- >16- > 18. At the egress node 18, the tunnel label is popped (i.e., removed) from the label stack and the packet is forwarded to its next destination node based on the second label or based on the packet contents if no such second label exists in the label stack, in accordance with the prior art. Where the second label is a generic associated channel label (GAL), the packet may be forwarded to a generic associated channel header (G-ACH) processing function of node 18, and in the example of an OAM function, from there to a Maintenance End Point (MEP). However, the tunnel label is lost.

According to the present invention, the existing multi-protocol label switching (MPLS) frame forwarding process is extended at an MPLS node, wherein a context is defined for each frame received on a connection terminated at the node, and wherein the context is provided to a corresponding function (e.g., OAM) along with the frame as needed. The context is constructed based on key attributes characterizing the terminated connection over which the frame is received, and addresses a particular function endpoint (maintenance endpoint (MEP), selector bridge protecting instance, etc.) of the corresponding function (OAM, protection, etc.).

In a first embodiment, the MPLS node is directed to examine not only the first label but also the second label, and not to discard the first label (and associated label space) when the second label is a generic associated channel label (GAL). In this way, the original context of the packet is preserved (i.e., information about the connection over which the packet was received) and can be used for demultiplexing to the corresponding MEP. The identifier within the OAM payload may then be used to verify connectivity. It should be noted that if a context-specific label space or label space per interface is used, the label space is considered relevant, in which case the label value alone cannot fully identify the connection.

Fig. 3 shows the steps performed by the present invention according to an embodiment of the present invention. In step 201, the node receives an MPLS frame. The frame is then examined in step 203 to determine whether the node is an end point of the LSP tunnel, i.e., the egress node. For example, in one embodiment (described in detail below in fig. 4), a first label of the MPLS frame is checked in step 203, where the first label indicates that the node is an end point of an LSP tunnel. According to another embodiment (described in detail below in fig. 5), time-to-live (TTL) information received in an MPLS frame is used to determine whether the node is an end point of an LSP tunnel.

If it is determined in step 203 that the node is not an end point of the LSP tunnel, processing continues in step 211 for the frame in the normal manner, e.g., checking for the next hop, and forwarding the frame accordingly.

If it is determined in step 203 that the node is an end point of an LSP tunnel, a second label of the MPLS frame is also checked in step 205. In step 207, it is determined whether the second tag is GAL,.

If it is determined in step 207 that the second label is not a GAL, the MPLS frame is processed in a conventional manner in step 209, thereby popping up the first label, and processing of the frame continues in a normal manner in step 211, e.g., checking for the next hop, and forwarding the frame accordingly.

However, if it is determined in step 207 that the second tag is a GAL, a context descriptor is obtained in step 213 based on the attributes of the forwarding step. For example, the context descriptor may be constructed using a tunnel label (i.e., the first label) and a label space, or using the NHLFE key value. Once the context descriptors have been obtained, the MPLS frame may be processed in a conventional manner by sending the frame to higher layers in step 215, for example by sending the frame to a G-ACH demultiplexing operation together with the context descriptors obtained in step 213. The context descriptor obtained in step 213 is retained and may be used for further processing, such as Connectivity Verification (CV), Continuity Check (CC), or other functions that may require identification of the origin of the frame.

As mentioned above, one way to obtain the context descriptor is to store a first label that would otherwise be lost during the pop-up operation performed on the first label. Fig. 4 shows the steps performed in such an embodiment of the invention. In step 301, the node receives an MPLS frame. Next, the first label of the MPLS frame is checked in step 303. It is determined whether the first label indicates that the node is an endpoint by determining whether a POP (POP) operation is to be performed in step 304. If it is determined in step 304 that the node is not an end point in the LSP tunnel, processing of the MPLS frame continues in step 313 in a conventional manner, e.g., checking for a next hop and forwarding the frame accordingly.

If the first label indicates that the node is an endpoint, then according to this embodiment, the first label is stored in step 305. Next, a second label of the MPLS frame is checked in step 307, and it is determined whether the second label is a GAL in step 309.

If it is determined in step 309 that the second tag is not a GAL, then the first tag is popped in step 311, which results in discarding the first tag. The MPLS frame then continues to be processed in a conventional manner in step 313, for example to check for a next hop and forward the frame accordingly.

However, if it is determined in step 309 that the next label is a GAL, the MPLS frame may be processed in a conventional manner by, for example, demultiplexing the GAL and G-ACH in step 317 and sending the MPLS frame to higher layers in step 319, without discarding the first label (which was previously stored in step 305). Thus, it should be appreciated that the storage of the first tag in step 305 enables the context of the incoming frame to be obtained and retained for further processing, such as verifying a connection or continuity check. The first tag may be stored by storing a copy of the tag value in a designated memory different from the tag stack. Alternatively, the first label may be stored in a memory provided for storing a history of label stacks, such that the history thereby provides the desired context. It should be noted that for this purpose it is sufficient to store in the history only the last processed tag.

Although the embodiment of fig. 4 also shows the first label being stored before the second label is checked, it should be noted that the first label may be stored in other instances or in other ways as long as it is stored before the first label is ejected and can be retained after the first label is ejected.

In one application example, the embodiments described in fig. 3 and 4 may involve demultiplexing the OAM payload and then directing the frame to the desired MEP. However, it should be understood that the present invention is also applicable to other applications that require a context for an incoming frame based on key attributes characterizing the terminated connection over which the frame is received.

Fig. 5 is a flow chart illustrating a more specific application of the present invention in an egress node 18 according to an embodiment of the present invention. This embodiment shows how generic MPLS data plane operations (e.g., Internet Engineering Task Force (IETF) RFC 3031) can be extended.

In step 401, an MPLS frame is received. This embodiment is shown with a time-to-live (TTL) mechanism operating in conjunction with the present invention. TTL mechanisms are provided in MPLS systems to indicate how many hops a frame must perform before reaching its intended destination. This may be used, for example, to ensure that a misconfigured loop (e.g., a ring LSP) does not result in frames being forwarded all the time. Thus, in step 403, it is first determined whether a time-to-live (TTL) value reaches a predetermined value, e.g., 1, indicating that the frame has expired. If so, the frames are sent to a TTL expiration module in step 405 and the expired frames are processed in a conventional manner. It should be noted that the use of a TTL mechanism is not necessary for the embodiment of fig. 5.

Assuming that the received frame has not expired, the tag space is identified in step 407. This step may include identifying the appropriate Input Label Mapping (ILM) table for processing that particular frame. One ILM is defined for each label space. Based on the node configuration, each received frame is assigned a label space value that enables selection of an ILM table. For example, one specific label space may be defined for one specific interface and a second label space may be defined for a set of other interfaces, thereby giving two ILM tables.

Next, the tag value of the first tag in the tag stack is checked in step 409. If the first tag is not a GAL (e.g., because the GAL is the second tag in the tag stack), then processing moves to step 411. In step 411, the NHLFE key is found using the first label (i.e., the outermost label). The NHLFE key identifies a particular NHLFE in the NHLFE table. The NHLFE key may be, for example, a line number. In step 413, the NHLFE opcode (i.e., retrieved through the NHLFE key in step 411) is checked to determine the attributes of the NHLFE opcode.

If it is determined in step 413 that the NHLFE opcode is any opcode other than the POP opcode (e.g., swap, push a new tag, etc.), then processing moves to step 415. Next, the next hop is checked in step 417. If the next hop is indicated as the same node, the process returns to step 403, where the process begins again in step 403. If it is determined in step 417 that the next hop is indicated as another node, the frame is processed in step 419 according to RFC3031 packet forwarding operations, and is sent accordingly in step 421.

If it is determined in step 413 that the NHLFE opcode is a POP opcode, then it is determined in step 423 whether the MONITORED-CONECTION (MON _ CON) status bit is set and whether the second tag in the tag stack is a GAL. It should be noted that the (MON CON) bit is an optional feature that provides for indicating that a connectivity check is required at some point during subsequent processing of the frame, thus requiring the context (e.g., the first tag) to be stored. Thus, the (MON CON) bit serves as an indication to "peek" at the second tag to determine whether the second tag is a GAL. The MON CON status bit is located in the NHLFE (and may be considered an attribute of an entry in the NHLFE table).

If it is determined in step 423 that the MON CON bit is not set or the second tag is not GAL, the process proceeds to step 425, the first tag is popped in step 425 (e.g., according to RFC 3031), and then the process moves to step 417, and the next hop is checked in step 417. It should be noted that in conventional systems, when the NHLFE is determined to be a POP opcode in step 413, processing would simply move from step 413 to step 425.

The process from step 425 continues as described above. In other words, if it is determined in step 417 that the next hop is indicated as the same node, the process returns to step 403, and the process starts again in step 403. If it is determined in step 417 that the next hop is indicated as another node, the frame is processed in step 419 according to RFC3031 packet forwarding operations, and is sent accordingly in step 421.

Returning to step 423, if it is determined that the MON _ CON bit is set and the second tag is a GAL, the process moves to step 427, in step 427, the GAL and G-ACH are demultiplexed (e.g., according to RFC 5586), and the frame is then sent to the higher layer in step 429. In this way, the first label is not popped, which means that the first label will still be available for future use by the system, e.g. to verify a connection, a continuity check, etc. The first label may remain in the memory in which it is stored while waiting to be ejected in step 425, or stored elsewhere for future processing. It should be noted that the above-described embodiments avoid further lookups to identify the GAL as a top-of-stack label, which would otherwise normally be required.

When used in applications relating to OAM payloads, the demultiplexing and sending steps 427, 429 may include demultiplexing OAM payloads and sending frames to MEPs.

Thus, it should be appreciated from the above that if the first label and label space are available in step 423, the first label and label space may be passed to the G-ACH processing function of step 427 as part of the context descriptor. There may be situations where the first tag or tag space is lost before the time at which the process reaches step 423. However, the NHLFE may still provide context if the first label or label space has been lost, but in the latter case the NHLFE must be connection-specific, i.e. the NHLFE cannot encode the forwarding behavior of more than one connection endpoint. This limitation is satisfiable in MPLS-TP for other purposes.

Although not explicitly shown in fig. 5, the method further includes the step of examining the incoming label to determine if the first label is not at the bottom of the label stack. This can be provided as an initial check, thus saving unnecessary processing.

It should be appreciated that the embodiment depicted in FIG. 4 performs a form of "two-tag check," i.e., checking a first tag and then checking a second tag. Depending on implementation-specific implementation options, instead of this double label check, the method may include the step of preserving the original MPLS behavior and storing the removed first label and label space, thus incorporating a method similar to that of fig. 4. In other words, the first tag is not stored until such time as when the second tag has been checked, and if the first tag is not needed, the first tag is discarded, but if the first tag is needed for future processing, the first tag is retained. For example, after a second lookup and removal of the second (GAL) tag, the stored context may be discarded unless OAM CV G-ACH is found. An alternative solution to this discarding is to check not only the first label and the second label, but also the possible OAM G-ACH, and to save the first label and the context only if an OAM G-ACH is found.

In this way, the original context of the packet is available to the ACH processing function and can be used to address the corresponding MEP. The identifier within the OAM payload may then be used to verify connectivity or check continuity.

As can be seen from the above, the embodiment of fig. 5 may have an additional optional function, wherein an additional flag in the form of a "MONITORED _ CONNECTION" flag is provided in the corresponding NHLFE, indicating that the second tag needs to be checked. Such explicit indication has the following advantages: system performance is improved because the checking of the second tag is performed only if needed, rather than every instance.

It should be noted that during the setup process, the flag may be explicitly transmitted from the source to the destination node (e.g., an optional TLV or new bit may be used in RSVP-Path (RSVP-Path) messages when setting up the LSP) or may be set based on deductions from other received parameters (e.g., configuration of OAM).

It will be appreciated that the invention as described in the embodiment of figure 5 has the following advantages: the first tag (i.e., context descriptor) is made available for future processing, e.g., for performing connection verification or continuity checks.

Fig. 6 is a flow chart illustrating a method in the egress node 18 according to another embodiment of the present invention. As with fig. 5, this embodiment shows how generic MPLS data plane operations (e.g., Internet Engineering Task Force (IETF) RFC 3031) may be extended. The embodiment of fig. 6 provides a new mechanism for identifying associated channels by reusing the TTL expiration mechanism defined for MPLS.

In step 501, an MPLS frame is received. As with fig. 5, the embodiment of fig. 6 is shown operating with a time-to-live (TTL) mechanism. TTL mechanisms are provided in MPLS systems to indicate how many hops a frame must perform before reaching its intended destination. Assuming that the source MEP knows the hop distance to the destination MEP, the source node sets the TTL field in the LSP identification label to this hop count for any frame carrying a G-ACH message. At the destination node, TTL expiration will occur and the entire context is available for processing functions. This is described in further detail below.

In step 503, it is first determined whether a time-to-live (TTL) value has reached a predetermined value, e.g., 1, indicating that the frame has expired. If so, the process moves to step 525 where it is determined whether the GAL is the next (second) tag in step 525. If the GAL is not the next (second) tag, processing moves to step 527 whereupon, in step 527, the frame is sent to a TTL expiration module and such expired frames are processed in a conventional manner.

If it is determined in step 525 that the GAL is the next (second) tag, the process moves to step 521, demultiplexes the GAL and G-ACH (e.g., according to RFC 5586) in step 521, and then sends the frame to higher layers in step 523. At the AH processing function of the destination node, the full context (including the label) of the packet exists and can be used to address the corresponding MEP. This is because the GAL and G-ACH are demultiplexed without performing POP operations on the outermost tag that would result in the loss of context. The identifier contained within the OAM payload may then be used, for example, for connectivity verification or continuity check.

If it is determined in step 503 that the received frame has not expired, indicating that the node is not an egress node, the MPLS mechanism operates in a conventional manner, with the label space identified in step 505. This step may include identifying the appropriate Input Label Mapping (ILM) table for processing that particular frame.

Next, the first tag value is checked in step 507. If the first tag is not a GAL (e.g., because the GAL is the next (second) tag in the tag stack), then processing moves to step 509. In step 509, the NHLFE key is found using the outermost label. The NHLFE key identifies a particular NHLFE in the NHLFE table. The NHLFE key may be, for example, a line number. In step 511 the NHLFE opcode (i.e. retrieved in step 509 by the NHLFE key) is checked to determine the attributes of the NHLFE opcode.

If it is determined in step 511 that the NHLFE opcode is any opcode other than a POP opcode (e.g., swap, push a new tag, etc.), then processing moves to step 513. Next, the next hop is checked in step 515. If the next hop is indicated as the same node, the process returns to step 503 and the process starts again in step 503. If it is determined in step 515 that the next hop is indicated as another node, the frame is processed in step 517 in accordance with RFC3031 packet forwarding operations, and is transmitted accordingly in step 519.

If it is determined in step 511 that the NHLFE opcode is a POP opcode, processing proceeds to step 522, where the first tag is popped (e.g., according to RFC 3031) in step 522, and then processing proceeds to step 515 where the next hop is checked in step 515. Note that step 522 may be incorporated as part of step 513.

The process from step 515 continues as described above. In other words, if it is determined in step 515 that the next hop is indicated as the same node, the process returns to step 503, and the process starts again in step 503. If it is determined in step 515 that the next hop is indicated as another node, the frame is processed in step 517 in accordance with RFC3031 packet forwarding operations, and is transmitted accordingly in step 519.

It should therefore be appreciated that the TTL expiration processing functionality is extended by providing additional functionality. First, the second label on the stack is checked (if any second label is present) and if the second label is a GAL, the frame and all contexts are passed to the ACH processing function.

It can also be seen from fig. 6 that if there is no TTL expiration, the first label is removed and forwarding continues based on the second label. The second label may be, for example, a GAL, which means that the local node should process the packet. Then, after removing the second label, the G-ACH with the OAM payload is found. However, at this step, the first tag and original context have been lost and cannot be used for connection verification. However, for continuity checks, this conventional operation may still be used.

There are various alternatives that may be used to determine the number of hops between a source and a destination MEP.

According to one embodiment, the connection setup process may determine the number of hops and provide this information to the source and destination. The implementation depends on whether the connection setup is done in a centralized way (through the management plane) or in a distributed way (through the control plane).

In a centralized connection setup, the entity controlling the setup process has a full knowledge of the connection to be established. It can therefore calculate the hop distance based on local knowledge and send the hop distance to the end point MEP together with other configuration parameters.

In a distributed connection setup, the control plane protocol must provide a method for determining the number of hops. If GMPLS is used as the control plane for MPLS-TP, the GMPLS connection Provisioning protocol (RSVP-TE) must compute the hop distance. One option is to apply the route recording capability of RSVP-TE. The second option is to add a new hop counter to the RSVP-TE signaling message, which counts the number of physical hops of the MPLS-TP connection.

After connection establishment (but before connectivity verification), the source MEP sends a measurement frame with the TTL of the message set to a well-known value, e.g., 250. The destination node may calculate the hop distance from the source node by subtracting the actual TTL value in the OMA message from the known value. Then, the destination MEP may notify the source MEP based on the result.

Already existing CC frames may be used for this purpose. Using these frames, the destination MEP knows its distance from the source MEP. However, a new distance measurement message may also be used; in this case, the message indicates the measurement, and a reply message is generated from the destination MEP in response thereto.

An alternative method may be used for returning the value to the source MEP. One option is to extend the CC message that the destination MEP replies to the source MEP with an optional field carrying this value. According to another option, the value is returned via a new distance measurement reply message.

It should be noted that in case CC messages are used instead of distance measurement messages, the destination MEP should be informed about when to send back the measured distance to the source. This may be achieved using one of the following options. One option is to loop back only once after receiving the first CC message. A second option is to continuously send back the measured distance unless a stop notification is received from the source; the notification may be the first CV message, or an additional bit in the CC message. It should be understood that the above options for measuring jump distance assume: until such time as the measurement has been completed, the path is correct or static.

Fig. 7 is a flow chart illustrating a method in the egress node 18 according to another embodiment of the present invention. As with fig. 5 and 6, this embodiment shows how generic MPLS data plane operations (e.g., Internet Engineering Task Force (IETF) RFC 3031) may be extended. The embodiment of fig. 7 specifies a dedicated label space for each monitored connection and the label space is used to address MEPs. Thus, according to this embodiment, the tag space to which the incoming connection belongs identifies the context for addressing the MEP. The RFC3031 procedure is defined, for example, for each platform and each interface label space, whereas RFC 5331 is used to add "context-specific label spaces".

The label space can be thought of as having a numeric identifier that is meaningful only within the node. A particular label space identifier is assigned to a label value received on a particular interface. This means that each frame received on the interface and carrying the defined first label belongs to a context-specific label space. The first tag may then be pruned (prune) and a check performed on the second tag (e.g., GAL). In this step, the label space identifier will still be available and can be provided with the frame to the G-ACH demultiplexing layer. The NHLFE key may be used under certain restrictions if the tag space identifier is not available.

Thus, this embodiment defines a dedicated tag space for a particular incoming tag, and specifies a dedicated tag mapping table (ILM) for that tag. A more detailed description is given below.

In step 601, an MPLS frame is received. As with fig. 5 and 6, the embodiment of fig. 7 is shown operating with a time-to-live (TTL) mechanism. In step 603, it is first determined whether a time-to-live (TTL) value has reached a predetermined value, e.g., 1, indicating that the frame has expired. If so, processing moves to step 627 whereby the frame is sent to a TTL expiration module and such expired frames are processed in a conventional manner.

If it is determined in step 603 that the received frame has not expired, then the tag space is identified in step 605. This step may include identifying the appropriate Input Label Mapping (ILM) table for processing that particular frame. The tag space defines a range of tag values, i.e., the uniqueness of the tag values is guaranteed only within the tag space. Ideally, the tag space and tag value together define the operation to be performed on the received frame. The label space may be bound to a node, to an interface of a node, or to a tunnel endpoint (i.e., with a label value that identifies the tunnel).

Since the first label in the stack defines the label space, next in step 607, the value of the next (second) label is checked. In other words, instead of checking the label value of the first label (which would normally occur at this stage of MPLS operation), the label value of the next label (i.e., the second label) is checked. If the next (second) tag is not GAL, then processing moves to step 609. In step 609, the NHLFE key is found using the next (second) tag. The NHLFE key identifies a particular NHLFE in the NHLFE table. The NHLFE key may be, for example, a line number. In step 611, the NHLFE opcode (i.e., retrieved in step 609 by the NHLFE key) is checked to determine the attributes of the NHLFE opcode.

If it is determined in step 611 that the NHLFE opcode is any opcode other than a POP opcode (e.g., swap, push a new tag, etc.), then processing moves to step 613. Next, the next hop is checked in step 615. If the next hop is indicated as the same node, i.e. the current node, the process returns to step 603 and the procedure starts again in step 603. If it is determined in step 615 that the next hop is indicated as another node, the frame is processed in accordance with RFC3031 packet forwarding operations in step 617 and is transmitted accordingly in step 619.

If it is determined in step 611 that the NHLFE opcode is a POP opcode, processing proceeds to step 621 where the first tag is popped (e.g., according to RFC 3031) in step 621, processing then moves to step 615 where the next hop is checked in step 615. It should be noted that step 621 may be incorporated as part of step 613.

The process from step 615 continues as described above. In other words, if it is determined in step 615 that the next hop is indicated as the same node, the process returns to step 603, and the process starts again in step 603. If it is determined in step 615 that the next hop is indicated as another node, the frame is processed in accordance with RFC3031 packet forwarding operations in step 617 and is transmitted accordingly in step 619.

In the embodiment of fig. 7, the first tag defines the tag space, and the tag space explicitly defines the connection itself, despite the missing exact value of the first tag. As such, the context descriptor may be defined using a tag space. In other words, the first tag describes a context that is used to address the MEP. Thus, the first tag addresses the MEP and the second tag is just the GAL and the second tag indicates that the frame should be sent to the GAL and G-ACH demultiplexing.

From the above it will be appreciated that the embodiment of figure 7 reuses e.g. the procedure of RFC 5331 (derived from RFC 3031) to provide a dedicated label space to be allocated to each monitored connection. The egress node may determine which label space to use based on the criteria listed below. If the label space instance is bound to a node, then the "default" label space is assigned to any received frame. If a label space instance is bound to an interface (port), the node assigns the label space to any frame received on that interface/port. If the label space instance is bound to a tunnel endpoint, the node assigns the label space to any frame received over the tunnel. These three label space categories may be assigned to each node, each interface, and context specific label space.

The connection-specific ILM table may contain:

● point to label entries for client connections tunneled through a monitored connection and demultiplexed at a node

● points to the label entry of the encapsulated pseudo-wire stream

● tag entry pointing to GAL (tag value 13) if the associated channel is defined for the monitored connection

● point to a tag entry that defines an explicit null tag (value O) for processing of non-encapsulated client streams.

It should be noted that each entry in the ILM may point to the NHLFE. The NHLFE addressed by the tag entry of the GAL for this context tag space can then encode context information. In this way, the connection over which the frame is received can be identified and used to address the MEP. The connection information may also be used to perform subsequent operations, such as performing connection verification.

Fig. 8 shows a node 100 of a packet-switched network according to an embodiment of the invention. The node 100 is adapted to operate as the egress node 18 described in relation to fig. 2.

The node 100 comprises a receiving circuit 102 for receiving data traffic packets from a connected node. The received packet is passed to the processing circuitry 104, and the processing circuitry 104 processes the packet, for example, according to any of the methods described with respect to fig. 3-7. If the received packet is determined to have a GAL tag, the packet is passed to GAL demultiplexing circuitry 108, and GAL demultiplexing circuitry 108 determines the appropriate operations to perform on the packet. For example, if the packet is identified as an OAM packet, GAL demux circuitry 108 may forward the packet to the MEP over interface 110. If the received packet does not have a GAL tag, the processing circuitry 104 may forward the packet to another node connected thereto via the interface circuitry 106. Thus, via the interface circuit 110, OAM, protection functions, and the like, providing other functions for the LSP and segment layers may be connected.

It should be appreciated that the various embodiments described above support similar connection verification functions that are IETF BFD based, ITU-t y.1731 based, or capable of meeting the requirements of MPLS-TP connectivity verification in the case of LSP tunnels and segment layers. For example, when using one of the proposals described in the above embodiments, undesired connectivity (e.g., a wrong merge, or a wrong connection) between two MEs may be detected, where the MEPs from each ME are located on the same node. Without these extensions, the functionality is unable to detect errors.

It should be noted that the above-described embodiments are applicable to solve the problem in the case of LSP tunnel layers. The embodiments of fig. 6 and 7 may be applied to solve the problem in the case of segment layers.

It should be noted that the above-mentioned embodiments 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 invention. 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 fulfill the functions of several units recited in the claims. Any reference signs in the claims shall not be construed as limiting the scope of the claims.

Claims (17)

1. A method in a node of a multi-protocol label switching, MPLS, communications network, the method comprising the steps of:

receiving an MPLS frame having a label stack including a first label and a second label;

the method is characterized by comprising the following steps:

determining whether the frame has reached its terminating node, an

If the frame has reached its terminating node, checking a second label in the label stack to determine if the second label is related to a generic associated channel label GAL, and

if the second label is related to a generic associated channel label GAL, storing a context descriptor constructed based on key attributes characterizing the terminated connection on which the frame has been received for use by operations, administration and maintenance OAM functions during subsequent processing of the frame when performing connection verification CV, continuity check CC, or other functions requiring identification of the origin of the frame, and

the frames are routed for general associated channel header G-ACH processing.

2. The method of claim 1, wherein the step of determining whether the frame has reached its terminating node comprises: a step of checking a first label in the label stack.

3. The method of claim 2, wherein the step of checking the first label in the label stack comprises the step of checking whether the first label is associated with a pop operation.

4. The method of claim 1, wherein the step of determining whether the frame has reached its terminating node comprises: a step of checking time-to-live TTL information received with the frame.

5. The method according to any of the preceding claims, wherein the step of storing a context descriptor comprises: a step of storing the first label for future processing of the operation, administration and maintenance OAM function.

6. The method of claim 5, wherein the step of storing a context descriptor further comprises: and storing the label space information.

7. The method of claim 6, wherein the storing step comprises: a step of storing the first tag and tag space information before checking the second tag, an

If the second tag is a GAL, retaining the first tag and tag space information; and

if the second tag is not a GAL, the first tag and tag space information are discarded.

8. The method of claim 6, wherein the storing step comprises: a step of storing the first tag and tag space information after the checking step has determined that the second tag is a GAL.

9. The method of claim 5, wherein the storing step comprises: a step of storing the last processed label in a memory for storing a history of label stacks.

10. The method of claim 1, wherein the step of checking the second tag is performed in response to a status bit being set in the received frame, the status bit indicating that the connection is a monitored connection.

11. The method of claim 1, wherein the stored context descriptors are based on information provided in a label space of the received MPLS frame, wherein the label space is allocated to each monitored connection.

12. The method of claim 11, wherein a separate Input Label Mapping (ILM) table is provided for each label space.

13. A method according to claim 11 or 12, wherein the label space for a monitored connection is used for addressing a maintenance end point, MEP.

14. The method of claim 1, wherein the context descriptor is stored using a Next Hop Label Forwarding Entry (NHLFE) key.

15. The method of claim 1, further comprising the step of:

demultiplexing the received frames to obtain data related to operation, administration and maintenance, OAM, functions;

routing the frame to a maintenance end point, MEP, based on routing information contained in the demultiplexed data; and

a connectivity check is performed using the stored context descriptors.

16. A node of a multi-protocol label switching, MPLS, communication network, the node comprising:

receiving means for receiving an MPLS frame having a label stack including a first label and a second label; characterized in that the node is configured to:

determining whether the frame has reached its terminating node, and, if the frame has reached its terminating node:

examining a second label in the label stack to determine whether the second label is related to a generic associated channel label GAL; and if the second tag is related to the generic associated channel tag GAL, then

Storing context descriptors constructed based on key attributes characterizing terminated connections on which frames have been received for use by operation, administration and maintenance, OAM, functions during subsequent processing of the frames when performing connection verification, CV, continuity check, CC, or other functions requiring identification of the origin of the frames; and

the frame is routed for generic associated channel header G-ACH processing.

17. The node of claim 16, wherein the node is further configured to perform the method of any of claims 2-15.