RU2321867C2 - Method for exchanging oam echo-messages for checking network expansion route, based on a service - Google Patents

Abstract

FIELD: method for exchanging OAM echo-messages for checking network expansion route, based on a service.

SUBSTANCE: in accordance to the method, expansion routes, based on a service, or transport tunnels, include services, projected onto a route or assigned to a route which is associated with a transport tunnel. Exchange in echo-messages ensures OAM capabilities for monitoring related to working status of expansion route, based on service, including detection of configuration, capacity for connection and other characteristics of route of associated services which transmit data. OAM functions, represented by exchange of echo-messages make the OAM functions possible independently from amount of services in base network, a route or a set of routes.

EFFECT: simplified operation, management and maintenance of services used for transmission of data through a network.

3 cl, 9 dwg

Description

CROSS REFERENCES TO RELATED PATENT APPLICATIONS

This application claims the priority of US patent application No. 60/466248, entitled "Echo messaging to Verify Service-based Network Distribution Paths", filed April 28, 2003, which is incorporated herein by reference in its entirety.

This application is linked to pending US Patent Application No. 10/833489 (Patent Attorney Case Number 137797), entitled "Using Network Transport Tunnels To Provide Service-Based Data Transport", filed in conjunction with this application, and claims the priority of provisional US patent application No. 60/466340, entitled "Using Network Transport Tunnels To Provide Service-Based Distribution Path", filed April 28, 2003, which is incorporated into this description by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates generally to computer networks and network protocols. In particular, the OAM exchange is disclosed (Operation, Management, Maintenance (a group of network management functions that provide network error indication, performance information, diagnostic functions)) by echo messages to check the network distribution route based on the service.

BACKGROUND OF THE INVENTION

Transport tunnels are used in communication systems, networks, and network equipment (e.g., routers, switches, hubs, and the like) to route data between endpoints, for example, between provider edge network routers (PE routers) at the provider's network edge. In some cases, transport tunnels can be used to link packets over a network that does not support the specific packet protocol used. For example, a transport tunnel can be used to transmit non-IP packets over an IP network (network based on the Internet protocol), multicast packets over a unidirectional network, and so on.

Services (eg, leased lines, virtual leased lines (VLLs), and the like) can be associated with a transport tunnel, and often many services can be associated with a single transport tunnel. However, when using multiple services, effective service management is also difficult to implement. This limits the ability of networks to implement and operate services over core networks, and leads to significant time and expense in managing transport tunnels and the services associated with them. Moreover, in addition to transmitting data packets, implementing capabilities for testing, monitoring, and managing transport tunnels can be difficult when a large number of services are used.

Existing protocols and standards make it possible to verify the configuration and connectivity of a transport tunnel, such as a label-switched path (LSP) (for example, using LSP Ping). However, existing tools do not adequately solve the problem of checking the configuration of the service and the ability to connect to the service.

Thus, a solution is needed that simplifies the operation, management and maintenance of services used to transmit data over the network.

LIST OF DRAWINGS FIGURES

Various implementations of the invention are disclosed in the following detailed description and accompanying drawings.

Figure 1 is an illustrative system for linking services to label-switched routes;

2A is an illustrative system for using transport tunnels associated with service-based distribution routes;

2B is an illustrative service-based propagation route, including associated transport tunnels;

3 is an illustrative system having unidirectional transport tunnels connecting endpoints over a network.

4 is an illustrative format for OAM messages;

5A is an illustration of a process for determining an existing service, in accordance with an embodiment;

5B is an illustration of a further process for checking an echo reply message, in accordance with an embodiment;

6 is an illustration of a process for an OAM echo message to verify a service-based propagation route in accordance with an embodiment; and

FIG. 7 is an illustration of an OAM echo messaging process for verifying a service on a service-based distribution route in accordance with an embodiment. FIG.

DETAILED DESCRIPTION

The invention can be implemented in a variety of ways, including a process, device, system, composition, computer-readable medium, such as a computer-readable storage medium or computer network, in which program instructions are sent via optical or electronic communication lines. In this description, these implementations, or any other form that this invention may take, may be called techniques. In general, the order of steps in the disclosed processes may be changed within the scope of the present invention.

A detailed description of one or more embodiments of the invention is presented below with the accompanying drawings, which illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the following claims, and the invention encompasses numerous alternatives, modifications, and equivalents.

