CN106817273B - Method and apparatus for L3VPN service diagnosis - Google Patents

Abstract

The invention discloses a method and a device for diagnosing L3VPN service. The apparatus is located in a first PE and comprises: a construction unit configured to construct an L3VPN service response request message; a transmitting unit configured to transmit the L3VPN service response request message to a second PE; and a receiving unit configured to receive an L3VPN service response message from the second PE; wherein the L3VPN service response request message includes a target service entity TLV for specifying the L3VPN service entity that should respond to the L3VPN service response request message.

Description

Method and apparatus for L3VPN service diagnosis

Technical Field

The present invention relates to the field of communications, and more particularly, to a method and apparatus for L3VPN traffic diagnosis.

Background

Currently, existing tools that can be used to diagnose layer 3 Virtual Private Network (L3 VPN) traffic include the Label Switched Path (LSP) Ping/traceroute tool specified in RFC 4379, or the Virtual Circuit Connectivity Verification (VCCV) tool specified in RFC 5085, or the traditional IP Ping/traceroute tool applied in the context of an L3VPN instance. While each can be used to diagnose some aspects of L3VPN traffic, they are not sufficient to diagnose all major aspects of L3VPN traffic: a status of the L3VPN service entity, a service label assignment pattern and a total number of service labels assigned to the L3VPN service entity and a data path of the L3VPN service packet.

Here, the data path of the L3VPN service packet refers to traversing all service nodes participating in the L3VPN service, regardless of all nodes not participating in the service. That is, only the operator Edge (PE) node that runs the L3VPN service entity and terminates the service label is considered as the L3VPN service node, and the general operator (Provider, P) node is not considered as the L3VPN service node.

For the LSP Ping/traceroute tool, the target of the LSP reply request/reply message is the MPLS label stack. If the MPLS label stack includes a traffic label, the binding of the traffic label can be confirmed. However, the LSP Ping/traceroute tool is not able to diagnose the L3VPN traffic entities.

For VCCV tools, current VCCV tools have specified some connection Confirmation (CV) types for Internet Control Message Protocol (ICMP) Ping, LSP Ping, and Bidirectional Forwarding Detection (BFD), but they are not suitable for diagnosing L3VPN business entities.

The IP Ping/traceroute tool may be used to verify the reachability and path of an IP host in an L3VPN environment, but it is transparent to the underlying MPLS label. The IP Ping/traceroute tool cannot be used to diagnose all major aspects of L3VPN traffic either.

It can be seen that there is no suitable diagnostic tool to verify the integrity of VPN traffic entities and the data path of traffic packets for Border Gateway Protocol (BGP)/multiprotocol Label Switching (MPLS) IP VPN traffic based on RFC 4364 to date.

Disclosure of Invention

In view of the above problems, the present invention proposes a solution for performing L3VPN service diagnosis comprehensively. More specifically, the present invention proposes two diagnostic tools: the L3VPN service Ping tool and the L3VPN service route tracking tool, and new diagnostic messages, i.e., an L3VPN service response (Echo) request message and an L3VPN service response message, are defined for the two tools, respectively. Wherein, when applied to PEs in the context of L3VPN service entities, the L3VPN service Ping tool can be used to verify the availability of all or one specific L3VPN service entity of the L3VPN service and return the system address (and other service related information) of the corresponding PE, while the L3VPN service route tracing tool can be used to reveal all possible data paths to all or one specific L3VPN service entity, i.e. the system addresses of all L3VPN service nodes on the path to the route traced L3VPN service entity.

According to a first aspect of the present invention, there is provided a method for L3VPN traffic diagnosis, the method comprising the following steps performed by a first PE: constructing an L3VPN service response request message; sending the L3VPN service response request message to a second PE; receiving an L3VPN service response message from the second PE; wherein the L3VPN service response request message includes a target service entity TLV for specifying the L3VPN service entity that should respond to the L3VPN service response request message.

According to a second aspect of the present invention, there is provided a method for L3VPN traffic diagnosis, the method comprising the following steps performed by a second PE: receiving an L3VPN service response request message from a first PE, wherein the L3VPN service response request message comprises a target L3VPN service entity TLV, and is used for specifying an L3VPN service entity which should respond to the L3VPN service response request message; determining whether the L3VPN service response request message is targeted to all L3VPN service entities or a specific L3VPN service entity; when the L3VPN service response request message is targeted to all L3VPN service entities, the second PE returns an L3VPN service response message to the first PE, updates the L3VPN service response request message and forwards the updated L3VPN service response request message; and when the L3VPN service response request message targets a specific L3VPN service entity and the second PE is the specific L3VPN service entity, the second PE returns a L3VPN service response message to the first PE.

According to a third aspect of the present invention, there is provided an apparatus for L3VPN traffic diagnosis, the apparatus being located in a first PE, comprising: a construction unit configured to construct an L3VPN service response request message; a transmitting unit configured to transmit the L3VPN service response request message to a second PE; and a receiving unit configured to receive an L3VPN service response message from the second PE; wherein the L3VPN service response request message includes a target service entity TLV for specifying the L3VPN service entity that should respond to the L3VPN service response request message.

According to a fourth aspect of the present invention, there is provided an apparatus for L3VPN traffic diagnosis, the apparatus being located in a second PE, comprising: a receiving unit configured to receive a L3VPN service response request message from a first PE, the L3VPN service response request message including a target L3VPN service entity TLV for specifying a L3VPN service entity that should respond to the L3VPN service response request message; a determining unit configured to determine whether the L3VPN service response request message is targeted to all L3VPN service entities or one specific L3VPN service entity; and a processing unit configured to return an L3VPN service response message to the first PE, update the L3VPN service response request message and forward the updated L3VPN service response request message when the L3VPN service response request message targets all L3VPN service entities; and returning an L3VPN service response message to the first PE when the L3VPN service response request message is targeted to a specific L3VPN service entity and the second PE is the specific L3VPN service entity.

Drawings

The present invention will be better understood and other objects, details, features and advantages thereof will become more apparent from the following description of specific embodiments of the invention given with reference to the accompanying drawings. In the drawings:

FIG. 1 shows a schematic diagram of a general deployment model of BGP/MPLS L3 VPNs based on RFC 4364;

