CN100484062C - Oam echo messaging to verify a service-based network distribution path - Google Patents

Abstract

Echo messaging for operation, administration, and management of a service based distribution path and associated services are disclosed. Service-based distribution paths or transport tunnels include services mapped or bound to a path associated with the transport tunnel. Echo messaging provides OAM capabilities to monitor the operational state of a service-based distribution path, including determining configuration, connectivity, and other characteristics of the path and associated services that transport data. OAM functions provided by echo messaging enable OAM functions despite service volume along a core network, path or set of paths.

Description

Examine O&M Management Echo Messaging Based on Service Network Distribution Paths

Cross References to Related Applications

This application claims priority to U.S. Provisional Patent Application 60/466,248, filed April 28, 2003, entitled "Echo Messaging to Verify Service-based Network Distribution Paths," which is hereby incorporated by reference.

This application is related to and filed concurrently with a pending U.S. Patent Application ______ (Attorney Docket No. 137797), entitled "Using Network Transport Tunnels To Provide Service-Based Data Transport," and filed for 2003 Priority is claimed to U.S. Provisional Patent Application 60/466,340, filed April 28, 1999, entitled "Using Network Transport Tunnel to Provide a Service-Based Distribution Path," which is hereby incorporated by reference.

technical field

The present invention relates generally to computer networks and network protocols. In particular, OAM echo messaging for verifying service-based network distribution paths is disclosed.

Background of the invention

Transport tunneling is employed in communications, networking, and networking equipment (eg, routers, switches, hubs, etc.) to route data between endpoints, such as between provider edge (PE) routers on the edge of a provider network. In some cases, transport tunnels may be used to forward packets through a network that does not support the particular packet protocol in use. For example, transport tunnels may be used to forward non-IP packets across IP networks, multicast packets across unicast networks, and so on.

Services (eg, leased lines, virtual leased lines (VLLs), etc.) can be bound to transport tunnels, and often many services can be associated with a single transport tunnel. However, for many services, effective service management is also difficult to achieve. This limits the network's ability to efficiently implement and operate services across the core network, which results in considerable time and expense in managing said transport tunnels and the services connected thereto. Also, the ability to test, monitor and manage transport tunnels in addition to transmitting data packets can be difficult where a large number of services are involved.

Existing protocols and standards allow the configuration and connectivity of transport tunnels to be checked (eg LSP ping (test pass procedure)), eg label switched paths (LSPs). However, existing tools do not adequately address the need to be able to verify service configuration and connectivity.

Therefore, there is a need for a solution that facilitates the operation, management and maintenance of services used to transfer data across networks.

Description of drawings

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

Figure 1 illustrates an exemplary system for binding services to label switched paths;

FIG. 2A illustrates an exemplary system for using a transport tunnel bound to a service-based distribution path;

Figure 2B illustrates an exemplary service-based distribution path including associated transport tunnels;

Figure 3 illustrates an exemplary system with unidirectional transport tunnels through network interconnection endpoints;

Figure 4 shows an exemplary OAM message format;

Figure 5A shows a process for operational service determination according to an embodiment;

Figure 5B shows another process for checking an echo reply (echo reply) message according to an embodiment;

Figure 6 illustrates a process for checking an OAM echo message for a service-based distribution path according to an embodiment; and

Fig. 7 illustrates a process of OAM echo messaging for checking services on a service-based distribution path according to an embodiment.

Detailed ways

The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition and a computer-readable medium such as a computer-readable storage medium or in which a program is transmitted over an optical fiber or electronic communication link Instructions for computer networks. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of steps in disclosed processes may be altered within the scope of the invention. .

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention has been described in connection with the embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The details are provided for the purpose of example and the invention may be practiced according to the claims without all or part of the specified details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