Numerous specific details are explained in the following description in order to provide a thorough understanding of the invention. These details are provided by way of example, and the invention may be practiced in accordance with the claims without some or all of these specific details. For simplicity, technical materials that are known in the technical fields associated with the invention are not described in detail, so as not to obscure the invention unnecessarily.

Interworking and transmitting data over one or more networks may require multiple protocols or techniques for transmitting packets between endpoints, such as internetwork gateway routers, capable of interworking. Endpoints, such as provider network edge routers (PE routers), service edge routers (ESR), or label edge routers (LERs) can use a transport tunnel, such as a service-based distribution route (SDP), to transport data to client side routers (CE) downstream and to the final destination of information (for example, the addresses of the medium access control protocol (MAC addresses)). A service-based distribution route may also be a service distribution point and one or more associated transport tunnels. SDP routes can be established using various protocols, such as the Multiprotocol Label Routing (MPLS) service, MPLS-Traffic Engineering (MPLS-TE), IP or other types of general routing encapsulation protocols (GRE protocols), which affect communication at levels 2 and 3. SDP routes can be implemented as transport tunnels (for example, unidirectional, bidirectional, omnidirectional) between endpoints to provide a transport tunnel for transmitting a service packet. However, in addition to transport capabilities, OAM functions may be supported in SDP routes. In the case of MPLS, label-switched routes (LSPs) can be associated (as separate routes or as sub-routes) with SDP routes, which in turn can have a service or a set of services displayed on them or linked to them. OAM functions are triggered using SDP routes, using information generated from echo messaging, a system for exchanging OAM messages and collecting information / data. Regardless of the underlying protocol used, the SDP route enables advanced management, monitoring, service configuration, and OAM capabilities.

A transport tunnel (e.g., an SDP route, a unidirectional transport tunnel, and so on) may have one or more routes associated with it (e.g., a plurality of LSPs). An SDP route may include unidirectional transport tunnels or other types of tunnels for transmitting data packets from multiple services. The use of LSP routes, such as those used in MPLS, can be implemented as separate routes within a specific SDP that routes data packets between destinations at the near and far ends (for example, ESR). As soon as a route is associated with a transport tunnel, the service is mapped to the corresponding route and transport tunnel. After the display, a check can be made regarding the operational status of the service, SDP, route, and so on. Checking for an existing service and SDP route can determine the configuration, connectivity, end-to-end operational status of SDP, idle SDP, transmission and acknowledgment times (RTT), payload characteristics or other information about the service or SDP, or other OAM capabilities.

OAM capabilities can be implemented in SDP using OAM messaging. An example of the type of such exchange is the exchange of OAM echo messages. In general, echo OAM can be used to verify that the specified SDP or service identifier (Service-ID) is operational and forms a connection between ESR routers. The echo message OAM formats include an SDP response request (echo request) and an SDP response request (echo response), an echo request and a service echo reply, which may include various header fields to identify the type of task to perform which specific message is intended.

Figure 1 illustrates a system for linking services directly to individual label-switched routes. Services 102-106 send data to the provider's edge router A (PE router) through the LSP A 112 using cross-flow switches (cross-switches) (CCs) 108, 116, and 120, respectively. Services 102-106 send PE data to router B via LSP B 114 using cross-switches (CC) 110, 118, and 122, respectively. Each service 102-106 is individually configured with an independent cross-switch for each LSP. More or fewer cross-switches and services may be implemented, but when multiple services are used, management, monitoring, and control can become significantly more difficult. For example, switching to LSP 112 will require that each of the cross-switches 108, 116, and 120 be reconfigured to reflect this switching. In the simplified example shown in FIG. 1, only three services (and their cross-switches associated with them) need to be reconfigured. However, in a typical commercial implementation, there are thousands of services and tens or more LSPs. In addition, personnel preparing services 102-106 must know certain information about LSPs 112 and 114 in order to be able to associate services directly with LSP routes by correctly configuring cross routers, which requires personnel configuring services , had knowledge of transport routes (LSP), which in other cases he does not need to have, thereby potentially increasing training, hiring, salaries and other costs.

