US9270564B2 - System and method for congestion notification in an ethernet OAM network - Google Patents
System and method for congestion notification in an ethernet OAM network Download PDFInfo
- Publication number
- US9270564B2 US9270564B2 US13/609,375 US201213609375A US9270564B2 US 9270564 B2 US9270564 B2 US 9270564B2 US 201213609375 A US201213609375 A US 201213609375A US 9270564 B2 US9270564 B2 US 9270564B2
- Authority
- US
- United States
- Prior art keywords
- congestion
- mep
- oam domain
- oam
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related, expires
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
- H04L43/0882—Utilisation of link capacity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
Definitions
- This invention relates generally to Ethernet networks and in particular to systems and methods for providing congestion notification in an Ethernet network using Ethernet Operations, Administration and Maintenance (OAM) protocols.
- OAM Operations, Administration and Maintenance
- Ethernet protocols are able to support multiple demanding services including, for example, voice-over-IP (VoIP), data, audio, video and multimedia applications.
- VoIP voice-over-IP
- Various standards are being developed to enhance Ethernet to provide carrier grade, highly available metro area networks (MAN) and wide area networks (WAN).
- Ethernet OAM helps to provide end-to-end service assurance across an Ethernet network.
- Ethernet OAM addresses performance management in Ethernet networks and defines protocols for connectivity fault management, such as fault detection, verification, isolation and performance monitoring, such as frame loss, frame delay and delay variation.
- Ethernet OAM protocol as currently standardized provides a framework for addressing certain connectivity fault management and performance monitoring issues, a number of other performance monitoring issues remain to be addressed.
- FIG. 1 illustrates a schematic block diagram of an embodiment of hierarchical OAM domains in an Ethernet OAM network
- FIG. 2 illustrates a schematic block diagram of an embodiment of congestion notification within an OAM domain in an Ethernet OAM network
- FIG. 3 illustrates a schematic block diagram of an embodiment of congestion notification between OAM domains in an Ethernet OAM network
- FIG. 4 illustrates a schematic block diagram of an embodiment of propagation of congestion notification in an Ethernet OAM network
- FIG. 5 illustrates a logic flow diagram of an embodiment of congestion notification in an Ethernet OAM network
- FIG. 6 illustrates a logic flow diagram of another embodiment of congestion notification in an Ethernet OAM network
- FIG. 7 illustrates a logic flow diagram of another embodiment of congestion notification in an Ethernet OAM network
- FIG. 8 illustrates a schematic block diagram of an embodiment of a network element operable for congestion notification in an Ethernet OAM network
- FIG. 9 illustrates a schematic block diagram of an embodiment of a network interface module in a network element operable for congestion notification in an Ethernet OAM network
- FIG. 10 illustrates a logical flow diagram of an embodiment of a method for congestion identification in an Ethernet OAM network
- FIG. 11 illustrates a logical flow diagram of an embodiment of a method for monitoring congestion in an Ethernet OAM network
- FIG. 12 illustrates a schematic block diagram of an embodiment of a congestion notification message in an Ethernet OAM network
- FIG. 13 illustrates a schematic block diagram of an embodiment of a network management protocol message in an Ethernet OAM network.
- Ethernet OAM defines hierarchically layered operations, administrative and maintenance (OAM) domains.
- OAM domains include one or more customer domains at the highest level of hierarchy, one or more provider domains occupying an intermediate level of hierarchy, and one or more operator domains disposed at a lowest level of hierarchy.
- An OAM domain is assigned to a maintenance level (MA Level), e.g., one of 8 possible levels, to define the hierarchical relationship between the OAM domains in the network.
- MA Level maintenance level
- MA levels 5 through 7 are reserved for customer domains
- MA levels 3 and 4 are reserved for service provider domains
- MA levels 0 through 2 are reserved for operator domains.
- a Maintenance Association is a set of Maintenance End Points (MEPs) configured with the same Maintenance Association Identifier (MAID) and maintenance level (MA Level). MEPs within a maintenance association are configured with a unique MEP identifier (MEPID) and are also configured with a list of other MEPIDs for MEPs in the same maintenance association.
- MIP Maintenance Intermediate Point
- MEPs are operable to initiate and monitor OAM activity in their maintenance domain while MIP nodes passively receive and respond to OAM frames initiated by MEP nodes.
- MEP nodes are operable to initiate various OAM frames, e.g., Continuity Check (CC), TraceRoute, and Ping, to other MEP nodes in an OAM domain and to MEPs in higher hierarchical OAM domains.
- An MIP node can interact only with the MEP nodes of its domain. Accordingly, in terms of visibility and awareness, operator-level domains have higher OAM visibility than service provider-level domains, which in turn have higher visibility than customer-level domains. Thus, whereas an operator OAM domain has knowledge of both service provider and customer domains, the converse is not true. Likewise, a service provider domain has knowledge of customer domains but not vice versa.
- FIG. 1 illustrates a schematic block diagram of an embodiment of an Ethernet OAM network 100 with hierarchical OAM domains.
- the Ethernet OAM network 100 includes customer premises equipment 102 a and 102 b and various network elements 104 a - g , such as switches, bridges and routers.
- the Ethernet OAM network has been logically separated into a hierarchy of OAM domains, a customer domain 106 , a provider domain 108 and operator domains 110 a and 110 b .
- the customer domain 106 , provider domain 108 and operator domains 110 a , 110 b may comprise various diverse network and transport technologies and protocols.
- the network 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), etcetera.
- the OAM domains are bounded by MEPs 112 (illustrated as squares) and include one or more internal MIPs 114 (illustrated as circles). MEPs 112 and MIPs 114 are configured in ports or NIMs of the network elements 104 .
- a network element 104 is operable to be configured to include an MEP 112 for one or more OAM domains as well as to include an MIP 114 for one or more OAM domains.
- Network Element 104 a is configured to include an MIP 114 for customer domain 106 , an MEP 112 for provider domain 108 and an MEP 112 for operator domain 110 a .
- the Ethernet OAM network 100 is logically separated into a number of hierarchical levels where, at any one level, an OAM domain may be configured as one or more MIPs 114 bounded by multiple MEPs 112 .
- FIG. 1 illustrates a point to point configuration of the OAM domains, point-to-multipoint configurations, ring networks, mesh networks, etc. may be configured into hierarchical OAM domains as well, e.g. with more than two MEPs 112 configured to bound an OAM domain.
- Ethernet OAM protocol as defined in IEEE 802.1ag supports various management issues, such as fault detection, fault verification, fault isolation and discovery using various OAM frames, such as continuity check messages (CCM), Trace route messages and loop back messages.
- Continuity check messages CCM are used to detect connectivity failures within an OAM domain.
- An MEP 112 in an OAM domain transmits a periodic multicast Continuity Check Message inward towards the other MEPs 112 in the OAM domain and monitors for CCM messages from other MEPs 112 .
- Link Trace messages are used to determine a path to a destination MEP 112 .
- An originating MEP 112 transmits a Link Trace message to a destination MEP 112 and each MEP 112 receiving the Link Trace message transmits a Trace route Reply back to the originating MEP 112 .
- IEEE 802.1ag also describes loop back or ping messages.
- An MEP 112 sending successive loopback messages can determine the location of a fault or can test bandwidth, reliability, or jitter of a service.
- the ITU-T Y.1731 specification describes various OAM frames for performing OAM operations, such as Ethernet alarm indication signal (ETH-AIS), Ethernet remote defect indication (ETH-RDI), Ethernet locked signal (ETH-LCK), Ethernet test signal (ETH-Test), Ethernet automatic protection switching (ETH-APS), Ethernet maintenance communication channel (ETH-MCC), Ethernet experimental OAM (ETH-EXP), Ethernet vendor-specific OAM (ETH-VSP), Frame loss measurement (ETH-LM) and Frame delay measurement (ETH-DM).
- ETH-AIS Ethernet alarm indication signal
- ETH-RDI Ethernet remote defect indication
- ETH-LCK Ethernet locked signal
- ETH-Test Ethernet test signal
- ETH-APS Ethernet automatic protection switching
- ETH-MCC Ethernet maintenance communication channel
- ETH-EXP Ethernet experimental OAM
- ETH-VSP Ethernet vendor-specific OAM
- ETH-LM Frame loss measurement
- ETH-DM Frame delay measurement
- a network element 104 in an Ethernet OAM network 100 is operable to detect congestion associated with an OAM domain and generate a congestion notification to MEPs 112 in the OAM domain using a modified Ethernet OAM protocol.
- the congestion notification includes a continuity check message (CCM) defined in IEEE 802.1ag that is enhanced to incorporate congestion information though other types of OAM frames or a newly defined OAM frame may also be implemented to perform the functions described herein.
- CCM continuity check message
- a network element 104 in the Ethernet OAM network 100 detects congestion in one or more queues that include packets for an OAM service monitored by an MEP or otherwise associated with an MEP 112 , it triggers a congestion state for the MEP 112 .
- the MEP 112 transmits a congestion notification to other MEPs 112 in the OAM domain.
- the notifying MEP 112 , as well as other MEPs 112 receiving the congestion notification initiate a network management protocol message to a network management system for the OAM domain.
- the MEPs 112 in the OAM domain may also propagate the congestion notification to MEPs 112 in a higher maintenance level OAM domain. As such, when congestion is detected at an MEP 112 in a local network element 104 , notification is provided to other network elements and network managers of the congestion detection and source of the congestion.
- FIG. 2 illustrates a schematic block diagram of an embodiment of congestion notification within an OAM domain in an Ethernet OAM network 100 .
- the Ethernet OAM network 100 is logically configured to include a provider domain 108 bounded by MEPs 112 a , 112 b , 112 c and 112 d with internal MIPs 114 a , 114 b , 114 c and 114 d and configured with a first maintenance level (e.g., MA level 3 ) and a first maintenance association identifier (MAID).
- a first maintenance level e.g., MA level 3
- MAID first maintenance association identifier
- the Ethernet OAM network 100 is also logically configured to include a customer domain 106 bounded by MEPs 112 e and 112 f with internal MIPs 114 e and 114 f configured with a second higher hierarchical maintenance level (e.g., MA level 7 ) and a second maintenance association identifier (MAID).
- a second higher hierarchical maintenance level e.g., MA level 7
- MAID second maintenance association identifier
- Network Element 104 a detects congestion in one or more queues associated with MEP 112 a in provider domain 108 .
- the one or more queues associated with the MEP 112 a are configured for a customer service instance or Ethernet virtual connection (EVC) in the provider domain 108 and monitored by MEP 112 .
- EEC Ethernet virtual connection
- a congestion state is triggered for MEP 112 a .
- the Network element 104 a detects congestion in ingress or egress queues configured to store packets labeled with a customer service instance in the provider domain 108 and monitored by MEP 112 a .
- the Network Element 104 a generates a Congestion Notification 200 that includes congestion information indicating the presence of congestion at MEP 112 a in provider domain 108 .
- the Network Element 104 a transmits the Congestion Notification 200 from MEP 112 a and 112 d to other MEPs 112 b , 112 c in provider domain 108 .
- the internal MIPs 114 a and 114 b in provider domain 108 receive congestion notification 200
- the internal MIPs 114 a and 114 b passively transmit congestion notification 200 to MEP 112 b .
- MIPs 114 c and 114 d passively transmit congestion notification 200 from MEP 112 d to MEP 112 c .
- the other MEPs 112 b, c, d in provider domain 108 are thus notified of the congestion detected at MEP 112 a.
- the Network Element 104 a continues to transmit the Congestion Notification 200 at predetermined intervals while MEP 112 a remains in a congestion state.
- the congestion states ends, e.g. the Network Element 104 a fails to detect congestion in ingress or egress queues associated with MEP 112 a (e.g., queues configured with services which are monitored by MEP 112 a ) for a predetermined time period or for a number of consecutive time intervals, the Network Element 104 a stops transmitting the Congestion Notification 200 .
- MEP 112 a exits the congestion state, it transmits a CCM message, or other type of OAM message, which no longer includes a flag for congestion or other congestion information.
- FIG. 3 illustrates a schematic block diagram of an embodiment of congestion notification between OAM domains in an Ethernet OAM network 100 .
- the Ethernet OAM network 100 is logically configured to include a provider domain 108 bounded by MEPs 112 a , 112 b , 112 c and 112 d with internal MIPs 114 a , 114 b, 114 c and 114 d and configured with a first maintenance level (e.g., MA level 3 ) and a first maintenance association identifier (MAID).
- a first maintenance level e.g., MA level 3
- MAID first maintenance association identifier
- the Ethernet OAM network 100 is also logically configured to include a customer domain 106 bounded by MEPs 112 e and 112 f with internal MIPs 114 e and 114 f configured with a second higher hierarchical maintenance level (e.g., MA level 7 ) and a second maintenance association identifier (MAID).
- a second higher hierarchical maintenance level e.g., MA level 7
- MAID second maintenance association identifier
- MEP 112 a In response to detecting congestion in one or more queues associated with MEP 112 a configured in provider domain 108 , MEP 112 a enters a congestion state and transmits a Congestion Notification 200 to other MEPs 112 b,c,d in the provider domain 108 .
- the congestion notification 200 is also propagated to a higher hierarchical level OAM domain such as customer domain 106 .
- MEPs 112 b , 112 c in the provider domain 108 propagate the congestion notification 200 to MEP 112 e in customer domain 106 .
- MEPs 112 a and 112 d in the provider domain 108 propagate the congestion notification 200 to MEP 112 f in customer domain 106 .
- MEPs 112 e and 112 f in customer domain 106 propagate the congestion notification to other MEPs 112 (not shown) in customer domain 106 .
- MEPs 112 in the higher hierarchical level OAM domain are informed of the congestion detected at MEP 112 a in the lower level hierarchical OAM domain.
- an MEP 112 in an OAM domain when it enters a congestion state or receives a congestion notification, it is operable to notify a network management system (NMS) for the OAM domain.
- NMS network management system
- MEP 112 a in provider domain 108 transmits a network management protocol message 210 to provider NMS 204 indicating the presence of congestion at MEP 112 a .
- the network management protocol message 210 is a Simple Network Management Protocol (SNMP) trap or SNMP response though other management protocols such as INMP, TELNET, SSH, or Syslog or other types of SNMP messages may be implemented to perform the congestion notification.
- SNMP Simple Network Management Protocol
- FIG. 4 is a schematic block diagram that illustrates an embodiment of propagation of congestion notification 200 in an Ethernet OAM network 100 .
- a three-level hierarchy of OAM domains includes an MEP 112 a in an OAM domain with an assigned maintenance association (MA) level (i) and a first maintenance association ID (MAID 1 ), an MEP 112 b in an OAM domain at MA level (i+n) and a second maintenance association ID (MAID 2 ) and an MEP 112 c in an OAM domain at MA level (i+m) where m>n and a third maintenance association ID (MAID 3 ).
- Associated with the OAM domains are corresponding NMS entities 220 a , 220 b and 220 c respectively.
- each OAM domain is monitored by level-specific CCM frames transmitted by the MEPs 112 therein.
- MEP 112 a When congestion is detected at MEP 112 a at MA Level i, or MEP 112 a receives a congestion notification from another MEP in OAM domain at MA Level i, MEP 112 a is operable to transmit a network management protocol (NMP) message 210 to the NMS 220 a for its OAM domain.
- NMP network management protocol
- MEP 112 a is also operable to propagate a congestion notification (such as CCM message with congestion information) to other MEPs at OAM domain at MA level i.
- MEP 112 a is also operable to propagate a congestion notification 200 to MEP 112 b at a higher hierarchical OAM domain level, e.g. OAM domain at MA Level i+n.
- MEP 112 b When MEP 112 b receives a congestion notification 200 from a lower hierarchical OAM domain level, such as OAM domain MA level i, it transmit a network management protocol (NMP) message 210 to the NMS 220 b for its OAM domain at MA level i+n.
- NMP network management protocol
- MEP 112 b is also operable to propagate a congestion notification 200 (such as CCM message with congestion information) to other MEP nodes at OAM domain at MA level i+n.
- the congestion notification includes information that the congestion is detected at the lower hierarchical OAM domain with MA level i.
- MEP 112 b is also operable to propagate a congestion notification 200 to MEP 112 c at a higher hierarchical OAM domain level, e.g. OAM domain at MA Level i+m, where m>n.
- MEP 112 c when MEP 112 c receives a congestion notification 200 from a lower hierarchical OAM domain level, such as OAM domain MA level i+n, it transmit a network management protocol (NMP) message 210 to the NMS 220 c for its OAM domain at MA level i+m.
- NMP network management protocol
- MEP 112 c is also operable to propagate a congestion notification 200 (such as CCM message with congestion information) to other MEP nodes at OAM domain at MA level i+m.
- the congestion notification includes information that the congestion is detected at the lower hierarchical OAM domain with MA level i.
- MEP 112 c is also operable to propagate a congestion notification 200 to another MEP at a higher hierarchical OAM domain level. In this manner, the higher hierarchical OAM domains and their corresponding network management systems 220 are notified of congestion and the source of the congestion.
- FIG. 5 illustrates a logic flow diagram 250 of an embodiment of congestion notification in an Ethernet OAM network 100 .
- congestion is detected at an MEP 112 in a first OAM domain at a first hierarchical OAM domain level. For example, congestion is detected in one or more ingress or egress queues associated with the MEP 112 , and the MEP 112 enters into a congestion state.
- a congestion notification is generated and propagated by the MEP 112 to other MEPs 112 in the first OAM domain.
- the congestion notification includes, for example, a CCM message with congestion information and the source of the congestion, such as an identifier for the MEP 112 (MEPID) in the congestion state.
- MEPID identifier for the MEP 112
- FIG. 6 illustrates a logic flow diagram 260 of another embodiment of congestion notification in an Ethernet OAM network 100 .
- congestion is detected at an MEP 112 in a first OAM domain at a first hierarchical OAM domain level (or the MEP 112 receives a congestion notification from another MEP 112 at the first hierarchical OAM domain level).
- a network management protocol (NMP) message 210 is generated by the Network Element 104 and transmitted to the NMS 220 for the OAM domain to inform the NMS 220 of the congestion.
- NMP network management protocol
- FIG. 7 illustrates a logic flow diagram 270 of another embodiment of congestion notification in an Ethernet OAM network 100 .
- congestion is detected at an MEP 112 in a first OAM domain at a first hierarchical level OAM domain (or the MEP 112 receives a congestion notification from another MEP at the first hierarchical level OAM domain).
- a congestion notification is generated and propagated by the MEP 112 in the first hierarchical level OAM domain to an MEP 112 at a second higher hierarchical level OAM domain.
- the congestion notification includes, for example, a CCM message with congestion information and the source of the congestion, such as an identifier for the OAM domain (such as MA level or MAID) including the MEP 112 in the congestion state.
- the identifier for the MEP 112 (MEPID) in the congestion state may also be included.
- FIG. 8 illustrates a schematic block diagram of an embodiment of a network element 104 operable for congestion notification in an Ethernet OAM network 100 .
- the network element 104 includes at least one control management module (CMM) 300 a (primary) and preferably a second CMM module 300 b (back-up), one or more Network Interface Modules (NIMs) 302 a - n , and Fabric Switch 308 .
- the Fabric Switch 308 is operable to provide an interconnection between the NIMs 302 a - n , e.g. for switching packets between the NIMs 302 a - n .
- NIMs 302 a - n such as line cards or port modules, include a Queuing Module 304 and Interface Module 306 .
- Interface Module 306 includes a plurality of external interface ports 310 .
- the ports 310 may have the same physical interface type, such as copper (CAT-5E/CAT-6), multi-mode fiber (SX) or single-mode fiber (LX).
- the ports 310 may have one or more different physical interface types.
- the ports 310 are assigned an external port interface identifiers (Port IDs), e.g., such as gport and dport values, associated with the Interface Modules 306 .
- the Interface Module 306 further includes a packet processor 312 that is operable to process incoming and outgoing packets.
- the Queuing Module 304 includes a packet buffer 316 with a plurality of packet queues 314 a - n .
- One or more of the queues 314 a - n are associated with a port 310 .
- the one or more queues 314 assigned to a port 310 may include ingress packets received at the port 310 to be transmitted to other NIMs 302 or the CMM 300 or include egress packets that are to be transmitted from the port 310 .
- the queue management 320 stores the egress packet in one or more of the queues 314 associated the destination port 310 to wait for transmission by the destination port 310 .
- the queue module 304 determines the destination port 310 for transmission of the packet in response to a destination address or egress port id in the egress packet. For example, an address or mapping table provides information for switching the packet into an appropriate egress queue for one or more of the ports 310 based on destination address in the egress packet.
- the packet processor 312 determines that an ingress packet is destined for one or more ports in another NIM 302 , it transmits the ingress packet to the Queuing Module 304 .
- the queue module 304 determines one or more queues 314 to store the ingress packet for transmission to the other NIMs 152 via the fabric switch 308 .
- the Interface Module 306 and Queuing Module 304 are illustrated as separate modules in FIG. 8 , one or more functions or components of the modules may be included on the other module or combined into one module or otherwise be implemented in one or more modules.
- one or more of the external ports 310 are configured as MEPs 112 or MIPs 114 for one or more OAM domains.
- port 310 a of NIM 302 a is configured as an MEP 112 a for a provider domain 108 (as shown in FIG. 3 ).
- the MEP 112 a is assigned a unique MEP ID for the provider domain 108 , which is assigned a maintenance level (such as MA level 3 ) and maintenance association ID (MAID).
- port 310 n of NIM 302 n is configured as an MIP 114 f for customer domain 106 (as shown in FIG. 3 ), which is assigned a maintenance level (such as MA level 7 ) and maintenance association ID (MAID).
- the MIP 114 is an internal port within the customer domain 106 .
- one or more of the ports 310 are configured into a link aggregation group (LAG), as described in the Link Aggregation Control Protocol (LACP) and incorporated in IEEE 802.1AX-2008 on Nov. 3, 2008, which is incorporated by reference herein.
- An MEP 112 or MIP 114 may be assigned to a LAG that includes a plurality of ports 310 .
- LAG 320 is then assigned or configured as MEP 112 d (as shown in FIG. 3 ).
- MEP 112 d is assigned a unique MEP ID for the provider domain 108 , which is assigned a maintenance level (such as MA level 3 ) and maintenance association ID (MAID).
- the Network Element 104 monitors one or more queues 314 associated with a port 310 configured as an MEP 112 for congestion.
- the CMM 300 , the Queuing Module 304 , Interface Module 306 and/or Fabric Switch 308 are operable to perform congestion monitoring of the queues 314 associated with an MEP 112 .
- the Network Element 302 determines congestion exists in one or more of the queues 314 associated with an MEP 112 (e.g., queues configured with services which are monitored by MEP 112 a )
- the Network Element 302 enters the MEP 112 (e.g., its associated one or more queues 314 and/or ports 310 ) into a congestion state.
- the Network Element 302 then generates a congestion notification 200 as described herein.
- One or more of the processing modules in the Network Element 104 may perform the generation of the congestion notification 200 , e.g. the CMM 302 , Queuing Module 304 and/or Interface Module 306 .
- the congestion notification 200 is then propagated as described herein.
- FIG. 9 illustrates a schematic block diagram of an embodiment of a network interface module 302 in a network element 104 operable for congestion notification in an Ethernet OAM network 100 .
- Queuing module 304 includes queue management 320 that is operable to manage and monitor the queues 314 in the packet buffer 316 .
- queues 314 a - n are allocated for Port 310 a configured as MEP 112 a .
- Other queues 314 are also allocated to other ports in the packet buffer 316 .
- the queue management 320 configures one or more flow based queues to a set of VLANs associated with an MEP 112 .
- the VLAN ID affected by the congestion is also identified.
- the congestion notification includes the information on the MEP (MEPID) associated with the set of VLANs, the maintenance entity identifier (MAID) and the VLAN identifier associated with the congested queue 314 .
- the queue management 320 dedicates one or more queues 314 per customer service instance serviced by an MEP 112 configured on a port 310 .
- a customer service instance is an Ethernet virtual connection (EVC), which is identified by a service virtual local area network (S-VLAN) identifier.
- the S-VLAN identifier is a globally unique service ID.
- a customer service instance can thus be identified by the S-VLAN identifier.
- a customer service instance can be point-to-point or multipoint-to-multipoint.
- OAM frames include the S-VLAN identifier and are issued on a per-Ethernet Virtual Connection (per-EVC) basis.
- queue management 320 configures one or more queues 314 per EVC serviced by the OAM domain of the MEP 112 .
- queues 314 a - n are allocated to store packets for EVC1-n respectively.
- the congestion notification 200 includes the information on the MEP 112 , such as (MEPID), the maintenance association identifier (MAID) and the S-VLAN identifier of the EVC associated with the congested queue.
- FIG. 10 illustrates a logical flow diagram of an embodiment of a method for congestion identification 350 in an OAM network 100 .
- one or more queues 314 associated with an MEP 112 in an OAM domain are monitored for congestion.
- the one or more queues are configured with a customer service instance or EVC in the OAM domain monitored by the MEP 112 .
- One or more congestion thresholds are pre-configured, e.g. thresholds related to queue depth, percentage of available queue depth, etc.
- a queue 314 compares unfavorably to a congestion threshold, a statistical sampling is performed on the queue 314 over a predetermined time period, e.g.
- a congestion state is triggered for the MEP 112 associated with the congested queue as shown in step 356 .
- FIG. 11 illustrates a logical flow diagram of an embodiment of a method for monitoring congestion 360 in an OAM network 100 .
- an MEP 112 is in a congestion state due to one or more congested queues 314 .
- the congestion state is triggered, the one or more congested queues 314 are continued to be monitored to determine whether the one or more queues 314 continue to compare unfavorably to the congestion threshold as shown in step 364 .
- the congestion state is exited or removed as shown in step 366 . This requirement prevents removal of the congestion state prematurely.
- CCM frames no longer indicate congestion at MEP 112 (e.g. a flag is removed indicating congestion) as shown in step 368 .
- a congestion notification 200 is propagated that specifically indicates removal of the congestion state.
- the congestion notification 200 includes a flag that indicates that the congestion state has ended or been removed at the MEP 112 . As such, the other MEPs receive confirmed notice of the end of the congestion state at MEP 112 .
- FIG. 12 illustrates a schematic block diagram of an embodiment of a congestion notification 200 in an OAM network 100 .
- the congestion notification 200 is a continuity check message (CCM) though other types of OAM frames or a new type of OAM frame may be implemented as well.
- the congestion notification 200 includes a destination MAC address field 400 and source MAC address field 402 .
- the congestion notification in an embodiment includes an S-VLAN ID field 404 and/or VLAN ID (or customer VLAN tag) field 406 . As described above, the S-VLAN ID 404 and/or VLAN ID 408 in the congestion notification 200 are associated with one or more congested queues of an MEP 112 in a congestion state.
- the congestion notification 200 also includes a maintenance level (MA level) field 410 for the OAM domain of the MEP 112 in the congestion state, e.g. MA level 0 - 7 .
- An OpCode field 412 designates the OAM message type, e.g. Continuity Check, Loopback, etc.
- the congestion notification 200 includes an OpCode in a range for a Continuity Check type OAM message.
- the Flags field 414 includes designated bits to indicate one or more states or variables dependent on the OAM message type. In the congestion notification 200 , one or more bits in the Flags field 414 is set to indicate a congestion state at the MEP 112 .
- the TLV Offset field 416 indicates an offset to a first TLV in the CCM relative to the TLV Offset field 416 .
- TLVs are optional and are included in the message body.
- the congestion notification 200 includes a TLV 418 with a new TLV type 420 defined to provide congestion information.
- TLV 418 includes MAID field 422 and MEPID field 424 .
- the MAID field 422 includes the maintenance association identifier and/or a network operator that is responsible for the maintenance association of the MEP 112 in the congestion state.
- the MEPID field 424 includes the MEP identifier of the MEP 112 in the congestion state.
- the Transmission Period field 426 is encoded in the Flags field 414 and can be in the range of 3 . 3 ms to 10 minutes.
- the Congestion Measurement field 428 includes one or more parameters of congestion information, such as a percentage of a max queue size consumed at the time of notification, while the Timestamp field 430 indicates when congestion was identified on the one or more congested queues 314 .
- the fields described in the congestion notification 200 and TLV 418 are exemplary and additional fields or alternative fields or fewer fields may also be implemented in the congestion notification 200 .
- FIG. 13 illustrates a schematic block diagram of an embodiment of a network management protocol (NMP) message 210 in an OAM network 100 .
- the NMP protocol message 210 is a Simple Network Management Protocol (SNMP) trap or SNMP response though other management protocols such as INMP, TELNET, SSH, or Syslog or other types of messages may be implemented to perform congestion notification to a network management system 220 .
- the NMP message 210 includes a PDU type field 450 , a MAID field 452 , MEPID field 454 and MA Level field 456 .
- the MAID field 452 includes the maintenance association identifier and/or a network operator that is responsible for the maintenance association of the MEP 112 in the congestion state.
- the MEPID field 454 includes the MEP identifier of the MEP 112 in the congestion state and the maintenance level (MA level) field 456 includes the maintenance level for the OAM domain of the MEP 112 in the congestion state, e.g. MA level 0 - 7 .
- the NMP message 210 further includes an S-VLAN ID field 458 and/or VLAN ID (or customer VLAN tag) field 460 .
- the S-VLAN ID 458 and/or VLAN ID 460 are associated with one or more congested queues 314 of the MEP 112 in the congestion state.
- the Congestion Measurement field 462 includes one or more parameters of congestion information, such as a percentage of a max queue size consumed at the time of notification, while the Timestamp field 464 indicates when congestion was identified on the one or more congested queues 314 .
- the fields described in the NMP message 210 are exemplary and additional fields or alternative fields or fewer fields may also be implemented in the NMP message 210 .
- One or more embodiments described herein are operable to provide a network management system with the ability to effectively identify and monitor congestion end to end in an Ethernet OAM network across multiple geographies and multiple OAM domains.
- the network management system is thus able to take remedial action regarding the congestion.
- NMP messages of the congestion By receiving NMP messages of the congestion, one or more embodiments described herein provide a log of the congestion states within the Ethernet OAM network which helps in handling problems related to traffic loss.
- the term(s) “operably coupled to”, “coupled to”, and/or “coupling” includes direct coupling between items and/or indirect coupling between items via an intervening item (e.g., an item includes, but is not limited to, a component, an element, a circuit, and/or a module) where, for indirect coupling, the intervening item does not modify the information of a signal but may adjust its current level, voltage level, and/or power level.
- inferred coupling i.e., where one element is coupled to another element by inference
- the term “operable to” or “operably coupled to” indicates that an item includes one or more of power connections, input(s), output(s), etc., to perform, when activated, one or more its corresponding functions and may further include inferred coupling to one or more other items.
- the term “associated with”, includes direct and/or indirect coupling of separate items and/or one item being embedded within another item, or one item configured for use with or by another item.
- the term “compares favorably”, indicates that a comparison between two or more items, signals, etc., provides a desired relationship. For example, when the desired relationship is that signal 1 has a greater magnitude than signal 2, a favorable comparison may be achieved when the magnitude of signal 1 is greater than that of signal 2 or when the magnitude of signal 2 is less than that of signal 1.
- processing module may be a single processing device or a plurality of processing devices.
- a processing device may be a microprocessor, micro-controller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that manipulates signals (analog and/or digital) based on hard coding of the circuitry and/or operational instructions.
- the processing module, module, processing circuit, and/or processing unit may be, or further include, memory and/or an integrated memory element, which may be a single memory device, a plurality of memory devices, and/or embedded circuitry of another processing module, module, processing circuit, and/or processing unit.
- a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and/or any device that stores digital information.
- processing module, module, processing circuit, and/or processing unit includes more than one processing device, the processing devices may be centrally located (e.g., directly coupled together via a wired and/or wireless bus structure) or may be distributedly located (e.g., cloud computing via indirect coupling via a local area network and/or a wide area network). Further note that if the processing module, module, processing circuit, and/or processing unit implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory and/or memory element storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry.
- the memory element may store, and the processing module, module, processing circuit, and/or processing unit executes, hard coded and/or operational instructions corresponding to at least some of the steps and/or functions illustrated in one or more of the Figures.
- Such a memory device or memory element can be included in an article of manufacture.
- the present invention is described herein, at least in part, in terms of one or more embodiments.
- An embodiment is described herein to illustrate the present invention, an aspect thereof, a feature thereof, a concept thereof, and/or an example thereof.
- a physical embodiment of an apparatus, an article of manufacture, a machine, and/or of a process that embodies the present invention may include one or more of the aspects, features, concepts, examples, etc. described with reference to one or more of the embodiments discussed herein.
- the embodiments may incorporate the same or similarly named functions, steps, modules, etc. that may use the same or different reference numbers and, as such, the functions, steps, modules, etc. may be the same or similar functions, steps, modules, etc. or different ones.
- signals to, from, and/or between elements in a figure presented herein may be analog or digital, continuous time or discrete time, and single-ended or differential. For instance, if a signal path is shown as a single-ended path, it also represents a differential signal path. Similarly, if a signal path is shown as a differential path, it also represents a single-ended signal path. While one or more particular architectures are described herein, other architectures can likewise be implemented that use one or more data buses not expressly shown, direct connectivity between elements, and/or indirect coupling between other elements.
- module is used in the description of the various embodiments of the present invention.
- a module includes a processing module (as described above), a functional block, hardware, and/or software stored on memory for performing one or more functions as may be described herein. Note that, if the module is implemented via hardware, the hardware may operate independently and/or in conjunction software and/or firmware.
- a module may contain one or more sub-modules, each of which may be one or more modules.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
Description
Claims (11)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/609,375 US9270564B2 (en) | 2012-09-11 | 2012-09-11 | System and method for congestion notification in an ethernet OAM network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/609,375 US9270564B2 (en) | 2012-09-11 | 2012-09-11 | System and method for congestion notification in an ethernet OAM network |
Publications (2)
Publication Number | Publication Date |
---|---|
US20140071831A1 US20140071831A1 (en) | 2014-03-13 |
US9270564B2 true US9270564B2 (en) | 2016-02-23 |
Family
ID=50233181
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/609,375 Expired - Fee Related US9270564B2 (en) | 2012-09-11 | 2012-09-11 | System and method for congestion notification in an ethernet OAM network |
Country Status (1)
Country | Link |
---|---|
US (1) | US9270564B2 (en) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3001612B1 (en) * | 2013-06-29 | 2017-08-09 | Huawei Technologies Co., Ltd. | Multi-domain network protection method and node |
US9703747B2 (en) * | 2014-05-21 | 2017-07-11 | Dell Products Lp | Remote console access of port extenders using protocol extension |
US9313132B1 (en) * | 2014-05-28 | 2016-04-12 | Altera Corporation | Standalone OAM acceleration engine |
US9755932B1 (en) * | 2014-09-26 | 2017-09-05 | Juniper Networks, Inc. | Monitoring packet residence time and correlating packet residence time to input sources |
US10025609B2 (en) * | 2015-04-23 | 2018-07-17 | International Business Machines Corporation | Virtual machine (VM)-to-VM flow control for overlay networks |
JP6332544B1 (en) * | 2017-12-26 | 2018-05-30 | 日本電気株式会社 | Network management apparatus, network system, method, and program |
JP6984569B2 (en) * | 2018-09-07 | 2021-12-22 | 日本電信電話株式会社 | Network equipment and network test method |
US11616723B2 (en) * | 2018-12-05 | 2023-03-28 | Intel Corporation | Techniques to reduce network congestion |
US11621918B2 (en) | 2018-12-05 | 2023-04-04 | Intel Corporation | Techniques to manage data transmissions |
US11451998B1 (en) * | 2019-07-11 | 2022-09-20 | Meta Platforms, Inc. | Systems and methods for communication system resource contention monitoring |
US11575609B2 (en) * | 2019-07-19 | 2023-02-07 | Intel Corporation | Techniques for congestion management in a network |
US20220294737A1 (en) * | 2021-03-09 | 2022-09-15 | Nokia Solutions And Networks Oy | Path congestion notification |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050141509A1 (en) * | 2003-12-24 | 2005-06-30 | Sameh Rabie | Ethernet to ATM interworking with multiple quality of service levels |
US20050249119A1 (en) * | 2004-05-10 | 2005-11-10 | Alcatel | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
US20060002370A1 (en) * | 2004-07-02 | 2006-01-05 | Nortel Networks Limited | VLAN support of differentiated services |
US20060153220A1 (en) | 2004-12-22 | 2006-07-13 | Alcatel | System and method for reducing OAM frame leakage in an ethernet OAM domain |
US20070115837A1 (en) * | 2005-06-17 | 2007-05-24 | David Elie-Dit-Cosaque | Scalable Selective Alarm Suppression for Data Communication Network |
US20090154478A1 (en) | 2007-12-13 | 2009-06-18 | Alcatel Lucent | Scalable Ethernet OAM Connectivity Check in an Access Network |
US20100246412A1 (en) | 2009-03-27 | 2010-09-30 | Alcatel Lucent | Ethernet oam fault propagation using y.1731/802.1ag protocol |
US7924725B2 (en) | 2003-11-10 | 2011-04-12 | Nortel Networks Limited | Ethernet OAM performance management |
US20110154099A1 (en) * | 2009-12-18 | 2011-06-23 | Fujitsu Network Communications, Inc. | Method and system for masking defects within a network |
WO2011129363A1 (en) * | 2010-04-15 | 2011-10-20 | 日本電気株式会社 | Transmission device, transmission method and computer programme. |
US8125914B2 (en) | 2009-01-29 | 2012-02-28 | Alcatel Lucent | Scaled Ethernet OAM for mesh and hub-and-spoke networks |
US20130135993A1 (en) * | 2006-08-22 | 2013-05-30 | Centurylink Intellectual Property Llc | System and method for routing data on a packet network |
-
2012
- 2012-09-11 US US13/609,375 patent/US9270564B2/en not_active Expired - Fee Related
Patent Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7924725B2 (en) | 2003-11-10 | 2011-04-12 | Nortel Networks Limited | Ethernet OAM performance management |
US20050141509A1 (en) * | 2003-12-24 | 2005-06-30 | Sameh Rabie | Ethernet to ATM interworking with multiple quality of service levels |
US20050249119A1 (en) * | 2004-05-10 | 2005-11-10 | Alcatel | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
US7855968B2 (en) | 2004-05-10 | 2010-12-21 | Alcatel Lucent | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
US20060002370A1 (en) * | 2004-07-02 | 2006-01-05 | Nortel Networks Limited | VLAN support of differentiated services |
US20060153220A1 (en) | 2004-12-22 | 2006-07-13 | Alcatel | System and method for reducing OAM frame leakage in an ethernet OAM domain |
US20070115837A1 (en) * | 2005-06-17 | 2007-05-24 | David Elie-Dit-Cosaque | Scalable Selective Alarm Suppression for Data Communication Network |
US20130135993A1 (en) * | 2006-08-22 | 2013-05-30 | Centurylink Intellectual Property Llc | System and method for routing data on a packet network |
US20090154478A1 (en) | 2007-12-13 | 2009-06-18 | Alcatel Lucent | Scalable Ethernet OAM Connectivity Check in an Access Network |
US8125914B2 (en) | 2009-01-29 | 2012-02-28 | Alcatel Lucent | Scaled Ethernet OAM for mesh and hub-and-spoke networks |
US20100246412A1 (en) | 2009-03-27 | 2010-09-30 | Alcatel Lucent | Ethernet oam fault propagation using y.1731/802.1ag protocol |
US20110154099A1 (en) * | 2009-12-18 | 2011-06-23 | Fujitsu Network Communications, Inc. | Method and system for masking defects within a network |
WO2011129363A1 (en) * | 2010-04-15 | 2011-10-20 | 日本電気株式会社 | Transmission device, transmission method and computer programme. |
Non-Patent Citations (1)
Title |
---|
"Ethernet Operations, Administration, and Maintenance," Cisco document, Sep. 2007, 15 pages, Cisco Systems, Inc., San Jose, CA. |
Also Published As
Publication number | Publication date |
---|---|
US20140071831A1 (en) | 2014-03-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9270564B2 (en) | System and method for congestion notification in an ethernet OAM network | |
US8259590B2 (en) | Systems and methods for scalable and rapid Ethernet fault detection | |
US10623293B2 (en) | Systems and methods for dynamic operations, administration, and management | |
US7855968B2 (en) | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network | |
EP2595350B1 (en) | GMPLS based OAM provisioning | |
US8982710B2 (en) | Ethernet operation and maintenance (OAM) with flexible forwarding | |
US9019840B2 (en) | CFM for conflicting MAC address notification | |
US9075717B2 (en) | Connectivity fault notification | |
US8184526B2 (en) | Systems and methods for Connectivity Fault Management extensions for automated activation of services through association of service related attributes | |
US20160041888A1 (en) | Link state relay for physical layer emulation | |
US20100287405A1 (en) | Method and apparatus for internetworking networks | |
WO2021185208A1 (en) | Packet processing method and apparatus, device, and storage medium | |
US9590881B2 (en) | Monitoring carrier ethernet networks | |
WO2009035808A1 (en) | Systems and methods for a self-healing carrier ethernet topology | |
US11483195B2 (en) | Systems and methods for automated maintenance end point creation | |
CN102238067B (en) | Switching method and device on Rapid Ring Protection Protocol (RRPP) ring | |
EP2129042B1 (en) | A multicast network system, node and a method for detecting a fault of a multicast network link | |
McFarland et al. | Ethernet OAM: key enabler for carrier class metro ethernet services | |
McGuire | Next Generation Ethernet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SINHA, ABHISHEK;SPIESER, FREDERIC;SIGNING DATES FROM 20120910 TO 20121001;REEL/FRAME:029190/0386 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:030510/0627 Effective date: 20130130 |
|
AS | Assignment |
Owner name: ALCATEL LUCENT, FRANCE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL-LUCENT USA INC.;REEL/FRAME:031420/0703 Effective date: 20131015 |
|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033949/0016 Effective date: 20140819 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574 Effective date: 20170822 Owner name: OMEGA CREDIT OPPORTUNITIES MASTER FUND, LP, NEW YO Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:043966/0574 Effective date: 20170822 |
|
AS | Assignment |
Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ALCATEL LUCENT;REEL/FRAME:044000/0053 Effective date: 20170722 |
|
AS | Assignment |
Owner name: BP FUNDING TRUST, SERIES SPL-VI, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:049235/0068 Effective date: 20190516 |
|
AS | Assignment |
Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:OCO OPPORTUNITIES MASTER FUND, L.P. (F/K/A OMEGA CREDIT OPPORTUNITIES MASTER FUND LP;REEL/FRAME:049246/0405 Effective date: 20190516 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20200223 |
|
AS | Assignment |
Owner name: OT WSOU TERRIER HOLDINGS, LLC, CALIFORNIA Free format text: SECURITY INTEREST;ASSIGNOR:WSOU INVESTMENTS, LLC;REEL/FRAME:056990/0081 Effective date: 20210528 |
|
AS | Assignment |
Owner name: WSOU INVESTMENTS, LLC, CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:TERRIER SSC, LLC;REEL/FRAME:056526/0093 Effective date: 20210528 |