Internetwork and data communication across one or more networks may require multiple protocols or technologies for forwarding packets between endpoints, such as edge routers of the Internetwork. Endpoints such as Provider Edge Routers (PEs), Edge Services Routers (ESRs), or other Labeled Edge Routers (LERs), may use transport tunnels such as Service-based Distribution Paths (SDPs) to transmit data to downstream User Edge Routers (CE) and terminal destination (eg MAC address). A service-based distribution path may also be a service distribution point and one or more associated transport tunnels. The SDP is established using a protocol such as Multiprotocol Label Switching Service (MPLS), MPLS Traffic Engineering (MPLS-TE), IP, or other types of Generic Routing Encapsulation (GRE) that affect Layer 2 or Layer 3 communications )protocol. SDP can be implemented as a transmission tunnel (eg, unidirectional, bidirectional, omnidirectional) between endpoints, thereby providing a transmission tunnel for service packet transmission. However, in addition to the transport capability, the OAM function is also implemented in the SDP. In the case of MPLS, a label-switched path (LSP) may be associated (as a separate path or sub-path) with an SDP, which may also have a service or set of services mapped or bound to the label-switched path. OAM functionality is implemented with SDP by using information generated from loopback messaging, a system for OAM messaging and information/data collection. SDP enables improved service control, monitoring, configuration and OAM capabilities regardless of the core network protocol in use.

A transport tunnel (eg, SDP, unidirectional transport tunnel, etc.) may have one or more paths (eg, multiple LSPs) associated therewith. SDP may include unidirectional and other types of transport tunnels for forwarding data packets from multiple services. The use of LSPs such as those used in MPLS can be implemented as separate routers in a particular SDP that route data packets between near-end and far-end destinations (eg ESRs). Once paths are associated with transport tunnels, services are mapped to individual paths and transport tunnels. Once mapped, inspections regarding the operational status of services, SDPs, paths, etc. can be performed. Operational service and SDP inspections may determine SDP configuration, connectivity, end-to-end operational status, non-operational SDPs, round trip time (RTT), payload capabilities, or other information about the service or SDP, or other OAM capabilities.

OAM capabilities can be implemented in SPDs using OAM messaging. An example of a class of messaging is "OAM Echo Messaging". In general, OAM echo messaging can be used to facilitate high-level verification that a given SDP or Service-ID is operational and connected between ESRs. The format of the OAM Echo message includes SDP Echo Request and Response, Service Echo Request and Response, which may include different header fields for identifying the type of task to be implemented by a particular message.

Figure 1 shows a system for binding services directly to individual label switched paths. Services 102-106 send data to provider edge (PE) router A via LSP A 112, utilizing cross-connects (CCs) 108, 116, and 120, respectively. Services 102-106 send data to PE router B via LSP B 114 using cross-connects 110, 118 and 122, respectively. Each service 102-106 is individually configured with an independent cross-connect for each LSP. Fewer or more cross-connects and services can be implemented, but with multiple services employed, management, monitoring and control can become increasingly complex. For example, a change to LSP 112 would require configuring each of cross-connects 108, 116, and 120 to reflect the change. In the simplified example shown in Figure 1, only three services (and/or their associated cross-connects) have to be reconfigured. However, in a typical commercial embodiment, there may be thousands of services and dozens or more LSPs. Additionally, the individual provisioning services 102-106 must know something about the LSPs 112 and 114 in order to be able to bind the services directly to the LSPs by properly configuring the cross-connect, which requires the person configuring the service to know its own No known transmission path (LSP), thereby potentially increasing training, recruiting, compensation and other costs.

FIG. 2A illustrates an example system 200 in which transport tunnels bound to service-based distribution points are used to provide service-based transport of network traffic. In FIG. 2A, services 1-3 labeled 202-206 are bound to one or more SDPs 210-216 via SDP 208 of the mapping module. Although the SDP 208 of the mapping module is shown as a single block in FIG. 2A , in some embodiments it may be represented as a set of separate cross-connects binding each service to one or more SDPs 210-216. be realized. SDPs 210-216 may be implemented with one or more transport tunnels (e.g., LSPs) associated with each SDP. The transport tunnel can be static or dynamic. In one embodiment, each SDP includes a distribution point for a single destination (egress) PE router. Each SDP may have multiple services bound to or mapped to that SDP by the SDP 208 of the mapping module. In one embodiment, an ingress PE router may have more than one SDP associated with the same destination (egress) PE, but each service may be bound or mapped to only one SDP for each destination , the service can be configured to send data to this destination. An LSP is an example of a type of transport tunnel that can be associated to an SDP for transporting service packets across the MPLS core network. With other types of core networks or networks that may use different core routing protocols, other types of paths may be used. Each SDP 210-216 can be viewed as a distribution point with one or more associated transport tunnels, independent of the core network protocol, connecting near endpoints with far endpoints/destinations, which can be One or more services are mapped to the transport tunnel to enable the service to send service packets (or some other form of service data) to the destination associated with the SDP. By binding the services 202-206 to the SDP, instead of binding the service directly to the transport tunnel (e.g. LSP) as in Figure 1, the services 202-206 can be configured independently of the transport tunnel and vice versa However, this simplifies the provisioning and/or reconfiguration of each. For example, if an LSP in SDP1 (210) is added, removed or changed, then in SDP, information about the LSP only needs to be modified once. Services 202-206 will not require any changes in system 200 by the SDP of the mapping module

