BACKGROUND

During initial set-up of a service or during troubleshooting of a service failure, test equipment is typically used at one or both ends of the service to verify installation or troubleshoot the service failure. A technician at one end of a service typically communicates with another technician during the install or service troubleshooting to obtain the actual provisioning state of the equipment at the other end of the service.

SUMMARY

In one embodiment, a system is provided. The system comprises a first endpoint device; and a second endpoint device coupled to the first endpoint device over a service provider network. The first endpoint device is configured to insert a Service Level Agreement (SLA) Type Length Value (TLV) element into a Protocol Data unit (PDU) to form an enhanced PDU, the first endpoint device further configured to transmit the enhanced PDU to the second endpoint device. The SLA TLV element includes fields for at least one of service configuration information and test capability information of the first endpoint device.

DRAWINGS

Understanding that the drawings depict only exemplary embodiments and are not therefore to be considered limiting in scope, the exemplary embodiments will be described with additional specificity and detail through the use of the accompanying drawings, in which:

FIG. 1 is a high level block diagram of one embodiment of an exemplary system.

FIG. 2 depicts one embodiment of an exemplary SLA egress configuration TLV.

FIG. 3 depicts one embodiment of an exemplary SLA ingress configuration TLV.

FIG. 4 depicts one embodiment of an exemplary Test Capability SLA TLV.

FIG. 5 is a high level block diagram of one embodiment of an exemplary endpoint device.

FIG. 6 is a flow chart depicting one embodiment of an exemplary method of

In accordance with common practice, the various described features are not drawn to scale but are drawn to emphasize specific features relevant to the exemplary embodiments.

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific illustrative embodiments. However, it is to be understood that other embodiments may be utilized and that logical, mechanical, and electrical changes may be made. Furthermore, the method presented in the drawing figures and the specification is not to be construed as limiting the order in which the individual steps may be performed. The following detailed description is, therefore, not to be taken in a limiting sense.

FIG. 1 is a high level block diagram of one embodiment of a system 100. System 100 includes a service provider network 102 configured to provide one or more services to customer premise equipment (CPE) 110 in customer network 106. In particular, service provider network 102 couples CPE 110 to service equipment 112 to provide the one or more services. For example, service equipment 112 can couple CPE 110 to public network 114. Hence, service equipment 112 includes any equipment configured to provide a respective service, as known to one of skill in the art. Public network 114 represents any type of network that is made available for general public access. Public network 114 commonly implements at least one layer three (L3) protocol (such as an Internet protocol or IP) to communicate data in the form of packets, where reference to layers followed by a number refers to an indicated layer of an Open Systems Interconnection (OSI) model. For this reason, public network 114 may be referred to as a packet-switched network. While shown as a single network, public network 114 may comprise one or more networks that are each interconnected to form public network 114. For example, public network 114 may comprise a large number of networks generally referred to collectively as the â€œInternet.â€

The service provider network 102 can comprise one such network that is interconnected with other networks to form public network 114. Hence, the service provider network 102 is shown separately from public network 114 for purposes of illustrating the techniques described in this disclosure. While described with respect to service provider network 102, the techniques may be implemented with respect to any type of network, including private networks that do not generally permit the general public to access the private network without first authenticating themselves as a valid member of that network.

In addition to or in lieu of the internet service by which CPE 110 may interface with public network 114, the service provider network 102 can also be configured to provide a television service (such as a cable television service), and/or a telephone service (either by way of a plain old telephone system (POTS), which is often referred to as a â€œlandlineâ€ service or as a Voice over IP (VoIP) service). In some instances, a service provider that owns and operates service provider network 102 may provide the infrastructure by which to provide one or more of the above noted services. Competing service providers may also contract with the service provider that owns and operates service provider network 102 to provide competing and additional services to those provided by the service provider that owns and operates service provider network 102. In any event, the service provider network 102 may provide a collection of one or more services, such as the services discussed above.

The CPE 110, which may also be referred to herein as a â€œsubscriber deviceâ€ , may include Internet-ready televisions, non-Internet-ready televisions, set-top boxes (STBs), gaming consoles, personal media players, digital video disc (DVD) players, Blu-ray players, desktop computers, laptop computers, slate or tablet computers, wireless telephones (including so-called â€œsmart phonesâ€ ), global positioning system (GPS) devices, wireless access points (WAPs), switches, hubs, printers, servers, and any other similar devices commonly employed by customers to access one or more of the services provided by service provider network 102. Customer network 106 represents a network owned and operated by customers of service provider network 102.

