PSEUDOWIRES

TBCHNICALFIF D

Various exemplary embodiments disclosed herein relate generally to cotnmvinicarion over pseudowires.

BACKGROUND

FIG. 1 illustrates the basic concept of pseudowire (PW) in a communication network. In the network 100, pseudowires 105a-b ace defined to run over a packet network 115, such as, I networks, layer two tunneling protocol (L2TP) networks, MP.T.-S networks, He. These networks provide the packet "cloud" 115 through which connection-oriented tunnels 110 arc formed to stipport pseudowires J05a-b. For the common MPLS case, two xuiidirccrionaJ, inner-tunnel, label-switched paths (ISPs) are contained within unidirectional, outer-tunnel LSPs (which act as traffic-engineering tunnels) and create a bidirectional connection between provider edge (PE) routers. The inner LSPs form the pseudowires 105a-b by using an interworkmg function (WP) - currently residing at the PE, although it can easily and rapidly migrate to die customer equipment (CE) - that encapsulates the CE data transmission format, such as frame relay, asynchronous transfer mode (ATM), or Ethernet, from the attachment circuit into a standard packetized pseudowire format. At the far end of the pscudowire 105a-b, the data is uncncapsulated and handed over to the destination CE.

SUMMARY

A brief summary of various exemplary embodiments is presented below. Sonic simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of a preferred exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections. Various exemplary embodiments relat to a method for determining peer status in a pseudowire (PW) node, the method including: sending a first PW status request message to a peer node including a PW node local message ID, PW node remote message ID, and request flag; starting a first retry rimer; starting a second retry timer when the first retry timer expires and no response to the first PW status request message is received; starting a first request timer when the second retry timet expires and no response to the first: PW status request message is received and starring a third retry timer when the first request rimer expires and no response to the first PW status request message is received.

Various exemplary embodiments relate to a method for determining peer status in a pseudowire (PW) node, the method mcluding: receiving a first PW status request message from a peer node including a peer node local message ID, peer node remote message ID, and request flag; setting a PW remote message ID to the peer node local message ID; sending a second PW status request message to the peer node, if requested by the peer node, including the PW node local message ID, PW node remote message ID, arid request flag; and starting a first request time* .

Various exemplary embodiments relat to a pseudowire (PW) node including: a network interface; a memory; and a processor in communication with the memory, the processor being configured to: send a first PW status request message to a peer node including a PW node local message ID, PW node remote message ID, and request flag; start a first retry timer; start a second retry timer when the first retry timer expires and no response- to the first PW status request message is received; start a first request timer when die second retry rimer expires and no response to the first PW status request message is received; and start a third retry timer when the first request timer expires and no response to die first PW status request message is received.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, reference is made to the accompanying drawings, wherein:

FIG. 1 illustrates the basic concept of a pseudowire (PW) in a communication network; FIG. 2 illustrates the problem of loops in a pseudowire network;

FIG. 3 illustrates an embodiment of a data arrangement for a

Rehable_Delivery_Messagc TLV in the PW status request, message;

FIG. 4 illustrates an example message exchange between two nodes over a PW; and

FIG. 5 illustrates a hardware diagram of an exemplary W node.

To facilitate understanding, identical reference numerals have been used in the

Figures and the text to designate elements having substantially the same or similar structure or substantially the same or similar ftinction.

Herein, various embodiments are described more fully by the Figures and the Detailed Description. Nevertheless, the inventions may be embodied in various forms and are not limited to the specific, embodiments that: are described in the Figures and Detailed Description.

DETAILED DESCRIPTION

The description and drawings merely illustrate the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recited herein are principally intended expressl to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering die art, and are to be construed as being without limitation to such specifically recited examples and conditions. Additionally, the term, "or," as used herein, refers to a non-exclusive or (i.e., and/or), unless otherwise indicated (e.g., "or else" or "or in the alternative"). Also, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new eiribodimctus. As used herein, the terms "context" and "context object" will be understood to be synonymous, unless otherwise indicated.