208 binds the service to an SDP and does not map directly to a transport tunnel associated with that SDP. Similarly, services can be added, removed, or changed without modifying multiple cross-connects to multiple LSPs (or other transport paths).

In one embodiment, SDP has several attributes for providing service-based data communication capabilities. Examples of these attributes include addresses (e.g., IP addresses) for remote destinations (e.g., PEs or other egress devices or nodes), encapsulation types (e.g., GRE, MPLS, L2TP, etc.) The path (where applicable, such as MPLS) and the maximum transmission unit (MTU) for the path to reach the remote destination, where the remote destination represents the endpoint to which the association can be sent Network traffic for the service is used for further delivery to user destinations associated with the service. Using these attributes, SDP provides control capabilities that determine service packets (i.e., packets that are transmitted to implement a specified service, such as a virtual leased line (VLL) or other type of service offered by a vendor or service provider etc.) are transmitted and processed on an end-to-end basis throughout the network. SDP can be used to transport packets associated with single or multiple services. By aggregating multiple LSPs or paths into a single transport tunnel (SDP), service packets can be shared among LSPs including the SDP. That is, instead of sending packets for a particular service across a single path, packets may be distributed among several paths for transmission to an end service destination. The protocol can also be used to dynamically monitor the end-to-end operational status of the SDP, providing the ability to determine if the operational status of the SDP changes, and if so, what services might be affected. As an example, a "keep alive" protocol can be implemented that specifies specified header values or information that can be used for operations, administration and maintenance (OAM) functions with respect to the demultiplexing.

Figure 2B illustrates an exemplary service-based distribution point including associated transport tunnels. SDP 230 is shown with several LSPs 232-240 associated with it (assuming MPLS is in use). In other instances where MPLS may not be in use, transport tunnels other than LSPs may be used. To illustrate the use of MPLS or MPLS-TE, LSPs 232-240 carry service packets between a near-end (incoming) router and one or more far-end (outgoing) routers associated with the SDP. In FIGS. 2A and 2B , an SDP is graphically represented as a tunnel, which includes one or more constituent transport tunnels, such as LSPs, thereby conveying the notion that the SDP provides a path for transporting data via the transport tunnel associated with the SDP to the The destination associated with this SDP. It should be understood that the SDP does not actually represent a transport mechanism separate from or layered on top of the transport tunnel associated with the SDP, and instead serves as a distribution point configured to communicate via the transport tunnel associated with the SDP A transport tunnel (eg, LSP) of the SDP transports data packets associated with services bound to the SDP to destinations associated with the SDP. The establishment and configuration of the SDP will be described in detail below with reference to FIGS. 3 to 9 .

FIG. 3 illustrates an exemplary system 300 with unidirectional transmission tunnels through network connection endpoints. The figure shows in detail an example of a system in which SDP can be used to provide service-based transport of data across a network or set of networks. Edge Services Routers (ESRs) 302 and 304 are connected across a network 306 . In this example, network 306 is shown as an IP/MPLS core network. In other embodiments, other types of core networks may be used. CEs 308-310 send packets received from ESRs 302 and 304, respectively, to their intended end-user destinations, such as MAC addresses in their respective user networks. CEs 308 and 310 also receive packets from associated user nodes to be transmitted using VLL service 123, and transmit the packets to ESRs 302 and 304, respectively, for transmission. Unidirectional transport tunnels 312 and 314 provide the transport mechanism for service packet transport and are associated with the SDP shown in the example. In one embodiment, transport tunnel 312 includes an LSP associated with SDP 324, and transport tunnel 314 includes an LSP associated with SDP 326. Here, services such as VLL may be implemented using bi-directional service access points 316-318. In other embodiments, other types of services may be provided, such as VPLS. Service packets are exchanged between service access points 316-318 and transported through unidirectional transport tunnels 312 and 314. In this example, virtual circuit (VC) labels 320 and 322 are applied to service packets originating from service access points 316 and 318, respectively. SDPs 324-326 forward service packets with VC tags 320-322 attached to ESRs 302-304 across unidirectional transport tunnels 312 and 314. When receiving a service packet with an attached VC tag, demultiplexers 328 and 330 identify, based on the VC tag, that the service packet is destined for service access point 316 or 318, and route the service packet accordingly.