Typically, a customer's premises (e.g., a customer's home or business) provides the necessary infrastructure (such as the physical communication medium) to support the customer network 106. For example, customer network 106 can include coaxial cable, copper telephone lines, Ethernet cable (which is typically referred to as â€œcategory 5 cableâ€ or â€œcats cableâ€ ), wireless communication medium or any other type of physical communication medium commonly employed in customer premises to facilitate the communication of data, such as voice data, Internet data, or video data. In addition, the customer network 106 can be as simple as a single subscriber device 110 coupled to the service provider network 102 or may involve multiple subscriber devices 110 networked together in a local area network (LAN), the LAN being coupled to the service provider network 102.

In this example, the service provider network 102 supports the layer two (L2) protocol referred to as Ethernet. In addition, the service provider network 102 can be implemented at the physical layer using one or more of fiber optic links, copper lines, coaxial cables, or other physical medium used for the transport of communication signals. The endpoint device 116-1 provides a subscriber drop or link 118 to the customer network 106 using one of a fiber optic link, copper line, coaxial cable, or other physical medium. Furthermore, in some embodiments, wireless communication mediums that do not involve physical communication cabling can be used for the link 118 or for communication of signals through the service provider network 102.

It is to be understood that service provider network 102 depicted in FIG. 1 has been simplified for purposes of explanation and that service provider network 102 can include multiple elements not shown, such as, but not limited to, intermediate devices between endpoint device 116-1 and 116-2, one or more access networks coupled to a core network for providing services, etc., as understood by one of skill in the art. Thus, the service provider network 102 may include combinations of various network devices such as access nodes, network switches, and routers. However, for ease of explanation only endpoint device 116-1 and 116-2 are depicted in FIG. 1. In addition, it is to be understood that endpoint devices 116-1 and 116-2 do not have to be located within a single network operator's administrative domain.

Endpoint device 116-1 couples CPE 110 to the service provider network 102. Hence, endpoint device 116-1 can also be referred to as an access node or network interface device. Similarly, endpoint device 116-2 provides an interface to couple service equipment 112 to the service provider network 102. Thus, endpoint device 116-2 can also be referred to as a network interface device.

In providing a given service to CPE 110, endpoint device 116-1 and endpoint device 116-2 communicate user data over the service provider network 102 using a networking technology, such as Ethernet. In addition, in order to provide the given service, the endpoint device 116-1 and the endpoint device 116-2, along with any intermediate equipment required for transporting the service, are first provisioned or configured for the given service and communication is established between endpoint device 116-1 and 116-2. Typically, during initial set-up of a service or during troubleshooting of a service failure, a technician at one end of the service (i.e. at endpoint device 116-1 or 116-2) verifies Key Performance Indicators (KPIs) for the given service. Such KPIs can include, but are not limited to, Throughput, Frame Loss, Delay, and Delay Variation, as defined by the Metro Ethernet Forum 10.2 standard. In addition, as known to one of skill in the art, these KPIs can be verified by using one or both of a modified RFC 2544 standard and the ITU Y.1564 standard methodologies. A measure of these KPIs can be made at multiple frame sizes and offered data rates as defined by one or more ingress and egress service parameters, such as, but not limited to, Committed Information Rate (CIR), Committed Burst Size (CBS), Excess Information Rate (EIR), and Excess Burst Size (EBS).

These measurements are typically made end-to-end for a given service either in a unidirectional manner or as a round-trip measurement. The testing can be made, in some embodiments, from a single end of a service to minimize the operational expenses of service installation. However, in conventional systems, a technician at one end of the service does not have a view into the configuration of the endpoint device at the other end (also referred to as â€œfar endâ€ ) of the service without involving other personnel with a network wide view of the provisioning process. If the service is an out of region offering the technician may not have access to the appropriate personnel.

In system 100, however, one or both of endpoint device 116-1 and 116-2 is configured to advertise or communicate ingress and egress service parameters and/or test capabilities to the other endpoint device 116-2 and 116-1, respectively. Such advertisement/communication of service parameters and/or test capabilities can be performed automatically or in response to a trigger, such as a request from the other endpoint device.

In particular, endpoint device 116-1 and/or 116-2 is configured to insert a Service Level Agreement (SLA) Type Length Value (TLV) element into an Ethernet Operations, Administration, and Management (OAM) Protocol Data Unit (PDU) to generate an enhanced PDU (ePDU). The SLA TLV in the ePDU is used to advertise/communicate the service provisioning and the test capabilities of the respective endpoint device which generated the ePDU.

