CN100492987C - Domain Configuration in Ethernet Operations Management Maintenance Networks with Multiple Levels - Google Patents

Abstract

The present invention provides a domain configuration system and method operable in an Ethernet OAM network having multiple levels of OAM domains. A port of a first end bridge of the network is configured as a first MEP node belonging to a predetermined OAM domain having a particular level. GARP or CC frames are transmitted from the first MEP node in a forward attribute registration process towards the remaining bridges of the network. A port of a second end bridge of the network is configured as a second MEP node of the predetermined OAM domain. In a backward attribute registration process, GARP or CC frames are transmitted from the second MEP node towards the remaining bridges of the network. Responsive to the frame flow, ports in bridges disposed between the first and second end bridges are automatically configured as MIP nodes having the particular level.

Description

Domain Configuration in Ethernet Operations Management Maintenance Networks with Multiple Levels

Cross References to Related Applications

This non-provisional application claims priority based on the following earlier U.S. Provisional Patent Application: (i) filed on July 8, 2004 in the names of David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten PetrusJoseph Vissers and Tony Van Kerckhove The application number is 60/586,248 "OAM DOMAIN CONFIGURATIONUSING GARP (GENERICOAM REGISTRATION PROTOCOL-GORP)" (OAM domain configuration using GARP (General OAM Registration Protocol-GORP)). The content of which is hereby incorporated by reference into the application.

The subject matter disclosed in this application is related to that disclosed in the following commonly owned pending patent applications: (i) filed December 28, 2004 in the names of David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Petrus Joseph Vissers and Tony Van Kerckhove Application No. 11/023,784 "ALARM INDICATION ANDSUPPRESSION (AIS) MECHANISM IN AN ETHERNET OAM NETWORK" (Alarm Indication and Suppression (AIS) Mechanism in Ethernet OAM Network); and (ii) by David Elie-Dit-Cosaque, Application No. 11/020,898, Attorney File No. 1285-0150US, filed December 22, 2004 in the names of Kamakshi Sridhar, Maarten Vissers and Tony Van Kerckhove, "AUTOCONFIGURATION OF ETHERNET OAM POINTS" ). The contents of these patent applications are hereby incorporated by reference into the present application.

technical field

The present invention generally relates to Ethernet OAM networks. More specifically, and without any limitation, the present invention focuses on systems and methods for configuring OAM domains in an Ethernet OAM network with multiple levels.

Background technique

In order to adapt the well-known Ethernet technology to a carrier-class service environment, various standards have been developed with the goal of providing improved operations, administration and maintenance (OAM) capabilities (also referred to as Ethernet Network Connectivity and Fault Management or Ethernet CFM). Since an end-to-end service network environment typically includes a wide variety of different component networks (such as metro access and core networks using various technologies), possibly belonging to different organizations, network operators and service providers, The Ethernet OAM plane is therefore viewed as a hierarchical and layered domain space, in which specific OAM domains are defined corresponding to constituent network infrastructure and settings. In particular, two specifications, IEEE 802.1ag and ITU-T (Issue 3, Study Group 13), incorporated herein by reference specifically focusing on end-to-end Ethernet OAM, define user-level domains at the highest level of the hierarchy, which Consists of one or more Provider Domains (occupying an intermediate level), each Provider Domain in turn comprises one or more Operator Domains deployed at lower levels of the hierarchy. By means of normalization, the OAM domain space can be divided into multiple levels, for example, 8 levels, and each domain corresponds to a specific level, wherein the domain is defined according to a flow point. In the context of the IEEE 802 series of specifications, a flow point is a new entity included in the Media Access Control (MAC) "interface" and "port" defined in the relevant standards document. Traffic points at the edge of an OAM domain are called "maintenance endpoints" or MEPs. A traffic point within a domain and visible to a MEP is called a "Maintenance Intermediate Point" or MIP. While system administrators use MEP nodes to initiate and monitor OAM activity (by issuing appropriate OAM frames), MIP nodes passively receive and respond to OAM flows initiated by MEP nodes. An OAM domain with one or more MIP nodes is bound by two or more MEP nodes, where a "Maintenance Entity" (ME) is defined to include a set of MIP nodes deployed between one MEP node and another MEP node . Therefore, there can be more than one ME in a particular OAM domain.

In order to properly filter OAM frame streams so that these frame streams are only processed by the intended domain nodes, it is necessary to properly configure the MEP/MIP family of the Ethernet OAM network. According to the current standard, absolute OAM level encodings use integer values to represent specific domain levels. Furthermore, each MIP node of a given layer must be manually configured at its domain level in order to support correct OAM operation. However, especially in networks with many stages and a large number of MIP nodes, manual configuration is time-consuming and error-prone. If for any reason the wrong domain level is misconfigured for a MIP node, or if a MEP node fails, there is a potential for security breaches due to leakage of OAM frames between domains.

Contents of the invention