In the example shown in FIG. 3 , user packets associated with VLL service 123 are sent to ESR 302 by, for example, CE 308, said VLL service 123 being sent by a source associated with CE 308 to a destination associated with CE 310. ESR 302 receives the packet and associates the packet with VLL service 123 (eg, based on the port on which the packet was received, the encapsulation used, a tag or other identifying information included in the packet, etc.). The service access point 316 forwards the packet to the SDP 324 (directly as in the illustrated embodiment or via the SDP of the mapping module, not shown in FIG. 3 but described above in conjunction with FIG. 2A , e.g. in multiple In an embodiment where the services can use the same SDP) for delivery to the outgoing ESR 304. SDP 324 encapsulates the packet for delivery to ESR 304 via unidirectional transport tunnel 312, including by adding a VC tag 320 identifying that the packet is associated with service 123. In one embodiment, SDP 324 includes two or more transport tunnels to ESR 304. SDP 324 selects the tunnel to be used to transmit the packet to ESR 304. For example, in an embodiment where SDP 324 includes two or more LSPs, SDP 324 may be configured to bind a service to a particular LSP so that all traffic for that service is sent via the same LSP, the The service is, for example, a VLL service such as VLL service 123 . For other types of services (such as VPLS or VPRN), the SDP can map packets to LSPs by associating them with a "conversation," that is, a set of related packets exchanged between two endpoints. for transmission, and select an LSP associated with the session (eg, to prevent packets from being delivered out of order, as might occur if different packets associated with the session were sent via different paths). In some embodiments, where VPLS, VPRN, or similar services are provided, the destination MAC address may be used to identify the LSP to be used to transport the packet. When a packet arrives at ESR 304, demultiplexer 330 identifies the packet as being associated with service 123, e.g., based on VC tag 320, and passes the original (payload) packet to service access point 318 for processing. Service access point 318 then transmits the packet to CE 310.

Figure 4 shows an exemplary OAM message format. In this embodiment, the OAM message 400 may include two parts, a common header part 402 and a message specific part 404 . The common header portion 402 includes fields that may be populated by the originator or responder of the echo message. Examples of fields that may be included in the common header portion 402 include fields for identifying the version of OAM messaging used, message type, message length, message identifier, originator's identity, responder's identity , the identifier of the SDP used by the originator, the identifier of the SDP used by the responder and/or associated with the service by the responder, and an optional checksum. Other fields may be used in this or other embodiments and are not limited to the examples above.

In one embodiment, the OAM messaging version field defines the version of OAM messaging used. This field determines whether the endpoint for a particular service or SDP is using the same or correct OAM messaging version. If different, the echo message is discarded.

In one embodiment, the message length field identifies the total length of the message, which includes the common header portion 402 and the message specific portion 404 . The message type field identifies the OAM message by type. In one embodiment, the following types are defined: SDP Echo Request (sent by a near-end or incoming SDP to a far-end destination, e.g. to verify configuration and/or connectivity of the SDP); SDP Echo Response (in response to an SDP Echo Request ); Service Echo Request (sent from the near-end or incoming ESR, eg to verify service configuration on the near and/or far-end); and Service Echo Response (in response to the Service Echo Request). In this example, messages other than the types described above are discarded. However, in other embodiments, different types of messages may be used. The message identifier is a unique identifier (eg, sequence number) assigned by the originator of the message. Exemplary rules for assigning message identifiers are described in US Provisional Patent Application 60/466,340, filed April 28, 2003.

The originator identifier included in the originator identifier field of common header field 402 may be used to authenticate received response messages. As an example, a responder that echoes a request message does not change the originator field, but populates an echo response message that includes the originator identifier of the request message in the common header. The responder can use this originator identifier to determine the source of the echo message request, since tunnel/SDP information is not available for this purpose. When the response is sent via SDP to the originator of the request, the receiver returning the request can use the originator identifier field to find the appropriate SDP to use as the response path. If the response message is normally encapsulated in IP/GRE rather than sent via SDP, the originator identifier can be used to determine the originator's destination IP address as described below in connection with FIG. 5 .