2A is an illustration of a system 200 in which transport tunnels associated with service-based distribution routes (SDPs) are used to provide service-based transmission of network traffic. Services 1-3, designated 202-206 in FIG. 2A, are bound by the SDP display module 208 to one or more SDPs 210-216. Although the SDP display module 208 is shown as a single unit in FIG. 2A, in some implementations it can be implemented as a set of separate cross-switches linking each service to one or more of the SDP 210-216. SDPs 210-216 may be implemented as having one or more transport tunnels (e.g., LSPs) associated with each SDP. Transport tunnels can be static or dynamic. In one implementation, each SDP contains a distribution point for one target (outgoing) PE router. Each SDP can have many services associated with it or displayed on it by the SDP display module 208. In one implementation, an inbound PE router may have more than one SDP associated with the same target (outbound) PE, but each service can be mapped or mapped to only one SDP for each destination for which data can be sent. configured service. LSPs are one example of a type of transport tunnel that can be associated with SDPs for transmitting service packets over an MPLS core network. With other types of core networks or networks that can use other basic routing protocols, other types of routes can be used. Regardless of the underlying network protocol, each SDP 210-216 can be considered as a distribution point having one or more associated transport tunnels that connect the near end point to the far end point / destination to which one or more services can be mapped to in order to enable the sending of service packages (or service data in any other form) by the services to the destination associated with the SDP. By associating services 202-206 with SDP routes, instead of associating services directly with transport tunnels (e.g., LSPs), as shown in FIG. 1, services 202-206 can be configured independently of transport tunnels, and vice versa, thereby simplifying preparation to work and / or reconfiguration of each of them. For example, if the LSP in SDP 1 (210) were added, deleted, or changed, the LSP information would only need to be updated once in the SDP. Services 202-206 that are located in system 200 and are tied by the SDP SDP mapping module 208 to the SDP, but not tied directly to the transport tunnels associated with the SDP, will not require any changes. Similarly, services can be added, removed, or changed without requiring that multiple cross-switches to multiple LSPs (or other transport routes) change.

In one implementation, SDP has several attributes to provide service-based data transfer capabilities. Examples of such attributes include the address (e.g., IP address) for the destination at the far end (e.g., PE or other outgoing equipment or node), which is the endpoint to which network traffic associated with the service can be sent for further delivery to the client destination associated with the service, the type of encapsulation used to transfer data to the destination (for example, GRE, MPLS, L2TP, and so on), the route used to reach the destination at the far end (where for example, MPLS), and the maximum transmission unit size (MTU) for the route. SDP provides management capabilities using these attributes, which determine how service packages (that is, packets sent to implement a particular service, such as virtual leased lines (VLLs) or other types of services provided by a manufacturer or service provider, and so on ) are transmitted and processed based on end-to-end passage through the network. SDP can be used to transfer packets associated with a single service or with multiple services. By grouping multiple LSPs or routes into a single transport tunnel (SDP), the load associated with service packets can be shared between the LSP routes that make up the SDP. Thus, packets can be distributed over several routes for routing to the final destination of the service, instead of sending packets for a specific service along a single route. A protocol can also be used to dynamically monitor the end-to-end operational state of the SDP, providing the ability to determine if the operating state of the SDP has changed, and if so, which services can be affected. As an example, a “keep alive” protocol can be implemented that provides certain header values or information that, when demultiplexed, can be used for operation, management, and maintenance (OAM) functions.

2B is an illustrative service-based propagation route, including associated transport tunnels. SDP 230 is shown to have several LSP 232-240 (assuming that MPLS is used) associated with it. In other examples where MPLS may not be used, transport tunnels other than LSPs may be used. For purposes of illustration, where MPLS or MPLS-TE are used, the LSP 232-240 transmit service packets between the (inbound) near end router and one or more (outbound) far end routers associated with the SDP. 2A and 2B, SDPs are depicted graphically as tunnels containing one or more component transport tunnels, such as LSPs, in order to bring the concept that SDPs provide a path for transmitting data through the transport tunnels associated with them to their destination, associated with SDP. It should be understood that SDPs are not actually transport mechanisms that are separate from or organized as layers on top of the transport tunnels associated with them, but rather serve as a distribution point configured to transmit data packets associated with services associated with SDPs, to the destination associated with the SDP via a transport tunnel (e.g., LSP) associated with the SDP. The installation and configuration of the SDP will be described in more detail below in connection with FIGS. 3 to 7.