In one aspect, the present invention discloses a domain configuration system and method for an Ethernet OAM network with multi-level OAM domains. A port of a first end bridge of the network is configured to belong to a first MEP node of a predetermined OAM domain with a specific level. During the forward attribute registration process, a GARP or CC frame is sent from the first MEP node to the remaining bridges in the network. A port of the second end bridge of the network is configured as the second MEP node of the predetermined OAM domain. During the backward attribute registration process, a GARP or CC frame is sent from the second MEP node to the remaining bridges in the network. In response to the stream of frames, ports in bridges deployed between the first end bridge and the second end bridge are automatically configured as MIP nodes with a particular class.

On the other hand, the present invention focuses on network bridge entities operable in Ethernet with multi-level OAM domains. Also included within the bridge is means for configuring the associated port as a MEP node belonging to a predetermined OAM domain with a particular class. Also included is means for generating a set of GARP or CC frames for sending from the port to the remaining ports of the network bridge entity during attribute registration. When using GARP frames, OAM level information is provided as attribute values. Optionally, if CC frames are used, class information about the specific class is included in the OAM class field.

Description of drawings

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate one or more presently preferred exemplary embodiments of the invention. Various advantages and features of the present invention can be understood from the following detailed description in relation to the appended claims and with reference to the accompanying drawings, in which:

Fig. 1 has described the embodiment that has the end-to-end Ethernet OAM network of a plurality of OAM domains;

Figure 2 depicts an exemplary hierarchical OAM layering scheme operable with respect to end-to-end Ethernet;

FIG. 3 has described an exemplary embodiment of an OAM domain bound by a pair of MEP nodes;

Fig. 4 is a flow chart of a configuration method for configuring an OAM domain in a multi-level Ethernet according to an embodiment of the present invention;

FIG. 5 depicts an exemplary GARP frame structure used in the domain configuration scheme of the present invention according to one embodiment;

Fig. 6 is the flowchart of an embodiment of the domain configuration method that adopts GARP frame;

7A and 7B illustrate an embodiment of a GARP-based domain configuration method in an exemplary Ethernet network with multiple bridges;

FIG. 8 depicts an exemplary CC frame structure used in the domain configuration scheme of the present invention according to another embodiment;

FIG. 9 depicts a flowchart of one embodiment of a domain configuration method using CC frames.

Figures 10A and 10B illustrate one embodiment of a CC-based domain configuration method in an exemplary Ethernet network with multiple bridges; and

11A and 11B show the steps of class allocation for MIP nodes in the domain configuration scheme of the present invention.

Detailed ways

Embodiments of the invention will now be described with reference to various examples of how the invention is best made and used. Like reference numerals are used to designate like or corresponding parts throughout the specification and several views of the drawings, wherein the various elements are not necessarily drawn to scale. Referring now to the accompanying drawings, and more specifically to FIG. 1 , shown in the figure is an embodiment of an end-to-end Ethernet OAM network 100 having a plurality of OAM domains, wherein a domain configuration scheme may be provided according to an aspect of the present invention . As shown, the Ethernet OAM network 100 comprises a hierarchical and layered network environment comprising a first customer premises network 102A and a second customer premises network 102B forming part of its terminations, which in turn are connected to the core by respective access networks 106A and 106B transmission network 108 . While a single service provider may manage the setup of an end-to-end service between two users, in practice one or more operators may be involved in providing and maintaining the underlying network infrastructure. Accordingly, the access network and core network may include a variety of different networks, transport technologies, and protocols for enabling end-to-end Carrier Ethernet services between end-user network 102A and end-user network 102B. For example, these different technologies may include Ethernet over SONET/SDH, Ethernet over ATM, Ethernet over Resilient Packet Ring (RPR), Ethernet over Multiprotocol Label Switching (MPLS), Ethernet over Internet Protocol (IP) Ethernet, etc.

The different network parts of the Ethernet OAM network 100 and its constituent segments are interconnected using appropriate forwarding entities such as bridges and switches. According to the illustration, the entity 111, the entity 110 and the entity 120, the entity 121 are examples of user equipment deployed in the respective user network 102A and user network 102B. Similarly, entities 112 and 118 of access network 106A and access network 106B are operable to interface with respective user equipment 110 and user equipment 120 . The interfaces between the access network 106A, the access network 106B and the core network 108 are respectively realized by the entity 114 and the entity 116 . In addition to interface entities, a particular network may include a number of additional entities within the network. For example, entity 115, entity 117, and entity 119 are exemplary devices in core network 108 in which point-to-multipoint operation may be implemented.

As mentioned in the "Background" section of this patent application, the Ethernet OAM architecture of a hierarchical end-to-end carrier-level Ethernet service network such as Ethernet 100 is logically divided into domain-level Multiple OAM domains for the specified hierarchy. Regarding the Ethernet OAM network 100 of FIG. 1 , an example of a user domain 103, a provider domain 105, and one or more operator domains 107A-107C is given, each of which is bound by multiple MEP nodes and includes Configure one or more MIP nodes between these nodes. MEP nodes are operable to initiate various OAM commands and associated frames, such as Continuity Check (CC), TraceRoute (TraceRoute), Ping, etc., while MIP nodes passively receive and respond based on domain-level compatibility for incoming OAM frames.