The responder identifier field of the common header 402 is, in one embodiment, a bit field that is populated by the Echo Request message originator and checked by the Echo Request message receiver. In one embodiment, the responder's IP address is used as the responder identifier. In this embodiment, if the IP address in the Responder Identifier field is different from the service IP address of the receiving remote ESR, then in the Echo Response message sent by the receiving ESR in response to the Echo Request message The Responder Identifier field was changed to the correct IP address.

The format of the message specification section 204 depends on the type of message being sent. In one embodiment, if the OAM message 400 is an SDP Echo Request message or an SDP Echo Response message, the message specifying portion 404 includes a set of SDP Echo Originator flags (flags) and a set of SDP Echo Responder flags, the Echo The originator of a request (or in the case of an echo response, the originator of a request that replies to a response) uses a set of SDP echo originator flags to provide information about the request message and configuration of the SDP on the originator's end. information, the receiver of the request message uses a set of SDP echo responder flags to provide information in the receiver's response message about the receiver's SDP echo response message and the configuration of the SDP that the receiver associates with the SDP The originating party is associated. Examples of SDP echo originator flags used in one embodiment include the following: flags to indicate whether different fields of the common header 402 include valid values, flags to notify requesting receivers of the A flag of the originator SDP's operational and/or administrative status indicating whether the request was sent with the originator SDP identified in the common header (or, for example, using generic IP/GRE encapsulation) , a flag for indicating the operational and/or administrative status of the originator device associated with the originator identifier included in the header, and for informing the requesting receiver whether the receiver should The responder SDP identified in the flag to respond to the request. Examples of SDP echo responder flags used in one embodiment include the following flags: a flag for notifying the originator of the validity or invalidity of header values included by the originator in the request, flag indicating whether the request was sent with the responder SDP identified in the common header (or e.g. A flag indicating whether general IP/GRE encapsulation is used, etc.), a flag indicating the operational and/or administrative status of the responder device associated with the responder identifier included in the header, and a flag used to An indication that the party notifies that the Responder Identifier included in the Request is incorrect or has been changed and that the new Responder Identifier included in the Response should now be used. Other originator and/or responder flags and/or fields may be used similar to those described above to verify configuration and connectivity of outgoing and/or returning SDPs.

In the case of an OAM Service Echo Request message or an OAM Service Echo Response message, in one embodiment, the message specifying part 404 may include information and/or one or more flags for providing and/or verifying information about the service being inspected. field, the one or more flags are used to signal information about the service echoing the request or response message and/or the service it refers to. For example, message specification portion 404 may include fields for providing a service identifier associated with the service, an identifier for each virtual circuit tag associated with the service by the originator and responder, respectively, and a set of A service returns an originator ID and a set of services echoes a responder ID. The Service Echo Originator Flag may be used to signal whether certain header fields (e.g. Originator SDP Identifier or Originator Identifier) contain valid data, whether the Originator identified in the header Operational and/or administrative status of the originator SDP, whether the originator SDP identified in this header was used to send the request, whether the receiver should use the responder SDP identified in this header for the response (if possible), whether the originator service identifier included in the corresponding field of the message designation part 404 is valid, and whether the associated service is operationally and/or administratively serviced or not provided at the originator's end, and Whether the service is bound to the originator SDP identified in the header. The service echo responder flag may be used to provide corresponding information about the configuration and status of the service on the responder side and the validity of the data in the common header 402 and/or the message specific part 404 . Additional flag sets may be included to provide information on the validity and operational status of incoming and outgoing VC tokens associated with each peer's service, and on how to signal or provision the VC token.

FIG. 5A illustrates the process of operating services and SDP determination according to an embodiment. Operational services or SDP determinations are general examples of OAM functions that can be implemented. In this embodiment, as described above, loopback messaging for OAM purposes may be used to enable operational service determination. An Echo Request message is sent to the remote ESR to determine service or SDP availability and/or configuration, operational status, connectivity, and other information (eg, MTU, payload, etc.) (504). A determination is made as to whether an echo response message was received (506). If an echo response message is received, the message is checked for information about the remote ESR's configuration, service ID, etc. (508). If the echo response message is not received, an error message is sent to the administrator (510) and the service or SDP is left in a non-operational state (512). The above description may be used to describe the use of echo messaging for service or SDP determinations, and may be used for other purposes in other embodiments.

