HK1218192B - A method and system of updating conversation allocation in link aggregation - Google Patents

Description

Method and system for updating session allocation in link aggregation

Technical Field

Embodiments of the present invention relate generally to link aggregation, and more particularly, to methods and apparatus for conversation-aware collection of link aggregation groups (LAGs).

Background Art

As illustrated in FIG1A , link aggregation is a network configuration and process for aggregating multiple links between a pair of nodes 120, 122 in a network to enable transmission of user data on each of the links participating in a link aggregation group (LAG) 101 (see, for example, Institute of Electrical and Electronics Engineers (IEEE) standard 802.1AX). Aggregating multiple network connections in this manner can increase throughput beyond what a single connection can sustain, and/or can be used to provide resilience in the event of a failure of one of the links. "Distributed Resilient Network Interconnect" (DRNI) 102 (see clause 8 of IEEE 802.1AX-REV/D1.0) specifies an extension to link aggregation to enable the use of link aggregation on network interfaces even between more than two nodes (e.g., between the four nodes K, L, M, and O illustrated in FIG1B ).

As shown in FIG1B , a LAG is formed between network 150 and network 152. More specifically, a LAG is formed between LAG virtual nodes or "portals" 112 and 114. First LAG virtual node or portal 112 includes a first node (K) and a second node (L). Second LAG virtual node or portal 114 includes a third node (M) and a fourth node (O). These nodes may also be referred to as a "portal system." It should be noted that first and second LAG virtual nodes or portals 112 and 114 may include a single node or more than two nodes within a portal. LAG nodes K and M are connected as peer nodes, and LAG nodes L and O are also connected as peer nodes. As used herein, "LAG virtual node" refers to the DRNI portal in the IEEE document discussed above (i.e., two or more nodes that appear as a single node to their respective peers). Furthermore, the statement that virtual node or portal 112 "includes" two nodes K and L means that virtual node or portal 112 is emulated by nodes K and L, which may be referred to as an "emulated system." Similarly, the statement that the virtual node or portal 114 "contains" two nodes M, O means that the virtual node or portal 114 is emulated by the nodes M, O. Note that a link aggregation group 161 is also formed between the K-M and L-O links.

Multiple nodes participating in a LAG appear to their peer partners in the LAG as the same virtual node or portal with a single system ID. The system ID is used to identify each node (e.g., node K, node L, node M, and node O). The system ID is included in the Link Aggregation Control Protocol Data Unit (LACPDU) sent between the various partner nodes in the LAG (e.g., between K and M or between L and O). The system ID can be generated based on the identifiers of the portal's constituent nodes, using any individual identifier or any combination thereof. A common and unique system ID for each LAG virtual node or portal can be consistently generated. Thus, as shown in FIG1B , node K and node L belong to the same network 150 and are part of the same DRNI portal 112 (i.e., the same LAG virtual node), using the common system ID "K" for emulating LAG virtual node 112. Similarly, nodes M and O of network 152 are seen by nodes K and L as a single LAG virtual node or portal with a system ID "M."

FIG1B also illustrates the DRNI link allocation for a specific device (see the bold link between K and M in FIG1B ). The service allocation for an interface may involve a virtual local area network (VLAN), and the identifier of the service may be a VLAN identifier (VID), such as a service VID (i.e., "S-VID") (typically identifying a service on a network-to-network interface (NNI)) or a customer VID (i.e., "C-VID") (typically identifying a service on a user-to-network interface (UNI)). (Note that B-VIDs are indistinguishable from S-VIDs because they have the same Ethernet type.) In the example of FIG1B , the service is allocated to the upper link (between upper nodes K and M). The upper link is thus selected as the "working" link, and the lower link (between nodes L and O) is the "backup" link or "protection" link. Service link allocation, i.e., using the same physical link for frame transmission in both the forward and reverse directions, is highly desirable.

Transmitted frames can be dynamically redistributed, and such redistribution can result from removed or added links or changes in the load balancing scheme. Traffic redistribution occurring in the middle of a traffic flow can cause out-of-order frames. To ensure that frames are not duplicated or logged due to this redistribution, link aggregation uses a marker protocol. The purpose of using a marker protocol is to detect when all frames for a given traffic flow have been successfully received at the remote peer node. To achieve this, LACP transmits a marker protocol data unit (PDU) on each port channel link. The partner system responds to a received marker PDU once it has received all frames transmitted on that link prior to the marker PDU. The partner system then sends a marker response PDU for each received marker PDU. Once the local system receives the marker response PDU on all member links of the portal, it can redistribute the frames in the traffic flow, thereby avoiding any risk of out-of-order frames. However, ensuring that the marker response PDU works properly in DRNIs where either or both peer nodes of a LAG may include multiple systems can be problematic. Therefore, measures must be taken to ensure that frame ordering is maintained for a certain sequence of frame exchanges between ports in such a LAG—called a conversation.

Summary of the Invention

A method for updating conversation allocation in a link aggregation is disclosed. A network device implements the method for updating conversation allocation on links of a link aggregation group. The network device is communicatively coupled to an aggregation port via a link of the link aggregation group and processes a conversation consisting of an ordered sequence of frames. The method begins by verifying that an implementation of a conversation-aware Link Aggregation Control Protocol (LACP) is operational. A determination is then made that operation via an enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible. The enhanced LACPDU can be used to update conversation allocation information, and the determination is based at least in part on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device. Then, based on a determination that the conversation allocation state is incorrect, a conversation allocation state of the aggregation port of the link aggregation group is updated, wherein the conversation allocation state of the aggregation port of the link aggregation group indicates a list of conversations transmitted through the aggregation port.

A network device configured to update conversation allocation in a link aggregation is disclosed. The network device is configured to be communicatively coupled to an aggregation port via a link of a link aggregation group, and the network device is configured to process conversations, wherein each conversation consists of an ordered sequence of frames. The network device includes an aggregation port controller configured to receive frames from the aggregation port of the link aggregation group and a network processor and to transmit frames to the aggregation port. The network processor includes: an aggregation controller configured to verify that an implementation of a conversation-sensitive link aggregation control protocol (LACP) is operational; determine that operation is possible via an enhanced link aggregation control protocol data unit (LACPDU), wherein the enhanced LACPDU can be used to update conversation allocation information, wherein the determination is based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device; and update a conversation allocation state for the aggregation port of the link aggregation group based on a determination that the conversation allocation state is incorrect, wherein the conversation allocation state for the aggregation port of the link aggregation group indicates a list of conversations transmitted through the aggregation port.

A non-transitory computer-readable storage medium is disclosed, having stored therein instructions that, when executed by a processor, cause the processor to perform operations for updating conversation allocations in a link aggregation. A network device implements operations for updating conversation allocations on links of a link aggregation group. The network device is configured to be communicatively coupled to an aggregation port via a link of the link aggregation group and to process a conversation consisting of an ordered sequence of frames. The operations begin by verifying that an implementation of a conversation-aware Link Aggregation Control Protocol (LACP) is operational. A determination is then made that operations via enhanced Link Aggregation Control Protocol Data Units (LACPDUs) are possible. The enhanced LACPDUs may be used to update conversation allocation information, and this determination is based at least in part on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device. Then, based on a determination that the conversation allocation state is incorrect, a conversation allocation state of the aggregation port of the link aggregation group is updated, wherein the conversation allocation state of the aggregation port of the link aggregation group indicates a list of conversations transmitted through the aggregation port.

A computer program having instructions that, when executed by a processor, cause the processor to perform operations implemented by a network device for updating conversation allocations on links of a link aggregation group. The network device implements the operations for updating conversation allocations on links of the link aggregation group. The network device is configured to be communicatively coupled to an aggregation port via a link of the link aggregation group and to process conversations consisting of an ordered sequence of frames. The operations begin by verifying that an implementation of a conversation-aware Link Aggregation Control Protocol (LACP) is operational. A determination is then made that operations using enhanced Link Aggregation Control Protocol Data Units (LACPDUs) are possible. The enhanced LACPDUs can be used to update conversation allocation information, and this determination is based at least in part on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device. Then, based on a determination that the conversation allocation state is incorrect, a conversation allocation state of the aggregation port of the link aggregation group is updated, wherein the conversation allocation state of the aggregation port of the link aggregation group indicates a list of conversations transmitted through the aggregation port.

A carrier comprising the computer program mentioned above, wherein the carrier is one of an electronic signal, an optical signal, a radio signal or a computer-readable storage medium.

Embodiments of the present invention provide a mechanism for updating the session assignments of ports in a link aggregation group between network devices, thereby maintaining the frame ordering of the frame exchange sequence by the network devices. Embodiments of the present invention can be utilized in network devices that implement a link aggregation group between a pair of nodes or a portal system, where each portal (such as a DRNI system) contains multiple nodes.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may best be understood by referring to the following description and accompanying drawings which illustrate embodiments of the invention. In the drawings:

FIG. 1A is a diagram of one embodiment of a link aggregation group between two network devices.

FIG. 1B is a diagram of one embodiment of two portals connecting two networks via a link aggregation group.

FIG2 is a diagram of one embodiment of a link aggregation sublayer.

FIG3 is a flow chart illustrating a process of updating conversation allocations of an aggregation port according to one embodiment of the present invention.

FIG. 4A illustrates a conversation mask TLV of an aggregation port according to one embodiment of the present invention.

4B illustrates a Conversation Mask Status field within a Conversation Mask TLV of an aggregation port according to one embodiment of the present invention.

FIG. 4C illustrates a port operation session mask for an aggregation port of a link aggregation group in a network device according to one embodiment of the present invention.

FIG5A is a diagram of one embodiment of a Port Session Service Mapping TLV.

FIG5B is a diagram of one embodiment of an aggregated management service conversation map.

FIG. 6 is another flow chart illustrating a process of updating conversation allocations of an aggregation port according to one embodiment of the present invention.

FIG. 7 is a flow chart illustrating updating a conversation mask of an aggregation port upon receiving a long LACPDU according to one embodiment of the present invention.

8A-D illustrate a sequence for updating a conversation mask of an aggregation port according to one embodiment of the present invention.

FIG9 is a flow diagram of one embodiment of a process for conversation-sensitive collection of link aggregation groups.

FIG10 is a flow diagram of another embodiment of a process for conversation-sensitive collection of link aggregation groups.

11 is a diagram of one embodiment of a network device implementing conversation-aware collection of link aggregation groups.

12A-C illustrate conversation mask-1 to mask-3 TLVs for an aggregation port according to one embodiment of the present invention.