Those of ordinary skill in the art should realize that, utilizing MEP and MIP setting, can realize the static division of Ethernet OAM network, so MEP node can delineate the boundary of disjoint Ethernet domain, so that reduce OAM frame from one domain to another domain leakage. That is, OAM frames intended for one domain must remain processed in that domain, while all other OAM frames are filtered out. In addition, MEP and MIP nodes can be set in the Ethernet OAM network, so that multiple easy-to-manage maintenance entity (ME) domains can be defined according to business and service models and deployment environments. Due to the hierarchical arrangement of OAM domains, user-level domains are deployed at a higher level in the hierarchy than service provider domains, which in turn are deployed at higher levels than operator-level domains. Therefore, in terms of visibility and knowability, carrier-level domains have higher OAM visibility than service provider-level domains, which in turn have higher visibility than user-level domains sex. Therefore, although the operator OAM domain knows both the service provider domain and the user domain, it is not the other way around. Similarly, the service provider domain knows about the user domain, but not vice versa.

As described in the IEEE 802.1ag specification document referenced above, various rules govern the processing of an Ethernet packet/frame as it moves from one domain level to another. A MEP node is operable to distribute OAM frames to all other MEP nodes on that level/OAM domain, whereas a MIP node can only interact with the MEP nodes of its domain. Each MIP node on a higher domain level can also operate as a MEP node for the next hierarchical level below. Therefore, a single forwarding entity device (such as a bridge) may have different levels of MIP and MEP nodes at the same time. Frames on a given level i, i = 1, 2, . . . , N are still at that level since the OAM streams are not bound. The class of the OAM frame is encoded according to the domain class assigned to the MEP node originating the OAM frame. In addition, MIP/MEP nodes at the same level process or drop OAM frames: (i) when the OAM frame is initiated from outside the immediate OAM domain, drop the OAM frame; and (ii) when the OAM frame is When initiated within the immediate OAM domain, the OAM frame is processed. Due to the hierarchical nature of OAM visibility, frames from lower-level maintenance domains (eg, operators) are transparently relayed by MEP/MIP nodes deployed at higher-level domains (eg, subscribers). On the other hand, OAM frames of higher domains (eg, frames initiated by user-level MEP nodes) are usually processed by lower-level MEP/MIP nodes (eg, operator-level nodes).

FIG. 2 depicts an exemplary hierarchical OAM layering scheme 200 operable with respect to end-to-end Ethernet, such as the network 100 in FIG. The forwarding entity of the MIP/MEP node. Reference numeral 202-1 and reference numeral 202-9 refer to user network bridge devices deployed at both ends of the network. Deploying two operator networks operator-A and operator-B between the user equipment 202-1 and the user equipment 202-9, wherein the operator-A network includes a network bridge 202-2 to a network bridge 202-4, And the Carrier-B network includes bridge 202-5 to bridge 202-9. At the user level, the OAM domain is bound by the MEP node 204-1 and the MEP node 204-2 implemented on the user network bridge device 202-1 and the user network bridge device 202-9 respectively, and the OAM domain includes the operator- Two MIP nodes 206-1 and 206-2 are implemented on the A bridge 202-2 and the Carrier-B bridge 202-8. Deployed below user-level MIP node 206-1 and user-level MIP node 206-2 are two MEP nodes 208- 1 and MEP node 208-2, which binds the service provider level OAM domain. In this domain, a MIP node 210-1 implemented on a Carrier-A bridge 202-4 interfaces with another MIP node 210-2 implemented on a Carrier-B bridge 202-5. Two carrier-level domains are defined to correspond to two carrier networks, where carrier-level MEP node 212-1 (implemented on carrier-A bridge 202-2) and carrier-level MEP node 212-2 (implemented on Carrier-A Bridge 202-4) binds a Carrier-Level Domain, and Carrier-Level MEP Node 216-1 (implemented on Carrier-B Bridge 202-5) and Carrier-Level MEP Node 216-2 (implemented on Carrier-B bridge 202-8) binds another carrier domain. In addition, MIP nodes 214-1 to 214-4 are deployed in a carrier-level domain defined by MEP nodes 212-1 and MEP nodes 212-2, wherein bridge 202-2 implements MIP nodes 214-1, Bridge 202-3 implements MIP node 214-2 and MIP node 214-3 and bridge 202-4 implements MIP node 214-4. Similarly, MIP node 218-1 through MIP node 218-6 are deployed in a carrier-grade domain defined by MEP node 216-1 and MEP node 216-2, where bridge 202-5 implements MIP node 218- 1. Bridge 202-6 implements MIP node 218-2 and MIP node 218-3, bridge 202-7 implements MIP node 218-4 and MIP node 218-5, and finally bridge 202-8 implements MIP node 218- 6.