fig. 2 shows a schematic diagram of the operation of the L3VPN traffic Ping tool according to the present invention;

FIG. 3 illustrates a schematic diagram of the operation of an L3VPN traffic route tracking tool in accordance with the present invention;

fig. 4 is a schematic diagram illustrating a format of an L3VPN service response request and response message according to the present invention;

fig. 5 is a schematic diagram illustrating the format of TLV and sub-TLV fields in an L3VPN service response request and reply message according to the present invention;

fig. 6A and 6B illustrate schematic diagrams of an L3VPN service response request message and an L3VPN service response message for the L3VPN service Ping tool, respectively;

fig. 7A and 7B show schematic diagrams of a L3VPN service response request message and a L3VPN service response reply message, respectively, for a L3VPN service route tracking tool;

fig. 8 illustrates a block diagram of an apparatus for L3VPN traffic diagnosis according to the present invention;

fig. 9 shows a block diagram of another apparatus for L3VPN traffic diagnosis according to the present invention.

Detailed Description

Preferred embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present invention are shown in the drawings, it should be understood that the present invention may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

Before describing the basic idea of the present invention, a review of the L3VPN traffic model is made to introduce some of its necessary concepts and terms. FIG. 1 shows a schematic diagram of a general deployment model of BGP/MPLS L3 VPNs based on RFC 4364.

In general, distributed L3VPN traffic can be viewed as a set of Virtual Routing and Forwarding (VRF) instances interconnected by inter-VRF traffic transmission paths. The topology of the L3VPN is controlled by the settings of the Export (Export Target, RT), which is an extended community attribute of the L3VPN routes distributed by the BGP protocol, and the Import (Import) RT, which controls the L3VPN routes that each VRF allows for Import, which in turn determines whether the VRF should redistribute the imported L3VPN routes to other peer VRFs. The L3VPN route redistribution rule may be described by the concept of Split Horizon Group (Split Horizon Group). Traffic transmission paths between VRFs (or equivalently, L3VPN traffic peers) may be grouped into multiple split-level groups, and VRFs never redistribute incoming L3VPN routes to other traffic peers within the same split-level group, but always redistribute incoming L3VPN routes to other traffic peers within different split-level groups. The rules how to assign an inter-VRF traffic transmission path (or an L3VPN traffic peer) to a particular horizontally split group are determined only by the values of the input RT and the output RT. Since the rules (or algorithms) are not new, the invention will not be described in detail, provided only that each VRF is associated with one or more automatically created horizontally split groups, that the topology of the L3VPN traffic is controlled by these horizontally split groups, and that each inter-VRF traffic transmission path (or each L3VPN traffic peer) explicitly belongs to one horizontally split group. The topology and associated horizontal split groups of L3VPN traffic are shown in fig. 1.

Note that, herein, a horizontally split group may refer to a traffic transmission path group or an L3VPN traffic peer group depending on the context.

Assuming that the topology of the L3VPN traffic (or the bi-directional L3VPN route distribution path) is controlled by the horizontally split group associated with the VRF, the present invention suggests two L3VPN traffic diagnostic tools: the L3VPN service Ping tool and the L3VPN service route tracking tool, and describe the related message coding and implementation algorithm.

The invention proposes to define two messages for an L3VPN service Ping tool and an L3VPN service route tracking tool: an L3VPN service response request message and an L3VPN service response message. These messages are carried by User Datagram Protocol (UDP) packets, and the UDP port number may be manually configured on each PE or may be Assigned by the Internet Assigned Number Authority (IANA).

Note that: the present invention is an extension of application No.2015100804040, proposed by the same inventor for layer 2VPN (L2VPN) business diagnostics, and therefore its parts reuse previous message encoding and algorithms. However, since the L2VPN and the L3VPN have respective characteristics, such as whether based on routing or not, they are solutions suitable for different application scenarios.

The L3VPN service response request message and the L3VPN service response message can carry various types-Length-Value (TLV) for different purposes. The present invention proposes to reuse the two previous TLVs for L2VPN and define two new TLVs applicable only to L3VPN traffic Ping/route tracing:

1) a target L3VPN service entity TLV that specifies the L3VPN service entity that should respond to the L3VPN service reply request message. The present invention defines two values for a target L3VPN service entity: all L3VPN service entities and a particular L3VPN service entity (e.g., as identified by the IPv4 address of the PE running the particular L3VPN service entity).

2) A traceroute TLV that encodes the system addresses of all PEs traversed by the L3VPN service request message from the originating PE to the terminating PE. The route trace TLV will be sent back to the originating PE in an L3VPN traffic reply message.

3) The traffic label assignment pattern TLV indicates how the PE assigns the traffic label to the L3VPN traffic entity. According to RFC 4364, a PE may choose to assign a single traffic label to the entire VRF, one traffic label to each direct circuit, one traffic label to each IP route, or the PE may use other special methods to assign traffic labels. The present invention defines the new TLV to query the traffic label assignment pattern from the remote L3VPN traffic entity.

4) And the distributed service label number TLV is used for encoding the service label number distributed by the PE for the L3VPN entity. The present invention defines this new TLV to query the assigned traffic label number from the remote L3VPN traffic entity.

Fig. 2 shows a schematic diagram of the operation of the L3VPN traffic Ping tool according to the present invention. Fig. 3 shows a schematic diagram of the operation of the L3VPN traffic route tracking tool according to the present invention.

The L3VPN traffic Ping utility and the L3VPN traffic route tracking utility may be implemented as Command Line Interface (CLI) commands that are invoked from the CLI interfaces of the PEs participating in the L3VPN traffic. Fig. 2 and 3 illustrate the CLI screen and the propagation of the L3VPN service diagnostic message on the service transmission path.

As shown in fig. 2 and 3, the solid line with arrows represents the transmission path of the L3VPN service response request message, where the L3VPN service response request message is originated by the node 10.1.1.1, the target node is 10.1.2.3, and all L3VPN service entities are reached along the data path of the broadcast packet in the L3VPN service domain.

The present invention is an extension of the previous invention that reuses the overall message encoding format proposed in the previous invention and defines the necessary new extensions (two new message types, four new service-specific error subcodes, and two new TLVs) to support the operation of the L3VPN service Ping and the route tracing tool.