FIG. 13 illustrates the set of TLVs required to support conversation-sensitive frame collection and distribution functionality according to one embodiment of the present invention.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth. However, it is to be understood that embodiments of the present invention may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring an understanding of this description.

However, those skilled in the art will recognize that the present invention can be practiced without such specific details. In other instances, control structures, gate-level circuits, and full software instruction sequences are not shown in detail to avoid obscuring the present invention. A person of ordinary skill in the art will be able to implement appropriate functionality using the included description without undue experimentation.

References in the specification to "one embodiment," "an embodiment," "an example embodiment," and the like indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment may include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with one embodiment, it is understood that it is within the knowledge of those skilled in the art to incorporate such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

the term

The following terms may be used in the description.

Actor: The local entity (ie, node or network device) in a Link Aggregation Control Protocol (LACP) exchange.

Aggregation Key: A parameter associated with each Aggregation Port and each Aggregator in an Aggregation System that identifies the Aggregation Ports that can be aggregated together. Aggregation Ports in an Aggregation System that share the same Aggregation Key value can potentially be aggregated together.

Aggregation Port: A Service Access Point (SAP) in an aggregation system supported by an Aggregator.

Aggregation System: A uniquely identifiable entity that includes (among other things) any combination of one or more Aggregation Ports for the purpose of aggregation. An instance of an Aggregation Link always occurs between two Aggregation Systems. A physical device may include a single Aggregation System or more than one Aggregation System.

Aggregation Client: The layered entity immediately above the Link Aggregation Sublayer that provides an instance of the Internal Sublayer Services (ISS).

Aggregator: A logical media access control (MAC) address bound to one or more aggregated ports, providing access to the physical medium through its aggregator clients.

Dialogue: A set of frames transmitted from one end station to another in which all frames form an ordered sequence and in which the communicating end stations require that order be maintained among the sets of frames exchanged.

Data Terminal Equipment (DTE): Any source or destination of data connected to a local area network.

Distributed Relay (DR): A functional entity distributed on the portal via the DR function in each aggregation system including the portal, which distributes outgoing frames from the gateway to the aggregator and distributes incoming frames from the aggregator to the gateway.

Distributed Resilient Network Interconnect (DRNI): Link aggregation is extended to include a portal and an aggregation system or two portals.

DR functionality: The portion of a distributed relay station that resides within a single portal system.

Gateway: A connection consisting of a gateway link and two gateway ports, typically connecting a distributed relay station virtually to a system (not a physical link between systems).

Internal Sublayer Service (ISS): An enhanced version of the MAC service defined in IEEE Std 802.1AC-2012.

Link Aggregation Group (LAG): A group of links that appears to the aggregator client as if they were a single link. A Link Aggregation Group can connect two aggregation systems, an aggregation system and a portal, or two portals. One or more conversations can be associated with each link that is part of a Link Aggregation Group.

Partner: The remote entity (ie, node or network device) in a Link Aggregation Control Protocol exchange.

Port Conversation Identifier (ID): The conversation identifier value used to select frames passing through the aggregate port.

Portal: One end of a DRNI that contains one or more aggregation systems, each with physical links that together comprise a link aggregation group. The aggregation systems of the portal operate in concert to emulate the presence of a single aggregation system to which the entire link aggregation group is attached.

Type/Length/Value (TLV): A short variable-length encoding of an information element consisting of type, length, and value fields in sequence, where the type field identifies the type of information, the length field indicates the length of the information field (in octets), and the value field contains the information itself. The type value is locally defined and needs to be unique within the protocol defined in this standard.

In the following description and claims, the terms "coupled" and "connected," and their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements operate or interact with each other, and they may or may not be in direct physical or electrical contact with each other. "Connected" is used to indicate that communication is established between two or more elements that are coupled to each other. As used herein, "set" refers to any positive integer item, including one item.

Electronic devices (e.g., end stations, network devices) use machine-readable media, such as non-transitory machine-readable media (e.g., machine-readable storage media, such as magnetic disks; optical disks; read-only memory; flash memory devices; phase-change memory) and transitory machine-readable transmission media (e.g., electrical, optical, acoustic, or other forms of propagated information, such as carrier waves, infrared signals) to store and transmit (internally and/or over a network with other electronic devices) code (composed of software instructions) and data. Furthermore, such electronic devices include hardware, such as a collection of one or more processors coupled to one or more other components, such as one or more non-transitory machine-readable storage media (to store code and/or data) and a network connection (to transmit code and/or data using propagated signals), and in some cases, user input/output devices (e.g., a keyboard, touch screen, and/or display). The collection of processors and other components are typically coupled via one or more interconnects (e.g., buses, and possibly bridges) within the electronic device. Thus, the non-transitory machine-readable medium of a given electronic device typically stores instructions for execution on one or more processors of that electronic device. One or more portions of embodiments of the present invention may be implemented using various combinations of software, firmware, and/or hardware.

As used herein, a network device (e.g., a router, switch, bridge) is a piece of networking equipment that includes hardware and software that communicatively interconnects other devices on the network (e.g., other network devices, end stations). Some network devices are "multi-service network devices" that provide support for multiple networking functions (e.g., routing, bridging, switching, layer 2 aggregation, session border control, quality of service, and/or subscriber management) and/or provide support for multiple application services (e.g., data, voice, and video). Subscriber end stations (e.g., servers, workstations, laptops, netbooks, PDAs, mobile phones, smartphones, multimedia phones, voice over Internet Protocol (VOIP) phones, user equipment, terminals, portable media players, GPS units, gaming systems, set-top boxes) access content/services provided over the Internet and/or provided over a virtual private network (VPN) superimposed on the Internet (e.g., tunneled over the Internet). The content and/or services are typically provided by one or more end stations (e.g., server end stations) belonging to a service or content provider or end stations participating in a peer-to-peer (P2P) service, and may include, for example, public web pages (e.g., free content, storefronts, search services), private web pages (e.g., web pages accessed by username/password for email services), and/or corporate networks over VPNs, etc. Typically, subscriber end stations (e.g., customer premises equipment coupled to an access network (wired or wireless)) are coupled to edge network devices, which are coupled to other edge network devices (e.g., via one or more core network devices), which are coupled to other end stations (e.g., server end stations).

Network devices are typically divided into a control plane and a data plane (sometimes called a forwarding plane or media plane). In the case where the network device is a router (or is implementing routing functionality), the control plane typically determines how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing port for that data), and the data plane is responsible for forwarding that data. For example, the control plane typically includes one or more routing protocols (e.g., exterior gateway protocols such as Border Gateway Protocol (BGP) (RFC 4271), interior gateway protocols (IGPs) such as Open Shortest Path First (OSPF) (RFCs 2328 and 5340), Intermediate System to Intermediate System (IS-IS) (RFC 1142), Routing Information Protocol (RIP) (version 1 RFC 1058, version 2 RFC 2453, and next generation RFC 2080)), Label Distribution Protocol (LDP) (RFC 5036), Resource Reservation Protocol (RSVP) (RFCs 2205, 2210, 2211, 2212, and RSVP-Traffic Engineering (TE): An Extension to RSVP for LSP Tunnels RFC 3209, Generalized Multiprotocol Label Switching (GMPLS) Signaling RSVP-TE RFC 3473, RFC 5036) that communicate with other network devices to exchange routes and select those routes based on routing metrics. 3936, 4495, and 4558). In addition, the control plane typically also includes ISO Layer 2 control protocols, such as Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), and SPB (Shortest Path Bridging), which have been standardized by various standards bodies (for example, SPB has been defined in IEEE Std 802.1aq-2012).

Routes and adjacencies are stored in one or more routing structures (e.g., the Routing Information Base (RIB), the Label Information Base (LIB), and one or more adjacency structures) on the control plane. The control plane programs the data plane with information (e.g., adjacency and routing information) based on the routing structures. For example, the control plane programs adjacency and routing information into one or more forwarding structures (e.g., the Forwarding Information Base (RIB), the Label Forwarding Information Base (LFIB), and one or more adjacency structures) on the data plane. The data plane uses these forwarding and adjacency structures when forwarding traffic.

Each routing protocol downloads routing entries to the master RIB based on certain routing metrics (the metrics can be different for different routing protocols). Each routing protocol can store routing entries in a local RIB (e.g., an OSPF local RIB), including routing entries that have not been downloaded to the master RIB. The RIB module that manages the master RIB selects routes from the routes downloaded by the routing protocols (based on a set of metrics) and downloads those selected routes (sometimes referred to as active routing entries) to the data plane. The RIB module can also cause routes to be redistributed between routing protocols. For layer 2 forwarding, the network device can store one or more bridging tables for forwarding data based on the layer 2 information in that data.

Typically, a network device includes a set of one or more line cards, a set of one or more control cards, and optionally a set of one or more service cards (sometimes referred to as resource cards). These cards are coupled together via one or more interconnect mechanisms (e.g., a first full mesh coupling of line cards and a second full mesh coupling of all cards). The set of line cards constitutes the data plane, while the set of control cards provides the control plane and exchanges packets with external network devices via the line cards. The set of service cards can provide specialized processing (e.g., layer 4 to layer 7 services (e.g., firewalls, Internet Protocol security (IPsec) (RFCs 4301 and 4309), intrusion detection systems (IDS), peer-to-peer (P2P), voice over IP (VoIP) session border controllers, mobile wireless gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) gateways)). As an example, a service card can be used to terminate an IPsec tunnel and execute the accompanying authentication and encryption algorithms.