Based on the foregoing discussion, it is obvious that a single network entity can be operable to implement one or more MIP/MEP nodes at different levels according to its configuration and OAM service settings. Through the illustration, it can be seen that the bridge entity 202-2 implements the user-level MIP node 206-1, the service provider-level MEP node 208-1, the operator-level MEP node 212-1, and the operator-level MIP node 214-2 processing and logic. Thus, the physical devices of Ethernet represent flat, "vertically-compressed" layers that can be logically extended into multiple hierarchical levels, where at any level the OAM domain can be abstracted as A concatenation of multiple MIP nodes bound to a MEP node. Basically, FIG. 3 depicts such an exemplary embodiment of an OAM domain 300 comprising a MIP node 304-1 to a MIP node 304-N bound by a pair of MEP nodes 302-1 and 302-2, representing A special case of point-to-point operation. It should be appreciated that in the point-to-multipoint case, more than two MEPs are provided to bind one OAM domain (eg as seen in core network portion 108 of Figure 1).

As mentioned above, MEP nodes are operable to initiate various OAM frames that can be used to implement OAM service functions such as discovery, connectivity confirmation, latency/loss rate measurement, delay variation measurement, etc. in end-to-end Ethernet . In general, OAM frames are issued on a per-Ethernet Virtual Connection (per-EVC) basis, and OAM frames are treated as user data frames, but by employing (i) certain predetermined multicast addresses for OAM discovery and (ii) Certain predetermined EtherTypes (EtherType) used for OAM to distinguish OAM frames. Also, due to the nature of Ethernet as a connectionless transport technology that can send packets to different entities in the network that do not need or should receive them (for example, when the MAC address is unknown), domain-based OAM Barriers or filters are also coded into it. Additional details on the Ethernet OAM hierarchy and OAM domain levels can be found in the following co-pending commonly assigned US patent applications: (i) by David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Petrus Joseph Vissers and Tony Van Kerckhove "ALARM INDICATION AND SUPPRESSION (AIS) MECHANISM IN AN ETHERNET OAM NETWORK" (Alarm Indication and Suppression (AIS) Mechanism in Ethernet OAM Networks) in the name of Application No. 11/023,784, filed December 28, 2004; and (ii ) in the name of David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Vissers and Tony Van Kerckhove, Application No. 11/020,898, filed December 22, 2004 for "AUTOCONFIGURATION OF ETHERNET OAMPOINTS" . These patent applications cited herein are incorporated by reference into this application.

Fig. 4 is a flowchart of a general configuration method for configuring an OAM domain in a multi-level Ethernet with multiple bridge entities according to an embodiment of the present invention. In block 402, a first MEP node is configured on a port of a stub bridge of the network, wherein the network administrator preferably manually configures the first MEP node to belong to a predetermined OAM domain with a specific level (e.g. user level domains, provider-grade domains, or carrier-grade domains, etc.). Frame streaming is effected in a first direction (eg, from a first MEP node) for sending OAM level information in the network (block 404). Then, a second MEP node with a particular class is configured on a port belonging to a second stub bridge of the network (block 406). Frame streaming is effected in a second direction (eg, from a second MEP node) for sending OAM level information in the network (block 408). In response to the frame flow, one or more ports of the intermediate bridge are automatically configured as MIP nodes deployed between the first and second MEP nodes, wherein based on the class information carried in the bidirectional frame flow, for these MIP nodes The node assigns an OAM class (block 410). According to the description of the present invention, for domain configuration, frames operable to carry OAM-level information may include Generic Attribute Registration Protocol (GARP) frames (thus requiring the functionality of the GARP state machine engine at the bridge) or include a separate CC frame of the OAM level field. Additionally, the MEP nodes may be configured together before starting frame flow in either direction for sending OAM level information. These embodiments will now be set forth in more detail below.

As is well known, GARP provides a generic attribute distribution capability whereby devices in a bridge-based network, ie, end stations and bridges (or switches, synonymously), can register and de-register attribute values with each other. By doing so, attributes are propagated to devices in the network such that registered devices form a reachable tree structure, which is a subset of the valid topology. GARP, which forms part of the IEEE 802.1p extension to its 802.1d (Spanning Tree) specification, defines the architecture, operating rules, state machines and variables for registering and deregistering attribute values. Generally, a GARP participant in a bridge includes a GARP application component and a GARP Information Declaration (GID) component associated with each port of the bridge. Propagation of information between GARP participants for the same application in the bridge is performed by the GARP Information Propagation (GIP) component. Protocol exchanges between GARP participants take place over Logical Link Control (LLC) Type 1 services using the group MAC address and protocol data unit (PDU) format defined for the GARP application involved.