In some embodiments, the SLA TLV is inserted into a conventional Ethernet OAM PDU such as, but not limited to, the Continuity Check Protocol, Loopback Protocol, and the Link Trace Protocol known to one of skill in the art. For example, the Continuity Check Protocol is used to establish and monitor connectivity of the service endpoint device and can alarm an interruption of the connectivity. The OAM Loopback Request and Response PDUs can provide an on-demand test of connectivity and the Link Trace Protocol can be used to determine the path taken through the service provider network 102 between the endpoint device 116-1 and 116-2. Each of these PDUs can be enhanced to support a SLA TLV, such as those described in more detail below. Additionally, in some embodiments, an SLA TLV can be added to the Latching Loopback Protocol and Service Activation Testing (SAT) Protocol standards as part of the discovery process of loopback points within the network 102. Alternatively, or in addition to the PDUs mentioned above, a new OAM PDU is created in some embodiments to support the advertisement and reporting of the equipment configuration and/or test capability via an SLA TLV. FIGS. 2-4 depict exemplary SLA TLVs.

FIG. 2 depicts an exemplary SLA egress configuration TLV 200. The SLA egress configuration TLV 200 provides information regarding the egress SLA configuration of a single traffic class for the endpoint device which generated the SLA egress configuration TLV 200. As used herein, the term â€œegressâ€ refers to the direction service frames are communicated on a User-Network Interface (UNI) or External Network to Network Interface (ENNI) relative to the endpoint device advertising the SLA. For example, service frames egress or exit the endpoint device at a UNI or ENNI where an ePDU containing the SLA egress configuration TLV 200 is generated.

The fields of the exemplary SLA egress configuration TLV 200 begin at field or attribute 202. The field 202 indicates the type of TLV. In this example, the value of field 202 indicates to the receiving endpoint device that the TLV is an organization specific TLV. Field 204 indicates the length of the TLV 200 (e.g. the number of octets in the TLV that follow the field 204.) Field 206 contains an Organization Unique Identifier (OUI) which can be administered by a standards organization such as the Institute of Electrical and Electronics Engineers (IEEE). Field 208 is a sub-type field which identifies the type of Organization specific TLV. The value of field 208 can vary from organization to organization. In the exemplary embodiments described herein, the value of â€˜17â€™ indicates an Egress Class of Service (CoS) SLA Configuration TLV as shown in FIG. 2. A value of â€˜16â€™ indicates an Ingress CoS SLA Configuration TLV as shown in FIG. 3. A value of â€˜18â€™ indicates a Test Capability SLA TLV as shown in FIG. 4.

Field 210 of TLV 200 indicates the Class of Service to which the TLV 200 corresponds. That is, field 210 specifies the Layer 2 priority bit used for frames that belong to the traffic class defined by the respective SLA TLV 200. Field 212 indicates the egress Committed Information Rate (CIR) of the given service in Kbps. Field 214 indicates the egress Committed Burst Size (CBS) of the given service in Bytes. Field 216 indicates the egress Excess Information Rate (EIR) of the given service in Kbps. In some embodiments, if an Internet Engineering Task Force (IETF) policing algorithm is implemented, field 216 does not denote the EIR, but represents a Peak Information Rate (i.e. equivalent to a single value where PIR=CIR+EIR). Field 218 indicates the Excess Burst Size (EBS) of the given service in Bytes. As with field 216, in some embodiments, if an IETF policing algorithm is implemented, field 218 does not denote the EBS, but represents a Peak Burst Size (PBS).

Field 220 indicates the configured Color Mode. When set to enable (i.e. value 1=enable), the service is Color Aware. When set to disable (i.e. value 0=disable), the service is Color Blind. Color Aware is a bandwidth profile property where a pre-determined level of bandwidth profile compliance for each service frame is taken into account when determining the level of compliance for each service frame. Color Blind is a bandwidth profile property where a pre-determined level of bandwidth profile compliance for each service frame, if present, is ignored when determining the level of compliance for each service frame. A service frame is an Ethernet frame transmitted across the UNI toward the service provider or an Ethernet frame transmitted across the UNI toward the customer premise equipment. Hence, an egress service frame is a service frame sent from the service provider network to the CPE. An ingress service frame is a service frame sent from the CPE into the Service Provider network.