As used herein, a node forwards an IP packet based on some IP header information in the IP packet; wherein the IP header information includes a source IP address, a destination IP address, a source port, a destination port (wherein "source port" and "destination port" refer to protocol ports, as opposed to physical ports of a network device), a transport protocol (e.g., User Datagram Protocol (UDP) (RFCs 768, 2460, 2675, 4113, and 5405), a Transmission Control Protocol (TCP) (RFCs 793 and 1180), and a Differentiated Services Token Service (DSCP) value (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290, and 3317). Nodes are implemented in network devices. Physical nodes are implemented directly on network devices, while virtual nodes are abstractions implemented in software, and possibly hardware, on network devices. Thus, multiple virtual nodes can be implemented on a single network device.

A network interface can be physical or virtual, and the interface address is the IP address assigned to the network interface, if it is a physical or virtual network interface. A physical network interface is the hardware in a network device through which a network connection is made (e.g., wirelessly via a wireless network interface controller (WNIC) or by plugging a cable into a port connected to a network interface controller (NIC)). Typically, a network device has multiple physical network interfaces. A virtual network interface can be associated with a physical network interface, another virtual interface, or represent itself (e.g., a loopback interface, a Point-to-Point Protocol interface). A network interface (physical or virtual) can be numbered (a network interface with an IP address) or unnumbered (a network interface without an IP address). A loopback interface (and its loopback address) is a specific type of virtual network interface (and IP address) often used for management purposes for a node (physical or virtual); such an IP address is referred to as a node loopback address. The IP address assigned to a network interface of a network device is referred to as the IP address of that network device; at a more granular level, the IP address assigned to a network interface (a network interface is assigned to a node implemented on the network device) can be referred to as the IP address of that node.

Some network devices provide support for implementing VPNs (Virtual Private Networks), such as Layer 2 VPNs and/or Layer 3 VPNs. For example, the network devices that couple a provider's network and a customer's network are referred to as PEs (Provider Edge) and CEs (Customer Edge), respectively. In a Layer 2 VPN, forwarding is typically performed on a CE at either end of the VPN, and traffic is sent across the network (e.g., via one or more PEs coupled by other network devices). Layer 2 circuits are configured between the CE and the PE (e.g., Ethernet ports, ATM permanent virtual circuits (PVCs), Frame Relay PVCs). In a Layer 3 VPN, routing is typically performed by the PE. As an example, an edge network device that supports multiple contexts can be deployed as a PE; and a context can be configured using a VPN protocol, and thus, that context is referred to as a VPN context.

Some network devices provide support for VPLS (Virtual Private LAN Service) (RFCs 4761 and 4762). For example, in a VPLS network, subscriber end stations access content/services provided through the VPLS network by coupling to a CE, which is coupled through a PE coupled by other network devices. VPLS networks can be used to implement triple-play network applications (e.g., data applications (e.g., high-speed Internet access), video applications (e.g., television services such as IPTV (Internet Protocol Television), VoD (Video on Demand) services), and voice applications (e.g., VoIP (Voice over Internet Protocol) services)), VPN services, etc. VPLS is a type of Layer 2 VPN that can be used for multi-point connections. VPLS networks also allow subscriber end stations coupled to CEs at separate geographic locations to communicate with each other across a wide area network (WAN) as if they were directly attached to each other in a local area network (LAN) (referred to as an emulated LAN).

In a VPLS network, each CE is typically attached to a PE's bridge module, possibly via an access network (wired and/or wireless) via an attachment circuit (e.g., a virtual link or connection between the CE and PE). The PE's bridge module is attached to an emulated LAN via an emulated LAN interface. Each bridge module acts as a "virtual switch instance" (VSI) by maintaining a forwarding table that maps MAC addresses to pseudowires and attachment circuits. The PE forwards frames (received from the CE) to their destination (e.g., other CEs, other PEs) based on the MAC destination address field contained in those frames.

The network device may also support native L2 network technologies and device types, including VLAN bridged networks supported by C-VLAN bridges, provider bridges, provider backbone bridges, provider backbone bridge traffic engineering (TE) (as defined in IEEE std 802.1ad-2005, IEEE std 802.1ah-2008, IEEE std 802.1Qaq-2009, IEEE std 802.1Q-2011), and similar technologies and network device types. The above list of network device types and supported technologies is provided by way of example and not limitation. Those skilled in the art will appreciate that other technologies, standards, and device types may be included as network devices as used herein.

Link Aggregation Sublayer

FIG2 is a diagram of one embodiment of a link aggregation sublayer 200. Aggregator client 202 communicates with a collection of aggregation ports 292, 294, and 296 through aggregator 250. In one embodiment, aggregator 250 presents a standard IEEE Std 802.1Q Interior Sublayer Services (ISS) interface to aggregator client 202. Aggregator 250 binds to one or more aggregation ports, including aggregation ports 292, 294, and 296. Aggregator 250 distributes frame transmissions from aggregator client 202 to aggregation ports 292, 294, and 296, and collects received frames from aggregation ports 292, 294, and 296 and transparently passes them to aggregator client 202.

The binding of aggregated ports 292, 294, and 296 to aggregator 250 is managed by link aggregation control 210, which is responsible for determining which links can be aggregated, aggregating them, binding the aggregated ports to the appropriate aggregator, and monitoring conditions to determine when a change in aggregation is required. Such determination and binding can be under manual control by a network manager by directly manipulating state variables of the link aggregation (e.g., via an aggregation key). In addition, automatic determination, configuration, binding, and monitoring can occur through the use of Link Aggregation Control Protocol (LACP) 214. LACP 214 uses peer exchanges across links to determine the aggregation capabilities of various links on an ongoing basis and continuously provides the maximum level of aggregation capability achievable between a given pair of aggregated systems.

An aggregation system may contain multiple aggregators, serving multiple aggregator clients. A given aggregation port will be bound to (at most) a single aggregator at any given time. An aggregator client is served by a single aggregator at a time.

Frame ordering is maintained for certain sequences of frame exchanges between aggregator clients (called conversations). Frame distributor 234 ensures that all frames for a given conversation are delivered to a single aggregator port. For a given conversation, frame collector 224 is required to deliver frames to aggregator client 202 in the order in which they were received from the aggregator ports. Frame collector 224 is also free to select frames received from aggregator ports 292, 294, and 296 in any order. This ensures that frame ordering is maintained for any conversation, as there is no means to shuffle frames on a single link. Conversations can be moved between aggregator ports within a link aggregation group to facilitate load balancing and maintain availability in the event of a link failure.

Aggregation ports 292, 294, 296 are each assigned a Media Access Control (MAC) address that is unique across the link aggregation group and to any bridged local area network (LAN) to which the link aggregation group is connected (e.g., a LAN whose network complies with IEEE 802.1Q bridges). These MAC addresses are used as source addresses for frame exchanges initiated by entities within the link aggregation sublayer 270 itself (i.e., LACP 214 and tag protocol exchanges).

Aggregator 250 (and other aggregators, if deployed) is assigned a MAC address that is unique to the LAG and to the bridged LAN (e.g., a LAN bridged in accordance with IEEE 802.1Q) to which the LAG is connected. This address is used as the MAC address of the LAG from the perspective of aggregator client 202, serving as the source address for transmitted frames and the destination address for received frames. The MAC address of aggregator 250 can be one of the MAC addresses of the aggregated ports in the associated LAG.

Distributed Resilient Network Interconnect (DRNI)

Link aggregation creates a link aggregation group (LAG), which is a collection of one or more physical links that appears to higher layers as a single logical link. A LAG has two ends, each terminating in an aggregation system. DRNI extends the concept of link aggregation so that at either or both ends of a LAG, the single aggregation system is replaced by portals, each consisting of one or more aggregation systems.

DRNI is created by interconnecting two or more systems using distributed relays, each running link aggregation to create a portal. Each aggregation system in a portal (i.e., each portal system) runs link aggregation using a single aggregator. Distributed relays enable portal systems to jointly terminate a link aggregation group. To all other aggregation systems connected to the portal, the link aggregation group appears to terminate in a single simulated aggregation system created by the portal system.

Update the set of embodiments of the conversation allocation

FIG3 is a flow chart illustrating a process for updating conversation allocations for an aggregation port according to one embodiment of the present invention. The operations of this and other flow charts will be described with reference to exemplary embodiments of other figures (e.g., the embodiment illustrated in FIG11 ). However, it should be understood that the operations of the flow charts may be performed by embodiments of the present invention other than the embodiments discussed with reference to these other figures, and that embodiments of the present invention discussed with reference to these other figures may perform operations different from those discussed with reference to the flow charts.

The process illustrated in FIG3 can be implemented in a network including one or more network devices that deploy one or more link aggregation groups (such as network devices 120 and 122 in FIG1A and network devices including portals 112 and 114 in FIG1B ). The process is used to update the conversation assignments of the aggregation ports of the link aggregation group when the link aggregation group transmits one or more conversations, where each conversation is associated with a service or application in the network.

The process begins at block 301 by verifying that an implementation of the conversation-sensitive Link Aggregation Control Protocol (LACP) is operational. The conversation-sensitive LACP implementation must be operational, that is, LACP must be able to coordinate the collection and distribution of conversation-sensitive frames between a pair of actor and partner network devices. For example, the verification at block 301 can be performed by verifying that the conversation-sensitive LACP implementation is capable of transmitting and receiving LACPDUs that indicate port algorithms (used to assign frames to various conversations) by the actor and partner network devices, respectively. That is, the verification includes verifying that the port algorithm used by the network device (the actor network device) can be transmitted to the partner network device by the conversation-sensitive LACP implementation. In an alternative or additional embodiment, the verification includes verifying the consistency of the conversation identifier digest and the conversation service mapping digest, as discussed in more detail below. Without verification, the network device does not know whether it can transmit conversation-sensitive information via LACP, and the process for receiving conversation-sensitive LACP information is bypassed. When verification fails, the network device sends a notification of management action.

After verifying that the implementation of conversation-sensitive LACP is operational, the process flows to block 303. At block 303, the network device determines that operation via enhanced LACPDUs is possible based at least in part on a compatibility check. Enhanced LACPDUs are LACPDUs that can be used to update conversation allocation information for a link aggregation group, and they may not operate under all conditions. The compatibility check determines whether the set of operational parameters of the network device associated with the aggregation port matches the matching set of operational parameters of the partner network device associated with the matching port on the partner network device. The partner network device is a remote network device communicatively coupled to the network device. If the operational parameter sets match, process 300 continues. Optionally, if the operational parameter sets do not match, a notification may be sent to the management system of the link aggregation group, and the network operator may resolve the mismatch.

The enhanced LACPDU is different from the traditional LACPDU. The traditional LACPDU (such as the LACPDU compliant with IEEE Standard 802.1AX Version 1) has a frame size of 128 octets. If each bit of the 128 octets is used to indicate the state of the conversation, the traditional LACPDU may only contain up to 128×8=1024 conversations. However, the link aggregation group may also support more than 1024 conversations. For example, some embodiments may need to support up to 4096 conversations, and thus, for these embodiments, the traditional LACPDU is not sufficient, and for process 300, a different type of LACPDU is utilized, referred to as the enhanced LACPDU. In one embodiment, the enhanced LACPDU includes fields for a port algorithm TLV, a port conversation ID digest TLV, a port conversation mask, and/or a port conversation service mapping TLV.

After confirming that operation via the enhanced LACPDU is possible, the process then proceeds to block 305, where the conversation allocation state of the link aggregation group of the network device is updated. This update is based on a determination that the conversation allocation state of the aggregation port is inaccurate. The conversation allocation state indicates a list of conversations passing through the aggregation port. For example, when each conversation is identified by a conversation identifier (ID), the conversation allocation state of the aggregation port may contain a set of conversation IDs indicating the set of conversations passing through the port.

In certain situations, the conversation state of an Aggregation port on a network device may become out of sync with that of an Aggregation port on a partner network device. For example, an Aggregation port on a link aggregation group of a network device may be configured to transmit/receive conversations identified as conversations 1-5, resulting in the Aggregation port's conversation allocation state indicating that conversations 1-5 are passing through the conversation port. However, a matching port on a link aggregation group of a partner network device may be configured to transmit/receive conversations identified as conversations 1-7 (e.g., due to a different port on the partner network device being out of service). The conversation allocation state of the Aggregation port on the network device is out of sync with that of the partner network device, and is therefore considered incorrect. A similar problem occurs when another port on the same link aggregation group of a network device is configured to transmit/receive conversations identified as conversations 5-7. In this case, the Aggregation port's conversation allocation state is out of sync with the other port on the same link aggregation group, and conversation 5 cannot pass through both ports while preserving the order of the conversations' frames. In other words, a synchronization failure can simply be characterized as a failure or malfunction of the distribution algorithm (or related process) on the LAG side, which ensures that conversations are assigned to only a single port. Once the conversation allocation state of the aggregation port is determined to be incorrect, the conversation allocation state of the aggregation port is updated, for example, to match the conversation allocation state of a matching port on a partner network device, or to match the conversation allocation state of another port in the same link aggregation group on the network device.

Embodiment of a TLV for conveying conversation allocation state for an aggregate port

The conversation allocation state of an aggregate port needs to be represented in a data format transmitted via LACP. In one embodiment of the present invention, the conversation allocation state of an aggregate port is conveyed using a TLV format. FIG4A illustrates a conversation mask TLV for an aggregate port according to one embodiment of the present invention. Conversation mask TLV 400 contains four fields: TLV type 402, conversation mask length 404, conversation mask state 406, and port operation conversation mask 408. In other embodiments, the fields may not be positioned in the order illustrated in FIG4A , and other embodiments may contain more or fewer fields.

TLV Type 402 indicates the nature of the information carried in the TLV tuple. In one embodiment, the Conversation Mask TLV is identified by the integer 0x06. Conversation Mask Length 404 (labeled as Conversation_Mask_Length in FIG. 4A ) indicates the length in octets of the TLV tuple. The total length of the Conversation Mask TLV is 515 octets, so this field contains the value 515. In various embodiments, Conversation Mask Length 404 contains a value greater than or less than 515.

The conversation mask state (labeled as Conversation_Mask_State in FIG. 4A ) indicates the state of the conversation mask. FIG. 4B illustrates the conversation mask state field within the conversation mask TLV for an aggregation port according to one embodiment of the present invention. Conversation mask state 450 (an embodiment of conversation mask state 406) contains 8 bits (one octet), of which seven of the eight bits are reserved for future use (reserved 411-414). The remaining bit is a flag that indicates whether the conversation mask used by the frame distributor of the aggregation port of the link aggregation group of the network device is the same as the conversation mask used by the frame distributor of the associated aggregation port of the link aggregation group of the partner network device. This flag is therefore a synchronization flag, referred to as ActPar_Sync 410 in FIG. 4B . In one embodiment, the synchronization flag is a Boolean value and indicates "true" if the conversation mask used by the frame distributor of the aggregation port of the local network device is the same as the conversation mask used by the frame distributor of the aggregation port of the partner network device, and indicates "false" otherwise.

The port operation conversation mask 408 (labeled Port_Oper_Conversation_Mask in FIG. 4A ) contains a Boolean vector value indicating whether the indexed port conversation identifier (ID) is distributed across a specific Aggregation Port. In one embodiment, the Boolean vector value is constructed based on a preference agreement. The preference agreement dictates that a given conversation be directed to a single Aggregation Port of a Link Aggregation Group. Based on this information, the port operation conversation mask can be configured to indicate that the conversation indexed by the conversation identifier is transmitted on the Aggregation Port.

FIG4C illustrates the port operation conversation mask for an aggregate port in a link aggregation group of a network device, according to one embodiment of the present invention. Port conversation mask 470 (labeled as Port_Oper_Conversation_Mask in FIG4C ) is an embodiment of port operation conversation mask 408 and contains 4096 bits (512 octets x 8 bits/octet = 4096 bits), with each bit indicating whether a given conversation is transmitted (or received; if it is a distributor mask, transmitted; if it is a collector mask, received) via the aggregate port. As illustrated, reference 420 in bit 0 is for conversation 0, reference 421 in bit 1 is for conversation 1 (i.e., conversation ID = 1, similarly applicable to other conversations), and references 422 in bit 2 and 423 in bit 3 are for conversations 2 and 3, respectively. Finally, reference 424 in bit 4095 indicates whether conversation 4095 is transmitted on the aggregate port. In one embodiment, the Boolean value of the conversation indicates "true" when the conversation is transmitted via the aggregate port. When a link aggregation group can support up to 4096 conversations (addressable using 12 bits), a 512-octet port conversation mask 470 can indicate all permutations of possible conversations that can be transmitted over the link aggregation port. Note that some embodiments can support more or less than 4096 conversations and accordingly can implement the length of the port operation conversation mask to accommodate different maximum numbers of conversations.

Note that the Conversation Mask TLV 400 contains 515 octets, which is much longer than 128 octets, which is the length of a LACPDU in version 1 of the IEEE 802.1AX standard. Thus, in one embodiment of the present invention, a "long" LACPDU is required to transmit the Conversation Mask TLV.

In another embodiment, multiple TLVs are used to implement the port conversation mask. Figure 12-C illustrates an embodiment of implementing the conversation mask using three TLVs (Conversation Mask-1 through Mask-3 TLVs) for aggregated ports, according to one embodiment of the present invention. Referring to Figure 12A , Conversation Mask-1 TLV 1200 contains four fields, similar to Conversation Mask TLV 400 of Figure 4A : TLV Type 1202 , Conversation Mask-1 Length 1204 , Conversation Mask Status 1206 , and Port Operation Conversation Mask-1 1208 .

[00106] TLV Type 1202 identifies the type of information carried in the TLV tuple. In one embodiment, Conversation Mask-1 TLV may be identified by the integer 0x06. Conversation Mask-1 Length 1204 (labeled as Conversation_Mask_1_Length in FIG. 12A) indicates the length in octets of the TLV tuple. In one example embodiment, the length of Conversation Mask-1 TLV is 195 octets, so that field 1204 contains the value 195. In one embodiment, Conversation Mask State 1206 and Port Operation Conversation Mask-1 208 are fields constructed similarly to Conversation Mask State 406 and Port Operation Conversation Mask 408 described herein above with reference to FIG. 4B and FIG. 4C, respectively.

Figure 12B illustrates a Conversation Mask-2 TLV for an aggregation port according to one embodiment of the present invention. Conversation Mask-2 TLV 1210 contains three fields: TLV Type 1212, Conversation Mask-2 Length 1214, and Port Operation Conversation Mask-2 1216. These fields serve similar functions to the corresponding fields in Conversation Mask-1 TLV 1200.

Figure 12C illustrates the Conversation Mask-3 TLV for an aggregated port according to one embodiment of the present invention. Conversation Mask-3 TLV 1220 also contains three fields: TLV Type 1222, Conversation Mask-3 Length 1224, and Port Operation Conversation Mask-3 1226. These fields each serve similar functions to the corresponding fields of Conversation Mask-1 TLV 1210. In one example embodiment, the length of Conversation Mask-3 is 130 octets, and the total length of the three combined port conversation masks is 512 octets. The first two conversation masks already contain 384 octets (i.e., 192 octets each) for the port operation conversation masks, leaving only 130 octets required for the third port conversation mask, which is equal to the size of the port conversation mask described above with reference to Figures 4A-C. Thus, those skilled in the art will appreciate that alternative embodiments with three Conversation Mask TLVs can be used instead of a single TLV, and furthermore, the TLV can be divided into any number of separate TLVs according to the same principles discussed herein. Similarly, where embodiments are discussed herein with reference to utilizing a single Conversation Mask TLV, it will be understood that alternative embodiments having multiple Conversation Mask TLVs are also contemplated.

FIG5A illustrates one embodiment of a TLV that may be included in an enhanced LACPDU to exchange information about the state of conversation ID digests maintained by each aggregation system. The TLV is referred to herein as a Port Conversation Service Mapping TLV. The TLV includes a set of fields 502, 505, and 506 with the following field definitions: TLV_type 502 contains a value indicating that the TLV type is a Port Conversation Service Mapping Digest. A digest is a cryptographic hash or similar processing of data to generate an identifier that can be used to uniquely (or nearly uniquely) identify the processed data, enabling error checking and file content comparison (for example, if two files have different contents, their digests will be different). This field indicates the nature of the information carried in this TLV tuple. In one embodiment, the Port Conversation Service Mapping Digest TLV may be identified by the integer value 0x0A. The second field is the Port_Conversation_ServiceMapping Digest_Length field 505. This field indicates the length (in octets) of this TLV tuple. In one embodiment, the Port Conversation Service Mapping Digest TLV uses a length value of 18 (0x12). The third field is the Actor_Conversation_Service_Mapping_Digest 506. This field contains the value of the message digest (MD5) calculated from aAggAdminServiceConversationMap[] for exchange with the partner system. aAggAdminServiceConversationMap[] is an array of service ID to conversation ID mappings maintained by the network device. There are 4096 variables, aAggAdminServiceConversationMap[0] to aAggAdminServiceConversationMap[4095], indexed by the port conversation ID. Generally, each contains a unique set of service IDs within the array. If the service ID is representing a VID, only a single VID can apply, while in the case where the service ID is representing an I-SID, more than one I-SID is possible. Partner systems can compare the MD5 digest values to determine if there are any differences between the mappings maintained by each partner system.

FIG5B is a diagram of one embodiment of an aggregated admin service conversation map. The diagram illustrates the fields of the aggregated admin service conversation map, which is an array indexed by port conversation ID and contains service IDs or integers representing service IDs. In one embodiment, the aggregated admin service conversation map (aAggAdminServiceConversationMap[]) is an array of integers (such as 32-bit or 64-bit integers). In other embodiments, the array can have values of any size, number, or type. The aggregated admin service conversation map can be used to convert a service ID into a conversation ID, and vice versa. The conversation ID can be used to index into the array to retrieve the service ID. The array can be traversed to find the service ID, and the corresponding index is the conversation ID.

FIG13 illustrates a set of TLVs required to support conversation-sensitive frame collection and distribution functionality according to one embodiment of the present invention. The TLV set includes a Port Algorithm TLV, a Port Conversation ID Summary TLV, a Port Conversation Mask-1 through Mask-3 TLVs, and a Port Conversation Service Mapping TLV. Each of these TLVs has been discussed herein. In one example embodiment, the Port Algorithm TLV 1302 has a Type field value of 0x04. The Port Conversation ID Summary TLV has a Type field value of 0x05. The Port Conversation Mask-1 through Mask-3 have Type field values of 0x06 through 0x08, respectively. In one embodiment, the TLV set forms an enhanced LACPDU to implement the embodiments of the present invention illustrated in FIG3-6 and discussed herein.

Another set of embodiments for updating conversation allocation

FIG6 is another flow chart illustrating a process for updating session assignments for an aggregation port according to one embodiment of the present invention. This process can be implemented in a network comprising one or more network devices (such as network devices 120 and 122 in FIG1A ) that deploy a link aggregation group. This process can also be implemented in portals 112 and 114 in FIG1B . It is noted that process 600 is illustrated using blocks 602-616, which are overlaid with dotted lines from blocks 301-305 to indicate that process 600 is an embodiment of the present invention that implements process 300.

6 , the process begins by initializing conversation-sensitive LACP at block 602. In one embodiment, initialization includes recording the partner network device's default port algorithm as the partner network device's current operating port algorithm at the network device (e.g., using the recordDefaultPortAlgorithm() function to record the default port algorithm as the partner network device's current operating parameter at the network device). Initialization includes recording the partner network device's default conversation port conversation identifier (ID) digest as the partner network device's current operating parameter at the network device's conversation port digest (e.g., using the recordDefaultConversationPortDigest() function to record the default conversation port conversation ID digest as the partner network device's current operating parameter at the network device). Initialization may further include recording the partner network device's default conversation mask as the partner network device's current operating conversation mask at the network device (e.g., using the recordDefaultConversationMask() function to record the default conversation mask as the partner network device's current operating parameter at the network device). Additionally, initialization may include recording the default conversation service mapping digest of the partner network device as the current operational conversation service mapping digest of the partner network device at the network device (e.g., using a recordDefaultConversationServiceMappingDigest() function to record the default conversation service mapping digest as the current operational parameters of the partner network device at the network device). When the operational parameters of the partner network device are recorded using the default values, conversation-aware LACP is initialized.

The process continues at block 603, where the network device receives information about the port algorithm, the port conversation ID digest, and/or the conversation service mapping digest from the partner network device. The received information is used to record parameter values as operational values for the network device. The network device receives the information as a TLV embedded in the LACPUD. The information about the port algorithm identifies the port algorithm and is carried in the recordPortAlgorithmTLV, with the value carried being recorded as the current operational parameter value of the partner network device (e.g., the operational parameter is Partner_Port_Algorithm). The information about the port conversation ID digest is carried in the recordConversationPortDigestTLV, with the value carried being recorded as the current operational parameter value of the partner network device (e.g., the operational parameter is Partner_Conversation_PortList_Digest). Additionally, information about the conversation service mapping digest is carried in the recordConversationServiceMappingDigestTLV, with the value carried being recorded as the current operational parameter value of the partner network device (e.g., the operational parameter is Partner_Admin_Conversation_PortList_Digest). Once the information is received, the conversation sensitivity is verified as operational, as described in block 301 of Figure 3. Similar to block 303 of Figure 3, process 600 flows to blocks 604-606 and performs operations to determine that operation via enhanced LACPDUs is possible based at least in part on the compatibility check.

6 , at block 604, the network device determines whether the port algorithm used by the network device is the same as that used by the partner network device of the link aggregation group. The network device's operating port algorithm may be stored in a variable such as Actor_Port_Algorithm for the link aggregation group, while the partner network device's operating port algorithm may be stored in a variable such as Partner_Port_Algorithm for the same link aggregation group. The network device compares these two variables and determines whether they are consistent. For example, a function such as Differ_Port_Algorithms may be used, where Differ_Port_Algorithms returns a Boolean indicating whether the port algorithms used by the network device and the partner network device at both ends of the link aggregation group are the same. If the two variables are inconsistent, a notification may be optionally sent to inform the operator that the link aggregation group has resolved the anomaly.

If the two variables match, the process proceeds to block 605, where the network device determines whether the conversation ID digest used by the network device is the same as that of the partner network device of the link aggregation group. The network device's operational conversation ID digest may be stored in a digest such as Actor_Conversation_PortList_Digest, while the partner network device's operational conversation ID digest may be stored in a digest such as Partner_Conversation_PortList_Digest. The network device compares the two digests and determines whether they match. For example, a function such as Differ_Port_Conversation_Digests may be used, where Differ_Port_Conversation_Digests returns a Boolean indicating whether the port conversation digests used by the network device and the partner network device at both ends of the link aggregation group are the same. If the two digests do not match, a notification is optionally sent to inform the operator that the link aggregation group has resolved the anomaly.

If the two variables match, the process proceeds to block 606, where the network device determines whether the conversation service mapping digest used by the network device is the same as that used by the partner network device of the link aggregation group. The network device's operational conversation service mapping digest may be stored in a digest such as Actor_Conversation_Service_Mapping_Digest, while the partner network device's operational conversation service mapping digest may be stored in a digest such as Partner_Conversation_Service_Mapping_Digest. The network device compares the two digests and determines whether they match. For example, a function such as Differ_Conversation_Service_Digests may be used, where Differ_Conversation_Service_Digests returns a Boolean indicating whether the conversation service mapping digests used by the network device and the partner network device at both ends of the link aggregation group are the same. If the two digests do not match, a notification is optionally sent to inform the operator that the link aggregation group has resolved the anomaly.

Note that in some embodiments of the invention, the order of determination of blocks 604-606 may differ from that illustrated in Figure 6. Furthermore, some embodiments of the invention may deploy more or fewer compatibility checks as illustrated.

Once the operating parameters (however, some of these parameters may be considered management parameters) of the network device and the partner network device in the same link aggregation group are determined to be compatible, and both declare long LACPDUs (also referred to as version 2 LACPDUs), processing of conversation-sensitive information received via long LACPDUs becomes possible. Each long LACPDU is longer than 128 octets. As discussed above, enhanced LACPDUs require updated conversation allocation information because conventional LACPDUs may only support up to 1024 conversations. Long LACPDUs are one embodiment of enhanced LACPDUs, and other embodiments of enhanced LACPDUs are possible to support the disclosed invention. Enhanced LACPDUs, in a generalized form, can carry the control information required to exchange conversation allocation information on the links of the link aggregation group between the local network device and the partner network device. Some embodiments may not use long LACPDUs, for example when the LACP implementation only supports up to 1024 conversations. In other embodiments, long LACPDUs are used. Because each LACPDU is longer than 128 octets, it can support more conversations than conventional 128-octet LACPDUs. For example, a long LACPDU may transmit the conversation mask TLV illustrated in FIG4A , which may indicate a conversation allocation state of up to 4096 conversations. Long LACPDUs take more network resources to process and transmit, and it may not be efficient to always allow their transmission. Thus, block 608 may set a timer to provide a time window for the network device to transmit the LACPDU. Once the timer expires, the network device no longer transmits the long LACPDU, and the process ends without updating the conversation allocation. In the case where the timer for the long LACPDU is set, the network device determines that operation through the enhanced LACPDU (utilizing the long LACPDU in this embodiment of the present invention) is possible, as described in block 303 of FIG3 . Similar to block 305 of FIG3 , process 600 flows to blocks 608-622 and updates the conversation state of the aggregation port.

6 , at block 608, the network device receives one or more long LACPDUs from a partner network device, indicating different operational session allocation states at the partner network device. The operational session allocation state at the partner network device is the operational session mask of the partner network device conveyed by the received long LACPDU. The received long LACPDU may contain the operational session allocation state embedded within a single Session Mask TLV. In another embodiment, the operational session allocation state of the partner network device is embedded within multiple Session Mask TLVs (such as Session Mask-1 through Mask-3 illustrated in FIG. 12A-C ).

In one embodiment, for embodiments with multiple conversation mask TLVs, a function (such as recordReceivedConversationMaskTLV) is executed. The function records the parameter value of ActPar_Sync carried in the received PortConversationMask-1 TLV as the current operational parameter value of Partner_ActPar_Sync, concatenating the values of Port_Oper_Conversation_Mask_1, Port_Oper_Conversation_Mask_2, and Port_Oper_Conversation_Mask_3 carried by the PortConversationMask-1 TLV, PortConversationMask-2 TLV, and PortConversationMask-3 TLV, respectively, and records the concatenation as the current value of the PartnerConversationMask variable. When comparing the operational conversation allocation states at the partner network device and the local network device, at block 616, the function compares the variable PortConversationMask with the PartnerConversationMask.

The network device may not receive the long LACPDU, but instead detects a change in the operational state or administrative configuration of the port's link aggregation group at block 612. The network device may include a variable for each port of the aggregation group to track changes in the operational state of each port. For example, the network device may set a ChangeActorOperDist variable for each port, and this variable is set to true when the frame distribution state changes. The variable may be represented as the logical OR of the ChangeActorOperDist variables corresponding to all aggregation ports. The per-port variable ChangeActorOperDist may also track administrative configuration changes. For example, if a new administrative value for the aggregation port selection priority list tracked by aAggConversationAdminPort[] (which contains administrative values for the aggregation port selection priority list that references a port conversation ID) or a new administrative value tracked by aAggAdminServiceConversationMap[] (which contains a set of service IDs) is detected, the variable may be set to true. Consequently, also at block 612, the network device updates its operational conversation allocation state. In one embodiment, this update occurs by updating its operational conversation mask. In both cases, at block 616, the network device updates the port's collection conversation mask. In one embodiment, the collection conversation mask is an operational Boolean vector. It is indexed by the port conversation ID and indicates whether the indexed port conversation ID is allowed to reach the aggregator when received through the conversation port. The network device then checks to see if its operational conversation mask matches the mask used by the partner network device. In one embodiment, this verification is performed by checking the Partner_Oper_Conversation_Mask variable in the network device.

In one embodiment, the network device sets the port's collection conversation mask differently depending on whether the conversation masks of all aggregated ports (including intra-portal ports (IPPs) in the network device have been updated in the case of portals). If all conversation masks on all ports have been updated, the network device sets the port's collection conversation mask to be equal to the updated port's operational conversation mask (the updated port's operational conversation mask can be obtained based on the current conversation port list through an update function (e.g., updateConversationMask)). If the update of conversation masks for other ports in the network device is still in progress, the network device sets the port's collection conversation mask to be equal to a Boolean vector corresponding to the result of a logical AND operation (e.g., through the updateConversationMask function) between the current collection conversation mask and the updated port's operational conversation mask.

The network device indicates that the collection conversation mask is not synchronized with the distribution conversation mask (using the ActPar_Sync bit of the Conversation Mask Status field of the Conversation Mask TLV, such as illustrated in FIG4B ). As discussed above, the network device may include a variable for each port of the aggregation group to track changes in the operational state of each port, such as a ChangeActorOperDist variable for each port, where ChangeActorOperDist tracks the operational port of the network device distributing frames. The network device will set this variable to "false" to indicate that there has been no change in the frame distribution state.

When the port's operational conversation mask matches the operational conversation mask of the matching port on the partner network device, the process proceeds to block 622, and since both network devices (partners) have the same operational conversation mask, the process of sending long LACPDUs is stopped. When the port's operational conversation mask does not match the operational conversation mask of the associated port on the partner network device, the process proceeds to block 617, where an out-of-sync is detected.

The network device then sets a timer for sending an update long LACPDU to the remote network device at block 618. When the conversation mask is out of sync, it sets the update local setting to "true" (eg, using updateLocal to indicate that the local conversation mask does not need to be updated).

Example of updating the dialog mask

FIG7 is a flow chart illustrating updating the conversation mask of an aggregation port upon receiving a long LACPDU according to one embodiment of the present invention. Method 700 may be implemented in an aggregation controller of a network device. At block 705 in FIG7 , a long LACPDU containing a different conversation allocation state at a partner network device is received at the network device. When the long LACPDU contains a conversation mask for a partner network device that is different from the conversation mask at the conversation port (i.e., the partner network device has sent a different conversation mask), the network device determines whether the partner network device has sent a different conversation mask by checking a partner operation conversation mask variable, such as Partner_Oper_Conversation_Mask. The partner operation conversation mask variable is a variable associated with each link aggregation port. In one embodiment, the variable is stored in a storage device within the network device.

In one embodiment, the partner operational conversation mask is communicated via a conversation mask TLV, as illustrated in FIG4A . Upon receiving a new conversation mask TLV, the partner operational conversation mask embedded in the new conversation mask TLV updates the aggregation port's partner operational conversation mask variable. Consequently, the partner operational conversation mask variable of the link aggregation port is synchronized with the conversation mask of the partner network device operating on the port in the link aggregation group. The network device compares the partner operational conversation mask variable with the port operational conversation mask, and any discrepancies trigger block 616 .

7 , at block 707 , the collection conversation mask of the aggregation port is updated based on an update conversation mask function (eg, updateConversationMask function).

At block 708, the network device sets an indication that the conversation mask used at the network device is different from the conversation mask used at the partner network device. In one embodiment, a conversation mask state value (such as the ActPar_Sync bit at reference 410 of FIG. 4B ) may be set to indicate the difference.

Although FIG. 7 illustrates an order of operations, the order of operations may differ in other embodiments of the invention, for example, blocks 707 - 708 may be ordered differently in another embodiment of the invention.

Note that although aggregate ports are used in the discussion related to FIG. 7 , method 700 may be implemented for a portal of a Distributed Resilient Network Interconnect (DRNI) system whose network devices also implement aggregate ports as shown in FIG. 1B .

Figures 8A-D illustrate a sequence for updating the conversation mask of an aggregation port according to one embodiment of the present invention. Each figure includes the partner conversation mask variable associated with the aggregation port and also includes the values of the collection mask, distribution mask, and conversation mask state associated with the aggregation port. In Figure 8A, the aggregation port is operating in a normal state. The collection conversation mask and the distribution conversation mask are identical, both 01010101...00. In this example, the link aggregation group supports up to 4096 conversations, so the collection conversation mask and the distribution conversation mask contain 4096 bits (512 octets). For simplicity of illustration, only the first 10 bits and the last 2 bits of the mask are illustrated, so that the discussion focuses on conversations 0 to 9 (conversation IDs: 0 to 9) and conversations 4094 and 4095 (conversation IDs: 4094 and 4095). As shown, the aggregation port handles conversations 1, 3, 5, and 7. The port distributes and collects subframes of the same conversations 1, 3, 5, and 7. The partner conversation mask variable is the same as the collection conversation mask and the distribution conversation mask, and it indicates that conversations 1, 3, 5, and 7 are transmitted on the matching ports of the link aggregation group of the remote network device. Therefore, the conversation mask state indicates that the collection conversation mask and the distribution conversation mask are the same as the partner conversation mask encoding by setting the ActPar_Sync bit to 1, and thus, the conversation mask state is 10000000.

In FIG8B , an anomaly occurs in the link aggregation group, and the partner conversation mask variable is updated to a different value. The triggering event may be a link failure, a failure in the portal's link aggregation system, or some other event. The anomaly may trigger the transmission of one or more enhanced LACPDUs, such as long LACPDUs, and the receipt of the enhanced LACPDUs at the network device. An embedded TLV (such as the conversation mask TLV 400 illustrated in FIG4A ) is used to update the partner conversation mask variable associated with the aggregation port. The changed bit values of the partner conversation mask variable are highlighted by underscores, and the same notation applies to FIG8C-D . The partner conversation mask variable now instructs the partner network device to transmit conversations 0-3 to the aggregation port. It no longer transmits conversations 5 and 7, but has added conversations 0 and 2.

The network device then stores the partner conversation mask variable and maintains the aggregate port collection and distribution of frames for conversations 1, 3, 5, and 7. As before, the conversation mask used by the local network device (actor) is different from that of the remote system (partner). The conversation mask state indicated by the ActPar_Sync bit is reset to 0, and the variable updateLocal is set to 1 to indicate that the local conversation mask needs to be recalculated.

In FIG8C , a long LACPDU has arrived, and if all ports on the local network device have not been updated to match the same conditions as the partner, the collection conversation mask and the distribution conversation mask are updated via a logical AND operation between the current collection conversation mask and the updated port operation conversation mask (e.g., via an update operation, such as executing the updateConversationMask function). Consequently, the collection conversation mask and the distribution conversation mask are updated to 01010000..00 (i.e., the conversation port only collects frames from common conversations 1 and 3). Then, in FIG8D , all ports on the local network device have been updated to match the same conditions as the partner and, accordingly, are reported with the same Actor_Oper_Port_State. If the connection port on the remote partner is down, it sets the ActPar_Sync bit to 1, indicating that synchronization of the collection conversation mask with the distribution conversation mask has been completed on the partner port of the partner network device. The collection conversation mask can then be set to the same as the distribution conversation mask, and only frames for conversations 0-3 are collected, following the partner conversation mask variable.

Figure 9 is a flow diagram of one embodiment of a process for conversation-sensitive collection of link aggregation groups. The illustrated process is implemented in conjunction with a frame collection process. That is, this process involves handling frames containing regular data traffic, as opposed to handling LACPDUs as discussed above herein. Also, as described above herein, the frame collection process receives frames from the aggregation ports and collects them based on a port algorithm utilized in conjunction with the partner system's frame distributor. Where conversation-sensitive collection and distribution is implemented, the illustrated process implements conversation allocation per aggregation port. Conversations are assigned to specific ports such that frames for a given conversation arriving at a non-assigned aggregation port are out of order, as a result of a conversation reallocation to another aggregation port or similar issues.

The process may be initiated in response to receiving a frame on a link in a link aggregation group associated with a network device performing the process (block 901). The network device communicating on the link aggregation group may be part of a DRNI portal or similar network configuration. The received frame may be in any type of communication format, such as an Ethernet frame or similar communication unit. The frame may be received via an aggregation port and passed to a frame collector of the network device. In one embodiment, conversation-sensitive frame collection may be enabled and disabled via an administrative function or configuration. In other embodiments, conversation-sensitive frame collection is always enabled. Where conversation-sensitive frame collection is configurable, the frame collector may check whether conversation-sensitive frame collection is currently enabled (block 903). If conversation-sensitive frame collection is not enabled, the received frame is forwarded to the aggregator client (block 905). The frame collector organizes the received frames from all aggregator ports according to an aggregation algorithm or distribution process employed by the partner system.

When conversation-sensitive collection is enabled, a conversation identifier for the received frame may be determined (block 907). The conversation identifier may be determined using any process or technique utilizing information within the received frame such that both the frame distributor and the frame collector utilize the same process or technique to deterministically obtain the same conversation identifier. In one example implementation, a service identifier is extracted from the received frame. The service identifier may be any field or combination of fields in the received frame, such as a virtual local area network (VLAN) identifier (VID) field or a backbone service instance identifier (I-SID). The service identifier may then be converted into a conversation identifier. The conversion may utilize any local data structure, such as a lookup table, a mapping array, or similar data structure, to map the service identifier and the conversation identifier.

The resulting conversation identifier can then be compared to a conversation mask or similar data structure that tracks conversations that have been assigned to a specific Aggregation Port (block 911). If a match is found, the received frame is part of a conversation that has been assigned to the Aggregation Port, it is received on the Aggregation Port and is therefore in the proper order, and the frame collector can pass the frame to the Aggregator Client. However, if no match is found in the conversation mask or similar tracking structure, the received frame has been received out of order on the wrong Aggregation Port and is then discarded (block 913).

FIG10 is a flow chart of another embodiment of a process for conversation-sensitive collection of link aggregation groups. This embodiment provides an example implementation of the process described above with respect to FIG9 . In response to receiving a frame (block 901 ), a frame pointer or identifier may be received from a MAC aggregation port of a network device, where the aggregation port is associated with a link aggregation group (block 1001 ). A link aggregation group may be defined between two partner systems, namely, an aggregation system and a DRNI portal. The frame may be stored in any memory device, buffer, cache, register, or similar storage location within a network processor or within the network device. The pointer or similar identifier may provide location information for accessing the frame.

The received frames may be in any type of communication format, such as Ethernet frames or similar communication units. The frames may be received via an aggregation port and passed to a frame collector of the network device via a control parser/multiplexer and an aggregator parser/multiplexer, wherein the frame collector is a subcomponent of the aggregator of the link aggregation sublayer executed by the network processor of the network device. In one embodiment, conversation-sensitive frame collection can be enabled and disabled via a management function or configuration. In other embodiments, conversation-sensitive frame collection is always enabled. Where conversation-sensitive frame collection is configurable, the frame collector may check whether conversation-sensitive frame collection is currently enabled (block 903) by checking whether a flag or similar status indicator (e.g., an "enable error conversation drop" flag) is set in the configuration of the aggregator or similar location (block 1003). If conversation-sensitive frame collection is not enabled, the received frame, frame pointer, or similar frame identifier is forwarded to the aggregator client (blocks 905, 1005). The frame collector collects received frames from all aggregator ports according to an aggregation algorithm or distribution process employed by the partner system.

The frame is processed to determine the associated conversation identifier (block 907) using any function (e.g., a DeterminePortConversationID function) that utilizes a shared deterministic process between the frame collector and the frame distributor. In one exemplary embodiment, such a function may determine the conversation identifier by accessing the frame to extract the service ID (block 907), first examining the frame content and format to determine the service ID format and location by comparing the frame header information with the frame conversation assignment configuration information (block 1007). The frame format and configuration information may indicate the service ID in the form of a 12-bit VID field, a 24-bit I-SID field, or similar fields, or a combination thereof, depending on the frame format. The configuration may specify any field or set of fields to be used as the service ID for the received frame. The process then continues by retrieving the service ID from the frame using the service ID type and location information (block 1009). For example, the frame pointer and location information may take the form of an address and offset, respectively, enabling the frame collector to access and retrieve values at specified locations.

The retrieved service ID can then be used to obtain (i.e., converted into) a corresponding conversation identifier (block 909). The conversion process can take the form of a lookup table using a conversation service mapping table (i.e., an aAggAdminServiceConversationMap[] array, which uses the conversation identifier as an index and stores the service ID). The lookup table can use the service ID as an index and can traverse the data structure to match the service ID, or perform a similar lookup operation on the conversation service mapping digest. The lookup operation returns the corresponding conversation identifier for the received frame.

Can then check whether the received frame has the conversation identifier (piece 911) that has been assigned to the conversation of the aggregation port on which it is received.Can make clear this check by accessing the conversation mask of the aggregation port through which the frame is received, wherein the conversation mask is a bitmap or similar data structure (piece 1013) that is used to track the conversations assigned to the aggregation port.If the corresponding bit of the conversation identifier is set to Boolean "true" value, then this frame is associated with the conversation that is properly assigned to the aggregation port, and can be forwarded to the aggregator client (piece 1005).Yet, if the corresponding bit in the conversation mask is set to Boolean "false", then this frame is discarded (pieces 913, 1015), because frame is associated with the conversation that is not assigned to the aggregation port through which it is received, indicating that it is erroneously or disorderly sent due to reallocation process or similar changes.

FIG11 is a diagram of one embodiment of a network device that implements conversation-sensitive collection of link aggregation groups in a network. The network device may process conversations, each of which is for a service or application in the network. Network device 1180 may implement link aggregation sublayer 1170 described above with respect to FIG2 and support the link aggregation functionality described above. Network device 1180 may include a network processor 1100, a collection of ports 1140, a storage device 1150, and similar network device components. The components of the network device are provided by way of example and not limitation. Network device 1180 may implement aggregation functionality and link aggregation sublayer 1170 using any number or type of processors and in any configuration. In other embodiments, the aggregation functionality and link aggregation sublayer and related components are distributed across a collection of network processors, a collection of line cards, and their constituent general-purpose and application-specific processors, or similarly implemented within the network device architecture.

Ports 1140 can connect the network device to any number of other network devices via a physical medium such as Ethernet, fiber optics, or the like. Any number or type of ports can be present in network device 1180. Any combination or subset of ports 1140 can be organized and managed as a link aggregation group or DRNI portal, where the network device acts as an aggregation system.

The collection of storage devices 1150 within network device 1180 can be any type of memory device, cache, register, or similar storage device that can be used as working memory and/or permanent storage. Any number and type of storage devices 1150 can be utilized to store network device data, including programming data to be processed by network device 1180 and received data traffic. In one embodiment, summary database 1152 or a similar organization of conversation service map summaries, conversation allocation status for lists of conversations transmitted through aggregation ports, and similar data structures described above herein can be stored in such data structures. Other data structures stored in storage devices 1150 can include aAggAdminServiceConversationMap[] and similar data structures. In other embodiments, these data structures can be considered independent and distributed across any number of separate storage devices 1150 within network device 1180.

The collection of network processors 1100 may implement the aggregation functionality described above herein and the link aggregation sublayer 1170. The aggregation functionality may include an aggregator client 1172 and the link aggregation sublayer 1170, which may include the control parser/multiplexer 1102, the aggregation controller 1106, the frame collector 1125, the frame distributor 1120, and the client interface 1111. As further described above herein, the aggregator client 1172 may provide higher-level functionality of the network device, such as layer 3 functionality and similar higher-level functionality.

The aggregation controller 1106, described further above, implements link aggregation control and link aggregation control protocol functions. These functions manage the configuration and allocation of link aggregation groups, DRNI portals, and similar aspects. The control analyzer and multiplexer 1102 identifies LACPDUs and forwards LACPDUs from other data traffic received on the aggregation port, sending the LACPDUs to the aggregation controller 1106 and sending other data traffic to the link aggregation sublayer 1170.

The link aggregation sublayer 1170, described further above, manages the collection and distribution of frames according to a distribution algorithm. Within the link aggregation sublayer 1170, the frame collector 1125 receives frames and organizes them according to a distribution algorithm shared with partner systems on the link aggregation group. The frame distributor 1120 prepares and selects out-of-band frames for transmission on a set of aggregation ports based on the distribution algorithm. The client interface 1111 receives frames from and transmits them to the aggregation client 1172. In-band frames are transmitted from the frame collector 1125 to the aggregator client 1172, while out-of-band frames are transmitted from the frame distributor 1120 to the aggregator client 1172.

As discussed above herein with respect to conversation-sensitive collection of link aggregation groups, the frame collector 1125 is configured to determine a conversation identifier for a received frame (e.g., using a DetermineConversationID function that, in one example embodiment, extracts a service identifier from the frame and converts the service identifier into a conversation identifier, however, any deterministic process shared between the frame collector and the frame distributor may be utilized), compare the conversation identifier to the port conversation assignment, discard the frame in response to a mismatch between the conversation identifier and the port conversation assignment, and forward the frame to the aggregator client in response to a match between the conversation identifier and the port conversation assignment. Furthermore, in an example embodiment, the frame collector 1125 may check whether conversation-sensitive collection is enabled, may receive a frame pointer from an aggregation port associated with a link aggregation group, may extract a service identifier from a frame by comparing frame header information with a frame conversation assignment configuration to determine a service identifier format and location and retrieving the service identifier from the frame at the determined location, may convert the service identifier into a conversation identifier by looking up the service identifier in a conversation service mapping summary to obtain a conversation identifier, may compare the conversation identifier to a port conversation assignment by accessing a conversation mask of the aggregation port using the conversation identifier as an index, and may discard the frame in response to finding a Boolean "false" at a location in the conversation mask identified by using the conversation identifier as an index.

In one embodiment, the aggregation controller 1106 verifies that the implementation of the conversation-aware Link Aggregation Control Protocol (LACP) is operational. This verification is performed by the aggregation controller 1106 initializing the LACP implementation and then performing at least one of the following: (1) receiving an identifier of an algorithm for assigning frames to port conversation identifiers at a partner network device; (2) receiving a conversation identifier digest from the partner network device; and (3) receiving a conversation service mapping digest from the partner network device. The received parameters may be stored in the storage device 1150 (e.g., the digest data block 1152).

Aggregation controller 1106 then determines whether operation via enhanced LACPDUs is possible after verifying that the LACP implementation is operational. As discussed above, enhanced LACPDUs can be used to update session allocation information, and this determination is based on a compatibility check between a set of operating parameters of network device 1180 and another matching set of operating parameters of a partner network device of network device 1180. A partner network device is a remote network device at the other end of the link aggregation group of network device 1180. In one embodiment, enhanced LACPDUs are long LACPDUs, meaning they are greater than 128 octets in length.

In one embodiment, the compatibility check includes (1) determining that a first algorithm for assigning frames to a port conversation identifier at the network device is consistent with a second algorithm for assigning frames to a port conversation identifier received from the partner network device; (2) determining that a first conversation identifier digest of the network device is consistent with a second conversation identifier digest received from the partner network device; and (3) determining that a first conversation service mapping digest is consistent with a second conversation service mapping digest received from the partner network device. If the compatibility check passes, the aggregation controller 1106 processes the received aggregated sensitive information and sets a timer to provide a time window for transmitting an enhanced LACPDU. If the timer expires and no enhanced LACPDU is received, the partner's default configuration parameters are set and another verification/compatibility check cycle needs to be initiated.

If the compatibility check fails, enhanced LACPDUs cannot be used and manual intervention may be required, so the aggregation controller 1106 may optionally send out a notification indicating the compatibility check failure.

When the compatibility check passes, the aggregation controller 1106 may be configured to update the conversation allocation state of the aggregation port of the link aggregation group based on the determination that the conversation allocation state is incorrect. In one embodiment, the conversation allocation state of the aggregation port is represented by the conversation mask of the aggregation port. The conversation mask of the aggregation port may be represented by a conversation mask type/length/value (TLV), which contains (1) a TLV type field; (2) a conversation mask length field; (3) a conversation mask state field; and (4) a port operation conversation mask field. The structure of each field has been discussed above in this document. It is noted that the conversation mask may be represented by one or more conversation mask TLVs, as illustrated in Figures 4A-C and 12A-C and discussed above in this document.

Thus, in some embodiments, the aggregation controller may be viewed as comprising: a verification unit for verifying that an implementation of a conversation-sensitive link aggregation control protocol (LACP) is operable; a determination unit for determining that operation via an enhanced link aggregation control protocol data unit (LACPDU) is possible, wherein the enhanced LACPDU may be used to update conversation allocation information, wherein the determination is based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of a link aggregation group communicatively coupled to the network device; and an updating unit for updating a first conversation allocation state of an aggregation port of the link aggregation group based on a determination that the first conversation allocation state is incorrect, wherein the first conversation allocation state of the aggregation port of the link aggregation group indicates a first list of conversations transmitted through the aggregation port.

Updating the conversation allocation state may be based on determining that a first conversation allocation state of an aggregation port in a link aggregation group of the network device is different from a second conversation allocation state of an aggregation port received from a partner network device, wherein the second conversation allocation state indicates a second list of conversations received via the link aggregation group. Alternatively, updating the conversation allocation state may be based on detecting a change in the operational state of an adjacent aggregation port in the aggregation group of the network device. It is noted that the network device may set a timer to provide a time window for the network device to transmit a long LACPDU. Once the timer expires, the network device is prohibited from transmitting an enhanced LACPDU (e.g., the long LACPDU discussed above in this document), and the process of updating conversation allocation ends. In the event that the timer for the long LACPDU is set, the network device first determines whether operation using the enhanced LACPDU is possible, as described in block 303 of Figure 3.

For the sake of clarity, some terminology has changed between this document and the priority document. However, all changes in terminology are with respect to equivalent terminology. "Data stream" as used herein and in the priority document is to be understood to refer to an ordered sequence of frames, which is also equivalent to a "conversation". Reference has been made to the link aggregation group "level", which introduces a dichotomy between the "link level" and the link aggregation group "level", and stating that a conversation identifier identifies a conversation at the link aggregation group level is equivalent to indicating that a conversation identifier identifies a conversation at a given link aggregation group. Where reference is made to "each frame" in a set of frames received by a network device, the specific "received frame" is within this set of frames.

Although the present invention has been described in terms of several exemplary embodiments, those skilled in the art will recognize that the present invention is not limited to the embodiments described and can be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the description is to be regarded as illustrative rather than restrictive.

Claims (28)

1. A method implemented by a network device for updating session allocation on links of a link aggregation group, wherein the network device is communicatively coupled to an aggregation port via the links of the link aggregation group, wherein the network device processes sessions, and wherein each session consists of an ordered sequence of frames, the method comprising the following steps: The implementation of the (301) Dialogue Sensitive Link Aggregation Control Protocol (LACP) is verified to be operational; Determining (303) that operation via an Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible, wherein the enhanced LACPDU can be used to update dialogue allocation information, wherein the determination is at least partially based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device; and Based on the determination that the first conversation allocation state of the aggregation port of the link aggregation group is incorrect, the first conversation allocation state is updated (305), wherein the first conversation allocation state of the aggregation port of the link aggregation group indicates a first list of conversations transmitted through the aggregation port. 2. The method of claim 1, wherein verifying that the implementation of the dialogue-sensitive LACP is operable includes the following steps: Initialization (602) of the implementation of the dialogue-sensitive LACP in the network device; and Receive (603) at least one of the following: Identifiers for algorithms used to assign frames to port dialogue identifiers in the partner network device; A conversation identifier digest from the partner network device; and A summary of the dialogue service mapping from the partner network device. 3. The method of claim 1 or 2, wherein the compatibility check between the first set of operating parameters of the network device and the second set of operating parameters of the partner network device comprises: Determine (604) that the first algorithm for assigning a port session identifier to the port session identifier of the network device is consistent with the second algorithm for assigning a port session identifier to the port session identifier received from the partner network device. Determine (605) that the first session identifier digest of the network device matches the second session identifier digest received from the partner network device; and Determine (606) that the first dialogue service mapping digest is consistent with the second dialogue service mapping digest received from the partner network device. 4. The method of claim 1 or 2, wherein the enhanced LACPDU is a long LACPDU, and wherein each long LACPDU has more than 128 octets in length. 5. The method of claim 1 or 2, wherein the first dialogue allocation state of the aggregation port is represented by the dialogue mask of the aggregation port. 6. The method of claim 5, wherein the dialog mask of the aggregation port is represented by one or more dialog mask type/length/value (TLV). 7. The method of claim 6, wherein the dialog mask TLV comprises: TLV type field; Dialogue mask length field; Dialogue mask status field; and Port operation dialog mask field. 8. The method of claim 7, wherein the dialog mask state field contains a bit indicating whether the first dialog mask of the aggregation port of the network device and the second dialog mask of the matching aggregation port of the partner network device are consistent, wherein the collection dialog mask and the distribution dialog mask respectively indicate the lists of dialogs collected in the collection function and distributed in the distribution function. 9. The method of claim 7, wherein the port operation dialog mask field indicates the dialog allocation status of the aggregated link. 10. The method of claim 1 or 2, wherein the determination of an incorrect first dialogue assignment state is based on at least one of the following: Determining that the first session allocation state of the aggregation port of the link aggregation group in the network device is different from the second session allocation state of the aggregation port received from the partner network device, wherein the second session allocation state indicates a second list of sessions received through the link aggregation group; and Detect changes in the operational status or management configuration of the aggregation group in the network device, wherein the operational status is associated with each port of the aggregation group in the network device. 11. The method of claim 1 or 2, further comprising: After determining that operation via the enhanced LACPDU is possible, a timeout timer is set, wherein operation via the enhanced LACPDU is prohibited after the timeout period. 12. The method of claim 1 or 2, wherein each conversation is for a service or application in the network. 13. A network device (1180) configured to be communicatively coupled to an aggregation port via a link aggregation group, wherein the network device is configured to process conversations, and wherein each conversation consists of an ordered sequence of frames, the network device comprising: A set of aggregated ports (1140), configured to receive frames on the links of the link aggregation group; and Network device (1100), comprising: The aggregation controller (1106) is configured to verify that the implementation of the dialogue-sensitive link aggregation control protocol (LACP) is operable; The aggregation controller is further configured to determine whether operation via Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible, wherein the enhanced LACPDU can be used to update dialogue allocation information, wherein the determination is based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device; and The aggregation controller is also configured to update the first conversation allocation state based on the determination that the first conversation allocation state of the aggregation port of the link aggregation group is incorrect, wherein the first conversation allocation state of the aggregation port of the link aggregation group indicates a first list of conversations transmitted through the aggregation port. 14. The network apparatus of claim 13, further comprising: Storage device (1150) is configured to store the dialog assignment state of the list of dialogs transmitted through the aggregation port. 15. The network device of claim 13 or 14, wherein the network processor further comprises: The link aggregation sublayer includes: Control the parser and multiplexer, configured to process LACPDUs and frames from the aggregation port of the link aggregation group, and transmit them to the aggregation port of the link aggregation group; The client interface is configured to receive dialogue-sensitive frames from the partner network device and transmit them to the partner network device. A frame distributor configured to distribute frames from the buddy network device to the aggregation port; and A frame collector, configured to collect frames from the aggregation port to the partner network device; and The aggregator client is configured to interact with the link aggregation sublayer to process frames. 16. The network apparatus of claim 13 or 14, wherein the aggregation controller verifies that the implementation of the conversation-sensitive LACP is operable through the following steps: Initialize the implementation of the dialogue-sensitive LACP in the network device; and Receive at least one of the following: Identifiers for algorithms used to assign frames to port dialogue identifiers in the partner network device; A conversation identifier digest from the partner network device; and A summary of the dialogue service mapping from the partner network device. 17. The network device of claim 13 or 14, wherein the aggregation controller performs the compatibility check between the first set of operating parameters of the network device and the second set of operating parameters of the partner network device by means of the following steps: The first algorithm for determining the assignment frame to the port session identifier of the network device is consistent with the second algorithm for determining the assignment frame to the port session identifier received from the partner network device. Determine that the first session identifier digest of the network device matches the second session identifier digest received from the partner network device; and The first dialogue service mapping digest is determined to be consistent with the second dialogue service mapping digest received from the partner network device. 18. The network device of claim 13 or 14, wherein the enhanced LACPDU is a long LACPDU, wherein each long LACPDU has more than 128 octets in length. 19. The network apparatus of claim 13 or 14, wherein the first session allocation state of the aggregation port is represented by the session mask of the aggregation port. 20. The network apparatus of claim 19, wherein the session mask of the aggregation port is represented by one or more session mask type/length/value (TLV). 21. The network apparatus of claim 20, wherein the session mask TLV comprises: TLV type field; Dialogue mask length field; Dialogue mask status field; and Port operation dialog mask field. 22. The network apparatus of claim 21, wherein the session mask state field contains a bit indicating whether a first session mask of the aggregation port of the network apparatus and a second session mask of the matching aggregation port of the partner network apparatus are identical, wherein the collection session mask and the distribution session mask respectively indicate a list of sessions collected in the collection function and distributed in the distribution function of the aggregation port. 23. The network apparatus of claim 21, wherein the port operation session mask field indicates the session allocation status of the aggregated link. 24. The network apparatus of claim 13 or 14, wherein the determination of an incorrect first session allocation state is based on at least one of the following: Determining that the first session allocation state of the aggregation port of the link aggregation group in the network device is different from the second session allocation state of the aggregation port received from the partner network device, wherein the second session allocation state indicates a second list of sessions received through the link aggregation group; and Detect changes in the operational status or management configuration of the aggregation group in the network device, wherein the operational status is associated with each port of the aggregation group in the network device. 25. The network apparatus of claim 13 or 14, wherein the link aggregation controller sets a timeout timer after determining that operation via enhanced LACPDU is possible, wherein operation via enhanced LACPDU is prohibited after the timeout period. 26. The network apparatus of claim 13 or 14, wherein each conversation is for a service or application in the network. 27. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to perform operations implemented by a network device for updating session assignments on links of a link aggregation group, wherein the network device is configured to communicatively couple to an aggregation port via the links of the link aggregation group, wherein the network device is configured to process sessions, and wherein each session consists of an ordered sequence of frames, the operations comprising the following steps: Verify that the implementation of the (301) Dialogue Sensitive Link Aggregation Control Protocol (LACP) is operable; Determining (303) that operation via Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible, wherein the enhanced LACPDU can be used to update session allocation information, wherein the determination is at least partially based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device; and Based on the determination that the first conversation allocation state of the aggregation port of the link aggregation group is incorrect, the first conversation allocation state is updated (305), wherein the first conversation allocation state of the aggregation port of the link aggregation group indicates a first list of conversations transmitted through the aggregation port. 28. An apparatus implemented by a network device for updating session assignments on links of a link aggregation group, wherein the network device is configured to communicatively couple to an aggregation port via the links of the link aggregation group, wherein the network device is configured to process sessions, and wherein each session consists of an ordered sequence of frames, the apparatus comprising: The component used to verify that the implementation of the (301) Dialogue Sensitive Link Aggregation Control Protocol (LACP) is operational; The component for determining (303) whether operation via Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible, wherein the enhanced LACPDU can be used to update dialogue allocation information, wherein the determination is at least partially based on a compatibility check between a first set of operating parameters of the network device and a second set of operating parameters of a partner network device, and wherein the partner network device is a remote network device of the link aggregation group communicatively coupled to the network device; and The component for updating (305) the first dialogue allocation state based on the determination that the first dialogue allocation state of the aggregation port of the link aggregation group is incorrect, wherein the first dialogue allocation state of the aggregation port of the link aggregation group indicates a first list of dialogues transmitted through the aggregation port.