RFC6478 describes a standard mechaiiistn for advertising the status of a pseudowire (PW) that is not controlled by a label distribution protocol (LDP) session. Such a pseudowire has labels that are manually configured by the operator and is tenned a static pseudowire. This solution may involve sending a packet iit-band containing a bit field representing the status of the PW along an associated control channel on the PW between a sending PE node and a receiving PE node. The status message may be periodically refreshed at a refresh timer interval.

However, this mechanism docs not ensure that the receiving node actually receives the status message. Further, a sending node is unable to determine if the receiving node actually received a specific status message. Also, a sending node is unable to determine reliably if the status that it currently holds for a P is inaccurate or if it is stale. Further, when a PW is newly configured (either during execution of configuration file on boot up or when it is later provisioned), there is no way defined in the .RFC to send a request for the peer's PW status. Also, the RFC specifies the default PW status bits indicate a status of "no faults" until a refresh message is received from peer node containing the peer PW status. Also, the RFC specifies that if the PW status bits expire, then they will be set to the default value of "no faults." There remains a need for a PW control channel status request mechanism so that a peer that has stale PW status for the far-enti of a PW can request that the peer node send a PW status update. Accurate and current information, about the far end status of a PW is required for proper operation of various types of PW operation, for example, a redundant PW configuration. This mechanism may ensure that a consistent: view of the control plane is maintained, as far as possible, between peer nodes.

The following types of problems may occur in the current PW operation. The PW refresh timer is either disabled, or set: to a long interval, so a node does not know if it's currently held status is still valid. RFC6478 specifies that if the peer refresh timer times out, a status of 0, no defect, should be assumed, unless some other defect detection, mechanism indicates that the PW ^T is down. If no other defect detection mechanism is used, then the status of 0 for the PW may not be accurate. Also, the current mechanism may generate too man packets on a status change, which may- cause control plane congestion in a downstream node.

Another type of problem occurs if a node has just rebooted, and the rebooted node does not hold status for the far aid node of the PW. This may cause loops in the forwarding path tor broadcast traffic. F G. 2 illustrates the problem of loops in a pseudowitc network. The P network 200 includes four nodes: Node A, Node B, Node C, suid Node D. Node A communicates with Node Ii using pseudowitc PW A-B. Node A also communicates with Node C using a pseudowire PW A-C. Node B connects with Node D using any type of communication, likewise, Node C connects to Node D using any type of communication. In the PW network 200, PW A-B and PW A-C provide redundant communication paths between Node A and Node D. In this example, Node A selects PW A-B to be active and to provide the primary communication path between Node A and Node D. Node A selects PW A-C to be in standby. If PW A-B becomes unavailable, Node A may divert traffic l:o Node D through Node C. As discussed above a loop back problem may occur if Node C needs to restart. According the current PW operation defined in the RFC, upon start up, Node C will assume that it is active and establish connections with both Node A and Node . Now Node D will send traffic for Ncxle A to Node C which will then forward it to Node A. But because, node A has selected PW A-B to be active and PW A-C to be in standby it will ignore the traffic from Node C which includes the traffic from Node. . Hence, a loop back situation occurs because the nodes at the end of the PWs cannot determine the status of its peer node. A peer node is another node connected to the other end of a PW from the local node.

The problems described above may be overcome by including an identifier for the. message from the sending node in the PW status message between a pair of nodes. Further, the PW status message from the sending node may include a flag or some other indicator to request that the receiver acknowledge receipt of that specific status message and to t ec-uest that: the receiving node include an update of the status of the PW from its local perspective.

The sending node may thus determine if a receiving node has actually received the status message and the receiving node's view of the PW status. If an acknowledgement for the status message is not received, then the sending node may continue to send status messages on the PW associated control channel until the acknowledgement is received. If an acknowledgement is not received within, a certain interval of the first status message being sent, then the sending node may declare that the PW as down so as to prevent: blackholirig of traffic on the PW. - 6 -

An embodiment of a PW system using a PW status message including request for return PW status report is now described. The use of the request for a return status feature may be enabled when a RetryTimer parameter is non-zero. When enabled, the normal RFC6478 refresh timer behavior is overridden. The refresh rimer value in the status packet defined in RFC6478 is typically set to zero which indicates that PW status message will never be refreshed. In such a situation the request for a return status feature may be used.