The message encoding format and its fields are described below, with the existing definitions of the previous invention and the new definitions proposed by the present invention being appropriately labeled.

The L3VPN service response request and response messages are carried by UDP packets. The UDP port number may be assigned by the IANA or may be configured locally on each participating PE.

Fig. 4 is a schematic diagram illustrating a format of an L3VPN service response request and response message according to the present invention. Where both messages are in the form of UDP packet payload, as in the previous invention.

The definition of the fields is re-described here for the sake of document integrity. Note that the following definition section is the same as that defined previously, and all L2 VPNs in the previous invention are changed to more appropriate terms (such as L3 VPNs). Although the message format is unchanged, the present invention suggests a new message type, a new service-specific error code and a new TLV that are only applicable to L3VPN service Ping/traceroute applications.

Version number: version number of message format. In the present invention, the version number may be set to 1 but is not limited to 1.

Time To Live (TTL): indicating the maximum number of L3VPN service entities (or hop count) through which the L3VPN service response request or response message is allowed. If the value of this field decreases to zero, the L3VPN service response request/reply message must be discarded and forwarding is terminated. After each hop of the L3VPN business entity, the value of this field must be decremented by 1. The purpose is to ensure that the L3VPN service response request/reply message will eventually be finished forwarding even in the presence of a layer two broadcast loop in the topology of the L3VPN service domain (note: layer two broadcast loop is usually caused by incorrect service configuration and should normally be avoided). The maximum value of TTL is 255, which means that the diagnostic message should be propagated to the L3VPN service entity as far as possible. The minimum value of TTL is 1, which means that the diagnostic message should not propagate beyond the adjacent L3VPN service entity by one hop distance (note: the IP header also contains the TTL field, but it does not have the same meaning as the TTL field of the L3VPN service response request/reply message and therefore cannot be confused).

And (3) reserving: unused field, which may be set to 0.

Message type: this field identifies the type of service diagnostic message. In addition to the message type values defined in the previous invention, the invention also defines two new message type values:

TABLE 1 diagnostic message types

Value of	Means of
		3	L3VPN service response request message
4	L3VPN service response message

Note that: in the former invention, message types 1 and 2 are defined for the L2VPN service response request message and the response message, and the present invention expands the kinds of message types for L3VPN service diagnosis.

Response mode: this field indicates the return path of the service response reply message that the remote PE sends back a reply. The present invention reuses the existing answer mode defined for L2VPN service diagnostics in the previous invention. For example, the response mode ═ 1 represents a response by an IPv4UDP packet. Generally, the reply pattern value based on the IPv4UDP packet is sufficient for the L3VPN traffic diagnosis. This value can be extended if other answer modes are required in special cases. Although the present invention defines only one answer mode value, it will be understood by those skilled in the art that the answer mode value is not limited thereto and any suitable answer mode value falls within the scope of the present invention.

A general error code: in this field, the remote PE returns a generic error code, which applies to all types of business entities. The present invention reuses existing generic error codes defined for L2VPN service diagnostics as shown in table 2. It will be appreciated by those skilled in the art that the generic error codes in table 2 can be extended according to actual needs.

TABLE 2 general error code

Value of	Means of
		0	Without errors
1	Version number does not support
		2	Message type not support
3	Answer mode not supported
		4	Receiving TTL 0 message
5	TLV format error
		6	Common message format errors
7	Service specific errors

Service-specific error subcodes: in this field, the remote PE returns a service-specific error code, which applies only to a specific service entity type. For L3VPN service diagnostics, the present invention defines a new service-specific error subcode, as described below (note: the following service-specific error subcodes are only applicable to L3VPN service response request/response messages, i.e. message type 3 or 4).

TABLE 3 service-specific error subcodes

Handle of sender: the field is filled by a sender of the L3VPN service response request message, and the receiver returns the L3VPN service response message without any change. The sender may use the value of this field to match the reply and request messages.

Sequence number: this field is arbitrarily set by the sender of the L3VPN service response request message and can be used to detect a lost response message.

Sending a time stamp: this field is a date and Time according to a clock of the sender when the L3VPN service response request message is sent, and may be in a Network Time Protocol (NTP) format, for example.

Receiving a time stamp: this field is in the format of NTP according to the date and time of the clock of the receiving party when the L3VPN service response request message is received.

TLV: fig. 5 is a diagram illustrating the format of TLV and sub-TLV fields in an L3VPN service response request and reply message according to the present invention. The type of TLV is defined as follows. Where the length is the length of the "value" field, expressed in 8-bit bytes. The "value" field, depending on the type, is zero-padded so that boundaries of 4 8-bit bytes are aligned. The TLVs may be nested within other TLVs, in which case the nested TLVs are referred to as sub-TLVs. sub-TLVs are of independent type and must also align 4 8-bit bytes.

Table 3 lists the top level TLVs for L3VPN traffic diagnostic messages as follows:

TABLE 3 Top-level TLVs for L3VPN service diagnostic messages

Type (B)	Means of
		1	Target L3VPN service entity// reusing what was defined in the previous invention
3	Traceroute// reusing TLV defined in previous invention
		4	Service tag assignment scheme/newly defined in the present invention
5	Number of assigned service tags// newly defined in the invention

It should be noted that, in the previous invention, top level TLVs 1, 2 and 3 are defined, and the present invention reuses the existing top level TLVs 1 and 3 and defines two new top level TLVs 4 and 5. The top-level TLV2 is not generally applicable to L3VPN traffic diagnostic tools and is therefore not shown in the table.

Hereinafter, TLVs used in the present invention (including reused and newly defined) are introduced, respectively.

Target service entity TLV (TLV1)

The value of the target traffic entity TLV is a sub-TLV as defined in table 4 below:

TABLE 4 target service entity TLV

The target service entity is the TLV that is necessary in the L3VPN service response request message.

Route trace TLV (TLV3)

The traceroute TLV is an optional TLV used to trace the path of the L3VPN service request message from the originating PE to the terminating PE and associated timestamp information. The route trace TLV may be used in both L3VPN response service request messages and L3VPN response reply messages. The presence of the TLV is used to determine whether the L3VPN traffic response request message is for a L3VPN traffic PING operation or a L3VPN route trace operation.