Field 222 indicates if the coupling flag is enabled or disabled. A value of 1 sets the coupling flag to enable and a value of 0 sets the coupling flag to disable. When set to enable, the coupling flag allows unused tokens from the CIR traffic to be used by the Excess traffic flow. Field 224 indicates whether the service is being policed. A value of 1 indicates that the service is being policed and a value of 0 indicates that the service is not being policed. Field 226 indicates the policing algorithm applied to the service. For example, in this embodiment, a value of 0 indicates the Metro Ethernet Forum (MEF) (RFC 4115) Two Rate Three Color Marker. A value of 1 indicates the IETF (RFC 2697) Single Rate Two Color Marker. The value of 2 indicates the IETF (RFC 2698) Two Rate Three Color Marker. It is to be understood that other policing algorithms can be used in other embodiments. Field 228 indicates whether the endpoint device is configured to shape the traffic for the respective traffic class or not.

FIG. 3 depicts an exemplary SLA ingress configuration TLV 300. The SLA ingress configuration TLV 300 provides information regarding the ingress SLA configuration of a single traffic class for the endpoint device which generated the SLA ingress configuration TLV 300. As used herein, the term â€œingressâ€ refers to the direction service frames are communicated on a User-Network Interface (UNI) or External Network to Network Interface (ENNI) relative to the endpoint device advertising the SLA. For example, service frames are received by the endpoint device at a UNI or ENNI where an ePDU containing the SLA ingress configuration TLV 300 is generated. Fields 302-328 are similar to fields 202-228 in FIG. 2. However, fields 312-328 are associated with ingress service frames as opposed to egress service frames.

FIG. 4 depicts an exemplary Test Capability SLA TLV 400. The Test Capability SLA TLV 400 provides information regarding the test capabilities supported by the endpoint device which generated the ePDU containing the Test Capability SLA TLV 400. Fields 402-410 are similar to fields 202-210 described above. Field 430 is a bit mask of the SLA test modes supported by the endpoint device that generated the ePDU containing the Test Capability SLA TLV 400. For example, in this embodiment, there are 7 possible test modes. Hence, field 430 contains at least 7 bits, each bit corresponding to one of the possible test modes as shown in the exemplary Table 1 below.

TABLE 1BITTEST MODE0Loopback; Management Control1Loopback; Inband Latching Loopback2Loopback; Inband SAT Protocol3one-way Sink; Management Control4one-way Source; Management Control5one-way Sink; Inband SAT Protocol6one-way Source; Inband SAT Protocol

It is to be understood that Table 1 is provided by way of example only and that other test modes can be represented in other embodiments. Additionally, the association of a given test mode to a particular bit in Table 1 is provided by way of example only. A value of â€œ0â€ in a given bit indicates that the endpoint device does not support the associated test mode. A value of â€œ1â€ in a given bit indicates that the endpoint device supports the associated test mode.

Field 432 indicates the test state of the endpoint device. In particular, a value of â€œ0â€ in field 432 indicates that the endpoint device is unavailable for tests. For example, the endpoint device may be unavailable if a test is already in progress, a test resource is not available or for any other reason. A value of â€œ1â€ in field 432 indicates that the endpoint device is available for testing; test resources are available; and there is no issue supporting one of the tests identified in field 430. Field 434 indicates whether the endpoint device is Time of Day (ToD) synchronized with a network timing source. If the endpoint device is ToD synchronized, then one-way delay and delay variation measurements can be made.

Hence, through the use of the SLA TLVs described above, a technician located remotely from the endpoint device generating the SLA TLVs is able to view the service SLA of interest as it is actually provisioned on the endpoint device. This enables the technician to quickly see if there is any mismatch in provisioning and avoid many hours of frustrating test and debug before isolating a problem to the far-end endpoint device as opposed to intermediate equipment. The technician is also provided information to see what testing options are available and also if a test can even be initiated. Status of the far-end endpoint device as far as testing availability is concerned can also save many hours of debug and investigation. Furthermore, it is to be understood that the fields described above are provided by way of example only and that, in other embodiments, other fields can be included in lieu of or in addition to those described above.

FIG. 5 is a high level block diagram of one embodiment of exemplary endpoint device 500 (also referred to as an Ethernet OAM Service Endpoint). Endpoint device 500 can be implemented as endpoint device 516-1 and/or 516-2 in FIG. 1. Endpoint device 500 includes a customer/service interface 501 which is configured to transmit data to and receive data from customer premise equipment or service provider equipment. Endpoint device 500 also includes network interface 503 which is configured to transmit data to and receive data from another endpoint device over the service provider network.