FIG. 5B illustrates another process for checking echo response messages, according to an embodiment. In this example, an echo response message is received (520). Once received, the echo response message is inspected for information about the service or SDP with the remote destination (eg, ESR) (522). Once checked, the echo response message produces information from which it can be determined whether there is an inconsistency between the far-end ESR and the near-end ESR (524).

If no inconsistencies are found between the far-end ESR service or SDP and the near-end ESR service or SDP, then the service or SDP is placed in an operational state (526). If an inconsistency is found between the far-end ESR service configuration and the near-end ESR service or SDP based on the information included in the echo response message, an error message is sent to the network/system manager (528) and the service or SDP remains Non-operational state (530).

Fig. 6 illustrates a process for checking an OAM echo message of a service distribution point according to an embodiment. In one embodiment, the process of Figure 6 is an SDP-specified implementation of all or part of the more general process shown in Figures 5A and 5B. Here, OAM SDP echo messages are sent and received between a near-end point (eg, an originator) and a far-end point (eg, a responder). The OAM SDP Echo message may include an OAM SDP Echo Request message and an OAM SDP Echo Response message.

In this example, an OAM SDP Echo Request message is generated (602). During generation, the OAM SDP Echo Request message can have different bit fields, header values, VC flags and be used to identify specific OAM functions or information requests (e.g. SDP connectivity, SDP RTT test, SDP-ID test, SDP operation message transfer, etc.) other control words. Once generated, the OAM SDP Echo Request message is sent to the remote endpoint (eg, ESR) (604). At the remote point, the OAM SDP Echo Request message is received (606). Once received, the OAMSDP Echo Request message is processed (608) according to the information included in the message format. In this example, processing may be performed to determine and perform the requested OAM function, or to generate and send an OAM SDP Echo Response message from the responder back to the originator that generated the OAM SDP Echo Request message.

FIG. 7 illustrates a process for verifying OAM echo messaging of a service mapped to a service distribution point according to an embodiment. In this example, an OAM Service Echo Request message is generated by the originator (702). After the OAM service echo request message is generated, it is sent to the responder or remote service destination (eg, ESR) (704). At the remote service destination, the OAM service echo request message is received and processed. For example, the receiver may examine "responder" data included in the request, and may collect and/or examine information about the service configuration on the responder side. An OAM Service Echo Response message is generated by the responder and sent back to the originator. The OAM service echo response is received (706). Once received, the OAM Service Echo Response message is processed to determine if the service is properly configured (708). OAM Service Echo messages can be used to determine information about various characteristics of the service, including whether the service exists at the remote end, and if so, the operational and/or administrative status of the service at the remote end, Service connectivity of the SDP (i.e. the local ESR is able to successfully send the service packet to the remote end), service connectivity via the remote SDP (i.e. the remote ESR is able to send the service involving the packet back to the originator), and includes Whether the VC token associated with the service by the sender and responder is bound to the correct user/service. In other examples, OAM functions other than those described above may be used for OAM service echo messaging, such as verifying that changes in how services are provisioned have been implemented and propagated correctly.

Although the foregoing embodiments have been described in detail for clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.

Claims (32)

1. be used to check method based on the distribution path of service, one or more transmission tunnel that described distribution path comprises service distribution point and is associated with this service distribution point, this method comprises the following steps:

Generation is at the request of the information that is associated with described path,

This request is sent to the far-end destination that is associated with described service distribution point, and

Reception is to this request responding,

Wherein, described service distribution point is configured to have one or more services, described one or more service is not by being mapped to described distribution path based on service with the service distribution point of described one or more tunnels direct correlation, and be configured to use described one or more transmission tunnel will with the transfer of data of described one or more service associations to the described related destination of distribution path based on service, and the information related with described path comprise indication at far-end that far-end is configured based on the operation and/or the controlled state of the distribution path of service and be mapped to described far-end based on one or two the information in the state of service at far-end of the distribution path of service.

2. according to the process of claim 1 wherein, described response comprises the information that is requested that described and described path is associated.