The values of the traceroute TLV are sub-TLVs as defined in table 5 below:

TABLE 5 traceroute TLV

sub-TLV class	Length of	Value of
			Type 1	Multiple of 12	Pairing list of IPv4 addresses and timestamps

The "value" field is a column of 12 byte entries, each entry containing a 4 byte IPv4 address sub-entry and an 8 byte timestamp sub-entry. The IPv4 address sub-entry is used to record the system address of the PE receiving the L3VPN service response request message, and the time stamp sub-entry records the date and time when the L3VPN service response message is received according to the clock of the PE, for example, the time stamp sub-entry may be in NTP format.

If the originating PE intends to activate the L3VPN traffic route tracing facility, it should include a route tracing TLV in the L3VPN traffic reply request message, whose value must include the IPv4 address and timestamp pairing. The IPv4 address is the system address of the originating PE and the timestamp is the date and time when the L3VPN service reply request message (same as the transmission timestamp value in fig. 4) is transmitted, which may be in NTP format, for example. When receiving the L3VPN service response request message having the route trace TLV, each downstream PE should update the L3VPN service response request message by appending its own system address and date time within the route trace TLV (and decrementing the TTL value), and then forward the updated L3VPN service response request message along a normal downstream path.

The newly defined TLV of the present invention (TLV4 and TLV5)

Service tag assignment pattern TLV (TLV4)

The traffic tag assignment mode TLV is an optional TLV that can be used in both the L3VPN traffic response request message and the L3VPN traffic response reply message. For example, the length of the TLV may be preset to 1. If the TLV is present in the L3VPN service reply request message, its value may be, for example, 0, indicating that the initiating PE is requesting the responding PE to report the service label assignment pattern. When the terminating PE constructs the L3VPN service response reply message, it decides whether to include the service tag allocation mode TLV based on whether the service tag allocation mode TLV (e.g., value 0) exists in the incoming L3VPN service response request message. However, those skilled in the art will appreciate that the above-described setting of the length and value of the traffic tag assignment mode TLV is merely exemplary and may be set differently for particular applications.

In the above example, the reported traffic label assignment pattern may be, for example, one of the values in table 6 below:

TABLE 6 traffic tag assignment mode TLV

Value of	Means of
		0	Request for traffic label assignment pattern
1	PE assigns a service label to the whole VRF
		2	The PE allocates a service label to each direct-connected circuit
3	The PE allocates a service label for each IP route
		4	PE uses other special methods to assign service labels

Assigned service tag number TLV (TLV5)

The assigned traffic tag number TLV is an optional TLV that can be used in both the L3VPN traffic response request message and the L3VPN traffic response reply message. In one implementation, if the TLV is present in the L3VPN service reply request message, its length should be 1 and its value is also 1, which indicates that the originating PE is requesting the responding PE to report the number of assigned service labels. When the terminating PE constructs the L3VPN service response reply message, it decides whether or not to include the assigned service tag number TLV based on whether or not the assigned service tag number TLV (e.g., value 0) exists in the incoming L3VPN service response request message. However, those skilled in the art will appreciate that the above-described setting of the length and value of the assigned traffic tag number TLV is merely exemplary and may be set differently for particular applications.

In the above example, the number of assigned service tags reported may be an integer value as listed in table 7 below:

TABLE 7 assigned traffic tag number TLV

Value of	Means of
		0	Request for assigned number of service tags
Integer number of	Number of assigned service tags

Examples of the values of the various fields and the various TLVs and their corresponding meanings are given above in the form of a list. However, those skilled in the art will appreciate that the above arrangement is merely exemplary, and those skilled in the art can rearrange or set the fields according to actual needs, or make any other different arrangement of the TLV values, without departing from the scope of the present invention.

Operation of L3VPN traffic PING and route tracing tool

Fig. 2 shows a schematic diagram of the operation of the L3VPN traffic Ping tool according to the present invention, and fig. 3 shows a schematic diagram of the operation of the L3VPN traffic route tracking tool according to the present invention. The operation of the L3VPN traffic Ping and the route tracing tool is similar. For both, the originating PE sends a L3VPN service reply request message and waits for a L3VPN service reply message from the replying PE. The L3VPN service response request message is transmitted along the data path of the broadcast packet so that it can reach all PEs of the L3VPN service instance as long as the TTL value is large enough. Each traversed PE must first check whether the destination of the incoming L3VPN service reply request message is directed to itself and thus operate accordingly. If not, the L3VPN service response request message is updated firstly (the TTL value is reduced by 1; for L3VPN service route tracking, a route tracking TLV is added with a new IPv4 address and timestamp information), and then forwarded to all downstream L3VPN service entities (if the target is all L3VPN service entities, the forwarding is stopped after the last PE is reached; if the target is a specific L3VPN service entity, the forwarding is stopped after the specific PE is reached); otherwise (i.e. the L3VPN service response request message is directed to the PE itself), the PE should reply to the L3VPN service response request message in addition to updating and forwarding the L2VPN service response request message. Wherein the TTL value is to prevent a dead-loop from occurring in case of a misconfiguration of the L3VPN topology.

The L3VPN service Ping and the route tracking tool use different formats for the L3VPN service response request message and the L3VPN service response reply message. Fig. 6A and 6B illustrate diagrams of an L3VPN service response request message and an L3VPN service response message for the L3VPN service Ping tool, respectively.

As shown in fig. 6A and 6B, the L3VPN service response request message for the L3VPN service Ping utility includes a target L3VPN service entity TLV (mandatory) and a service tag allocation mode TLV (optional) and an allocated service tag number TLV (optional), and the L3VPN service response reply message for the L3VPN service Ping utility includes a service tag allocation mode TLV (optional) and an allocated service tag number TLV (optional).

Fig. 7A and 7B show schematic diagrams of an L3VPN service response request message and an L3VPN service response reply message for the L3VPN service route tracking tool, respectively.

