Patent Application
20100017539
The present invention relates to methods and devices for the exchange of data between a client network access system and a provider network access system.
In a broadband access network, for example with digital subscriber line (DSL) or passive optical network (PON) technologies for the subscriber access, the network operator is interested in monitoring the connection from a provider network access system up to a client network access system.
A provider network access system has the primary task of providing for a connection to a client network access system.
The provider network access system is typically a device which can be connected directly to the client network access system via Layer 2 of the OSI model. The provider network access system can be, for example, a network node (especially a Layer 2 network node), a broadband network gateway (BNG), an IP edge router, a broadband remote access server (BRAS), a multiplexer, especially a digital subscriber line access multiplexer (DSLAM), or a combination thereof. The provider network access system is normally accommodated in the premises of a network operator.
The client network access system has the primary task of providing for a connection to a provider network access system. It is normally accommodated at a customer and in most cases also in his property. It is primarily used for connecting electronic devices or electronic assemblies of the customer to the access network of the provider. The term “client network access system” therefore especially covers the terms “network terminating device”, “modem”, “switch”, “bridge” and “router”.
Tasks which are to be solved by the monitoring of the provider are, for example determining whether the connection is operating and, in the case of complaints by the customer finding, eliminating or preventatively counteracting certain faults. In some broadband access networks, asynchronous transfer mode (ATM) is used as Layer 2 protocol in order to establish an end-to-end connection from the BNG to the network terminating device. To provide for the required monitoring, ATM supports corresponding operation, administration and maintenance (OAM) functions which enable the end-to-end connection to be monitored. OAM functions for ATM (ATM OAM) are disclosed, for example, in ITU-T standard 1.610.
ATM is traditionally used as a Layer 2 protocol where Ethernet can then be transmitted via ATM. This means that Ethernet frames are segmented at the transmitter, packed into ATM cells and transmitted and are unpacked from the ATM cells at the receiver and assembled together to form Ethernet frames. In modern broadband networks, however, ATM is increasingly replaced by Ethernet or, respectively, new broadband access networks based on Ethernet are installed. Ethernet is then transmitted directly via Layer 1. This means that Ethernet frames are transmitted directly by means of the technology of the physical layer (e.g. DSL). There is no additional encapsulation into ATM cells. In the case where Ethernet is used on Layer 2, an end-to-end monitoring of the connection should still be possible. For this purpose, OAM functions for Ethernet (Ethernet OAM) have already been defined, for example in ITU-T Standard Y.1731 and IEEE Draft Standard 802.1ag. These provide for end-to-end monitoring on the Ethernet MAC layer (Layer 2).
In order to be able to use standardized Ethernet OAM functions, however, they need to be implemented in the client network access system and in the provider network access system. Whilst the network operator has full control over the provider network access system and can equip the latter correspondingly with OAM functions, the client network access system is normally in possession of the customer and can therefore not be easily exchanged and/or configured for Ethernet OAM. For this reason, there is a need to adapt the interface of a provider network access system to which a client network access system is connected to the configuration of the client network access system. For this purpose, the provider network access system must have knowledge about any support of Ethernet OAM provided by the client network access system.
From the Liaison Statement of ITU-T Q.5/13 to the DSL Forum of 24 Feb. 2006 “Reply Liaison Statement on Ethernet OAM functionality”, a method is known in which the provider network access system attempts to obtain knowledge about the support of Ethernet OAM by the client network access system by sending a multicast Ethernet Loopback Message (ETH-LBM) frame to the client network access system and evaluating the response of the client network access system. If the client network access system sends back an Ethernet Loopback Reply (ETH-LBR) frame, it obviously supports Ethernet OAM. If no ETH-LBR frame arrives within a certain time, Ethernet OAM is obviously not supported. The disadvantageous factor in this method is, however, that the ETH-LBR frame can also originate from another device located in the network of the customer instead of from the client network access device which possibly does not support Ethernet OAM. In this case, the provider network access system would obtain misleading information and draw from this a wrong conclusion. It is also possible that the special Layer-2 connection which is to be monitored with Ethernet OAM is faulty. In this case, it is also possible that the ETH-LBM and/or the ETH-LBR frames are not transmitted via the connection. Although the client network access system possibly supports Ethernet OAM, the provider network access system falsely assumes that it does not support the latter.
The present invention is based on the object of exchanging data between a client network access system and a provider network access system.
This object is achieved by the features specified in the independent claims. Advantageous embodiments of the invention are specified in further claims.
In this context, a message is sent from the provider network access system to the client network access system. The message uses in its destination MAC address field a multicast address which is not forwarded by the client network access system.
This means that a frame which is sent to this address is not forwarded by the client network access system. On the basis of the message, the client network access system sends a response which relates to an Ethernet OAM function. In a preferred embodiment, it can be found out in this manner whether the Ethernet OAM function is supported by the client network access system.
It is advantageous in this solution that, by using the multicast address which is not forwarded, the message of the provider network access system cannot be forwarded beyond the client network access system into the network of the customer. This ensures that devices in the network of the customer which are behind the client network access system cannot respond to the message with a response to the provider network access system and thus the provider network access system cannot draw a wrong conclusion with respect to the client network access system. In addition, the solution can be used with Ethernet OAM implementations according to ITU-T Standard Y.1731 and according to IEEE Draft Standard 802.1ag. It is also not necessary that the provider network access system knows the MAC address of the client network access system before sending the message because the message does not use a unicast MAC address but a multicast MAC address. Furthermore, the message and the response can still be transmitted even if the special Layer-2 connection to be monitored is faulty.
MAC addresses which are not forwarded by the client network access system are, for example, Slow Protocol Multicast Addresses (Annex 43B from IEEE Standard 802.3-2005) or Group MAC addresses (Table 7.10 and Chapter 7.12.6 from IEEE Standard 802.1D-2004).
Normally, a maximum of ten frames per second are sent for a Slow Protocol. However, several Slow Protocols can also run in parallel when the rate of frames per unit time is greater. In addition, frames of a Slow Protocol are untagged, i.e. the frames do not run in a VLAN. A Slow Protocol normally uses the value (Ethertype) “88-09” in the Length/Type Field of the Ethernet frame. The receiver recognizes from this value that the frame belongs to a Slow Protocol.
In an advantageous embodiment, the information contained in the response states whether an Ethernet OAM function is supported by the client network access system or not. If, for example, the client network access system is newly connected to an interface of the provider network access system, the provider network access system is informed in this way that the Ethernet OAM function is supported. As a consequence, the provider network access system can configure the interface for the Ethernet OAM function.
Since the response uses the source MAC address of the message in its destination MAC address field, the response can be transmitted directly to the provider network access system. As an alternative, the response, in order to be transmitted to the provider network access system, can also use in its destination MAC address field a multicast address which is not forwarded by the provider network access system.
By determining a Layer-2 protocol, which is used by the client network access system, preferably before sending the message or before sending the response, it is already possible to draw conclusions with respect to any support of Ethernet OAM by the client network access system. If, for example, the client network access system only supports ATM via the Layer 1, it can be concluded that Ethernet OAM is not supported by the client network access system.
By checking whether an Ethernet protocol is supported by the client network access system on Layer 2, especially whether Ethernet via ATM and/or whether Ethernet via Layer 1 is supported, it is possible to conclude that the possibility exists that Ethernet OAM is supported by the client network access system and that therefore a check whether Ethernet OAM is supported is appropriate.
In a preferred embodiment, the response contains information about several Ethernet OAM functions which are supported by the client network access system. In an especially preferred embodiment, the response contains information about all Ethernet OAM functions which are supported by the client network access system.
The response can be divided into several part-responses. For example, each part-response can contain a value “true” or “false”, the values specifying whether a particular Ethernet OAM function is supported by the client network access system.
Examples of Ethernet OAM functions are the Loopback protocol, the Linktrace protocol and the Continuity Check protocol, which are defined in ITU-T Y.1731 and IEEE 802.1ag. Other examples which are defined in ITU-T Y.1731 are the Ethernet Alarm Indication Signal protocol, the Ethernet Remote Defect Indication protocol, the Ethernet Locked Signal protocol, the Ethernet Test Signal protocol, the Ethernet Automatic Protection Switching protocol, the Ethernet Maintenance Communication Channel protocol, the Ethernet Experimental OAM protocol, the Ethernet Vendor Specific OAM protocol, the Frame Loss Measurement protocol, the Frame Delay Measurement protocol and the Throughput Measurement protocol.
According to a further aspect of the invention, a provider network access system is proposed which comprises means which are adapted to carrying out a method according to the invention.
In the text which follows, the invention will be explained in greater detail by way of example referring to the drawing, in which:
The message M preferably uses in a source MAC address field MS the MAC address of the provider network access system which is inserted into the destination MAC address field AD of the response A by the client network access system. The source MAC address field AS of the response preferably comprises the MAC address of the client network access system KM.
In an especially preferred embodiment, the response A comprises the information that the client network access system has implemented the Ethernet OAM function. This information is especially useful if the client network access system has been connected to the provider network access system PN immediately before the sending of the message because the provider network access system PN can be informed by this means that the provider interface PS to which the client network access system KN has been connected should be configured for the Ethernet OAM function.
In a further especially preferred embodiment, the message M comprises a write command and at least one value for a parameter which is adjusted in the client network access system KN. In this case, the response A contains a confirmation that the parameter has been adjusted. The written parameters can also be optionally supplied together with the response A.
In a further especially preferred embodiment, the message M comprises a read command. This is useful, for example, if the provider network access system must find out values of the parameters adjusted in the client network access system at the time. The parameters to be read are supplied together with the response.
The client network KNW comprises a client network access system which is constructed as network terminating device NT. The client network KNW can contain further devices which are connected to the network terminating device NT and are symbolized here by a terminal, for example a personal computer PC.
The provider network PNW uses Ethernet as Layer-2 technology. It can therefore be monitored by means of Ethernet OAM functions. This monitoring is designated as monitoring of the provider network UPN in
The monitoring messages can also be transmitted in the opposite direction from the access node AN to the broadband network gateway BNG. By this means, for example, the operation of the data transmission from AN to BNG is checked. It is also possible to monitor only individual subsections in this manner, for example the section from the broadband network gateway BNG to a network node located in the Ethernet aggregation network EAN.
In the text which follows, the network section from the access node AN to the network terminating device NT is called the subscriber interface TS. The subscriber interface TS can only be checked with Ethernet OAM functions if the network terminating device NT supports Ethernet OAM. Since this is possibly not known to the operator, however, it is either necessary to carry out a detection of the Ethernet OAM functionality in the network terminating device NT or to dispense with Ethernet OAM and to monitor this section with other methods. Commonly used methods for monitoring the subscriber interface TS are, for example, the monitoring by means of “Ethernet in the first mile” EFM OAM according to IEEE Standard 802.3-2005 and monitoring Layer 1, dispensing with monitoring of Layer 2. Although it is possible to check in the monitoring of the subscriber interface TS by means of EFM OAM whether Ethernet frames can be transmitted at all between access node AN and network terminating device NT, the possibility is lacking to check the logical channels individually within Layer 2. If, as an alternative, only Layer 1 of the subscriber interface is monitored and monitoring of Layer 2 is dispensed with, it is only possible to monitor whether the transmission technology is operating, i.e. whether information can be transmitted at all. It is not possible to monitor whether messages of the Layer-2 protocol used can be transmitted.
For this reason, the access node AN has a means for sending a message via the subscriber interface to the network terminating device NT. The message uses in its destination MAC address field a special multicast address on the basis of which the immediately nearest layer-2 device receives, but does not forward, the message. An example of such a special multicast address is, for example, a Slow Protocol multicast address. The message also contains the request to send an answer which provides information as to whether the network terminating device NT has implemented Ethernet OAM, back to the access node AN. The message can be triggered autonomously by the access node or on command of a network management system MGMT. If the network terminating device NT has implemented Ethernet OAM, it will understand the request and send a confirmatory response. If it has not implemented the Ethernet OAM function, it will either understand the request and send a negative response or it will not understand the request and will not send a response. Using the special multicast address devices which are behind the network terminating device NT in the client network are prevented from sending a wrong response to the access node AN. As a result, the access node AN is able to reliably assess whether it can monitor the monitoring section UTS by means of Ethernet OAM up to the network terminating device NT. Such an automatic determination is useful, especially if the network terminating device NT is newly connected to the access node AN. For this purpose, it can be provided that the access node AN repeatedly sends the message to the special multicast address at predefined time intervals.
As a consequence, the subscriber interface TS can be monitored by means of Ethernet OAM. All subsections between the network terminating device NT and the broadband network gateway BNG would therefore be monitored: between the network terminating device NT and the access node AN, on the one hand, and between the access node AN and the broadband network gateway BNG, on the other hand. However, a fault could now still occur within the access node AN which would not be recognized since one monitoring section would already be finished but the next one would not have begun yet.
In a further preferred embodiment, it is therefore desirable to introduce a genuine end-to-end monitoring ETE in which monitoring messages are sent from the BNG through all network nodes up to the NT and from the NT through all network nodes back to the BNG. This is possible, for example, by the network terminating device NT writing its own MAC address into the source MAC address field. As a consequence, this is forwarded, together with the information that the network terminating device NT has implemented the Ethernet OAM function, to the broadband network gateway BNG. Conversely, the broadband network gateway BNG can subsequently transmit its own MAC address with a message addressed to the network terminating device NT. This creates the prerequisites for monitoring messages to be selectively sent between the network terminating device NT and the broadband network gateway BNG as a result of which the complete path from the BNG to the NT can be monitored by means of Ethernet OAM functions. This monitoring is indicated by an Ethernet loopback message frame ETH-LBM which is sent from the BNG to the NT and which is answered with an Ethernet Loopback reply frame ETH-LBR from the NT to the BNG. The monitoring therefore represents an end-to-end monitoring ETE.
Since, on the other hand, the Layer-2 technology in the provider network is Ethernet, the provider network can be monitored by means of Ethernet OAM functions. End-to-end monitoring only possible in a restricted way because the messages which are used by Ethernet OAM functions for monitoring the provider network must be translated in the AN into such messages as are used by the ATM OAM functions for monitoring. In this context, a part of the information can be lost. For example, the Ethernet loopback message frame ETH-LBM sent by the BNG to the AN is converted into one or more ATM loopback message cells ATM-LBM in the AN and sent to the NT. The NT responds to the incoming ATM loopback cell with a further ATM loopback reply cell ATM-LBR which it sends back to the access node AN. Following the reception of the ATM loopback reply cell ATM-LBR, the access node AN generates an Ethernet loopback reply frame ETH-LBR which it sends back to the BNG. From the received ETH-LBR frame, it is possible to conclude that the data transmission from the BNG up to the NT and from the NT up to the BNG is working.
In a special embodiment which is independent of the previously described embodiments, the network management system MGMT sends a request to the access node AN to send a message which contains a write or read command to the network terminating device NT. The request contains, for example, the information whether the message should contain a write command or a read command. In the case of a write command, the request additionally contains, for example, information about one or more parameters to be written and, for example, their values. In the case of a read command, the request contains additional information about one or more parameters to be read. The information which is contained in the response of the network terminating device NT, for example the read values of the parameter or parameters in the case of a read command and, for example, a confirmation in the case of a write command, is sent to the network management network MGMT from the access node AN.
The present invention is independent of what Layer-1 technology is used. For an access network, DSL (digital subscriber line) or PON (passive optical network) can be used at Layer 1, for example.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2006 055 959.2 | Nov 2006 | DE | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP2007/010006 | 11/20/2007 | WO | 00 | 5/18/2009 |