3. according to the method for claim 1, also comprise processes said request.

4. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information in relevant this path.

5. according to the process of claim 1 wherein, the information that described and described path is associated comprises the connectivity in relevant this path.

6. according to the process of claim 1 wherein, the information that described and described path is associated comprises such information, and whether its indication described request arrives the far-end destination that is associated with described service distribution point.

7. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information of the relevant service that is associated with this path.

8. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information of the existence of the relevant service that is associated with this path.

9. according to the process of claim 1 wherein, the information that described and described path is associated comprises the identification information that is associated with the service that is associated with this path.

10. according to the process of claim 1 wherein, the information that described and described path is associated comprises the mark that is associated with the service that is associated with this path.

11. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information of the mode of operation of the relevant service that is associated with this path.

12. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information of the controlled state of the relevant service that is associated with this path.

13. according to the process of claim 1 wherein, the information that described and described path is associated comprises the information of the relevant service configuration that is associated with this path.

14. according to the process of claim 1 wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises the second group of information that is associated with this path.

15. according to the process of claim 1 wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises second group of information in relevant this path.

16. method according to claim 1, wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises the second group of information that is associated with this path, produce described request by the near-end node that is associated with described service distribution point, and described second group of information comprises the information how relevant described path is configured at described near-end node.

17. according to the process of claim 1 wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises second group of information about the service that is associated with this path.

18. method according to claim 1, wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises the second group of information that is associated with this path, produce described request by the near-end node that is associated with described service distribution point, and described second group of information comprises the information that how is configured at described near-end node about the service that is associated with this path.

19. method according to claim 1, wherein, the information that is requested that described and described path is associated comprises the first group of information that is associated with this path, and described request comprises the second group of information that is associated with this path, produce described request by the near-end node that is associated with described service distribution point, and described second group of information comprises about the service that is associated with this path information at the state of described near-end node.

20., also comprise the state of monitoring described path by processes said request and response according to the method for claim 1.

21., also comprise by processes said request and response and come the state of monitor service according to the method for claim 1.

22. according to the process of claim 1 wherein, described transmission request comprises sending it back to refer to asks message.

23. according to the process of claim 1 wherein, described reception comprises receiving to have the back response message of described far-end destination-address to the response of described request.

24. according to the process of claim 1 wherein, described reception comprises the parameter of determining described path to the response of described request.

25. according to the process of claim 1 wherein, described request is sent out based on the distribution path of serving via described.

26. according to the process of claim 1 wherein, described request is sent out via described transmission tunnel.

27. according to the process of claim 1 wherein, described request is not sent out via described distribution path based on service.

28. method according to claim 1, wherein, described distribution path based on service comprises first distribution path based on service, produce and send described request by being associated with this first near-end node, and receive described response from described far-end destination to described near-end node via second the distribution path based on service based on the distribution path of serving.

29. according to the process of claim 1 wherein, described request comprises the information that is requested that described and described path is associated, and this method also comprises by handling the information that described and described path is associated and comes processes said request.

30. method according to claim 29, wherein, produce and send described request by the near-end node that is associated with described service distribution point, and described processing and the information that described path is associated comprise how whether the information of determining to be included in the described response be configured consistent at described near-end node with described path.

31. method according to claim 29, wherein, produce and send described request by the near-end node that is associated with described service distribution point, and described processing and the information that described path is associated comprise how whether the information of determining to be included in the described response be configured consistent at described near-end node with service.

32. a system that is used for based on the distribution path of service, one or more transmission tunnel that described distribution path comprises service distribution point and is associated with this service distribution point, this system comprises:

Processor, it is configured to produce request at the information that is associated with described path, described request is sent to the far-end destination that is associated with described service distribution point and receive to this request responding and

Network interface, it is configured to described request is sent to described far-end destination via network, and receives described response from described network,

Wherein, described service distribution point is configured to have one or more services, described one or more service is not by being mapped to described distribution path based on service with the service distribution point of described one or more tunnels direct correlation, and be configured to use described one or more transmission tunnel will with the transfer of data of described one or more service associations to the described related destination of distribution path based on service, and the information related with described path comprise indication at far-end that far-end is configured based on the operation and/or the controlled state of the distribution path of service and be mapped to described far-end based on one or two the information in the state of service at far-end of the distribution path of service.

Images