As shown in fig. 7A and 7B, the L3VPN service response request message for the L3VPN service route tracing tool includes a target L3VPN service entity TLV (mandatory) and a route tracing TLV (mandatory) and a service tag assignment mode TLV (optional) and an assigned service tag number TLV (optional), and the L3VPN service response message for the L3VPN service route tracing tool includes a route tracing TLV (mandatory) and a service tag assignment mode TLV (optional) and an assigned service tag number TLV (optional).

The L3VPN service response request message and the L3VPN service response reply message are both encapsulated in UDP packets. The UDP port number may be configured locally on each PE with Vendor proprietary (Vendor proprietary) values, or publicly assigned by IANA to support global interoperability. In the present invention, the UDP port is referred to as the L3VPN traffic Ping port.

For L3VPN traffic response request packets, the target IPv4 address is set to any IPv4 address within the range of 127/8 and the source IPv4 address is set to the system address of the originating PE. The destination UDP port number is set to the L3VPN traffic Ping port number, and the source UDP port is arbitrarily set by the originating PE. For the corresponding L3VPN service response reply message, the target IPv4 address is set to the source IPv4 address of the received L3VPN service response request packet, and the source IPv4 address is set to the system address of the responding PE. The target UDP port number is set as a source UDP port of the received L3VPN service response request packet, and the source UDP port number is set as a Ping port of the L3VPN service.

The diagnostic packets carrying the L3VPN service response request message travel along the loop-free data path of the broadcast packets within the L3VPN service instance to be able to reach all L3VPN entities within the L3VPN service instance once and only once. Note that the diagnostic packet is in fact a tagged IPv4 packet, the MPLS label is any traffic label assigned to the L3VPN traffic instance, and the IPv4 packet carries the UDP payload of the L3VPN traffic echo request message. The tagged IPv4 packet is transmitted over an inter-VRF traffic transport path, which may be an MPLS LSP or a Generic Routing Encapsulation (GRE) tunnel. Under normal circumstances, if the operator has configured the L3VPN traffic characteristics (i.e., has properly configured the outgoing RT and the incoming RT), the horizontally split group associated with each VRF should not include a loop in the data path of the broadcast diagnostic packet. In a misconfigured L3VPN service, there may be loops in the data path broadcasting the diagnostic packets. To prevent such an undesired endless loop, each L3VPN service echo request message is limited to a TTL value (maximum TTL value is 255).

Operation of originating PE

When the above-mentioned L3VPN service response request message and service response message are used for L3VPN service diagnosis, the originating PE performs the following steps: constructing an L3VPN service response request message; sending the L3VPN service response request message to other PEs; and receiving L3VPN service response messages from other PEs. Wherein the L3VPN service response request message includes a target L3VPN service entity TLV. In the claims and elsewhere in the specification, an originating PE is sometimes also referred to as a first PE, and accordingly, other PEs than the originating PE that participate in L3VPN traffic are also referred to as second PEs. In particular, the operation of the originating PE according to embodiments of the present invention is described in detail below.

(1) The originating PE builds an L3VPN service response request message to send.

In one implementation, in the constructed L3VPN service response request message, the version number may be 1, the message type is 3, the response mode is 1, and the TTL value is input from an administrator. The reserved field, the generic error code and the service-specific error code are all set to 0. The sender's message handle is used to match the reply and request messages and may be set in a variety of different ways. For example, when a new continuous L3VPN service response request message group transmission is transmitted, it may be set to a new random number. The sequence number is used to detect missed reply messages and may also be set in a different way, e.g. it may be set to 1, 2, 3 … … when each successive message of a set of L3VPN service response request messages with the same sender message handle value is sent. The transmission time stamp is set to the time of day (e.g., in NTP format) when the L3VPN service reply request message is transmitted. The reception timestamp may be set to 0.

(2) For both L3VPN traffic Ping and route tracing tools, a target L3VPN traffic entity TLV is mandatory. The value of the target business entity TLV may be set to a type 1 sub-TLV (all business entities) or a type 2 sub-TLV (one specific business entity) according to an administrator's input.

The route trace TLV is mandatory for L3VPN traffic route trace tools, but not necessary for L3VPN traffic Ping tools. When the administrator invokes the L3VPN traffic route tracking tool, the originating PE must include a route tracking TLV in the L3VPN traffic reply request message. The route trace TLV must contain only one pair of IPv4 address, which is the system address of the originating PE, and a timestamp, which is the time of day (same as the value in the send timestamp field in fig. 4) when the L3VPN service reply request message was sent.

The traffic tag assignment mode TLV and the assigned traffic tag number TLV are optional for the L3VPN traffic diagnostic tool. Depending on the administrator's input, the L3VPN service response request message may include one, both, or none of them.

The constructed L3VPN service response request message is encapsulated in a UDP IPv4 packet. However, those skilled in the art will appreciate that the present invention is not limited thereto, and other protocol packets may be used to carry the constructed L3VPN service response request message (and/or L3VPN service response reply message).

(3) The originating PE sends the constructed L3VPN service response request message over all inter-VRF traffic transmission paths to the traffic peers of the L3VPN service instance to be diagnosed.

For the case that all L3VPN service entities are Ping or route traced, all PEs participating in the L3VPN service should reply with an L3VPN service reply message. For the case that only one specific L3VPN service entity is Ping or route traced, only the specific target PE will reply to the L3VPN service response message, and all other PEs simply update and forward the L3VPN service response request message without responding to it.

If all L3VPN traffic entities within the L3VPN traffic are Ping or route traced, the initial TTL value may be set to 255 (or any other number deemed sufficiently large by the implementer). If only a portion of the L3VPN traffic entity is Ping or route traced, the TTL values can be set to 1, 2, 3, … …. For example, the L3VPN service reply request message with TTL ═ 1 will Ping or route all adjacent (i.e., one hop apart) L3VPN service entities.

When each PE receives a tagged IPv4 packet from any incoming L3VPN traffic transmission path and the target UDP port of the IPv4 packet is equal to the configured L3VPN traffic Ping port, the PE must treat it as a L3VPN traffic diagnostic packet. The PE must first verify that the version number, message type, and reply mode are all correct, and that the TTL value is not zero. And if any one of the verification items is wrong, the PE returns an L3VPN service response packet and stops forwarding the L3VPN service response request message, wherein the L3VPN service response packet comprises a corresponding universal error code.