In extending the PW protocol to allow for a request for a return PW status report, the following parameters may be defined: RetryTimer; RcquestTimer; and TimeoutMuitiplier. The Retry' Timer parameter determines the interval at which PW status messages, including a reliable deliver type, length, value pair (TLV) -with the request bit set (see below) are sent. The RetryTimer may not be enabled if refresh timer≠ 0. The RequestTimer parameter determines the rimeout interval if no response to a PW status request message is received. The RcquestTimer defaults to 0 when no RcquestTimer is specified. The TimeoutMuitiplier parameter is used to determine if a peer node is down. If a requesting node does not heat back from a peer node after RequestTimer * TimeoxuMultiplier, then it may assume that the peer is down. The TimeoutMuitiplier defaults to 0 when no RcquestTimer is present. In extending the PW protocol to allow for a request for a return PW status report, the following protocol states may be defined: UnknownSleeping UnknownRequcsting; AcitveSleeping; and AcitveRequesting. Further, the extended PW protocol may include the following parameters (which will be further described below): Local Message ID (LocallD); Remote Message ID (RemodelD); and I,ast Request ID (LastReqlD).

When the local node is in the UnknownSleeping state, the local node does not kno the peer's view of the PW status, and is not actively trying to find it out. The local node is waiting for the Ret-tyTimer timer to expire before attempting to obtain a peers's status. In this state, the RetryTimer is running, RemotelD ~ 0, and the peer's status code is forced to be not-forwarding.

When the local node is in the UnknownRequesting state, the local node does not know the peer's view of the. PW status, but is actively trying to determine it The local no k lias sent a PW status request message to its peer and is waiting for an acceptable response. In this state, the RetiyTimer timeout timer is ninning, the RequestTitncr timer is running, RemotelD = 0, and peer's status code is forced to be not- forwarding.

When the local node is in the AcitvcSleeping state, the local node does know the peer's view of the PW status, and is waiting for the for the Retty imer timer to expire before requesting a refresh of the peer with its status values. In this state, the RetryTttner-timer is running, RcrnotelD = the ID that was last sent by the peer, and the peer's status code is the status code that was last sent by the peer.

When the local node is AcitveRequestmg state, die local node does know the peer's view of the P status, and is actively trying to get a refresh of the peer's view of the PW status, having sent a PW status request message to the peer and is waiting for an acceptable response. In this state, the RetryTimer timeout timer is running, RcquestTimer is running, RemotelD = the ID that was last sent by the peer, and the peer's status code is what was last sent by the peer.

PIG. 3 illustrates an embodiment of a data arrangement for a Reliable_Delivery_Message TLV in the PW status request message. The PW status request message uses a Reliable_Delivery_Message TLV carried in the static PW status message to ensure reliable delivery of a request message to a peer. 'litis TLV may be carried in addition to the existing R.FC6478 status TLV. 'Ilie 'UP' field may be set to 10, to indicate that if a receiving node does not understand die TLV, it should ignore it and should not forward it. The R-bit {Req) indicates that the sending node is requesting the status of a peer node. Req may be set to 1 or T to indicate a request that a peer send a static PW status update. The R-bit may be set t 0 or F to indicate that the Reliable_Delivery_M<issage TLV contained in the packet is a response to a PW status request message. The Flags field is set to zero. This is shown in the TLV structure for future extensibility. Local Message ID (LocallD) may be 32 bit: number indicating the ending node's current message ID. The LocallD value may be incremented when a PW statas request message is sent and the status of the PW status message changes. Remote Message ID (RemotelD) is a 32 bit number indicating sending node's known value of the remote nodes LocallD. A RemotelD of 0 may indicate that the value is unknown.

When a PW node starts, the PW node may be placed in the UnknownSleeping state. Hie LocallD may be set to a random initial value. The LastReqlD and RemotelD may be set to 0. The RequcstTimer may be set to an initial value between 0 and the configured value. In future iterations the RequestTimer, it will be set to the configured value. This may prevent bursting.