Endpoint device 500 also includes a processing unit 505. Processing unit 505 includes or functions with software programs, firmware or other computer readable instructions for carrying out various methods, process tasks, calculations, and control functions, used in the generation and communication of SLA TLVs, as described above.

These instructions are typically stored on any appropriate computer readable medium used for storage of computer readable instructions or data structures. The computer readable medium can be implemented as any available media that can be accessed by a general purpose or special purpose computer or processor, or any programmable logic device. Suitable processor-readable media may include storage or memory media such as magnetic or optical media. For example, storage or memory media may include conventional hard disks, Compact Disk-Read Only Memory (CD-ROM), volatile or non-volatile media such as Random Access Memory (RAM) (including, but not limited to, Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate (DDR) RAM, RAMBUS Dynamic RAM (RDRAM), Static RAM (SRAM), etc.), Read Only Memory (ROM), Electrically Erasable Programmable ROM (EEPROM), and flash memory, etc.

For example, in this embodiment, SLA TLV instructions 509 are stored on memory 507. SLA TLV instructions 509, when executed by processing unit 505, cause processing unit 505 to insert an SLA TLV into a PDU to generate and communicate an ePDU to another endpoint device, as described above. Endpoint device 500 also includes an Input/Output (I/O) port 511. When an SLA TLV is received over network interface 503, SLA TLV instructions 509 cause the processing unit 505 to extract data and provide data to a user/technician over I/O port 511. For example, the data can be provided to a display unit, a printer, a handheld device, etc. via I/O port 511.

FIG. 6 is a flow chart depicting one embodiment of an exemplary method 500 of advertising SLA attributes of a service and/or the test capability of the respective endpoint device. Method 600 can be implemented in endpoint device, such as endpoint device 116-1, 116-2 or 500 described above. At block 602, it is determined when to report SLA attributes and/or test capabilities. For example, in some embodiments, the SLA attributes and/or test capabilities are reported automatically at pre-determined intervals and/or at specific times. In other embodiments, the SLA attributes and/or test capabilities are reported in response to a received request. For example, a request for reporting SLA attributes and/or test capabilities can be inserted into a PDU transmitted from another endpoint device. Upon receiving the request, the endpoint device receiving the request, begins the process of reporting the requested information.

At block 604, when it is determined to report the SLA attributes and/or test capabilities, the SLA TLV is inserted into a PDU to generate an ePDU, as discussed above. For example, one or more of an SLA egress configuration TLV, SLA ingress configuration TLV, or Test Capability SLA TLV is inserted into a PDU. In some embodiments, the PDU is an existing PDU, such as but not limited to, continuity check protocol PDU, loopback request PDU, loopback response PDU, link track protocol PDU, etc. In other embodiments, a new OAM PDU type is created to insert the SLA TLV. In other words, a new OAM PDU is a PDU configured to transport only the configuration information and/or the test capability information. Thus, an existing PDU is a PDU configured to transport data other than the configuration information or test capability information in the SLA TLV. The same PDU options can also be used by other endpoint devices to transmit a request for the SLA attributes and/or test capabilities.

At block 606, the ePDU is transmitted over the service provider network to another endpoint device where the SLA attributes and/or test capability information is extracted from the ePDU and output to a user. In this manner, a user/technician is able to verify consistent and correct provisioning. Additionally, the technician can determine the appropriate test methodology based on a received Test Capability SLA TLV. For example, if the received Test Capability SLA TLV indicates that the endpoint device supports only Service Loopback capability, the technician can determine if the service is symmetric, and if not, what the service limits on Looping back test frames will be. Additionally, in some embodiments, an automatic selection of the appropriate test methodology can be determined by the endpoint device which receives the SLA TLV based on the information in the Test Capability SLA TLV.

EXAMPLE EMBODIMENTS

Example 1 includes a system comprising: a first endpoint device; and a second endpoint device coupled to the first endpoint device over a service provider network; wherein the first endpoint device is configured to insert a Service Level Agreement (SLA) Type Length Value (TLV) element into a Protocol Data unit (PDU) to form an enhanced PDU, the first endpoint device further configured to transmit the enhanced PDU to the second endpoint device; wherein the SLA TLV element includes fields for at least one of service configuration information and test capability information of the first endpoint device.

Example 2 includes the system of Example 1, wherein the second endpoint device is configured to extract information from the SLA TLV element and output the extracted information.

Example 3 includes the system of any of Examples 1-2, wherein the second endpoint device is configured to transmit a request for information to the first endpoint device; wherein the first endpoint device is configured to insert the SLA TLV element into the PDU in response to the request from the second endpoint device.