If there is no error in the incoming message format (and thus the message type must be 3), the PE should parse the TLV field. TLV1 (target business entity) is mandatory and TLVs 3, 4 or 5 are optional. If there are any TLV (or sub-TLV) format errors in the incoming L3VPN service response request message, the PE must return the L3VPN service response request message with a generic error code 5 (format error TLV) and stop forwarding the L3VPN service response request message.

If neither the message format nor the TLV format is in error, the PE should verify the correctness of the traffic label, its binding to the L3VPN traffic entity (and its related components), and the integrity of the L3VPN traffic entity itself. If the service label is not in the label information base or associated with any L3VPN service entity, the PE must return a L3VPN service response packet with a service specific error subcode of 1 (service label error or incorrectly bound to the L3VPN service instance). If the L3VPN service entity (or its related components) has any errors, the PE must return a L3VPN service response acknowledgement packet with a service specific error sub-code of 2(L3VPN service instance error). If there are any other errors that are not covered by the defined service-specific error codeword, the PE must return a service-specific L3VPN service response acknowledgement packet with a service-specific error subcode of 3 (universal error). If there are any traffic-specific errors, the PE must stop forwarding the L3VPN traffic reply request message.

After verifying the message format, TLV format, service tag, and L3VPN service entity, the PE can determine the L3VPN service instance being diagnosed and then determine the target of the incoming L3VPN service reply request message.

When receiving the L3VPN service response request message, all PEs except the originating PE behave as follows:

if the received L3VPN service response request message is targeted to all L3VPN service entities, then:

the PE executes the process of returning the L3VPN service response message;

the PE executes the process of updating the L3VPN service response request message;

the PE executes the process of forwarding the updated L3VPN service response request message;

otherwise, if the received L3VPN service response request message is targeted to a specific L3VPN service entity and happens to be the PE, then:

the PE executes the process of returning the L3VPN service response message;

otherwise (i.e. the received L3VPN service response request message is not targeted to all L3VPN service entities nor to the specific PE), then

The PE executes the process of updating the L3VPN service response request message;

the PE performs a process of forwarding the updated L3VPN service response request message.

In the present invention, the processes of updating the L3VPN service response request message, forwarding the updated L3VPN service response request message, and returning the L3VPN service response message are as follows:

the process of updating the L3VPN service response request message comprises the following steps:

(1) firstly, making a copy of an incoming L3VPN service response request message, and processing the copy as follows:

the PE reduces the TTL value in the message copy by 1;

if the message copy contains a traceroute TLV, the PE adds its system address and the time of day (e.g., in NTP format) that the incoming message was received at the end of the traceroute TLV.

In this way, the message copy becomes an updated L3VPN service response request message.

The process of forwarding the updated L3VPN service response request message:

if the updated TTL value of the L3VPN service response request message is zero, stopping forwarding;

otherwise, the PE sends the updated L3VPN service response request message in the same manner as the broadcast packet through all inter-VRF service transmission paths of the L3VPN service instance. That is, the updated message should be sent through all other inter-VRF traffic distribution paths (through all inter-VRF traffic transmission paths belonging to different split-level groups), except for inter-VRF traffic transmission paths belonging to the same split-level group as the incoming traffic peer.

Note that: the forwarding process will stop in either case: (a) the TTL value is reduced to 0; (b) the L3VPN service response request message reaches the most downstream PE.

And returning the L3VPN service response message:

(1) the PE constructs an L3VPN service response message to be sent. In one implementation, in the constructed L3VPN service response message, the version number is 1 and the message type is 4. TTL and the reply mode are not used in the L3VPN service reply response message, and may be set to 0. The handle, sequence number and transmission time stamp of the sender are copied from the incoming L3VPN service reply request message. The receive timestamp field is populated by the time of day (e.g., in NTP format) that the incoming L3VPN traffic response request message was received.

(2) If the incoming L3VPN service response request message does not include a route tracking TLV (i.e., for the case of L3VPN service Ping), the PE should construct an L3VPN service response message having zero, one, or two TLVs depending on whether the incoming L3VPN service response request message includes a service tag assignment mode TLV (value 0) and/or an assigned service tag number TLV (value 0). For the L3VPN service Ping case, the L3VPN service response reply message constructed by the PE should not include the route trace TLV.

Otherwise, if the incoming L3VPN service response request message includes a route tracking TLV (i.e., for the case of L3VPN service route tracking), the PE should construct an L3VPN service response message having one route tracking TLV plus zero, one, or two other optional TLVs (service tag assignment mode TLV and/or assigned service tag number TLV). The traceroute TLV is generated by appending the system address of the PE and the time of day (e.g., in NTP format) when the incoming L3VPN service response request message is received to the end of the traceroute TLV copied from the incoming L3VPN service response request message. Whether the L3VPN service response reply message should include the service tag assignment mode TLV and/or the assigned service tag number TLV depends on whether one or both of them (value 0) are present in the incoming L3VPN service response request message.

(3) The PE returns the constructed L3VPN service response message through UDP IPv4 grouping.

In one implementation of the present invention, to avoid that many very similar L3VPN service response reply messages flood the replied PEs in case of diagnosing all service entities, each replying PE should delay a random time interval before sending the reply message. Any reasonable random delay algorithm may be used and the invention is not limited to a particular delay algorithm.

In one implementation of the invention, only forwarded L3VPN service response request messages traverse the data path of the L3VPN service packets. The returned L3VPN service response message does not pass through the data path of the L3VPN service packet, but passes through a normal IP forwarding data path.

In one implementation of the present invention, since L3VPN traffic packets may traverse multiple data paths of the L3VPN traffic packets from the originating PE to the particular target PE, after initializing the L3VPN traffic response request message, the originating PE may receive multiple L3VPN traffic response reply messages that represent the multiple data paths that the L3VPN traffic response request message may traverse, for example as shown in fig. 3.

CLI command for L3VPN traffic Ping and route tracking tool

The L3VPN traffic Ping and the route tracing tool may be implemented in Command Line Interface (CLI) commands. In the CLI interface of the PE, when the current CLI context is an L3VPN service instance to be diagnosed, the administrator may call the L3VPN service Ping or the route tracking tool with the following command:

l3vpn-ping*|ip-address[[no]service-label-assign-mode][[no]nbr-of-service-label][hop hop-count]

l3vpn-traceroute*|ip-address[[no]service-label-assign-mode][[no]nbr-of-service-label][hop hop-count]

wherein, "| ip-address" is a mandatory CLI parameter that specifies the target L3VPN service entity. Denotes all L3VPN service entities and ip-address denotes one specific L3VPN service entity on a PE with a specified system address. "[ no ] service-label-assign-mode" and "[ no ] nbr-of-service-label" are optional CLI parameters that specify whether a service label assignment pattern and/or a service label number should be reported. The implementer may decide on its default values.

The "hop hop-count" is an optional CLI parameter that specifies the initial TTL value of the L3VPN service reply request message. The implementer may decide on its default values.

Fig. 8 shows a block diagram of an apparatus 800 for L3VPN traffic diagnosis according to the invention. The apparatus 800 may be located, for example, in an originating PE (first PE).

As shown in fig. 8, the apparatus 800 comprises: a constructing unit 810 configured to construct an L3VPN service response request message; a transmitting unit 820 configured to transmit an L3VPN service response request message to the second PE; a receiving unit 830 configured to receive an L3VPN service response message from the second PE; wherein, the L3VPN service response request message includes a target service entity TLV for specifying the L3VPN service entity which should respond to the L3VPN service response request message.

In one implementation, the target L3VPN service entity TLV is configured to designate that the L3VPN service entity that should respond to the L3VPN service response request message is all L3VPN service entities or a specific L3VPN service entity, and wherein when the target L3VPN service entity TLV designates that the L3VPN service entity that should respond to the L3VPN service response request message is all L3VPN service entities, the second PE is any one of all PEs participating in the L3VPN service except the first PE, and when the target L3VPN service entity TLV designates that the L3VPN service entity that should respond to the L3VPN service response request message is a specific L3VPN service entity, the second PE is the specific L3VPN service entity.

In one implementation, the L3VPN service response request message further includes a message type field set to a first value, and the L3VPN service response reply message further includes a message type field set to a second value different from the first value.

In one implementation, when the L3VPN service response request message is used for L3VPN service route tracing, the L3VPN service response request message further includes a route tracing TLV for indicating system addresses of all PEs traversed by the L3VPN service response request message from the first PE to the terminating PE.

In one implementation, the L3VPN service response request message further includes a service label allocation mode TLV and/or an allocated service label number TLV, which are used to respectively indicate a mode of allocating a service label to the L3VPN service entity by the second PE and an allocated service label number.

In one implementation, the L3VPN service response request message further includes at least one of: version number, time-to-live, reserved field, reply mode, generic error code, service specific error subcode, sender's handle, sequence number, send timestamp, and receive timestamp.

Fig. 9 shows a block diagram of another apparatus 900 for L3VPN traffic diagnosis according to the present invention. Apparatus 900 may be located, for example, in a PE other than the originating PE (a second PE).

As shown in fig. 9, the apparatus 900 includes: a receiving unit 910 configured to receive a L3VPN service response request message from the first PE, the L3VPN service response request message including a target L3VPN service entity TLV for specifying a L3VPN service entity that should respond to the L3VPN service response request message; a determining unit 920 configured to determine whether the L3VPN service response request message is targeted to all L3VPN service entities or one specific L3VPN service entity; a processing unit 930 configured to, when the L3VPN service response request message is targeted to all L3VPN service entities, return an L3VPN service response message to the first PE, update the L3VPN service response request message and forward the updated L3VPN service response request message; and returning an L3VPN service response message to the first PE when the L3VPN service response request message is targeted to a specific L3VPN service entity and the second PE is the specific L3VPN service entity.

In one implementation, the L3VPN service response request message further includes a message type field set to a first value, and the L3VPN service response reply message further includes a message type field set to a second value different from the first value.

In one implementation, when the L3VPN service response request message is used for L3VPN service route tracing, the L3VPN service response message further includes a route tracing TLV for indicating system addresses of all PEs traversed by the L3VPN service response request message from the first PE to the terminating PE.

In one implementation, the L3VPN service response message further includes a service label allocation mode TLV and/or an allocated service label number TLV, which are used to respectively indicate a mode of allocating a service label to the L3VPN service entity by the second PE and an allocated service label number.

In one implementation, the processing unit 930 is further configured to: when the target of the L3VPN service response request message is neither all L3VPN service entities nor the second PE, the L3VPN service response request message is updated and the updated L3VPN service response request message is forwarded.

In one implementation, the apparatus 900 further includes a verifying unit 940 for verifying the L3VPN service response request message before the determining unit 920 determines whether the L3VPN service response request message targets all L3VPN service entities or one specific L3VPN service entity. More specifically, the verifying unit 940 is configured to verify at least one verification item in the L3VPN service response request message, the verification item including a version number, a message type, a reply mode, a TTL value, and a TLV format; and if any of the verification items is wrong, returning an L3VPN service response message and stopping forwarding the L3VPN service response request message, wherein the L3VPN service response message comprises a corresponding error code to indicate the verification error.

In one implementation, the processing unit 930 returns the L3VPN service response acknowledgement message over an IP forwarding data path instead of over the data path of the L3VPN service packet.

To summarize:

the present invention provides two new L3VPN traffic diagnostic tools (L3VPN traffic Ping tool and L3VPN traffic route tracking tool) which are extensions to the previous invention for L2VPN traffic diagnosis. In order to support two new diagnostic tools, the present invention suggests the following extensions to the previous invention: two new message types, four new traffic-specific error subcodes, two new TLVs, and describes the behavior or pseudo-algorithm of the PE implementing the new L3VPN service Ping and the traceroute tool.

In one or more exemplary designs, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. Such computer-readable media can comprise, for example, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of instructions or data structures and which can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the present invention. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the present invention is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (14)

1. A method for L3VPN traffic diagnosis, the method comprising the following steps performed by a first PE:

constructing an L3VPN service response request message;

sending the L3VPN service response request message to a second PE; and

receiving an L3VPN service response message from the second PE;

