Source: https://patents.google.com/patent/KR101487572B1/en
Timestamp: 2020-01-22 06:32:14
Document Index: 690376461

Matched Legal Cases: ['Application No. 60', 'Application No. 12', 'Application No. 12', 'Application No. 12', 'Application No. 12', 'Application No. 12', 'Application No. 12', 'Application No. 12', 'Application No. 12']

KR101487572B1 - Continuity check management in a link state controlled ethernet network - Google Patents
Continuity check management in a link state controlled ethernet network Download PDF
KR101487572B1
KR101487572B1 KR20107010431A KR20107010431A KR101487572B1 KR 101487572 B1 KR101487572 B1 KR 101487572B1 KR 20107010431 A KR20107010431 A KR 20107010431A KR 20107010431 A KR20107010431 A KR 20107010431A KR 101487572 B1 KR101487572 B1 KR 101487572B1
KR20107010431A
KR20100100784A (en
디네쉬 모한
폴 언베하겐
스리칸쓰 키사라
2007-10-12 Priority to US97943807P priority Critical
2007-10-12 Priority to US60/979,438 priority
2008-10-14 Application filed by 노오텔 네트웍스 리미티드 filed Critical 노오텔 네트웍스 리미티드
2008-10-14 Priority to PCT/US2008/079825 priority patent/WO2009049311A1/en
2010-09-15 Publication of KR20100100784A publication Critical patent/KR20100100784A/en
2015-01-29 Publication of KR101487572B1 publication Critical patent/KR101487572B1/en
Link State Protocol In a controlled Ethernet network, an OAM link trace message is sent from the source node to the target node. The link trace message uses the 802.1ag format except that it uses the unicast Ethernet MAC node ID of the target node or the multicast destination address of the service instance as the destination address. A network topology verification method in a link state protocol controlled Ethernet network checks a link state protocol database at a node to identify a control plane topology view of at least a portion of the network. And executes one or more Ethernet OAM commands from the node to identify a data plane topology view of the same portion of the network. These views are compared to see if the control plane topology view of the network matches the data plane topology view of the network.
[0002] CONTINUITY CHECK MANAGEMENT IN A LINK STATE CONTROLLED ETHERNET NETWORK [0003]
[Related Application Cross Reference]
The present application claims priority to U.S. Provisional Patent Application No. 60 / 979,438 filed on October 12, 2007 entitled "PLSB AND IP SHORTCUTS OAM", the contents of which are incorporated herein by reference.
This application is related to U.S. Patent Application No. 12 / 249,941, filed October 12, 2008, entitled " IP NETWORK AND PERFORMANCE MONITORING USING ETHERNET OAM " U.S. Patent Application No. 12 / 249,944 (filed on October 12, 2008 entitled " AUTOMATIC MEP PROVISIONING IN A LINK STATE CONTROLLED ETHERNET NETWORK "); And US Patent Application No. 12 / 249,946 (filed on October 12, 2008, entitled " CONTINUITY CHECK MANAGEMENT IN A LINK STATE CONTROLLED ETHERNET NETWORK ", co-applicant: Nortel Networks Limited) No. 12 / 151,684 filed on May 5, 2008, entitled " IP FORWARDING ACROSS A LINK STATE PROTOCOL CONTROLLED ETHERNET NETWORK, co-applicant: Nortel Networks Limited.
The present invention relates to a link state protocol controlled Ethernet network, and more particularly to operation, maintenance, and maintenance (OAM) in a link state protocol controlled Ethernet network.
A data communication network may include various computers, servers, nodes, routers, switches, bridges, hubs, proxies, and other network devices coupled together and configured to communicate data with one another. Such a device will be referred to herein as a "network element. &Quot; By communicating protocol data units, such as logical combinations of Internet Protocol packets, Ethernet frames, data cells, segments, or other data bits / bytes, between network elements using one or more communication links between network elements, And communicates data through the network. A particular protocol data unit may be processed by multiple network elements across multiple communication links while moving between the source and destination via the network.
The various network elements on the communication network communicate with each other using a predetermined set of rules (hereinafter referred to as protocol). How to configure the signal for communication between network elements, what the protocol data unit should look like, how the protocol data unit should be processed by the network element and routed through the network, Different protocols are used to control different aspects of communication, such as whether information should be exchanged between network elements.
Ethernet is a well-known networking protocol defined by the American Institute of Electrical and Electronics Engineers (IEEE) as standard 802.1 in the Ethernet network architecture, where devices connected to the network compete for the ability to use a shared telecommunication path at any given time. When multiple bridges or nodes are used to interconnect network segments, there are often multiple possible paths for the same destination. The advantage of this architecture is that it provides path redundancy between bridges and allows capacity to be added to the network in the form of additional links. However, in order to prevent loops from forming, a spanning tree is generally used to limit the manner in which traffic is broadcasted or flooded on the network. The nature of the spanning tree is that there is only one path between any pair of destinations in the network and thus can "learn" the connectivity associated with a given spanning tree by looking at where the packet comes from. However, the spanning tree itself is limited and often leads to non-utilization of links that are not over-utilization of the links on the spanning tree or parts of the spanning tree.
In order to overcome some of the limitations inherent in the Ethernet network implementing the Spanning Tree, a link state protocol controlled Ethernet network is disclosed in U.S. Patent Application 11 / 537,775 filed on October 2, 2006, entitled &quot; (Provider Link State Bridging, the contents of which are incorporated herein by reference). As described in detail in this application, rather than using the learned network view at each node using spanning tree protocol (STP) combined with transparent bridging, the link state protocol controlled Ethernet network Bridges forming a mesh network exchange link state advertisements so that each node can have a synchronized network topology view. This is accomplished through a known mechanism of the link state routing system. The bridges in the network have a synchronized network topology view, knowledge of the required unicast and multicast connectivity, can calculate the shortest path connectivity between any pair of bridges in the network, The forwarding information base (FIB) of the base station can be individually populated.
If all nodes compute their roles in the synchronized view and populate their FIBs, then the network is able to determine the set of peer bridges (those that require communication with the bridge for whatever reason) A loop-free unicast tree to a given bridge, and a loop-free point-to-point connection, both congruent to either the same bridge bridge set or subset from any given bridge by a service instance hosted at the bridge, And will have a point-to-multipoint (p2mp) multicast tree. As a result, the path between a given pair of bridges is not limited to passing through the root bridge of the spanning tree, so the overall result can take advantage of the breadth of the mesh's connectivity. Essentially all bridges are roots for one or more trees that define unicast connectivity to that bridge and multicast connectivity from that bridge.
When the customer traffic enters the provider network, the customer MAC address (C-MAC DA) is decomposed into a provider MAC address (B-MAC DA) and the provider uses the provider MAC address space Thereby allowing traffic to be forwarded. The network elements on the provider network are also configured to forward traffic based on the virtual LAN ID (VID) so that different frames addressed to the same destination address but with different VIDs are forwarded through different paths in the network . In operation, the link state protocol controlled Ethernet network may associate a VID range with shortest path forwarding so that unicast and multicast traffic can be forwarded using the VID from the range, Path can be generated across the network on a path other than the shortest path and forwarded using the second VID range.
In order to add a true carrier class feature to the link state protocol controlled Ethernet, a certain Operational Management Maintenance (OAM) feature is desirable. The Ethernet OAM defines a set of connectivity fault management protocols for use in an Ethernet network, as currently defined in the IEEE Standard 802.1ag "Connectivity Fault Management ". These include continuity checking, link tracing, and loopback protocols. The 802.1ag standard has been extended to include performance monitoring metrics and messages. This standard is reflected in ITU-T SG 13, Y.1731 - "Requirements for OAM in Ethernet Networks". However, the mechanisms described in these standards can not be applied directly to the link state protocol Ethernet network because of some differences in addressing between the standard and the link state protocol controlled Ethernet network, VLAN semantics and utilization. It is therefore desirable to include OAM features in a link state protocol controlled Ethernet network for purposes of fault identification, isolation, troubleshooting, and performance monitoring.
According to the present invention, a method of transmitting an OAM message in a link state protocol controlled Ethernet network is provided. The method includes transmitting an OAM link trace message from a source node to a target node in the link state protocol controlled Ethernet network, wherein the link trace message includes a unicast Ethernet MAC node ID of the target node as a destination address Except that it uses the 802.1ag format.
According to another aspect of the present invention, another method of transmitting an OAM message in a link state protocol controlled Ethernet network comprises transmitting an OAM link trace message from a source node in the link state protocol controlled Ethernet network to trace a service instance Where the link trace message uses the 802.1ag format except that it uses the multicast destination address of the service instance as the destination address.
According to a third aspect of the present invention, a method for verifying a network topology in a link state protocol controlled Ethernet network comprises the steps of: checking a link state protocol database at a node to identify a control plane topology view of at least a portion of the network; Executing one or more Ethernet OAM commands from the node to identify a data plane topology view of the same portion of the network; Comparing the views of the network to find out whether they match the control plane topology view of the network and the data plane topology view of the network; And flagging the error if these views do not match.
Wherein checking the link state protocol database may include tracing all paths through the network from a first node in the link state protocol controlled Ethernet network and wherein executing the one or more Ethernet OAM commands comprises: And executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service instance, wherein the link trace instruction uses a multicast destination address of the service instance as a destination address Except for the 802.1ag format.
Alternatively, checking the link state protocol database may include tracing a path through the network from a first node to a second node in the link state protocol controlled Ethernet network, wherein the one or more Ethernet OAM commands May include executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service path, wherein the link trace instruction is operable to send the Ethernet MAC node ID &lt; RTI ID = 0.0 &gt;Lt; / RTI &gt; format except for using a unicast destination address of &lt; RTI ID = 0.0 &gt;
According to another aspect of the present invention there is provided a program product comprising a computer readable medium for storing data, wherein a computer program is embodied, the computer program comprising: means for transmitting an OAM message in a link state protocol controlled Ethernet network Logic. Wherein the logic includes logic for transmitting an OAM link trace message from a source node to a target node in the link state protocol controlled Ethernet network, wherein the link trace message includes a unicast Ethernet MAC node ID The 802.1ag format is used.
According to a further aspect of the present invention there is provided a program product comprising a computer readable medium for storing data, wherein a computer program is embodied, the computer program comprising: And logic for transmitting an OAM link trace message from a source node in an Ethernet network, wherein the link trace message uses the 802.1ag format except that it uses the multicast destination address of the service instance as a destination address.
According to another aspect of the present invention, there is provided a program product including a computer readable medium for storing data, in which a computer program is embodied. The computer program performs network topology verification in a link state protocol controlled Ethernet network. The computer program comprising: logic for checking a link state protocol database at a node to identify a control plane topology view of at least a portion of the network; Logic for executing one or more Ethernet OAM commands from the node to identify a data plane topology view of the same portion of the network; Logic for comparing the views of the network to those of the control plane topology view and the data plane topology view of the network; And logic for flagging errors if these views do not match.
According to one embodiment of the present invention, the logic for checking the link state protocol database comprises logic for tracing all paths through the network from a first node in the link state protocol controlled Ethernet network, Logic for executing the Ethernet OAM instruction further comprises logic for executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service instance, It uses the 802.1ag format except that it uses the multicast destination address of the service instance.
According to another embodiment of the present invention, the logic for checking the link state protocol database comprises logic for tracing a path through the network from a first node to a second node in the link state protocol controlled Ethernet network Wherein the logic for executing the one or more Ethernet OAM commands comprises logic for executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service path, The 802.1ag format is used except that the unicast destination address of the Ethernet MAC node ID is used as the address.
An aspect of the invention is particularly pointed out in the appended claims. The present invention is illustrated by way of example in the following figures, wherein like elements are designated by like reference numerals. The following drawings illustrate various embodiments of the invention for purposes of illustration only and are not intended to limit the scope of the invention. For the sake of clarity, not all components are indicated in each figure. The drawing is as follows:
1 is a functional block diagram of a mesh network that may be used to implement a link state protocol controlled Ethernet network;
2 is a schematic diagram illustrating an implementation of a network element 12 configured for use in a link state protocol controlled Ethernet network;
Figure 3 illustrates that a link state protocol, such as IS-IS, performs a discovery phase to interconnect bridges in a loop-free configuration using the Sys-ID of each bridge, Gt; a &lt; / RTI &gt; configured link state protocol controlled Ethernet network that generates an EVPN between all of the nodes in the network;
4 is a schematic diagram illustrating a link state protocol controlled Ethernet network similar to that of FIG. 3, currently shown to map multiple services, with the exception of the discovery phase tree;
5 is a block diagram of an Ethernet OAM maintenance domain defined by the 802.1ag standard;
6 is a block diagram of an 802.1ag OAM packet;
7 is a flow diagram of the processing of an infrastructure level OAM packet at a node of a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention;
FIG. 8 is a flowchart of an infrastructure level continuity check process executed in a node of a link state protocol controlled Ethernet network according to an embodiment of the present invention; FIG.
9 is a flow diagram of the processing of a service level OAM packet at a node of a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention;
10 is a flowchart of a service bevel continuity check process executed in a node of a link state protocol controlled Ethernet network according to an embodiment of the present invention;
11 is a flow diagram of MEP generation and distribution by a node of a link state protocol controlled Ethernet network according to an embodiment of the present invention;
12 is a flow diagram of MEP reception and forwarding table updates at nodes in a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention;
13 is a flow diagram of a MEP of a process that uses MEP lookups to send OAM commands from a node A to a node B in accordance with an embodiment of the present invention;
Figure 14 is a schematic diagram of an IP "Ping" command executed between two IP nodes on a link state protocol controlled Ethernet network;
15 is a flow diagram of the processing of an IP level "ping" instruction at a node of a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention;
16 is a flow diagram of the processing of an IP level "Traceroute" command at a node of a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention;
FIG. 17 is a flow chart illustrating a method of monitoring a VoIP network in which a provider is coupled to a customer premise with an IP phone, all communication takes place over a link state protocol controlled Ethernet network, and performance monitoring of a VOIP network is performed using an Ethernet OAM command A block diagram of the network, occurring at a level;
18 is a flow diagram of the processing of an IP level performance monitoring command at a node of a link state protocol controlled Ethernet network in accordance with an embodiment of the present invention.
Link State Protocol A controlled Ethernet network provides equivalent Ethernet bridged connectivity, but accomplishes this by configuring the Network Element Forwarding Information Base (FIB) rather than flooding and learning. Using the link state protocol for control of an Ethernet network, the Ethernet network can be scaled from LAN space to WAN or provider network space by making network communication capacity more efficient with loop-free shortest path forwarding. Rather than using the learned network view at each node using Spanning Tree Protocol (STP) combined with transparent bridging, the bridges forming the mesh network in the link state protocol controlled Ethernet network exchange link state advertisements, Allows a node to have a synchronized network topology view. This is accomplished through the use of a link state routing system. The bridges in the network have a synchronized network topology view, knowledge of the required unicast and multicast connectivity, can calculate the shortest path connectivity between any pair of bridges in the network, The forwarding information base (FIB) of the mobile station can be individually populated. In the case where all nodes compute their roles in the synchronized view and populate their FIBs, the network may determine that the loop-free unicast tree from the peer bridge set to any given bridge and the same peer bridge from any given bridge Both sets will have a suitable loop-free point-to-multipoint (p2mp) multicast tree. As a result, the path between a given pair of bridges is not limited to passing through the root bridge of the spanning tree, so the overall result can take full advantage of the connectivity of the mesh.
Link State Protocol-controlled Ethernet networks typically use symmetric link metrics such that connectivity between any two bridges follows the same path in both directions, and unicast to suit the forwarding between multicast and unicast packets And multicast connectivity.
A shortest path loop (for both unicast and multicast purposes) between (slightly modified) bridge sets to provide transparent LAN services to a C-MAC (Customer MAC) layer or other layer network, - The MAC configuration can be used to establish the free connectivity. This requires the operation of the link state routing protocol within the network in place of the piggybacking of MAC information on the routing system advertisement and the spanning tree protocol for the associated VLAN.
1 is a schematic diagram illustrating an example of a portion of a link state protocol controlled Ethernet network; From the shared network topology, each node uses the shortest path algorithm to compute the optimal shortest path to the other provider backbone bridge (PBB) or node in the network. Applying the shortest path algorithm across the network and performing the corresponding FIB populations on the bridges will provide a unique tree through each mesh from the respective bridge to the member bridges of the network.
MAC addresses (unicast and multicast) associated with bridges are used for global, destination-based forwarding for link state protocol controlled Ethernet networks. This means that these MAC addresses can be simply flooded into the routing system advertisements and instantiated at the local bridge forwarding database (or FIB) as indicated by the routing system at the local convergence of the routing system . In this way, distributed computing of layer 2 connectivity can be applied to an Ethernet bridge without requiring a separate signaling system to associate connectivity with the topology. In its simplest form, if you have calculated that the bridge is on the shortest path between two given bridge nodes, you can simply install the MAC address associated with these bridges in the FIB, where the unicast MAC address is the bridge of interest And the multicast MAC address points from the bridges of interest.
It should be understood that although a single unicast MAC address is described for each bridge, it does not exclude finer granularity, and that a unicast MAC address can be referred to as a line card, a virtual switch instance (VSI), or a UNI port do. This may be desirable to simplify the de-multiplexing of the flows at the destination bridges.
In the network, during an unstable period (a topology change period, a period during which the routing system advertises a topology change to all bridges in the network, a re-convergence to a common new topology view, and an update period of corresponding forwarding information) Loop suppression is required to maintain connectivity (even in degraded form). Instability of a distributed system often means that the entire network view will not be synchronized at least temporarily. In the case where the network element does not have a synchronized network view, a temporary loop may be formed. As described in more detail in the parent application, the PLSB network may use an inverse path forwarding check to minimize the loop. The network element such as the Ethernet bridge compares the segment that the packet arrives with the source MAC address included in the packet with the value configured for the same MAC address as the destination in the forwarding database and checks the packet, Can be performed. If the learned segment for the source MAC address changes a static entry or there is no static entry, the packet is discarded. The RPFC check may optionally be disabled in a particular instance as desired.
The link state protocol controlled Ethernet network may provide a service instance, which requires only connectivity to ports and hence a subset of bridges in the network. An example of an identifier that can be used to identify a packet associated with a particular service instance is the Extended Service ID field (I-SID) defined in IEEE 802.1ah. A bridge that finds itself on the shortest path between two bridges installs a unicast MAC address (s) associated with each bridge and a multicast MAC address for all I-SIDs common to the two bridges. As a result, a given edge bridge will have unicast connectivity for all peer bridges and multicast connectivity specific to each I-SID-identified community of interest. This is a form that is a leaf on a multipoint-to-point (mp2p) unicast tree for each peer and a (S, G) point-to-peer for a set of peer nodes for each community of interest. - the root of a multipoint (p2mp) multicast tree, where S is the address of the source and G is the multicast group address.
In addition, U.S. Patent Application No. 12 / 151,684, filed on May 5, 2008, entitled IP FORWARDING ACROSS A LINK STATE PROTOCOL CONTROLLED ETHERNET NETWORK ), Which is hereby incorporated by reference in its entirety), a link state protocol controlled Ethernet network may support native IP. Thus, when learning an IP address, a node inserts an IP address into its link state advertisement to advertise the arrival probability of an IP address to other nodes on the network. Each node adds its IP address to its link state database. When a packet arrives at the ingress node, the ingress node reads the IP address, determines which node on the link state protocol controlled Ethernet network recognizes its IP address, constructs a MAC header to forward the packet to the correct node do. The DA / VID of the MAC header is the nodal MAC of the node that advertised the IP address. Unicast and multicast IP forwarding can be implemented.
2 is a schematic diagram of a possible implementation of network element 12 configured for use in a link state protocol controlled Ethernet network. Network element 12 includes a routing system module 80 configured to exchange control messages including routing and other information with peers 12 within network 10 with respect to the network topology using a link state routing protocol do. The information received by the routing system 80 may be stored in the link state database 90 or in other manners. As described above, the exchange of information causes the nodes on the network to create a synchronized network topology view, thereby causing the routing system module 80 to calculate the shortest path to another node on the network. The shortest path computed by the routing system 80 is programmed into the FIB 82 which is based on the computed shortest path, multicast tree, traffic engineering path entry, Lt; RTI ID = 0.0 &gt; traffic &lt; / RTI &gt;
The routing system 80 may exchange route updates that include network layer arrival probability information. The network layer address known to the node on the network is stored in the link state database 90 on the network element 12 which allows the ingress node to select the correct egress node on the link state protocol controlled Ethernet network when a network layer packet arrives . The knowledge of the network layer address also makes it possible to implement a multicast forwarding state on the network so that the nodes on the network are able to establish a forwarding state between pairs of nodes interested in the same IP multicast Network-layer multicast.
The network element 12 also processes the incoming frame and performs a lookup at the FIB 82 to determine whether the port on which the frame is received matches the port identified in the FIB 82 for a particular source MAC Such as a reverse path forwarding check (RPFC) module 84, If the input port does not match the exact port identified in the FIB, the RPFC module can drop the message.
If the frame passes the RPFC 84 module, the destination lookup 86 module determines from the FIB 82 the port or ports to which the frame should be forwarded. If the FIB does not have an entry for DA / VID, the frame is discarded.
It should be noted that the above described modules are described for illustrative purposes only and may be implemented by combining or distributing the functions within a module of a node, as will be appreciated by those skilled in the art.
Referring to FIG. 3, a link state control protocol, such as IS-IS, performs a discovery phase to generate bridges 302a through 302h (FIG. 3b) in a loop-free configuration using the Sys-ID of each bridge, aka nodal- A link state protocol controlled Ethernet network 300 is shown. When the ISID, for example ISID 23, is configured, it sends an IS-IS update, and the multicast connectivity creates an EVPN between all nodes that are members of the ISID 23. And sends out a different set of IS-IS updates to generate multicast connectivity for ISID 10. Once these ISIDs are generated, all forwarding is completed through the paths created using the Sys-ID during link state discovery. Also referring to FIG. 4, each service is a leaf of its base topology. [0002] U.S. Patent Application No. 12 / 151,684, filed on May 5, 2008, entitled IP FORWARDING ACROSS A LINK STATE PROTOCOL CONTROLLED ETHERNET NETWORK, The IP subnet 306 may be mapped directly to the Sys-ID, as described in U.S. Pat. [0006] U.S. Patent Application No. 12 / 215,350, filed on June 26, 2008, entitled IMPLEMENTATION OF VPN PROTOCOL CONTROLLED ETHERNET NETWORK, , Which is hereby incorporated by reference in its entirety), the VRF 308 is mapped through the ISID.
The Ethernet OAM defines a set of connectivity defect management protocols for use in an Ethernet network, as currently defined in the IEEE Standard 802.1ag "Connectivity Defect Management" (included herein by reference). These include continuity checking, link tracing, and loopback protocols. The 802.1ag standard has been extended to include performance monitoring metrics and messages. This standard is reflected in ITU-T SG 13, Y.1731 - "Requirements for OAM in an Ethernet network" (incorporated herein by reference). However, the mechanisms described in these standards can not be applied directly to link state protocol Ethernet networks. According to the present invention, the link state protocol Ethernet network includes OAM features for the purposes of fault identification, isolation, troubleshooting and performance monitoring.
The 802.1ag CFM message includes the following items.
Continuity Checks - These are "heartbeat" messages periodically issued by maintenance endpoints. These allow maintenance endpoints to detect loss of service connectivity between them.
Link Trace - These are sent by the maintenance endpoint at the administrator's request to track the path to the destination maintenance endpoint (hop-by-hop). They allow the sending node to discover connectivity data about the route. Link traces are conceptually similar to UDP trace routes.
Loopback - These are sent by the maintenance endpoint at the request of the administrator to verify connectivity to other maintenance endpoints. Loopback indicates whether the destination is reachable and does not allow hop-by-hop discovery on the path. It is conceptually similar to ICMP echo (Ping).
Within any given provider network, the Ethernet CFM relies on a functional model configured as a hierarchical maintenance domain as shown in FIG. Domains are assigned a unique maintenance level (among the eight possible) by the administrator, which is useful for defining hierarchical relationships of domains. When two domains are established, the outer domain must have a higher maintenance level than the inner domain. 5, a customer domain 402 including a provider domain 404 including two operator domains 406 is shown. Maintenance endpoints (squares) are at the edge of the maintenance domain, while maintenance midpoints (circles) are inside the domain. Thus, the intermediate point (as opposed to the loopback or link trace towards the midpoint) forwards the CFM packet, while the endpoint does not forward the CFM packet because it must keep the CFM packet in the domain. The only exception to this is when the endpoint also acts as an intermediate point for a higher level domain, in this case forwarding the CFM packet as long as it is part of the higher level domain.
5 shows an example in which a service provider uses a network having two operators to provide services. The service provider's maintenance level is indicated at 322. The maintenance level for operator A and operator B is indicated at 324. The maintenance levels for the two special cases are the customer level 320 and the physical layer level 326. The customer level allows the customer to test connectivity (using connectivity checks) and isolate issues (using loopbacks and link traces). On the other hand, the physical layer level defines the narrowest possible maintenance domain: single link domain.
According to a first aspect of the present invention, an Ethernet OAM standard is modified to accommodate differences between conventional spanning tree based Ethernet and link state protocol controlled Ethernet. According to a second aspect of the present invention, the new service level OAM feature uses link state protocol controlled Ethernet. According to a third aspect of the present invention, an Ethernet OAM is utilized by an IP service across a link state protocol controlled Ethernet network for performance monitoring and control.
According to the present invention, link state protocol controlled Ethernet can implement a CFM message at the infrastructure level prior to the establishment of the first I-SID. Thus, a CFM message is used by the link layer in FIGS. 3 and 4, and is used at the link OAM level in FIG. In this regard, a diagnostic OAM may be useful for testing connectivity between nodes prior to placing the service on the nodes.
The 802.1ag CFM message format is shown in FIG. Some CFM messages conforming to the 802.1ag standard, i.e., LBM messages, employ unicast destination addresses. It is useful to be able to use these CFM messages for diagnostic purposes to check the topology of the link state controlled Ethernet network. To do so, a proper destination address of the node in the link state topology is needed. Thus, in accordance with the present invention and as shown in FIG. 6, in the case of a CFM message employing a unicast destination address, i.e., an LBM, LBR message, a null MAC address derived from the Sys-ID of the destination node is used 400, 402, 404 in Fig. 7). This node level MAC address is installed in the FIB at link state protocol exchange.
Some CFM messages, such as mLBM and CCM, employ unique broadcast destination addresses. These addresses are incompatible with the link state Ethernet protocol in that RPFCs are broken and loops occur. So, at the infrastructure level, these messages are not used.
Also in accordance with the present invention, the LTM CFM message is addressed at the infrastructure level. According to this standard, the LTM message employs a known group multicast MAC address. However, in the link state controlled Ethernet network, there is no multicast entry in any node FIB until the first I-SID is established. Thus, at this stage, the standard LTM message received by the link state controlled Ethernet network node is dropped. Thus, the present invention provides a variation on a standard implementation. The LTM message according to the present invention employs a unicast destination address for the target destination node (400, 406, 408 of FIG. 7). Also, the adopted destination address is a no-draw MAC address derived from the Sys-ID of the target destination node. Since the link state controlled Ethernet network is preconfigured rather than "flooding and learning ", the path to the destination is known, and therefore the unicast LTM message can follow a preconfigured path to the target node.
Referring now to FIG. 8, using link state protocol controlled Ethernet with OAM provides an opportunity to double check connectivity at the infrastructure level. For a given node or nodes in the link state controlled Ethernet network, the operator may check the link state database itself (420, 422) to see what the link is created by the link state protocol. The operator then executes (424) a link trace from or to the node pairs to determine whether the LTM and LTR messages are valid for the path that the link state protocol originally set, as reflected by the FIB, (426-430). &Lt; / RTI &gt;
The link state protocol controlled Ethernet can also implement the CFM at the service level after the I-SID is established. The Ethernet OAM is designed to operate at the I-SID level and thus the 802.1ag standard and the Y.1733 standard can be utilized and refined to provide service level OAM functionality to the link state protocol controlled Ethernet.
In a typical flooding and reverse path learning Ethernet network, all I-SIDs follow the same multicast distribution path based on a single multicast source address. However, in a link state protocol controlled Ethernet network, each service instance, ISID, is rooted in a multicast distributed path. So, if you want to troubleshoot the service instance path in a link state protocol controlled Ethernet network, then instead of using a unicast LTM or a standards-based multicast LTM that does not fit into the ISID path, it makes sense to use a new alternative. therefore. According to an aspect of the invention, a new OAM link trace message is provided at the service level. This link trace message uses the I-SID multicast address as a DA instead of using the multicast standard Ethernet DA of FIG. 6 (456 in FIG. 9). By using the ISID multicast DA, link traces follow an optimized multicast path based on the node from which the trace is launched, rather than from a typical Ethernet multicast tree.
The service level OAM may be used for discovery purposes to validate the topology of the link state protocol controlled Ethernet network. For example, referring to FIG. 9, an instruction "display ISID tree" may be launched 454 from the node to which the ISID is attached. According to the work option, the mLBM command (wildcarding) may be launched 4512 from the ISID node using the ISID mDA, rather than the CFM mDA of the 802.1ag standard. Alternatively, for each ISID endpoint, a unicast LTM (trace route) may be launched within the ISID (460). According to an alternative option, the previously described mLTM (Wildcard Trace Route) command may be issued (456) to the path of the multicast ISID tree from the ISID node to be traced.
It should be noted that the link state protocol populates all nodes in the network with their network topology view. Thus, for example, the IS-IS database can be queried for all end nodes attached to a given ISID, as shown in steps 500 through 506 of FIG. 10, where the link state database is an IS-IS database. The service level OAM link trace described above can then be executed via the data plane to see if the data plane topology is actually arranged as the control plane should represent.
Discovery can also be used to validate paths in the network. The command "Display ISID path" (462 in FIG. 9) can verify the path between endpoints. For example, an LTM (Trace Route) may be launched 464 from Node A to Node B on ISID 101 to indicate the path on ISID 101 between Node A and Node B. Also, the LTM DA is a unicast DA of the destination node's Sys-ID (Node B), not the standards-based CFM DA.
The link state protocol also populates the mode nodes in the network with their network topology view. Thus, for example, as shown in steps 508-512 of FIG. 10, where the link state database is an IS-IS database, it is possible to determine, from an arbitrary node in the IS-IS database for the I-SID path between node A and node B You can query. Alternatively, it can query from an end node on the I-SID for a path to another end node and query from the end node A, for example, to indicate the path to the end node B. [ The service level OAM link trace described above can then be executed via the data plane to see if the data plane topology is actually arranged as the control plane should represent.
Service OAM can also be used for connectivity verification and fault detection between I-SID endpoints and within I-SID. An OAM message equivalent to the CFM CCM may be issued from the end node attached to the I-SID as a connectivity checking mechanism (514 in FIG. 10). These CCM messages can also be addressed (i. E., Decomposed into Sys-IDs) based on the I-SID mDA, as opposed to CFM-DA. Further, these CCM messages can be issued at all service levels. IP subnet level CCM messages are directly decomposed into Sys-IDs, while IP-VPN, VRF, etc. are decomposed through I-SID.
Automatic generation of MEP / MIP
According to aspects of the present invention, a link state protocol controlled Ethernet network allows automatic generation of MEPs and MIPs.
As part of the Link Trace Protocol Discovery, each node in the link state protocol controlled Ethernet network automatically instantiates the default MD level 802.1ag logic, but this can be done using the translated Sys-ID name as the MAC address. have. 11, at the infrastructure level, each node hashes the Sys-ID to derive (600) the MEP and / or MIP and populate that information with the TLV (602 ). The TLV is transmitted on the network to the link status PDU (LSP) (604). In FIG. 12, it is shown that when a node receives this LSA (610), the LSA associates the received MEP information in the TLV with the received end node. The receiving node adds an entry to its FIB and the LSA creates a MEP / Sys-ID association by associating the MEP with the old MAC of the node that received it. Thus, each node knows what the MIP and MEP points are for all other nodes in the network.
Thus, an operator can execute an infrastructure level OAM command from a perspective of a particular node. For example, as shown in steps 620 through 626 of FIG. 13, the operator selects to perform a continuity check between node A and node B. Thus, from node A, the operator executes the Ethernet OAM LBM, or "ping" command. According to the present invention, node A checks the link state database against the MEP of Node B, which is pre-populated during link state configuration. When this becomes known, an LBM message with the destination address of the Node B is established. The FIB of node A indicates that an LBM message should be sent to the next hop MIP while going to node B (if there is actually a node between node A and node B).
As shown in FIG. 5, different maintenance domains are associated with different MEP and MIP MD levels. Thus, at the service level, different MEPs and MIP sets are specified. Link State Protocol A controlled Ethernet network allows dynamic autoconfiguration of MEPs and MIPs as required at various service levels. At the infrastructure level, the port MEP for monitoring the link is instantiated at the "default" MAID level, as described in the 802.1ag standard, which is MD level 0, and is always -ON. Various service levels can also have a MEP that is always -ON to carry messages such as CCM. This MEP is created with MAID, which is a function of the service level identifier I-SID, and the MD level is suitable for that domain. The MIP can always be generated as -ON during link state protocol discovery, and the MD level is suitable for that domain.
Link State Protocol IP OAM in an Ethernet network
As described above, the pending U.S. Patent Application No. 12 / 151,684 filed on May 5, 2008 entitled IP FORWARDING ACROSS A LINK STATE (IP FORWARDING) PROTOCOL CONTROLLED ETHERNET NETWORK, the entirety of which is hereby incorporated by reference), the IP address may be directly mapped to the MAC address used for forwarding in the link state protocol Ethernet network. When a node in the link state protocol controlled Ethernet network learns an IP address, as described in the application, the IP address is inserted into the link status advertisement to advertise the arrival of that IP address to other nodes on the network something to do. Each node adds this LSP with the advertised IP address to the link state database. When the packet arrives at the ingress node, the ingress node reads the IP address, determines which node on the link state protocol controlled Ethernet network recognizes the IP address, and constructs the MAC header to forward the packet to the correct node . The DA / VID of the MAC header is the nodal MAC of the node that advertised the IP address, for example, it may be the Sys-ID.
Because IP subnets can be mapped appropriately for link state protocol controlled Ethernet networks, improved OAM for link state protocol controlled Ethernet, and automatic generation of MEP and MIP, can be used to support ping and trace route capabilities based on Ethernet OAM OAM functionality for IP can be enabled.
For example, referring to FIG. 14, there is also shown a link state protocol controlled Ethernet network in which MEP and MIP are automatically configured as described above. A node that is a Sys-ID San Jose is shown to have an IP address of 10.20.0.16/24. A node that is a Sys-ID Denver is shown to have an IP address of 10.20.8.128/24. Referring to Fig. 15, at node San Jose, the operator writes 720 the IP command "Ping 10.20.8.128 ". (Or it may be an equivalent IP name disassembled via DNS or some other means of IP-name translation). The node of San Jose receives the LSA in advance from Denver who informed that 10.20.8.128 has been attached to it, so the San Jose database decomposes the destination IP address into Denver's MAC (722). The IP ping instruction is decomposed 724 as an Ethernet OAM LBM instruction with a destination denver. The San Jose node checks the FIB to know the MEP for Denver. The LBM is transmitted to the DA denver, VID MIP (726). Assuming infrastructure continuity between Denver and San Jose, LBR is returned to San Jose.
Similarly, referring to FIG. 16, at node San Jose, the operator writes 740 the IP command "trace route 10.20.8.128 ". (Again, there can be an equivalent IP name resolution). The node of San Jose receives the LSA in advance from Denver who informed that 10.20.8.128 has been attached, so the San Jose database decomposes the destination IP address into Denver's MAC (742). The IP trace route command is decomposed 744 as an Ethernet OAM LTM command with a destination denver. The San Jose node checks the FIB to know the MEP for Denver. The LTM is transmitted to the DA denver, VID MIP (746).
The 802.1ag standard has been extended to include performance monitoring metrics and messages. This standard is reflected in the requirements for OAM in the ITU-T SG 13, Y.1731-Ethernet network (included herein by reference). The following performance parameters are measured by appropriate OAM messages.
1) Frame Loss Rate (FLR) - FLR is defined as a percentage of the number of service frames that have not been delivered divided by the total number of service frames over time T, The difference between the number of service frames transmitted to the UNI and the number of service frames received at the exit UNI. Two types of FLR measurements are possible: dual-ended LM (loss measurement) and single-ended LM. A dual-ended LM is achieved by exchanging a CCM OAM frame that includes an appropriate count of transmitted and received frames. These counts do not include OAM frames at the MEP ME level. The dual-ended LM enables proactive measurement of near-end and far-end FLR at each end of the MEG. Single-ended LMs are achieved by on-demand exchange of LMM and LMR OAM frames. These frames include an appropriate count of the transmitted frame and the received frame. A single-ended LM provides a near-end and a far-end FLR only at the end that initiated the LM request.
2) Frame Delay (FD) - The FD is specified as a round trip delay for the frame, where FD has been transmitted by the source node since receiving the last bit of the loopback frame by the same source node since sending the first bit of the frame Lt; RTI ID = 0.0 &gt; time, &lt; / RTI &gt; where the loopback is performed at the destination node of the frame.
3) Frame delay variation (FDV) - FDV is a measure of the variation in FDs between pairs of service frames, where service frames belong to the same class of service (COS) instance for point-to-point Ethernet connections.
It should also be noted that the IP subnet is in most cases mapped to a link state protocol controlled Ethernet network. Now, automatic generation of MEPs and MIPs and improved OAM and performance monitoring for link-state protocol-controlled Ethernet enable a sophisticated, detailed "SONET-style" OAM for IP over unavailable Ethernet do.
Referring to FIG. 17, one of many applications in which the Ethernet performance OAM is useful for IP applications is shown. The provider 800 and the customer premises 802 are shown. The customer has an IP phone 804 coupled to the provider 800 via the access box 806 via the link state protocol controlled Ethernet network 808. [ Within the provider 800 there may be various bridges 810 that couple the network 808 to the server 812 that provides VOIP services to the access box 806 and hence the IP phone 804. All the devices shown in Fig. 18 are IP devices. IP phones, servers, and bridges together with other bridges and devices not shown constitute a link state protocol controlled Ethernet network. As such, each of these is associated with a Sys-ID. A link state protocol such as IS-IS establishes a unicast loop-free communication path between all elements in the network. [0002] U.S. Patent Application No. 12 / 151,684, filed on May 5, 2008, entitled IP FORWARDING ACROSS A LINK STATE PROTOCOL CONTROLLED ETHERNET NETWORK, The IP phone and the server establish IP communication in accordance with the method described in U.S. Pat. Briefly, an IP phone IP subnet is learned by an IP phone node and inserted into a link state advertisement to advertise the arrival probability of an IP subnet to another node on the link state protocol controlled Ethernet network. Likewise, the IP subnet of the server is learned by the server node and inserted into the link state advertisement to advertise the arrival probability of the IP subnet to other nodes on the link state protocol controlled Ethernet network. When a packet arrives at the ingress node, the ingress node reads the IP address, determines which node on the link state protocol controlled Ethernet network recognizes its IP address, constructs a MAC header to forward the packet to the correct node do. The DA / VID of the MAC header is the nodal MAC of the node that advertised the IP address. In this case, the IP flow from the IP phone to the server (i.e., VOIP) is decomposed into the MAC of the node to which the IP phone is attached. The IP flow from the server to the IP phone is decomposed into the MAC of the node to which the server is attached.
As discussed above with respect to the CFM OAM, the operator may execute IP level commands such as "ping " and" trace route "that may be mapped directly to link state Ethernet commands. Further, according to the present invention, an IP level performance monitoring function is provided based on link state Ethernet OAM commands and feedback.
For example, referring to FIG. 18, it is desirable that the server 812 monitors delay and jitter for a particular VOIP stream associated with the IP phone 804. In accordance with the present invention, this task is enabled by the fact that the VOIP stream is delivered across the link state protocol controlled Ethernet and can also directly use the OAM functions described herein. For example, an operator may launch an 820 command from server node 812 to "monitor delay, jitter for IP phone for next hour." The IP level OAM command is decomposed into a series of Ethernet level OAM commands between the server 812 and the IP phone 804 at the server 812. The OAM level commands used in this example are FD and FDV. First, by checking the FIB, the MAC address for the node to which the IP phone is attached or the phone itself is decomposed (822). The OAM FD and FDV commands are forwarded from the node attached to the server 812 to the node attached to the IP phone 804 along the MIP bridge 810 forwarding path specified in the FIB of the server 812 for the identified time period (826). Thus, performance statistics may be collected for IP flows in a very detailed manner that is not possible for IP flows over an Ethernet network. Thus, if necessary, the VOIP flow can be adjusted based on the resulting feedback from the OAM command (828).
According to the present invention, IP performance monitoring can be implemented in many IP technologies such as IP telephones, IP TV / video, mobile IP, data centers, and the like. Link State Protocol Controlled Ethernet enables IP performance monitoring and control to integrate many different types and levels of IP domains and devices. The ability to use direct Ethernet OAM performance monitoring at the IP level in accordance with the present invention enables IP traffic control levels for voice, data, and video that can be easily applied to specific LSAs.
The present invention may be implemented as one or more computer readable software programs embodied on or in one or more articles of manufacture. The article of manufacture can be, for example, a floppy disk, a hard disk, a hard disk drive, a CD-ROM, a DVD-ROM, a flash memory card, an EEPROM, an EPROM, a PROM, a RAM, have. In general, standard or proprietary, programming or interpretive languages may be used to write the computer readable software program. Examples of such languages include C, C ++, Pascal, JAVA, BASIC, Visual Basic, and Visual C ++. The software program may be stored on or in the article of manufacture as source code, object code, interpreted code, or executable code.
While the present invention has been particularly shown and described with reference to certain preferred embodiments thereof, it should be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the following claims.
A network topology verification method in a link state protocol controlled Ethernet network,
Checking a link state protocol database at a node to identify a control plane topology view of at least a portion of the network, the topology view indicating a connection relationship between the node and other nodes in the network;
Executing one or more Ethernet OAM commands from the node to identify a data plane topology view of the same portion of the network;
Comparing the views of the network to find out whether they match the control plane topology view of the network and the data plane topology view of the network; And
If these views do not match, the step of flagging the error
Wherein checking the link state protocol database comprises tracing all paths through the network from a first node in the link state protocol controlled Ethernet network,
Wherein executing the one or more Ethernet OAM commands comprises: executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service instance, the link trace instruction being a multi- Using an IEEE 802.1ag format, except using a cast destination address. &Lt; Desc / Clms Page number 19 &gt;
Wherein checking the link state protocol database comprises tracing a path through the network from a first node to a second node in the link state protocol controlled Ethernet network,
Wherein executing the one or more Ethernet OAM commands further comprises: executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service path, the link trace instruction comprising an Ethernet MAC node ID Using the IEEE 802.1ag format except for using the unicast destination address of the network topology.
There is provided a computer program for implementing network topology verification in a link state protocol controlled Ethernet network, the computer program comprising:
Logic for checking a link state protocol database at a node to identify a control plane topology view of at least a portion of the network;
Logic for executing one or more Ethernet OAM commands from the node to identify a data plane topology view of the same portion of the network;
Logic for comparing the views of the network to those of the control plane topology view and the data plane topology view of the network; And
If these views do not match, the logic to flag the error
Wherein the logic for checking the link state protocol database comprises logic for tracing all paths through the network from a first node in the link state protocol controlled Ethernet network,
Wherein the logic for executing the one or more Ethernet OAM commands further comprises logic for executing one or more link trace Ethernet OAM link trace instructions from the first node to trace service instances, Using an IEEE 802.1ag format, except for using a multicast destination address of &lt; RTI ID = 0.0 &gt;&lt; / RTI &gt;
Wherein the logic for checking the link state protocol database comprises logic for tracing a path through the network from a first node to a second node in the link state protocol controlled Ethernet network,
Wherein the logic for executing the one or more Ethernet OAM commands comprises logic for executing one or more link trace Ethernet OAM link trace instructions from the first node to trace a service path, Using an IEEE 802.1ag format, except using a unicast destination address of the ID.
KR20107010431A 2007-10-12 2008-10-14 Continuity check management in a link state controlled ethernet network KR101487572B1 (en)
US97943807P true 2007-10-12 2007-10-12
US60/979,438 2007-10-12
PCT/US2008/079825 WO2009049311A1 (en) 2007-10-12 2008-10-14 Continuity check management in a link state controlled ethernet network
KR20100100784A KR20100100784A (en) 2010-09-15
KR101487572B1 true KR101487572B1 (en) 2015-01-29
ID=40549624
KR20107010464A KR20100096086A (en) 2007-10-12 2008-10-13 Ip network and performance monitoring using ethernet oam
KR20107010431A KR101487572B1 (en) 2007-10-12 2008-10-14 Continuity check management in a link state controlled ethernet network
KR20137029416A KR20130132664A (en) 2007-10-12 2008-10-14 Automatic mep provisioning in a link state controlled ethernet network
KR1020147027292A KR20140130523A (en) 2007-10-12 2008-10-14 Continuity check management in a link state controlled ethernet network
KR20147030119A KR20140146143A (en) 2007-10-12 2008-10-14 Automatic mep provisioning in a link state controlled ethernet network
KR20107010469A KR20100105542A (en) 2007-10-12 2008-10-14 Automatic mep provisioning in a link state controlled ethernet network
US (5) US8264970B2 (en)
EP (3) EP2208312A1 (en)
JP (5) JP5306365B2 (en)
KR (6) KR20100096086A (en)
CN (4) CN101897151B (en)
BR (3) BRPI0818252A2 (en)
WO (3) WO2009049292A1 (en)
HUE040657T2 (en) * 2007-08-01 2019-03-28 Ericsson Telefon Ab L M GMPLS based OAM provisioning
US8441941B2 (en) * 2008-10-06 2013-05-14 Cisco Technology, Inc. Automating identification and isolation of loop-free protocol network problems
US8804552B2 (en) * 2009-02-05 2014-08-12 Telefonaktiebolaget L M Ericsson (Publ) Topological location discovery in an ethernet network
US8605603B2 (en) * 2009-03-31 2013-12-10 Cisco Technology, Inc. Route convergence based on ethernet operations, administration, and maintenance protocol
US8879401B2 (en) 2009-07-10 2014-11-04 Telefonaktiebolaget L M Ericsson (Publ) Loss measurement for multicast data delivery
JP5779584B2 (en) * 2009-11-13 2015-09-16 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Provider edge bridge with remote customer service interface
US20120140639A1 (en) * 2010-12-03 2012-06-07 Ip Infusion Inc. Convergence for connectivity fault management
CN102025571B (en) * 2010-12-30 2015-08-12 中兴通讯股份有限公司 The method and apparatus that multipoint link packet loss is measured
CN103609066B (en) * 2011-04-28 2017-04-26 华为技术有限公司 Method and node for querying operation administration maintenance configuration information
CN102571495B (en) * 2012-01-17 2015-01-28 深圳市汉普电子技术开发有限公司 Method and device for checking network topological structure for wire arrangement of printed circuit board
CN102651702A (en) * 2012-05-09 2012-08-29 华为技术有限公司 Ethernet performance measurement method and equipment
CN102868569B (en) * 2012-06-30 2015-12-09 华为技术有限公司 The method for testing performance of Layer3 Virtual Private Network, node and system
CN102752138A (en) * 2012-06-30 2012-10-24 华为技术有限公司 Asynchronous configuration management method and network device
US8687501B1 (en) 2012-07-25 2014-04-01 Overture Networks, Inc. Automatic detection and configuration of Ethernet OAM protocols
CN102801567B (en) * 2012-08-28 2015-07-08 北京傲天动联技术股份有限公司 Method for automatically discovering hierarchical network topology and method for establishing hierarchical network topology
EP2901629B1 (en) * 2012-09-27 2018-02-21 Hewlett-Packard Enterprise Development LP Transmit specific traffic along blocked link
CN103078791B (en) * 2013-01-31 2016-08-10 华为技术有限公司 OAM message processing method, equipment and system
CN105308904B (en) 2014-04-04 2019-05-21 华为技术有限公司 A kind of OAM message processing method, the network equipment and network system
CN104270280B (en) * 2014-09-02 2017-11-07 烽火通信科技股份有限公司 LSP ping and tracert system and method is realized on the router
CN105656705A (en) * 2014-11-12 2016-06-08 中兴通讯股份有限公司 Method and device for detecting multicast function of access equipment
CN105790996A (en) * 2014-12-26 2016-07-20 北京华为朗新科技有限公司 Distributed gateway backup processing method and network equipment
US9596167B1 (en) 2015-04-24 2017-03-14 Juniper Networks, Inc. Internet protocol virtual private network service performance monitoring
CN108206746A (en) * 2016-12-16 2018-06-26 华为技术有限公司 A kind of network transmission control method and relevant device
US10203998B2 (en) * 2017-02-22 2019-02-12 Accenture Global Solutions Limited Automatic analysis of a set of systems used to implement a process
JP3036526B2 (en) * 1998-09-09 2000-04-24 日本電気株式会社 Atm test apparatus and a recording medium recording a atm testing method and a control program used for the same
AU2003275183A1 (en) * 2002-09-20 2004-04-08 Nortel Networks Limited System and method for managing an optical networking service
ES2279078T3 (en) * 2003-06-24 2007-08-16 Alcatel Lucent Network access to digital subscriber line with improved control of authentication, authorization, accounting and configuration for multiple emission services.
JP3725146B2 (en) * 2004-02-24 2005-12-07 株式会社エヌ・ティ・ティ・ドコモ Communication network management apparatus and communication network communication confirmation test method
JP2006174156A (en) 2004-12-16 2006-06-29 Nippon Telegr & Teleph Corp <Ntt> Network congestion scale determining method and system
GB2421671A (en) * 2004-12-22 2006-06-28 Marconi Comm Gmbh A node selects a source of timing information using network topology and the timing status of network nodes
CN100403689C (en) 2005-05-16 2008-07-16 华为技术有限公司 Method for detecting Ethernet user line state
JP4546351B2 (en) * 2005-07-29 2010-09-15 富士通株式会社 Multicast trace route system in IP multicast network
KR101406922B1 (en) 2005-10-05 2014-06-20 노오텔 네트웍스 리미티드 Provider Link State Bridging
US20110174307A1 (en) 2006-01-04 2011-07-21 Lessi Stephane Device for Supplying Oxygen to the Occupants of an Aircraft and Pressure Regulator for Such a Device
US8331266B2 (en) 2006-06-14 2012-12-11 Nokia Siemens Networks Oy LAN topology detection and assignment of addresses
CN1866879A (en) 2006-06-21 2006-11-22 烽火通信科技股份有限公司 Method for realizing ADSL CPE tele-management by SNMP
US7622089B1 (en) * 2006-07-19 2009-11-24 Uop Llc Conically shaped screenless internals for radial flow reactors
CN100450101C (en) * 2006-08-30 2009-01-07 华为数字技术有限公司 Conversion control method and system of OAM message
CN100550785C (en) * 2006-08-30 2009-10-14 华为技术有限公司 Ethernet device link failure detection method and its system
US7990855B2 (en) * 2008-07-11 2011-08-02 Alcatel-Lucent Usa Inc. Method and system for joint reverse link access and traffic channel radio frequency overload control
2008-10-12 US US12/249,946 patent/US8264970B2/en not_active Expired - Fee Related
2008-10-12 US US12/249,941 patent/US7898965B2/en not_active Expired - Fee Related
2008-10-12 US US12/249,944 patent/US7996559B2/en not_active Expired - Fee Related
2008-10-13 KR KR20107010464A patent/KR20100096086A/en active IP Right Grant
2008-10-13 EP EP20080837640 patent/EP2208312A1/en not_active Withdrawn
2008-10-13 BR BRPI0818252 patent/BRPI0818252A2/en not_active IP Right Cessation
2008-10-13 WO PCT/US2008/079732 patent/WO2009049292A1/en active Application Filing
2008-10-13 JP JP2010529140A patent/JP5306365B2/en not_active Expired - Fee Related
2008-10-13 CN CN 200880120444 patent/CN101897151B/en not_active IP Right Cessation
2008-10-14 KR KR20107010431A patent/KR101487572B1/en not_active IP Right Cessation
2008-10-14 CN CN 200880120296 patent/CN101904184B/en not_active IP Right Cessation
2008-10-14 CN CN201310627460.2A patent/CN103607326A/en not_active Application Discontinuation
2008-10-14 BR BRPI0818254 patent/BRPI0818254A2/en not_active IP Right Cessation
2008-10-14 EP EP20080838426 patent/EP2210374A1/en not_active Withdrawn
2008-10-14 WO PCT/US2008/079825 patent/WO2009049311A1/en active Application Filing
2008-10-14 KR KR20137029416A patent/KR20130132664A/en active IP Right Grant
2008-10-14 BR BRPI0818246 patent/BRPI0818246A2/en not_active IP Right Cessation
2008-10-14 KR KR1020147027292A patent/KR20140130523A/en not_active Application Discontinuation
2008-10-14 KR KR20147030119A patent/KR20140146143A/en not_active Application Discontinuation
2008-10-14 WO PCT/US2008/079803 patent/WO2009049307A1/en active Application Filing
2008-10-14 JP JP2010529147A patent/JP5366959B2/en not_active Expired - Fee Related
2008-10-14 KR KR20107010469A patent/KR20100105542A/en active IP Right Grant
2008-10-14 CN CN 200880120443 patent/CN101904134A/en not_active Application Discontinuation
2008-10-14 EP EP20080836969 patent/EP2206367A1/en not_active Withdrawn
2008-10-14 JP JP2010529148A patent/JP5325887B2/en not_active Expired - Fee Related
2011-06-30 US US13/173,807 patent/US8918538B2/en not_active Expired - Fee Related
2012-07-29 US US13/561,040 patent/US9059918B2/en not_active Expired - Fee Related
2013-04-16 JP JP2013085376A patent/JP2013179628A/en active Pending
2014-12-05 JP JP2014246383A patent/JP2015080248A/en active Pending
US8264970B2 (en) 2012-09-11
JP2011501537A (en) 2011-01-06
KR20140146143A (en) 2014-12-24
KR20130132664A (en) 2013-12-04
JP2011501538A (en) 2011-01-06
KR20100100784A (en) 2010-09-15
US20090232006A1 (en) 2009-09-17
JP2015080248A (en) 2015-04-23
CN101897151A (en) 2010-11-24
JP2013179628A (en) 2013-09-09
EP2210374A1 (en) 2010-07-28
US7996559B2 (en) 2011-08-09
US7898965B2 (en) 2011-03-01
BRPI0818252A2 (en) 2015-04-07
CN101904184B (en) 2013-06-12
US20110255417A1 (en) 2011-10-20
WO2009049307A1 (en) 2009-04-16
BRPI0818254A2 (en) 2015-04-14
WO2009049292A1 (en) 2009-04-16
EP2208312A1 (en) 2010-07-21
BRPI0818246A2 (en) 2015-04-07
KR20100105542A (en) 2010-09-29
US9059918B2 (en) 2015-06-16
US8918538B2 (en) 2014-12-23
US20120287795A1 (en) 2012-11-15
CN101904134A (en) 2010-12-01
US20090232005A1 (en) 2009-09-17
EP2206367A1 (en) 2010-07-14
CN101904184A (en) 2010-12-01
KR20140130523A (en) 2014-11-10
US20090234969A1 (en) 2009-09-17
JP5306365B2 (en) 2013-10-02
JP5325887B2 (en) 2013-10-23
KR20100096086A (en) 2010-09-01
CN101897151B (en) 2013-06-26
JP5366959B2 (en) 2013-12-11
WO2009049311A1 (en) 2009-04-16
CN103607326A (en) 2014-02-26
JP2011501539A (en) 2011-01-06
EP2501082B1 (en) 2017-07-05 Packet loss measurement at service endpoints of a virtual private lan service
2014-09-26 A107 Divisional application of patent