3 is an illustrative system 300 having unidirectional transport tunnels connecting endpoints over a network. This illustration is a more detailed example of a system in which SDPs can be used to provide service-based data transmission over a network or series of networks. Edge Services Routers 302 and 304 (ESRs) are connected through a network 306. In this example, a network 306 is illustrated as being an IP / MPLS core network. In other embodiments, other types of core network may be used. CE 308-310 send packets received from ESR 302 and 304, respectively, to the client's final destinations to which they are addressed, for example, at the MAC address within their respective client networks. CEs 308 and 310 also receive packets from associated client nodes that are to be transmitted using VLL service 123, and deliver such packets to ESRs 302 and 304, respectively, for transmission. Unidirectional transport tunnels 312 and 314 provide a transport mechanism for transmitting service packets and are associated with the SDPs shown in this example. In one embodiment, the transport tunnel 312 contains the LSP associated with the SDP 324, and the transport tunnel 314 contains the LSP associated with the SDP 326. Here, a service, such as a VLL, can be implemented using bidirectional service access points 316-318. In other implementations, other types of services may be provided, such as VPLS. Service packets are exchanged between service access points 316-318, and these packets are transmitted through unidirectional transport tunnels 312 and 314. In this example, virtual channel (VC) tags 320 and 322 are applied to service packets originating from access points 316-318 service accordingly. SDP 324-326 forwards service packets with VC tags 320-322 attached through unidirectional transport tunnels 312 and 314 to ESR routers 302-304. After receiving service packets with VC tags attached in front, demultiplexers 328 and 330 identify the service packets as intended for service access points 316 and 318 based on VC tags 320-322, and route them accordingly.

In the example shown in FIG. 3, a client packet associated with a VLL service 123 that is sent by a source associated with CE 308 to a destination associated with CE 310, for example, CE 308 will be sent to ESR 302. ESR 302 will receive the packet and associates the packet with VLL service 123 (for example, based on the port on which the packet was received, the encapsulation used, tags, or other identifying information included in the packet, and the like). The service access point 316 will redirect the SDP packet 324 (either directly according to the shown embodiment, or through the SDP display module, not shown in FIG. 3, but described above in connection with FIG. 2A, for example, in an embodiment in which a plurality of services use the same SDP) to transmit to the outgoing ESR 304. SDP 324 encapsulates the packet for transmission of the ESR 304 through the unidirectional transport tunnel 312, including the option of attaching a VC label 320, which identifies the packet as a packet associated with service 123. In embodiment p An analysis in which the SDP 324 contains two or more transport tunnels to the ESR 304, the SDP 324 selects the tunnel to be used to transmit the packet to the ESR 304. For example, in an embodiment in which the SDP 324 contains two or more LSPs, the SDP 324 may be configured to associate the service with a particular LSP, for example, a VLL service, such as a VLL service 123, so that all traffic for the service is sent through the same LSP. For other types of services (for example, VPLS or VPRN), the SDP can map packets to the LSP for transmission by associating the packet with a “transform” (that is, an appropriate set of packets are exchanged between two endpoints) and select the LSP associated with this transform (for example , to prevent delivery of packets in the wrong order, as it would happen if different packets associated with the conversion were transmitted on different routes). In some implementations in which VPLS, VPRN, or a similar service is provided, the destination MAC address may be used to identify the LSP to be used to transmit the packet. When a packet arrives at ESR 304, demultiplexer 330 identifies the packet as a packet associated with service 123, for example, based on the presence of VC tags 320, and delivers the original packet (payload) to service access point 318 for processing. The service access point 318 then delivers the packet to CE 310.

4 is an illustrative OAM message format. In this embodiment, the OAM message 400 may comprise two sections, a general header section 402 and a specific message section 404. The general header section 402 includes fields that may be populated by the creator or responder of the echo message. Examples of fields that may be included in the general header section 402 include fields for identifying the version of the OAM messaging system used, message type, message length, message identifier, creator identification, responder identification, SDP used by the creator, identifier SDP used by the respondent and / or associated with the service by the respondent, and an optional checksum. Other fields may be used in this or other implementations and are not limited to the above examples.

In one embodiment, the version field of the OAM messaging system determines the version of the OAM messaging system used. This field determines whether the endpoints of a particular service or SDP use the same or the correct version of the OAM messaging system. If the versions are different, then the echo message is discarded.