According to the description of the present invention, for domain configuration, OAM level information is provided as an attribute value for propagation in an Ethernet OAM network. In the context of the present invention, domain configuration preferably includes the following operations: (i) automatic configuration of intermediate OAM traffic points (i.e. specific OAM-level attributes of domain's MIP nodes); (ii) placing MIP; and (iii) placing automatic MEP nodes or A-MEP nodes on the boundaries of domains to avoid frame leakage.

FIG. 5 depicts an exemplary GARP frame structure used in the domain configuration scheme of the present invention according to one embodiment. Reference numeral 500 refers to a GARP PDU frame having N octets for carrying a plurality of messages 512-1 through 512-N. The 2-byte protocol ID 510 identifies the GARP protocol. An end marker field 516 is provided as a GARP PDU frame 500 boundary. In one implementation, a unique ID field 514 is provided for distinguishing frames from two different domains in order to avoid potential failures caused by a failed border MEP. It is well known that if a border MEP in any domain fails, such failure will make the network potentially vulnerable to security breaches (due to frame leaks). For example, on a network-to-network interface (NNI) between two operators, if a MEP node bound to two different , would mistakenly merge two separate operator domains to form a single domain without alerting the network management system. Therefore, the Unique ID field 514, similar to the 32-bit UUCSIID identifier in an 802.1ag CC frame, is used to uniquely identify a globally-recognized Service Instance, thereby providing a reliable way to determine whether a GARP frame is in Whether it is initiated within the operator's domain or initiated outside the operator's domain. If the frame is externally generated, the unique ID value 514 in the frame will not match the value associated with the operator, which will cause the external frame to be discarded. Eventually, an alert can be propagated to network management to indicate that a leak has occurred in the domain.

Continuing to refer to FIG. 5, reference numeral 502 refers to a separate message structure having multiple octets with a 1-byte attribute type field 518 and an attribute list field 520 containing a plurality of attributes. Attribute type 518 is operable to define attributes such as group attributes or service requirement attributes. An exemplary attribute list structure 504 having K octets is shown as M attributes 522-1 through 522-M. An end tag field 524 may again be provided as a boundary for the property list structure 504 . The 3-octet attribute structure 508 includes an attribute length field 526 , an attribute event field 528 , and an attribute value field 530 . Attribute length 526 defines the length of a particular attribute. Attribute event 528 has defined a plurality of GARP operators, is used for realizing various GARP operations: [0] represents Leave_All operator (for example, is used to unregister an attribute); [1] represents Join_Empty operator; [2] represents Join_In operation [3] indicates the Leave_Empty operator; [4] indicates the Leave_In operator; and [5] indicates the Empty operator. Attribute values 530 include OAM domain-level values configured for a particular domain in Ethernet.

Referring now to FIG. 6, there is shown a flowchart of one embodiment of a domain configuration method using GARP frames. Basically, the general approach consists in implementing GARP in an OAM configuration application for defining the scope and boundaries of a predetermined OAM domain and assigning a specific OAM class to the nodes included in this domain. The following situations are something to be aware of in the exemplary implementation in a typical domain deployment scenario:

- Two types of traffic points that need to be configured: MIP and MEP.

- A single responsible person (i.e. network administrator) understands where the edge of a particular domain will be located. Configure the ports that will be identified as edge ports as MEP nodes.

- By way of example, on each domain level there may be only one administrator configuring MEP nodes at that level. In addition, an administrator may operate to manually configure MEP nodes for a certain class, ie assign a particular OAM class to a MEP node and determine its MEID. In general, there is no need for interaction between administrators.

- When an administrator activates MEP functionality on an edge bridge (ie, a bridge with edge ports), it also activates its associated GARP state machine engine for sending GARP frames as part of the attribute registration process. After the MEP nodes are configured, the intermediate MIP nodes need to be automatically configured.

To illustrate the disclosure of this patent, the aforementioned implementation framework is now used as a background, and a GARP-based OAM registration protocol, which may be called the General OAM Registration Protocol (GORP), is described below. When a port of a first end bridge deployed in the network is configured as a first MEP node of a certain level (e.g., level X) with a predetermined domain (block 602), the GARP associated with the end bridge The State Machine Engine (SME) generates GARP frames for sending in the forward attribute registration process to the remaining ports of the end bridge that declare (D) as nodes with the same OAM class (class X). Likewise, GARP frames carrying OAM-level information are propagated from the first end bridge to the next bridge to which it is coupled via physical links (ie, via inter-bridge links). When a port on the next bridge receives a GARP frame carrying the value of the OAM class over the link, the port registers (R) the value of the port's class. The receiving bridge's GARP state machine logic then declares (D) the OAM-level attribute values on the bridge's remaining ports. This process continues until the second end bridge of the domain is reached, thereby registering (when a GARP frame is received over a physical link) or declaring (when a GARP frame is received over a bridge structure) the ports of other bridge entities of the domain frame time) as part of the forward attribute registration process (block 604). In block 606, a port of the second stub bridge is configured (eg, manually configured) to belong to a second MEP node of a predetermined OAM domain having a particular OAM class (ie, class X). Then, in response thereto, start another attribute registration process in the opposite direction from the second MEP node to the remaining ports of the second end bridge and the remaining second end bridges of the OAM domain, thereby registering again (R) Or declare (D) these ports (block 608). Intermediate ports in different bridges between the first end bridge and the second end bridge will be deployed if the ports are both declared (D) and registered (R) during the forward and backward attribute registration process Automatically configured as a MIP node of a particular OAM class (ie class X) of a ME defined by the first and second MEP nodes of the OAM domain. In other words, after implementing the attribute registration process, the D and R cases or the intermediate ports of the R and D cases are configured as MIP nodes with the selected OAM level (block 610). Additionally, as part of GARP's excerpt method, ports can be automatically configured that certain ports of the domain are configured as border nodes capable of filtering OAM frames. Therefore, only bridges (i.e. MIP nodes) that are declared in the registration process of both attributes (i.e. ports designated as DD) and belong to a port designated as DR/RD can be automatically configured with the defined ME MEPs with a reduced set of capabilities (ie, automatic MEPs or A-MEPs) compared to the full MEP nodes of MEP (block 612). Although the A-MEP node cannot initiate any OAM business like a complete MEP, its filtering function is operable to prevent OAM frames from entering or leaving the OAM domain.

7A and 7B illustrate one embodiment of a GARP-based domain configuration method in an exemplary Ethernet network 700 with multiple bridges. Reference numerals 702-1 to 702-7 refer to the seven bridges of the network 700 on which a particular domain will be configured, each bridge having a corresponding GARP state machine 704-i, i=1, 2, .. ., 7. The MEP node is manually configured on Port 1 (ie P1 ) of Bridge 1 (B1 ) 702-1 to belong to a predetermined OAM domain with a specific OAM level (ie Level 1). Therefore, P1 of the first stub bridge B1702-1 is declared (D) as a node with level 1 . In response thereto, its associated GARP state machine engine 704-1 facilitates the sending of GARP frames 706 that include OAM level information as attribute values. In one implementation, such GARP frames may be intermittently multicast over the network. It has been pointed out earlier that when a GARP frame is received through the bridge structure, the receiving port is declared with respect to the attribute value. Therefore, the remaining ports of bridge 702-1, ie, P2 to P4, are declared (D) as nodes with OAM level 1 . When P3 of Bridge 2 (B2) 702-2 receives a GARP frame 706 over the physical link, it triggers the registration and registers (R) the port accordingly. Afterwards, GARP SME 704-2 associated with bridge 702-2 facilitates the multicast transmission of GARP frame 708, disseminating GARP frame 708 to the remaining ports (P1, P2, and P4) and to the next bridge, namely B3 704- 3 on. The attribute registration process is performed in a similar manner through the rest of the network 700 until the end bridge B7 702-7 is reached.

In FIG. 7B, the backward attribute registration process is shown, which is initiated by configuring P1 of B7 702-7 (i.e., the second end bridge) as the second MEP node of the domain with OAM level 1 process. In response, another set of GARP frames (exemplified by frames 720, 722, 724, and 726) are concatenated through network 700 until frame 726 reaches B1 702-1. Similar to the above process, except for the previous declaration/registration, also declare (D) or register (R) each port in the network. Therefore, after performing the attribute registration process, configure port P1 of B1 702-1 and B7 702-7 as two MEP nodes, and the remaining ports of network 700 are designated as DR/RD or designated as DD. Ports that have both declared and registered (DR or RD) are automatically configured as MIP nodes of OAM level 1. In the network 700, these ports include P2 and P3 of B2 702-2, and P1 of B3 702-3 and P4, and P1 and P4 of B5 702-5. In addition, in bridge OAM that includes DR/RD ports, configure ports that are only declared (that is, designated as DD (or simply designated as D)) during the registration process of the two attributes as A- MEP nodes. Thus, in the network 700 shown, A-MEP nodes are configured on P1 and P4 of B2 702-2, P2 and P3 of B3 702-3, and P2 and P3 of B5 702-5. Ports not participating in the configured domain can be deregistered by periodically sending (for example, sending once every 10-15 seconds) a GARP message with a Leave_All attribute event. Such a message is operable to forcefully refresh the registration status of a port that is not going to deregister its attributes (ie OAM level) by sending a GARP frame (Join message). A node intending to deregister does not send a Join message frame, and thus is removed from the domain defined by GARP.

FIG. 8 depicts an exemplary CC frame structure 800 used in one embodiment of the domain configuration scheme of the present invention. Various fields are provided such as destination MAC address 802 and source MAC address 804, virtual LAN (VLAN) ethertype 806, VLAN tag 808, OAM ethertype 810, and OAM level field 812, as well as version field 814 and reserved field 816. Therefore, although fields such as a preamble field, a postamble field, a cyclic redundancy check (CRC) field, a UUCSI ID identifier field, etc. are not shown in FIG. 8 , these fields may also be included in the CC frame 800 . An opcode 818 and a number of opcode-specific optional Type Length Value (TLV) fields 820 are included in the CC frame 800 for providing additional information. As can be seen in more detail below, the OAM-level information in CC frames can be used in a domain configuration scheme similar to the GARP-based GORP scheme described above. Those of ordinary skill in the art will recognize that while the GORP scheme requires the instantiation of a GARP state machine on each network bridge, in a CC-based domain configuration system for additional functionality on 802.1ag-compliant bridges, there is no special request.

FIG. 9 depicts a flowchart of one embodiment of a domain configuration method using CC frames. Similar to the aforementioned GORP scheme, a port of a first stub bridge is configured by an administrator as a first MEP node of a predetermined OAM domain with a particular class (ie, class X) (block 902). Thereafter, the first MEP node periodically issues CC frames to the remaining ports of the first stub bridge and the remaining bridge entities of the network, with the specific OAM class included in the CC frames (block 904). Similar to the attribute registration process in GORP, the network port is declared (D) if the CC frame is received via a bridge structure, or the network port if the CC frame is received over a physical link port to register (R). Then, a port of the second stub bridge is configured to belong to a second MEP node of the OAM domain with the same level (ie, level X) (block 906), and the second MEP node starts to pass traffic generated by the second MEP The backward attribute registration process implemented by CC flow. Accordingly, CC frames are periodically issued to the remaining ports of the second end bridge and to the remaining bridge entities of the network, in which the OAM level information is encoded (block 908). In response to this, the ports are declared or registered again such that the intermediate ports are in DD or RD/DR condition. Assuming these ports are both declared and registered during the forward and backward CC flows between MEP nodes, then the stub ports, which have been configured as two MEP nodes, will be deployed between the two stub bridges The ports of the different bridges of t are automatically configured as MIP nodes with a particular OAM class (class X) (block 910). Similar to the aforementioned GORP scheme, the port designated as DR or RD is again configured as the MIP node of the domain accordingly. In addition, similar to the GARP excerpt, a port in a bridge containing a DR/RD port may be automatically configured as an A-MEP node if only declared during the CC flow (block 912).

10A and 10B illustrate one embodiment of a CC-based domain configuration method in an exemplary Ethernet network 1000 having multiple bridges B1 1002-1 through 1002-7. Those of ordinary skill in the art should appreciate that the CC-based domain configuration scheme is substantially similar to the GORP scheme for network 700 in FIGS. 7A and 7B . As an alternative to GARP frames issued during attribute registration, multiple CC frames are provided, such as CC frame 1004 in FIG. 10A for forward CC flows (i.e., from bridge B1 1002-1 to bridge B7 1002-7 and CC frame 1006 in FIG. 10B for backward CC flow (i.e. from bridge B7 1002-7 to bridge B1 1002-1) to propagate OAM level information. Also, as previously mentioned, generating CC frames does not require any separate state machine functionality. However, it should be appreciated that in each of the domain configuration embodiments, the assignment of forward and backward directions is entirely arbitrary, and therefore, this assignment has nothing to do with which end bridge the MEP node is configured for first or in which direction first. Initiating frame flow is irrelevant. In any case, when attribute registration is achieved in both directions, the CC-based configuration scheme proposes to configure port P1 of B1 1002-1 and B7 1002-7 as two MEP nodes of the domain being established in network 1000 , and the remaining ports in network 1000 are either designated as DR/RD or designated as DD. Similar to the GORP scheme, ports that have both declared and registered (DR or RD) are automatically configured as MIP nodes of OAM level 1. In network 1000, these ports include P2, P3, and B3 of B2 1002-2 P1 and P4 of 1002-3, and P1 and P4 of B5 1002-5. Also, in bridges containing DR/RD ports, configure ports that are only declared (i.e. designated as DD (or simply D)) during registration of both attributes as A-MEPs at OAM level 1 node. Thus, in the network 1000 shown, A-MEP nodes are configured on P1 and P4 of B2 1002-2, P2 and P3 of B3 1002-3, and P2 and P3 of B5 1002-5. Similar to configuring A-MEP nodes in the GORP scheme, A-MEP nodes created under the CC-based configuration scheme also have a reduced capability set compared to full MEP nodes.

It will be recalled that, unlike GARP, CC frames are sent continuously in the network. Therefore, there is a periodic replenishment of registration and declaration of attribute values, ie, OAM-level values. As a result, CC frame loss is operable to trigger de-registration of attributes. For the probability of domain merging on the NNI between two operators, if an A-MEP node or MEP node fails at the border, the UUCSIID field in the CC frame provides a reliable way to determine whether the CC frame originated from a specific operator. Thus, an operator receiving a leaked CC frame from a neighboring operator avoids processing the CC frame as its own.

Regardless of implementing a CC-based domain configuration scheme or a GARP-based domain configuration scheme, multiple stages can be configured on a single port at the same time. If multiple stages are configured on the same port (i.e. MIP nodes with different stages are configured on the same port), since only one stage of a MIP node can be active at a time, a mechanism is needed to break down the MIP stages. FIG. 11A and FIG. 11B show steps of class allocation for MIP nodes in the domain configuration scheme of the present invention. Basically, the logic of a MIP-equipped node is operable to determine the minimum value of registered classes on a port configured with a class and select that minimum value as the OAM class for that port. That is, the activated MIP node makes a local judgment to determine Min{level value(i)}, where i=1, 2,..., K, which becomes the OAM of the MIP node in the Ethernet domain hierarchy class. According to the illustration, reference numeral 1100A in FIG. 11A generally refers to a three-level domain hierarchy configured in an eight-port network system, in which level 20 is assigned to a user-level domain including MEP1, MEP2, MIP1, and MIP2, and a domain including MEP3 , MEP4, MIP3, MIP4, MIP5, and MIP6 are assigned level 11 for provider-level domains, and are assigned level 9 for carrier-level domains including MEP5, MEP6, MIP7, and MIP8. One level is configured at a time, and for the purposes of the domain configuration scheme of the present invention, the order in which the levels are configured does not matter. As can be seen from Figure 11A, two MIP nodes are configured for each of ports P4 and P5, one MIP node at level 11 and the other at level 9, resulting in a total of four MIP nodes: MIP4 and MIP7 and MIP5 and MIP8 on P5. According to the description of the disclosure of the present invention, low-level attribute registration triggers level changes on P4 and P5, thereby activating the MIP nodes configured on P4 and P5 at Min{11, 9}, ie level 9. The resulting hierarchy is generally shown at reference numeral 1100B in FIG. 11B.

Based on the foregoing detailed description, it should be understood that the present invention advantageously provides a domain configuration mechanism operable in an Ethernet OAM network, wherein MIP nodes are automatically configured instead of manually configured. Thus, especially in OAM domains with a large number of MIP nodes, the probability of errors due to manual misconfiguration is significantly reduced. Furthermore, due to the configuration of A-MEP nodes at appropriate locations in the network, security breaches caused by leaking frames from one domain to another are reduced.

While the invention has been described with reference to certain exemplary embodiments, it is to be understood that the form of the invention shown and described is that of the exemplary embodiments only. Therefore, various changes, substitutions and modifications can be made without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims (10)

1. one kind is used for comprising at the territory collocation method that the ethernet network that has multistage operations, manages and safeguard the OAM territory is operated:

With the port arrangement of the first terminal bridge of the edge of predetermined OAM domain in the described ethernet network is the first maintaining end point MEP node, and described OAM territory has a specific order;

In the attribute logging process, send first group of Generic Attribute Registration Protocol GARP or continuity verification CC frame from a described MEP node to all the other ports of the described first terminal bridge and all the other bridges of described ethernet network, described first group of GARP or CC frame comprise the level information about described a specific order;

With the port arrangement of the second terminal bridge of the described edge in OAM territory described in the described ethernet network is the second maintaining end point MEP node, and described OAM territory has described a specific order;

In the attribute logging process, send second group of GARP or CC frame from described the 2nd MEP node to all the other ports of the described second terminal bridge and all the other bridges of described ethernet network, described second group of GARP or CC frame comprise the level information about described a specific order; And

In response to described first and second groups of GARP or CC frame, be Maintenance Intermediate Point MIP node with described a specific order with the port arrangement in the bridge that is deployed between the described first terminal bridge and the second terminal bridge.

2. one kind is used for comprising at the territory configuration-system that the ethernet network that has multistage operations, manages and safeguard the OAM territory is operated:

The port arrangement that is used for the first terminal bridge of described ethernet network predetermined OAM edge is the device of the first maintaining end point MEP node, and described OAM territory has a specific order;

Be used for being created in the device of the attribute logging process sends to all the other bridges of all the other ports of the described first terminal bridge and described ethernet network from a described MEP node first group of Generic Attribute Registration Protocol GARP or continuity verification CC frame, described first group of GARP or CC frame comprise the level information relevant with described a specific order;

The port arrangement that is used for the second terminal bridge of the described edge in OAM territory described in the described ethernet network is the device of the second maintaining end point MEP node, and described OAM territory has described a specific order;

Be used for being created in the device of the attribute logging process sends to all the other bridges of all the other ports of the described second terminal bridge and described ethernet network from described the 2nd MEP node second group of GARP or CC frame, described second group of GARP or CC frame comprise the level information relevant with described a specific order; And

Being operating as in response to described first group and second group of GARP or CC frame, is the device with Maintenance Intermediate Point MIP node of described a specific order with the port arrangement in the bridge that is deployed between the described first terminal bridge and the second terminal bridge.

3. territory according to claim 2 configuration-system, wherein said predetermined OAM domain comprise user class OAM territory.

4. territory according to claim 2 configuration-system, wherein said predetermined OAM domain comprise provider level OAM territory.

5. territory according to claim 2 configuration-system, wherein said predetermined OAM domain comprise carrier-class OAM territory.

6. territory according to claim 2 configuration-system, the device that wherein is used to dispose the described port of the described first terminal bridge comprise that the described port arrangement that is used for manually the described first terminal bridge is the device of a described MEP node.

7. territory according to claim 2 configuration-system, the device that wherein is used to dispose the described port of the described second terminal bridge comprise that the described port arrangement that is used for manually the described second terminal bridge is the device of described the 2nd MEP node.

8. territory according to claim 2 configuration-system, the device that wherein is used for disposing the described port of the described bridge of disposing between the described first terminal bridge and the second terminal bridge comprises that being used for automatically is the device with MIP node of described a specific order with described port arrangement.

9. territory according to claim 2 configuration-system also comprises:

Whether at least one of described port that is used to determine to be configured to the MIP node belongs to a plurality of grades device; And

Be used to respond and describedly determine, to described port described at least one distribute the device of a level, a level of described distribution comprises described a plurality of grades minimum value.

10. territory according to claim 2 configuration-system comprises that also at least one port on the middle bridge that is used for being deployed between the described first terminal bridge and the second terminal bridge automatically is configured to the device of the automatic MEP node relevant with described predetermined OAM domain.

Images