Example 4 includes the system of any of Examples 1-3, wherein the first endpoint device is configured to insert the SLA TLV element into the PDU to form the enhanced PDU at predetermined time intervals.

Example 5 includes the system of any of Examples 1-4, wherein the first endpoint device is configured to insert the SLA TLV into an Operations, Administration, and Management (OAM) PDU configured to transport data other than the configuration information or test capability information of the first endpoint device.

Example 6 includes the system of Example 5, wherein the OAM PDU comprises one of a continuity check protocol PDU, a loopback request PDU, a loopback response PDU, or a link track protocol PDU.

Example 7 includes the system of any of Examples 1-6, wherein the first endpoint device is configured to insert the SLA TLV into a PDU configured to transport only the configuration information or the test capability information of the first endpoint device.

Example 8 includes an endpoint device comprising: a first interface configured to receive data from and transmit data to a customer device or to a service provider device; a second interface configured to receive data from and transmit data to another endpoint device via a service provider network; and a processor coupled to the first interface and the second interface, the processor configured to direct operation of the first interface and the second interface; wherein the processor is configured to insert a Service Level Agreement (SLA) Type Length Value (TLV) element into a Protocol Data unit (PDU) to form an enhanced PDU, the processor configured to transmit the enhanced PDU to the other endpoint device via the second interface; wherein the SLA TLV element includes fields for at least one of service configuration information and test capability information of the endpoint device.

Example 9 includes the endpoint device of Example 8, wherein the processor is configured to insert the SLA TLV element into the PDU in response to a request received over the second interface from the other endpoint device.

Example 10 includes the endpoint device of any of Examples 8-9, wherein the processor is configured to insert the SLA TLV element into the PDU to form the enhanced PDU at predetermined time intervals.

Example 11 includes the endpoint device of any of Examples 8-10, wherein the processor is configured to insert the SLA TLV into an Operations, Administration, and Management (OAM) PDU configured to transport data other than the configuration information or test capability information of the endpoint device.

Example 12 includes the endpoint device of Example 11, wherein the OAM PDU comprises one of a continuity check protocol PDU, a loopback request PDU, a loopback response PDU, or a link track protocol PDU.

Example 13 includes the endpoint device of any of Examples 8-12, wherein the processor is configured to insert the SLA TLV into a PDU configured to transport only the configuration information or the test capability information of the endpoint device.

Example 14 includes a method of advertising at least one of configuration information or test capability information from a first endpoint device to a second endpoint device, the method comprising: determining when to report at least one of the configuration information or the test capability information of the first endpoint device; when it is determined to report at least one of the configuration information or the test capability information of the first endpoint device, inserting a Service Level Agreement (SLA) Type Length Value (TLV) element into a Protocol Data Unit (PDU) at the first endpoint device to form an enhanced PDU; and transmitting the enhanced PDU over a service provider network to the second endpoint device; wherein the SLA TLV includes fields for at least one of service configuration information or test capability information of the first endpoint device.

Example 15 includes the method of Example 14, wherein determining when to report at least one of the configuration information or the test capability information comprises determining when to report at least one of the configuration information or the test capability information based on pre-determined time intervals.

Example 16 includes the method of any of Examples 14-15, wherein determining when to report at least one of the configuration information or the test capability information comprises determining when to report at least one of the configuration information or the test capability information based on receipt of a request from the second endpoint device over the service provider network.

Example 17 includes the method of any of Examples 14-16, wherein inserting the SLA TLV into the PDU comprises inserting the SLA TLV into an Operations, Administration, and Management (OAM) PDU configured to transport data other than the configuration information or test capability information of the first endpoint device.

Example 18 includes the method of Example 17, wherein inserting the SLA TLV into an OAM PDU comprises inserting the SLA TLV into one of a continuity check protocol PDU, a loopback request PDU, a loopback response PDU, or a link track protocol PDU.

Example 19 includes the method of any of Examples 14-18, wherein inserting the SLA TLV into the PDU comprises inserting the SLA TLV into a PDU configured to transport only the configuration information or the test capability information of the first endpoint device.

Example 20 includes the method of any of Examples 14-19, further comprising extracting at least one of the configuration information or the test capability information from the enhanced PDU at the second endpoint device; and outputting the extracted information to a user.

Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement, which is calculated to achieve the same purpose, may be substituted for the specific embodiments shown. Therefore, it is manifestly intended that this invention be limited only by the claims and the equivalents thereof.