In one embodiment, the message length field identifies the total length of the message, including the general header section 402 and the message-specific section 404. The message type field identifies the OAM messages by type. In one embodiment, the following types are defined: SDP ping (sent by the near end SDP or incoming SDP to the far end, for example, to verify the configuration and / or SDP connectivity); SDP ping (to respond to an SDP ping); service ping (sent by the near end ESR or incoming ESR, for example, to verify the configuration of the service at the near or far end); and an echo reply of the service (for responding to an echo request of the service). In this example, messages of types other than the above are discarded. However, in other implementations, other types of messages may be used. A message identifier is a unique identifier (for example, a sequence of digits) assigned by the creator of a message. Exemplary rules for assigning a message identifier are described in provisional patent application US No. 60/466340, filed April 28, 2003.

The creator identifier included in the creator identifier field of the general header section 402 may be used to authenticate (authenticate) the received response message. As an example, the responder to the echo request message does not change the creator field, but fills in the echo reply message, which includes the identifier of the request creator in the general header. The transponder may use the creator identifier to determine the source of the ping, as the tunnel / SDP information may not be suitable for this purpose. When a response needs to be sent via SDP to the creator of the request, the recipient of the echo request can use the creator identifier field to search for a suitable SDP that will be used as the response route. If the response message is encapsulated generically in IP / GRE, as opposed to being sent via SDP, as will be described below with reference to FIG. 5, the creator identifier can be used to determine the destination IP address for the creator.

The responder identifier field of the common header 402 is a bit field populated, in one embodiment, by the creator of the echo request and verified by the receiver of the echo request. In one implementation, the IP address of the responder is used as the identifier of the responder. In such an embodiment, if the IP address in the responder ID field is not the same IP address as the service IP address on the receiving far end ESR, then the responder ID field in the echo reply message sent by the received ESR in response to the echo message request is changed to the correct IP address.

The format of the section 404 specific to a particular message depends on the type of message being sent. In one embodiment, if the OAM message 400 is an SDP ping message or an SDP ping message, the message-specific section 404 contains a set of SDP echo maker flags used by the echo maker (or request creator, response to which is the answer, in the case of an echo reply) to provide information about the request message and SDP configuration on the side of the creator, and a set of SDP echo responder flags used by the recipient of the request message to provide in the response message and the recipient of the SDP echo reply message information of the receiver and the SDP configuration that the receiver associated with the creator. Examples of SDP echo creator flags used in one embodiment include flags to indicate whether the various fields of the general header 402 contain valid values, flags to inform the receiver of the request about the operational and / or administrative status of the SDP creator, identifiable in common header, a flag indicating whether the request was sent using the SDP creator identified in the common header (or, instead, whether generalized IP / GRE encapsulation was used, for example), flags for signifying the working and / or administrative state creation equipment associated with the maker identifier included in the header, and a flag, which informs the recipient of the request as to whether the recipient to reply to the request via the SDP recipient identified in the header. Examples of SDP echo message responder flags used in one embodiment include flags used to inform the creator of the validity or invalidity of the header values included by the creator in the request, flags to inform the requestor of the operational and / or administrative status of the SDP responder identified in the common header, a flag indicating whether the request was sent using the SDP responder identified in the common header (or, instead, whether general encapsulation of IP / GRE, for example), flags to indicate the operational and / or administrative status of the responder equipment associated with the responder identifier included in the header, and a flag informing the requestor that the responder identifier included in the request was incorrect or has been changed, and that the new responder identifier included in the response should now be used. Other flags of the creator and / or responder, and / or fields can be used similarly to those described above to verify the configuration and connectivity of outgoing and response SDPs.

In the case of an OAM service ping message or OAM service ping message, in one implementation, the section 404 specific to a particular message may contain fields for providing and / or checking information related to the service being checked, and / or one or more flags used to signal information related to the echo request message or the response of the service and / or service to which it relates. For example, a section 404 specific to a particular message may contain fields for providing a service identifier associated with the service, an identifier for the corresponding virtual channel labels associated with the service by the creator and the responder, respectively, as well as a set of flags of the creator of the service echo message and a set of flags of the responder to echo message service. The flags of the creator of the service echo message can be used to signal information such as whether certain header fields (e.g., creator SDP identifier or creator identifier) contain valid data, operational and / or administrative status of the creator SDP identified in the header, whether used the creator SDP identified in the header to send a request whether the recipient should respond using the SDP of the recipient identified in the header (if possible), is the ID valid the creator’s service identifier included in the corresponding field of the section 404 specific to the particular message and whether the working and / or administrative status of the associated service corresponds to a rise or fall on the creator’s side and whether the service is tied to the creator’s SDP identified in the header. Flags of a service echo message responder can be used to provide relevant information regarding the configuration and status of the service on the responder side and the validity of the data in the general header 402 and / or section 404 specific to the particular message. Additional flag sets may be included to provide information on the validity and operational status of the incoming and outgoing VC tags associated with the service at each end, as well as information regarding how the VC tags were transmitted or provided.