wherein the L3VPN service response request message includes a target L3VPN service entity TLV for specifying a L3VPN service entity that should respond to the L3VPN service response request message, and the target L3VPN service entity TLV for specifying that the L3VPN service entity that should respond to the L3VPN service response request message is all L3VPN service entities or a specific L3VPN service entity,

when the target L3VPN service entity TLV specifies that the L3VPN service entities that should respond to the L3VPN service response request message are all L3VPN service entities, the second PE is any one of all PEs participating in the L3VPN service except the first PE,

when the target L3VPN service entity TLV specifies that the L3VPN service entity that should respond to the L3VPN service response request message is a specific L3VPN service entity, the second PE is the specific L3VPN service entity,

when the L3VPN service entities responding to the L3VPN service response request message are all L3VPN service entities, the L3VPN service response message is sent by the second PE after a random time interval is delayed.

2. The method of claim 1, wherein the L3VPN service response request message further includes a message type field set to a first value, and the L3VPN service response reply message further includes a message type field set to a second value different from the first value.

3. The method of claim 2, wherein when the L3VPN traffic response request message is for L3VPN traffic route tracing, the L3VPN traffic response request message further includes a route trace TLV indicating system addresses of all PEs traversed by the L3VPN traffic response request message from the first PE to a terminating PE.

4. The method according to claim 2 or 3, wherein the L3VPN service response request message further includes a service tag assignment mode TLV and/or an assigned service tag number TLV for instructing the first PE to assign a mode of a service tag and an assigned service tag number to the L3VPN service entity, respectively.

5. The method of claim 1, wherein the L3VPN service response request message further comprises at least one of: version number, time-to-live, reserved field, reply mode, generic error code, service specific error subcode, sender's handle, sequence number, send timestamp, and receive timestamp.

6. A method for L3VPN traffic diagnosis, the method comprising the following steps performed by a second PE:

receiving an L3VPN service response request message from a first PE, wherein the L3VPN service response request message comprises a target L3VPN service entity TLV, and is used for specifying an L3VPN service entity which should respond to the L3VPN service response request message;

determining whether the L3VPN service response request message is targeted to all L3VPN service entities or a specific L3VPN service entity;

when the L3VPN service response request message is targeted to all L3VPN service entities, the second PE returns an L3VPN service response message to the first PE, updates the L3VPN service response request message and forwards the updated L3VPN service response request message; and is

When the L3VPN service response request message is targeted to a specific L3VPN service entity and the second PE is the specific L3VPN service entity, the second PE returns a L3VPN service response message to the first PE,

when the L3VPN service entities responding to the L3VPN service response request message are all L3VPN service entities, the second PE delays a random time interval before returning the L3VPN service response message to the first PE.

7. The method of claim 6, wherein the L3VPN service response request message further includes a message type field set to a first value, and the L3VPN service response reply message further includes a message type field set to a second value different from the first value.

8. The method of claim 7, wherein when the L3VPN traffic response request message is for L3VPN traffic route tracing, the L3VPN traffic response reply message further includes a route trace TLV indicating system addresses of all PEs traversed by the L3VPN traffic response request message from the first PE to a terminating PE.

9. The method according to claim 7 or 8, wherein the L3VPN service response reply message further includes a service label assignment mode TLV and/or an assigned service label number TLV for instructing the second PE to assign a mode of a service label and an assigned service label number to the L3VPN service entity, respectively.

10. The method of claim 6, further comprising:

when the target of the L3VPN service response request message is neither all L3VPN service entities nor the second PE, the second PE updates the L3VPN service response request message and forwards the updated L3VPN service response request message.

11. The method of claim 6, further comprising, prior to determining whether the L3VPN service response request message is targeted to all L3VPN service entities or to a particular L3VPN service entity:

verifying the L3VPN service response request message, further comprising:

verifying at least one verification item in the L3VPN service response request message, wherein the verification item comprises a version number, a message type, a response mode, a TTL value and a TLV format;

if any of the verification items is wrong, returning the L3VPN service response message and stopping forwarding the L3VPN service response request message, wherein the L3VPN service response message comprises a corresponding error code to indicate a verification error.

12. The method of claim 6, wherein the L3VPN traffic response reply message is returned over an IP forwarding data path and not over a data path of an L3VPN traffic packet.

13. An apparatus for L3VPN traffic diagnosis, the apparatus located in a first PE, comprising:

a construction unit configured to construct an L3VPN service response request message;

a transmitting unit configured to transmit the L3VPN service response request message to a second PE; and

a receiving unit configured to receive an L3VPN service response message from the second PE;

wherein the L3VPN service response request message includes a target L3VPN service entity TLV for specifying a L3VPN service entity that should respond to the L3VPN service response request message, and the target L3VPN service entity TLV for specifying that the L3VPN service entity that should respond to the L3VPN service response request message is all L3VPN service entities or a specific L3VPN service entity,

when the target L3VPN service entity TLV specifies that the L3VPN service entities that should respond to the L3VPN service response request message are all L3VPN service entities, the second PE is any one of all PEs participating in the L3VPN service except the first PE,

when the target L3VPN service entity TLV specifies that the L3VPN service entity that should respond to the L3VPN service response request message is a specific L3VPN service entity, the second PE is the specific L3VPN service entity,

when the L3VPN service entities responding to the L3VPN service response request message are all L3VPN service entities, the L3VPN service response message is sent by the second PE after a random time interval is delayed.

14. An apparatus for L3VPN traffic diagnosis, the apparatus located in a second PE, comprising:

a receiving unit configured to receive a L3VPN service response request message from a first PE, the L3VPN service response request message including a target L3VPN service entity TLV for specifying a L3VPN service entity that should respond to the L3VPN service response request message;

a determining unit configured to determine whether the L3VPN service response request message is targeted to all L3VPN service entities or one specific L3VPN service entity; and

a processing unit configured to return an L3VPN service response message to the first PE, update the L3VPN service response request message, and forward the updated L3VPN service response request message when the L3VPN service response request message targets all L3VPN service entities; and returning an L3VPN service response message to the first PE when the L3VPN service response request message is targeted to a specific L3VPN service entity and the second PE is the specific L3VPN service entity,

when the L3VPN service entities responding to the L3VPN service response request message are all L3VPN service entities, the second PE delays a random time interval before returning the L3VPN service response message to the first PE.

Images