The operation of a sending node using a PW status request message will now be described. When the RequcstTimer expires the receiving node may go into an UnknownRequesting state if the status of the PW is unknown or into the AcliveRequesting state if the status of the PW is known.

The sending node may send a PW status request message with die Req flag set to T to indicate a request for status at the receiving node and the current LocallD value. Also the RetryTimer timeout timer may be started The LastReqID may be set to the LocallD that was sent to the receiving node. If the RetryTimer timer expires, repeat sending a PW status request message. If the sending node sends TimeoutMultiplier, or three in this case, PW status request messages and the RetryTimer expires three times without receiving a return PW status message from the receiving node, then the sending node may be put into the UnknownSleeping state and the RequestTimer may be started. Also values other than three may be used as TimeoutMultiplicf, which is the number of times to send the PW status request message without a reply. When the RequestTimer Expires, the receiving node may restart and repeat the process by sending a PW status request message with the Req flag set to T.

If the sending node receives a status response message from the receiving node, the sending node may update its stare to ActiveSlecping and set the value of RemotelD to the LocallD received from the transmitting node. Further, the RequcstTimer may be restarted. In another embodiment, the RequestTimer may not be reset, but continue to run -until it expires.

The operation of a receivin node receiving a PW status message with a Reliabk_Dclivery_Message TLV will now be described. When the receiving node receives a P status message, it will me the status code as normal if it is in AcitveSlceping or AcitveRequesting state, The Rcliable_Dehve*y_Me«sagc TLV may be processed as follows. First, the receiving node may store the received LocallD as the RemotclD. If Req is set to T in the received Reiiable_Delivery_Message, then send a P status message back \x> the sending node wit Req set to F, /,#., no update request is requested back from the sending node. In another embodiment, Req may instead be set to T. This may be done if it is desired to verify the status of the sending node. If the RemotelD in the received Relkblc_Ddivery_Message TLV the matches LocallD or the LastReqlD of the receiving node, the receiving node may go into the AcitveSleeping state. If a RetryTimer is active, then it: is canceled, and a RequestTimer is started. If a RequestTimer is active, then it is canceled and restarted.

FIG. 4 illustrates an example message exchange between two nodes over a PW. At TO, Node A randomly sets LocallD to 1234. Node A also iwttaliaes RemotelD and LastReqlD to 0. Node A is put in the UnknownSleeping state. The RequestTimer is initially randomly set to a value between 0 and 20, where 20 is its selected configured value. In this case, die initial RequestTimer is set to 1. The RequestTimer for Node A is also started.

At TO, Node B randomly sets LocallD = 5678. Node B also initializes RemotelD and LastReqlD to 0. Node B is put in the UnknownSleeping state. The RequestTimer is initially randomly set to a value between 0 and 30, where 30 is its selected configured value. In this case, the initial RequestTimer is set to 10. The RequestTimer for Node B is also started.

At ΊΊ, die RequestTimer for Node A expires. Node A sends PW status request message A including LocallD = 1234, RemotelD = 0, and Req - T. Node A also sets LastReqlD = 1234 and enters the UrJcnownRefreshing state. Also, die RetryTimer is set to 3 and started. In diis example the PW status message is lost. The value that of the. Retry timer can be values other dien 3, which is just used as an example herein. At T4, the RetryTimer for Node A expires. Node A sends PW status request message B including LocallD - 1234, RemotelD ~ 0, and Req = T. Also, the RetryTimer is set to 3 and started. In this example die PW status message is again lost.

At T7, the RetryTimer for Node A expires. Node A sends PW status request message C including LocallD ~ 1234, RemotelD = 0, and Req = T. Also, the RetryTimer is sct to 3 and started. In this example rive PW status message is again lose

At TIG, the. RettyTimer for Node A expires. In this case, TirricoutMulfiplier is set to 3, so because this is the third attempt to receive a status update from Node B, Node A goes into the UnknownSleeping state, sets the RequestTimer to 20, and starts the RequestTimer. In this example, TimeoutMuMplier is set to 3, but it may also be set to other values as well.

At T10, the RequestTimer for Node B expires. Node B sends PW status request message D including LocallD ~ 5678, RemotelD ~ 0, and Req - T. Node B also sets I-astReqlD to 5678 and enters the Unkno nRefreshing state. Also, the RettyTimer is set to 3 and started