5A illustrates a process for determining an existing service in accordance with an embodiment. The definition of an existing service or SDP is a common example of an OAM function that can be performed. In this embodiment, the echo messaging for OAM purposes, as described above, can be used to implement the definition of an existing service. An echo request message is sent to the far end ESR to determine the availability and / or configuration of the service or SDP, operational status, connectivity, and other information (e.g., MTU, payload, and so on) (504). A determination is made as to whether or not an echo reply message has been received (506). If an echo reply message has been received, then the message is checked for the presence of far-end ESR configuration information, service ID, and the like (508). If an echo reply message has not been received, an error message is sent to the administrator (510), and the service or SDP remains in an idle state (512). The above description may be used to describe the use of echo messaging for service or SDP definitions, and, in other implementations, may be used for other purposes.

5B illustrates an additional process for checking an echo reply message, in accordance with an embodiment. In this example, an echo reply message (520) is received. Upon receipt, the echo reply message is checked to determine service or SDP information with a destination at the far end (e.g., ESR) (522). After checking, information is received from the echo reply message from which it can be determined whether there is an incompatibility between the far end ESR and the near end ESR (524).

If an incompatibility between the far end ESR or SDP and the near end ESR or SDP is not found, then the service or SDP is brought into operation (526). If an incompatibility between the far-end ESR or SDP and the near-end ESR or SDP is found, based on the information included in the echo reply message, an error message is sent to the network / system administrator (528) and the service or SDP remains inoperative (530) .

6 illustrates a process for an OAM echo message to verify a service-based propagation route in accordance with an embodiment. In one embodiment, the process of FIG. 6 is a SDP-specific implementation of all or part of the more general process shown in FIGS. 5A and 5B. Here, OAM SDP echoes are sent and received between the nearest endpoint (i.e., the originator) and the far endpoint (i.e., the responder). OAM SDP echo messages may include an SDP echo request OAM message and an SDP echo OAM message.

In this example, an SDP echo request OAM message is generated (602). During the generation process, the SDP echo request OAM message can have various bit fields, header values, VC tags and other control words used to identify specific OAM functions or information requests (for example, SDP connectivity, RTT SDP testing, SDP-ID testing , working SDP messaging). After generation, the OAM SDP ping message is sent to the far endpoint (e.g., ESR) (604). At the far endpoint, an OAM SDP ping message is received (606). After receiving the OAM, the SDP ping message is processed in accordance with the information included in the message format (608). In this example, processing can be performed to determine and execute the requested OAM functions, or to generate and send an OAM SDP echo reply message from the responder back to the creator who generated the OAM SDP echo request message.

7 illustrates a process for exchanging OAM echo messages to verify a service mapped to a service based distribution point in accordance with an embodiment. In this example, an OAM service echo request message is generated by the creator (702). After the OAM generation of the service ping message is generated, it is sent to the responder or the destination of the service at the far end (e.g., ESR) (704). At the far end of the service destination, the OAM service echo request message is received and processed. For example, the recipient can check the data of the responder included in the request, and can collect and / or check information related to the configuration of the service on the side of the responder. The responder generates an OAM service echo reply message and sends it back to the creator. An OAM echo reply message is received (706). Upon receipt of an OAM, an echo reply message is processed to determine if the service is configured correctly (708). OAM echo messages can be used to determine information related to various characteristics of the service, including whether the service exists at the far end, and if so, what is the working and / or administrative status of the service at the far end, the ability to connect to the service through a local SDP (that is, can the local ESR send the service packets to the far end successfully), the ability to connect to the service via the remote SDP (that is, can the far end ESR send the service packets back to the creator), and are the corresponding VCs bound tags associated with the service creator and responder to the correct customer / service. In other examples, OAM functions beyond those discussed above may also be used in OAM echoing services, such as checking that a change in how the service has been initialized has been implemented and distributed appropriately.

Although the above embodiments have been described in detail for purposes of clarity, the invention is not limited to the details presented. There are many alternative ways of implementing the present invention. The disclosed embodiments are illustrative and non-limiting.

Claims (30)

1. A method of checking a service-based distribution route comprising a service distribution point and a transport tunnel associated with a service distribution point, the method including the steps of generating a request for route information; send this request to the destination at the far end associated with the service distribution point; and receive a response to the request, and this answer includes the requested route information, while the route information contains one or more of the routing information related to the operation, management, maintenance (OAM) functions, the service status of the service at the destination far end and service configuration data at the far end destination. 2. The method according to claim 1, further comprising the step of processing the request. 3. The method according to claim 1, wherein the route information comprises connectivity information for the route. 4. The method according to claim 1, in which the route information contains information showing whether the request reached the far destination at the far end associated with the service distribution point. 5. The method according to claim 1, in which the route information contains information about the service associated with the route. 6. The method according to claim 1, in which the route information contains information about the existence of the service associated with the route. 7. The method of claim 1, wherein the route information comprises identification information associated with a service associated with the route. 8. The method according to claim 1, wherein the route information comprises a label associated with a service associated with the route. 9. The method according to claim 1, in which the route information contains information about the operational status of the service associated with the route. 10. The method according to claim 1, in which the route information contains information about the administrative status of the service associated with the route. 11. The method of claim 1, wherein the route information comprises configuration information of a service associated with the route. 12. The method according to claim 1, in which the requested route information comprises a first set of route information, and said request includes a second set of route information. 13. The method according to claim 1, in which the requested route information contains a first set of route information, and said request includes a second set of route information, wherein said request is generated by a near-end node associated with a service distribution point, and said the second set of information contains information about how the route is configured on said near end node. 14. The method according to claim 1, in which the requested route information comprises a first set of route information, and said request includes a second set of service information associated with the route. 15. The method according to claim 1, in which the requested route information comprises a first set of route information, and said request includes a second set of route information, said request being generated by a proximal end node associated with the service distribution point, and said second the information set contains information about how the service associated with the route is configured on said near end node. 16. The method according to claim 1, in which the requested route information comprises a first set of route information, and said request includes a second set of route information, said request being generated by a proximal node associated with a service distribution point, and said second the information set contains information about the state of the service associated with the route at the near end node. 17. The method according to claim 1, further comprising monitoring the state of the route by processing said request and response. 18. The method of claim 1, further comprising monitoring the status of the service by processing said request and response. 19. The method according to claim 1, in which the sending of the request includes the step of sending an echo request. 20. The method according to claim 1, wherein receiving the response to the request includes an echo reply having an address of said destination at the far end. 21. The method according to claim 1, in which receiving a response to the request includes the step of determining a parameter for the route. 22. The method of claim 1, wherein the request is sent via a service-based distribution route. 23. The method according to claim 1, wherein said request is sent through a transport tunnel. 24. The method of claim 1, wherein said request is not sent via a service-based distribution route. 25. The method according to claim 1, wherein the service-based distribution route comprises a first service-based distribution route, wherein said request is generated and sent by the proximal end node associated with the first service-based distribution route, and the response is received through a second based on the service, the propagation route from the destination at the far end to the near end node. 26. The method according to claim 1, wherein said request includes requested route information, and the method further includes processing the request by processing said route information. 27. The method of claim 26, wherein said request is generated and sent by a near end node associated with a service distribution point, and processing said route information comprises determining whether the information included in said response is consistent with how the route is configured on the near end node. 28. The method according to p. 26 in which said request is generated and sent by the near-end node associated with the service distribution point, and processing said route information comprises determining whether the information included in said response is consistent with how configured service on the near end node. 29. A system for checking a service-based distribution route containing a service distribution point and a transport tunnel associated with a service distribution point, comprising a processor configured to generate a request for route information, sending the request to a destination at the far end associated with the point distribution of the service, and receiving a response to said request, moreover, this response includes the requested route information; and a network interface configured to send said request to said destination at the far end via a network and receive said response from said network, wherein the route information contains one or more route-related operation, management, maintenance (OAM) functions , the operational status of the service at the far end and the configuration data of the service at the far end. 30. A computer program product for service-based verification of a distribution route comprising a service distribution point and a transport tunnel associated with a service distribution point, wherein the computer program is embodied as computer-readable medium and contains computer instructions for generating a request for route information; sending this request to the destination at the far end associated with the service distribution point; and receiving a response to said request, the response including the requested route information, wherein the route information contains one or more of the route data related to the operation, management, maintenance (OAM) functions, the service status of the service at the destination far end and service configuration data at the far end destination.

Images