At Ti 1, Node B has a local PW status change and updates its I-ocallD to 5679. Node B sends PW status request message E including LocallD - 5679, RemotelD = 0, and Req = F. In this case Req may be set to F because Node B is reporting its own status change and does not require an update from Node A, especially as PW status request message D was just sent. In other embodiments, Req could be set to T, especially if there is no currently pending PW staius request message.

A T12, Node A processes PW status message D. Node A sets RemotelD to 5678. In response and because Node B requested a PW status update, Node A sends a PW status message including LocallD ~ 1234, RemotelD = 5678, and Req = T. Also, the RequestTimer may be reset and restarted.

At T13, Node A processes PW status message. B. Node A sets RemotelD to 5679. Because Req = F in PW status update message E, Node A does not send a PW status message. Also, die RequestTimer may be reset and restarted.

At T13, Node B processes PW status message F. RemotelD is set to 1234. Also, Node B enters the ActiveSleeping state. In response and because Node A requested a PW status update, Node B sends a PW status message G including LocallD = 5679, RemotelD ~ 1234, and Req = F. Also, the RequestTimer is reset and restarted.

At T1 , Node A processes PW status messag G. Node A enters the ActiveSleeping state. Because Req = F in PW status update message G, Node A does not send a PW status message. Also, the RequestTimer may be reset and restarted.

At T34, the RequestTimer for Node A expires. Node A sends PW status request mcssage H including LocalTD = 1234, cmotelD = 5879, and Req = T. Node A also sets LastReqID = 1234 and enters the ActivcRefrcshmg state. Also, the RetryTimer is set to 3 and started.

At T34, Node B processes PW status message H. The RemotcID is set to 1234. Also, Node B remains in the ActiveSleeping state. In response and because Node A requested a PW status update, Node B sends a PW status message including LocallD - 5679, RemotcID = 1234, and Req - F. Also, the RequestTimer is reset and restarted.

At T34, Node A also processes PW status message I. Node A enters the ActiveSleeping state. Because Req = F in PW status update message G, Node A does not send a PW status message. Also, the RcquestTimcr may be reset and restarted. The message exchange illustrated in FIG. 4 provides examples of the operation of PW nodes in various situations. Other situations and responses may arise as well, line number of times a PW request message is sent without receiving a response may be varied. Also, the timer values may be varied as desired and needed by a system user. The example of FIG. 4 is meant to be illustrative of embodiments and not Hmiting. FIG. 5 illustrates a hardware diagram of an exemplary PW node. A PW node is any network node connected to a PW. The exemplary PW node 500 may correspond to the exemplary Nodes A-D of FIG. 2 or Node A or Node B of FIG. 4. The. PW node 500 may include a processor 510, a data storage 520, an input/ output (I/O) interface 530, and system bus 540.

In some embodiments, the processor 5 may include resources such as processors / CPU cores, the I/O interface 530 may include any suitable network interfaces, or the data storage 520 may include memory or storage devices. Moreover the PW node 500 may be any suitable physical hardware configuration such as: one or more servers or blades consisting of components such as processor, memory, network interfaces or storage devices.

The data storage 520 and the processor 510 may reside in iwo different physical machines. In some embodiments, the PW node 500 may be a general purpose computer programmed to perform the. methods described herein. When processor- executable programs are implemented on a processor 510, for example, programs that perform the methods described herein, the program code segments combine with the processor 510 to provide a unique, device that operates analogously to specific logic circuits.

In various methods described and/or recited in this application, various steps of methods may be performed in a sequential maimer, a parallel manner, or in a partially parallel manner.

It should be appreciated by those skilled in die art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention.

Although the various exemplary embodiments have been described in detail with particular reference to certain exemplary aspects diereof, it should be understood that the invention is capable of other emlxxlirneufs and its details are capable of modifications in various obvious respects. As is readily apparen to those skilled in the art, variations and modification can be effected while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description, and figures are for illustrative purposes only and do not in an way limit the invention, which is defined only by the claims.