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

Abstract

A method of updating conversation allocation in link aggregation is disclosed. The method starts with verifying that an implementation of a conversation-sensitive link aggregation control protocol (LACP) is operational at a network device of a network for an aggregation port. Then it is determined that operations through enhanced link aggregation control protocol data units (LACPDUs) are possible. The enhanced LACPDUs can be used for updating conversation allocation information, and the determination is based at least partially on a compatibility check between a first set of operational parameters of the network device and a second set of operational parameters of a partner network device. Then a conversation allocation state of an aggregation port of the link aggregation group is updated based on a determination that the conversation allocation state is incorrect, where the conversation allocation state indicates a list of conversations transmitting through the aggregation port.

Description

Method and system for updating conversation configuration in link aggregation

Embodiments of the present invention are generally directed to link aggregation, and more particularly to methods and apparatus for dialog sensitive collection for a Link Aggregation Group (LAG).

As illustrated in FIG. 1A, a plurality of link polymerization system for polymerization of a link between the node pair 120, 122 in the network 101 to enable participation in a link aggregation group (the LAG) (see, e.g. A network configuration and program for transmitting user data on each of the links of the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1AX. Aggregating multiple network connections in this manner can increase throughput by more than a single connection can support and can be used to provide resiliency in the event of failure of one of the links. "Distributed Resilient Network Interconnection" (DRNI) 102 (see clause 8 of IEEE 802.1 AX-REV/D1.0) specifies an extension of link aggregation to be able to be between even more than two nodes (for example, between the four nodes K, L, M and O, as illustrated in FIG. 1B) using a network interface on the link aggregation.

As shown in FIG. 1B, a LAG is formed between the network 150 and the network 152. More specifically, a LAG is formed between the LAG virtual node or "enter site" 112, 114. The first LAG virtual node or portal 112 includes a first node (K) and a second node (L). The 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 "entry portal systems." Note that the first LAG is virtual The quasi-node or portal website 112 and the second LAG virtual node or portal 114 may include one or more nodes in one of the portal websites. The LAG nodes K and M are connected as peer nodes, and the LAG nodes L and O are also connected as peer nodes. As used in this application, a "LAG virtual node" refers to one of the IEEE documents discussed above, the DRNI portal (ie, two or more nodes that appear to be a single node for their respective peers). ). In addition, the statement that the virtual node or portal 112 "contains" two nodes K, L means that the virtual node or portal 112 is simulated by nodes K, L, which may be referred to as a "simulated 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 nodes M, O. Note that the link aggregation group 161 is also formed between the K-M link and the L-O link.

The plurality of nodes participating in the LAG appear as virtual nodes or portals with a single system ID that are the same as their peers in the LAG. The system ID is used to identify each node (eg, 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 individual partner nodes of the LAG (eg, between K and M or between L and O). The system ID can be generated using any individual identifier or any combination thereof based on the identifier of the constituent nodes of an entry website. A common and unique system ID for one of the corresponding LAG virtual nodes or portals can be consistently generated. Thus, as shown in FIG. 1B, node K and L are of the same network node 150, the node and the node K and L are the same DRNI portal 112 (i.e., the same virtual node LAG) and part of the virtual node for LAG The simulation 112 uses a common system ID "K". Similarly, nodes K and L treat nodes M and O of network 152 as having a single LAG virtual node or portal 114 with a system ID "M".

Figure 1B also shows a DRNI link configuration for a particular service (see the thick link between K and M in Figure 1B). An interface service configuration may involve a virtual local area network (VLAN), and one of the identifiers for the service may be a VLAN identifier (VID), such as a service VID (ie, "S-VID") ( The network is typically identified as a service on the network interface (NNI) or a client VID (ie, "C-VID") (usually identifying the user's service to the network interface (UNI)). (Note that B-VID is indistinguishable from S-VID because it has the same Ethernet type.) In the example of Figure 1B , the service is configured to the upper link (between upper nodes K, M) . Therefore, the upper link is selected as the "working" link, and the lower link (between nodes L and O) is the "standby" link or the "protected" link. The service link configuration (i.e., using the same physical link for frame transmission in both the forward and backward directions) is highly desirable.

The transmitted frame can be dynamically reassigned, and this redistribution can result from a change or an addition of a link or a load balancing scheme. Traffic redistribution occurring in the middle of a traffic flow can result in an unordered frame. To ensure that frames are not repeated or reordered for reassignment, link aggregation uses a tag protocol. The purpose of using the tagging protocol is to detect when a frame of a given traffic flow is successfully received at a remote peer node. To achieve this, LACP transmits a Label Protocol Data Unit (PDU) on each of the 埠 channel links. Once the partner system has received all of the frames transmitted on the link prior to marking the PDU, the partner system responds to a received tag PDU. The buddy system then sends a tagged response PDU for each received tag PDU. Once the tag response PDU is received by the local system on all member links of the portal, the local system can redistribute the frame in the traffic flow, thereby avoiding any risk of frame disorder. However, ensuring that a tag response PDU is properly functioning in one of the LAG's or two peer nodes may include one of the multiple systems DRNI can be problematic. Therefore, measures must be taken to ensure that the specific sequence of frame exchanges (called conversations) between the LAGs is maintained in order.

The present invention discloses a method of updating a conversation configuration in link aggregation. The method is implemented by a network device to update a dialog configuration on a link of a link aggregation group. The network device is communicatively coupled to the aggregation port through the links in the link aggregation group. And it handles the conversation consisting of an ordered sequence of frames. The method begins by verifying that one of the dialog-sensitive Link Aggregation Control Protocol (LACP) implementations is in operation. Then, it is determined that the operation through the Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible. The enhanced LACPDUs can be used to update the session configuration information, and the determination is based at least in part on a compatibility between the first set of operational parameters of one of the network devices and the second set of operational parameters of one of the partner network devices Examining, wherein the partner network device is one of the link aggregation groups remotely connected to the network device. And then updating the session configuration state based on a determination that one of the link aggregation groups is one of the conversation configuration states is incorrect, wherein the conversation configuration state of the aggregation group of the link aggregation group indicates that the aggregation is transmitted through the aggregation埠 Transfer a list of conversations.

A network device configured to update a conversation configuration in a link aggregation is disclosed. The network device is configured to be communicatively coupled to the aggregation through a link of a link aggregation group, and the network device is configured to process the conversation, and wherein each conversation consists of an ordered sequence of frames composition. The network device includes a aggregation controller and a network processor configured to receive frames from the aggregate of the link aggregation group and transmit the frame to the link aggregation group The aggregation of the group. The network processor includes an aggregation controller configured to: verify an operational implementation of a Session Sensitive Link Aggregation Control Protocol (LACP); determine to aggregate control protocol data through the enhanced link aggregation The operation of a unit (LACPDU) is possible, wherein the enhanced LACPDUs can be used to update the dialog configuration information, wherein the determination is based on a first set of operational parameters of the network device and a second set of a partner network device a compatibility check between operational parameters, and wherein the partner network device is one of the link aggregation groups of the link aggregation group communicatively coupled to the network device; aggregating groups based on the link The session configuration state is updated by one of the aggregations, one of the dialog configuration state is incorrect, wherein the conversation configuration state of the aggregation of the link aggregation group indicates that one of the conversation lists is transmitted through the aggregation.

The invention discloses a non-transitory computer readable storage medium in which instructions are stored The instructions, when executed by a processor, cause the processor to perform an operation of updating the dialog configuration in the link aggregation. The operations are performed by a network device to update the dialog configuration on the link of a link aggregation group. The network device is configured to be communicatively coupled to the aggregate via the links of the link aggregation group and configured to process a conversation consisting of an ordered sequence of frames. These operations begin by verifying that one of the Session Sensitive Link Aggregation Control Protocol (LACP) implementations is in operation. Then, it is determined that the operation through the Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible. The enhanced LACPDUs can be used to update the session configuration information, and the determination is based at least in part on a compatibility between the first set of operational parameters of one of the network devices and the second set of operational parameters of one of the partner network devices Examining, wherein the partner network device is one of the link aggregation groups remotely connected to the network device. And then updating the session configuration state based on a determination that one of the link aggregation groups is one of the conversation configuration states is incorrect, wherein the conversation configuration state of the aggregation group of the link aggregation group indicates that the aggregation is transmitted through the aggregation埠 Transfer a list of conversations.

A computer program with instructions that, when executed by a processor, cause the processor to perform operations performed by a network device to update a dialog configuration on a link of a link aggregation group. The operations are performed by a network device to update the dialog configuration on the link of a link aggregation group. The network device is configured to be communicatively coupled to the aggregate via the links of the link aggregation group and configured to process a conversation consisting of an ordered sequence of frames. These operations begin by verifying that one of the Session Sensitive Link Aggregation Control Protocol (LACP) implementations is in operation. Then, it is determined that the operation through the Enhanced Link Aggregation Control Protocol Data Unit (LACPDU) is possible. The enhanced LACPDUs can be used to update the session configuration information, and the determination is based at least in part on a compatibility between the first set of operational parameters of one of the network devices and the second set of operational parameters of one of the partner network devices Examining, wherein the partner network device is one of the link aggregation groups remotely connected to the network device. Then, based on the link aggregation group The session configuration state is updated by one of the aggregations, one of the dialog configuration state is incorrect, wherein the conversation configuration state of the aggregation of the link aggregation group indicates that one of the conversation lists is transmitted through the aggregation.

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 a dialog configuration of a link aggregation group between network devices such that a sequence of frames exchanged by the network devices is maintained. Embodiments of the present invention may be utilized at a network device that implements a link aggregation group between one of a plurality of nodes per node or a portal system (such as a DRNI system).

101‧‧‧Link Aggregation Group

102‧‧‧Distributed flexible network interconnection

112‧‧‧Link Aggregation Group Virtual Node or Portal/First Link Aggregation Group Virtual Node or Portal/Virtual Node or Portal/Decentralized Flexible Network Interconnection Portal/Emulated Link Aggregation Group Group virtual node

114‧‧‧Link Aggregation Group Virtual Node or Portal/Second Link Aggregation Group Virtual Node or Portal/Virtual Node or Portal

120‧‧‧node/network device

122‧‧‧node/network device

150‧‧‧Network

152‧‧‧Network

161‧‧‧Link Aggregation Group

200‧‧‧Link Aggregation Sublayer

202‧‧‧Aggregator Client

210‧‧‧Link Aggregation Controls

214‧‧‧Link Aggregation Control Protocol

224‧‧‧ Frame Collector

234‧‧‧ Frame Dispenser

250‧‧‧Aggregator

270‧‧‧Link Aggregation Sublayer

292‧‧‧Polymer

294‧‧‧Polymer

296‧‧‧Polymer

400‧‧‧Dialog mask type/length/value

402‧‧‧Type/Length/Value Type

404‧‧‧Dialog mask length

406‧‧‧Dialog mask status

408‧‧‧埠 Operational dialogue mask

410‧‧‧ActPar_Sync/Reference

411‧‧‧Reserved

412‧‧‧Reserved

413‧‧‧Reserved

414‧‧‧Reserved

420‧‧‧Reference

421‧‧‧Reference

422‧‧‧Reference

423‧‧‧Reference

424‧‧‧Reference

450‧‧‧Dialog mask status

470‧‧‧埠Dialog mask

502‧‧‧Field/TLV_type

505‧‧‧Field/Port_Conversation_Service_Mapping_Digest_Length field

506‧‧‧Field/Actor_Conversation_Serice_Mapping_Digest

1100‧‧‧Network Processor

1102‧‧‧Control parser/multiplexer

1106‧‧‧Aggregate controller

1111‧‧‧User Interface

1120‧‧‧ Frame Dispenser

1125‧‧‧ Frame Collector

1140‧‧‧埠/aggregation

1150‧‧‧ storage device

1152‧‧‧Abstract Database

1170‧‧‧Link Aggregation Sublayer

1172‧‧‧Aggregator client

1180‧‧‧Network devices

1200‧‧‧Dialog Mask 1 Type/Length/Value

1202‧‧‧Type/Length/Value Type

1204‧‧‧Dialog Mask 1 Length/Field

1206‧‧‧Dialog mask status

1208‧‧‧埠Operational Conversation Mask 1/埠Operational Conversation Mask

1210‧‧‧Dialog Mask 2 Type/Length/Value/Dialog Mask 1 Type/Length/Value

1212‧‧‧Type/Length/Value Type

1214‧‧‧Dialog mask 2 length

1216‧‧‧埠 Operational dialogue mask 2

1220‧‧‧Dialog Mask 3 Type/Length/Value

1222‧‧‧Type/Length/Value Type

1224‧‧‧Dialog mask length 3

1226‧‧‧埠Operational dialogue mask 3

1302‧‧‧埠 Algorithm Type/Length/Value

K‧‧‧ Node/First Node/Link Aggregation Group Node/Common System Identifier/Upper Node

L‧‧‧ node/second node/link aggregation group node

M‧‧‧ node/third node/link aggregation group node/system identifier/upper node

O‧‧‧node/fourth node/link aggregation group node

The invention is best understood by reference to the following description and the accompanying drawings. In the drawings: Figure 1A is a diagram of one embodiment of a link aggregation group between two network devices.

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

2 is a diagram of an embodiment of a link aggregation sublayer.

3 is a flow chart illustrating one of the procedures for updating a dialog configuration of an aggregate in accordance with an embodiment of the present invention.

4A illustrates a dialog mask TLV for a convergent frame in accordance with an embodiment of the present invention.

4B illustrates one of the conversation mask status fields within one of the conversation masks TLVs in accordance with one embodiment of the present invention.

4C illustrates one of the link aggregation groups of one of the link aggregation groups at a network device in accordance with an embodiment of the present invention.

Figure 5A is a diagram of an embodiment of a dialog service mapping TLV.

Figure 5B is a diagram of one embodiment of an aggregate management service session map.

6 is another flow diagram illustrating one of the procedures for updating a dialog configuration of an aggregate in accordance with an embodiment of the present invention.

7 is a flow chart illustrating one of the dialog masks for updating a convergent layer upon receipt of a long LACPDU, in accordance with an embodiment of the present invention.

8A-8D illustrate a sequence of one of the dialog masks for updating an aggregate in accordance with an embodiment of the present invention.

9 is a flow diagram of one embodiment of a procedure for session sensitivity collection for a link aggregation group.

10 is a flow diagram of another embodiment of a procedure for session sensitivity collection of a link aggregation group.

Figure 11 is a diagram of one embodiment of a network device that implements session sensitivity collection of a link aggregation group.

12A through 12C illustrate a dialog mask 1 to a mask 3 TLV for a polymerization cassette in accordance with an embodiment of the present invention.

Figure 13 illustrates a set of TLVs required to support dialog sensitivity collection and distribution functionality in accordance with an embodiment of the present invention.

In the following description, numerous specific details are set forth. However, it is understood that the embodiments of the invention may be practiced without the specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of the description.

However, it will be understood by those skilled in the art that the present invention may be practiced without the specific details. In other instances, the control structure, the gate level circuit, and the full software command sequence are not shown in detail in order not to obscure the invention. With the included description, those skilled in the art will be able to implement appropriate functionality without undue experimentation.

The embodiments described in the specification, which are referred to as "an embodiment", "an embodiment", "an exemplary embodiment" and the like, may include a particular feature, structure or characteristic, but each embodiment may not necessarily include This particular feature, structure or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. In addition, it is to be understood that the specific features, structures, or characteristics of the embodiments of the invention are to be understood by those skilled in the art.

the term

The following terms can be used in this description.

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

Aggregate bond: A parameter associated with each polymerizer and each aggregator that identifies one of the polymerizers that can be polymerized together. Aggregates that share the same aggregated bond value in a polymerization system may be able to be aggregated together.

Aggregation: One aggregator supports one of the aggregation systems, Service Access Point (SAP).

Aggregation system: An entity that is uniquely identifiable, which includes, among other things, any one of one or more aggregates. An instance of an aggregated link always occurs between two aggregation systems. A physical device can include a single polymerization system or more than one polymerization system.

Aggregation client: A layered entity immediately above the link aggregation sublayer. The link aggregation sublayer provides an instance of the internal sublayer service (ISS) for the aggregation client.

Aggregator: A logical media access control (MAC) address that is coupled to one or more aggregates, and the aggregator client provides access to physical media through the aggregator.

Dialogue: A frame is transmitted from one terminal station to another terminal station, wherein all frames form an ordered sequence, and wherein the communication terminal station needs to maintain order among the group frames exchanged.

Data Terminal Equipment (DTE): Any source or purpose of data connected to a regional network Ground.

Decentralized Relay (DR): A functional entity that is dispersed in an portal site by a DR function in each of the aggregation systems including an portal site. The DR distributes the outgoing frame from the gateway. Go to the aggregator and assign the incoming frame from the aggregator to the gateway.

Decentralized Resilient Network Interconnection (DRNI): A link aggregation that is extended to include an ingress website and an aggregation system or two portals.

DR function: A part of a decentralized relay that resides in a single portal system.

Gateway: A decentralized relay is typically virtual (not a physical link between systems) connected to one of the systems. The gateway consists of a gateway link and two gateways.

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

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

Partner: A remote entity (ie, a node or network device) in a link aggregation control protocol exchange.

埠 Dialog ID (ID): Used to select the session identifier value of one of the frames through a 埠.

Portal: One end of a DRNI; it contains one or more aggregation systems, each aggregation system having a physical link that includes a link aggregation group together. The aggregation system of the portal cooperates to simulate the presence of the entire link aggregation group attached to one of the individual aggregation systems.

Type/Length/Value (TLV): A short variable length encoding of one of the information elements consisting of a sequence type, a length, and a value field, 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. Type values are defined locally and need to be unique within the agreement defined in this standard.

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

An electronic device (eg, an end station, a network device) stores and transmits (internally and/or via a network with other electronic devices) code (consisting of software instructions) and data using a machine readable medium, A machine-readable medium such as a non-transitory machine-readable medium (eg, a machine-readable storage medium such as a magnetic disk; a compact disk; a read-only memory; a flash memory device; phase change memory) and a transitory machine readable transmission Media (eg, electrical, optical, acoustic, or other forms of transmitted signals - such as carrier waves, infrared signals). Additionally, such electronic devices include hardware, such as a set of one or more processors coupled to one or more other components - for example, one or more non-transitory machine readable storage media (by storing codes and/or data) and network connections (to transmit signals and/or data using broadcast signals) and, in some cases, user input/output devices (eg, a keyboard, a touch screen, and / or a monitor). The coupling of the set of processors to other components is typically through one or more interconnects (e.g., busbars and possibly bridges) within the electronic device. Thus, a non-transitory machine readable medium of a given electronic device typically stores instructions for execution on one or more processors of the electronic device. One or more of the components of one embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.

As used herein, a network device (eg, a router, switch, bridge) is a network connection device that communicatively interconnects other devices on the network (eg, other network devices, end stations), Contains hardware and software. Some network devices are "multiple Service network device that provides support for multiple network connectivity functions (eg, routing, bridging, switching, layer 2 aggregation, session boundary control, quality of service, and/or user management) and/or provides multiple Support for application services such as data, voice and video. User terminal stations (eg, servers, workstations, laptops, laptops, palmtops, mobile phones, smart phones, multimedia phones, voice over internet protocol (VOIP) phones, user devices, terminals) , portable media player, GPS unit, gaming system, set-top box) access to content/services provided over the Internet and/or overlaid on the Internet (eg, tunneling through the Internet) Content/services available on a virtual private network (VPN). Content and/or services are typically provided by one or more end stations (eg, server end stations) or end stations participating in a peer-to-peer (P2P) service belonging to a service or content provider, and may include, for example, Public web pages (eg, free content, storefronts, search services), dedicated web pages (eg, web pages that provide username/password access for email services) and/or corporate networks via VPN. Typically, user end stations are coupled (eg, through a client device coupled to an access network (wired or wireless)) to an edge network device that is coupled (eg, through one or more cores) Network devices) to other edge network devices that are coupled to other terminal stations (e.g., server terminal stations).

Network devices are typically divided into a control plane and a data plane (sometimes referred to as a transfer plane or a media plane). In the case where the network device is a router (or implementing routing functionality), the control plane typically determines how the data (e.g., packet) is routed (e.g., a hop under the data and an outgoing message of the data). The data plane is responsible for forwarding the information. For example, a control plane typically includes communicating with other network devices to exchange routes and selecting one or more routing protocols based on one or more routing metrics (eg, such as Border Gateway Protocol (BGP) (RFC) 4271) An external gateway agreement, internal gateway agreement (IGP) (eg, Open Shortest Path First (OSPF) (RFC 2328 and 5340), Intermediate System to Intermediate System (IS-IS) (RFC 1142), routing information Agreement (RIP) (Version 1 RFC 1058, Edition 2 RFC 2453 and Next Generation RFC 2080)), Label Assignment Protocol (LDP) (RFC 5036), Resource Reservation Agreement (RSVP) (RFC 2205, 2210, 2211, 2212, and RSVP-Telecom Engineering (TE): RSVP extension of LSP tunnel RFC 3209, generalized multi-protocol label switching (GMPLS) signaling RSVP-TE RFC 3473, RFC 3936, 4495 and 4558)). In addition, the control plane usually also includes ISO layer 2 control protocols, such as the Rapid Extension Tree Protocol (RSTP), Multiple Extension Tree Protocol (MSTP), and SPB (Short Path Bridge) that has been standardized by various standards bodies (for example, IEEE Std 802.1aq). SPB has been defined in -2012.

The routing and adjacent storage are stored in one or more routing structures (eg, a Routing Information Base (RIB), a Label Information Library (LIB), one or more adjacent structures) on the control plane. The control plane programs the data plane with information based on the routing structure (eg, contiguous and routing information). For example, the control plane programs the adjacent and routing information into one or more forwarding structures on the data plane (eg, Transfer Information Base (FIB), Label Forwarding Information Base (LFIB), and one or more adjacent structures). . The data plane uses these forwarding and adjacent structures when forwarding traffic.

Each of the routing protocols downloads the routing item to a primary RIB based on a particular routing metric (the metric may be different for different routing protocols). Each of the routing protocols may store the routing items in a local RIB (eg, an OSPF local RIB) that includes routing items that are not downloaded to the primary RIB. One of the main RIBs managing RIB modules downloads routing routes by routing protocols (based on a set of metrics) and downloads their selected routes (sometimes called active routing items) to the data plane. RIB modules 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 Layer 2 information in the 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 passed through one or more interconnecting mechanisms (eg, coupling one of the line cards to the first complete network and coupling all of them) One of the cards is the second complete network) coupled together. The set of line cards form a data plane, and the set of control cards provides a control plane, and the packets are exchanged with the external network device through the line card. This set of service cards provides specialized processing (eg, Layer 4 to Layer 7 services (eg, firewall, Internet Protocol Security (IPsec) (RFC 4301 and 4309), Intrusion Detection System (IDS), Peer-to-Peer (P2P) , Internet Voice Protocol (VoIP) work phase border controller, mobile wireless gateway (gateway universal packet radio service (GPRS) support node (GGSN), evolved packet core (EPC) gateway) By way of example, a service card can be used to terminate an IPsec tunnel and perform a waiter authentication and encryption algorithm.

As used herein, a node forwards an IP packet based on some IP header information in an IP header information in an IP packet; wherein the IP header information includes a source IP address, a destination IP address, and a source.埠, destination 埠 (where “source 埠” and “destination 埠” are used in this context to refer to an entity 一), a transport agreement (eg, User Datagram Protocol (UDP) ( RFC 768, 2460, 2675, 4113, and 5405), Transmission Control Protocol (TCP) (RFC 793 and 1180), and Differentiated Services (DSCP) values (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290, and 3317). The node is implemented in the network device. A physical node is directly implemented on the network device, and a virtual node is implemented in a software on the network device (and Potentially hardware abstraction. Thus, multiple virtual nodes can be implemented on a single network device.

A network interface can be physical or virtual; and an interface address is assigned to one of the IP interfaces of the network interface, whether it is a physical network interface or a virtual network interface. A physical network interface is a hardware in a network device through which a network connection is made (for example, wirelessly through a wireless network interface controller (WNIC) or through a cable insertion Connect to one of the network interface controllers (NICs)埠). Typically, a network device has multiple physical network interfaces. A virtual network interface can be associated with a physical network interface, associated with another virtual interface, or exist independently (eg, a loopback interface, a peer-to-peer protocol) interface). A network interface (physical or virtual) can be numbered (a network mask has an IP address) or unnumbered (a network interface does not have an IP address). A return interface (and its return address) is a virtual network interface (and IP address) of one of a type of node (physical or virtual) that is typically used for administrative purposes; this IP address is called The node sends back the address. The IP address assigned to the network interface of a network device is referred to as the IP address of the network device; at a finer level of granularity, assigned to a node assigned to be implemented on a network device The IP address of the network interface can be referred to as the IP address of the node.

Some network devices provide support for implementing a VPN (Virtual Private Network) (eg, Layer 2 VPN and/or Layer 3 VPN). For example, a network device in which a provider's network and a customer's network are coupled is referred to as PE (provider edge) and CE (customer edge), respectively. In a layer 2 VPN, the transfer is typically performed on the CE at either end of the VPN and the traffic is sent across the network (eg, by coupling one or more PEs by other network devices). The layer 2 circuit is configured between CE and PE (for example, an Ethernet network, an ATM permanent virtual circuit (PVC), and a frame relay PVC). In a layer 3 VPN, the route is usually performed by the PE. By way of example, one of the multiple network enabled edge network devices can be deployed as a PE; and a network can be configured by means of a VPN protocol, and thus the context is referred to as a VPN context.

Some network devices provide support for VPLS (Virtual Private LAN Service) (RFC 4761 and 4762). For example, in a VPLS network, a user terminal station accesses content/services provided over a VPLS network by coupling to a CE that is coupled through PEs coupled by other network devices. The VPLS network can be used to implement triple play network applications (eg, data applications (eg, high speed internet access), video applications (eg, television services such as IPTV (Internet Protocol Television), VoD (Video on Demand) services and voice applications (for example, VoIP (Internet Voice Protocol) services), VPN services, etc. VPLS is one of the Layer 2 VPNs that can be used for multipoint connections. The VPLS network also allows user terminal stations coupled to CEs in separate geographic locations to span a wide area network (WAN) Communicate with each other as if they were directly attached to each other in a local area network (LAN) (called an emulated LAN).

In a VPLS network, each CE may typically be attached to a PE via an access network (wired and/or wireless) via an attached circuit (eg, a virtual link or connection between the CE and the PE). One of the bridge modules. The PE bridge module is attached to an emulated LAN via an emulated LAN interface. Each bridge module acts as a "virtual exchange instance" (VSI) by maintaining a MAC address mapping to a pseudowire and one of the attached circuits. The PE forwards the frame (received from the CE) to the destination (eg, other CEs, other PEs) based on the MAC destination address field contained in the frame.

The network device can also support native L2 network technologies and device types, including C-VLAN bridges, provider bridges, provider backbone bridges, provider backbone bridges - traffic engineering (TE) (eg IEEE std) A VLAN bridged network supported by 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 types of network devices listed above and the supported technologies are provided by way of example and not limitation. Those skilled in the art will appreciate that other technologies, standards, and device types can be included as network devices, as used herein.

Link aggregation sublayer

2 is a diagram of one embodiment of a link aggregation sublayer 200. Aggregator client 202 communicates with a set of aggregates 292, 294, 296 through aggregator 250. In one embodiment, aggregator 250 presents a standard IEEE Std 802.1Q internal sublayer service (ISS) interface to aggregator client 202. The polymerizer 250 is bonded to one or more polymeric ruthenium comprising polymeric ruthenium 292, 294, 296. The aggregator 250 distributes the frame transmissions from the aggregator client 202 to the aggregation ports 292, 294, 296 and collects the received frames from the aggregation ports 292, 294, 296 and transparently passes them to the aggregator client 202.

The incorporation of the aggregates 292, 294, 296 into the aggregator 250 is managed by the link aggregation control 210, which is responsible for determining which links can be aggregated, aggregating the links, The polymerization enthalpy is combined into a suitable aggregator and monitored to determine when a change in one of the polymerizations is required. This determination and combination can be controlled manually by direct manipulation of state variables (e.g., by aggregation keys) by a network manager's link aggregation. Additionally, automatic determination, configuration, bonding, and monitoring can occur through the use of Link Aggregation Control Protocol (LACP) 214. LACP 214 uses peer-to-peer switching across links to determine the aggregation capabilities of various links on a real-time basis and continuously provides the aggregated capabilities of a pair of achievable maximum levels between a given aggregation system.

A polymerization system can contain multiple aggregators that serve multiple aggregator clients. A given polymer will bind to (at most) a single aggregator at any one time. An aggregator client is served by a single aggregator at a time.

A specific sequence (called a dialog) for frame exchange between aggregators' clients is maintained in order. Frame allocator 234 ensures that all frames of a given conversation are passed to a single aggregate. For a given conversation, the frame collector 224 needs to pass the frame to the aggregator client 202 to receive it from the aggregation. The frame collector 224 is free to select frames received from the aggregates 292, 294, 296 in any other order. Since there is no component that confuses the frame on a single link, this ensures that the frame is maintained for any conversation. For both load balancing and maintaining availability in the event of a link failure, the conversation can move among the aggregates within a link aggregation group.

Aggregate ports 292, 294, 296 are each assigned a media access control (MAC) address that is within the link aggregation group and to any bridged area network to which the link aggregation group is connected ( LAN) (for example, one LAN that conforms to IEEE 802.1Q bridged LAN) is unique. These MAC addresses are used as source addresses for frame exchanges (i.e., LACP 214 and label protocol exchanges) initiated by entities within the link aggregation sublayer 270 itself.

Aggregator 250 (and other aggregators, if deployed) is assigned a MAC address that is within the link aggregation group and that is connected to the bridged LAN for the link aggregation group (eg, IEEE 802.1Q compliant) One of the bridged LANs is unique. Self-polymerization From the perspective of the companion client 202, this address is used as the MAC address of the link aggregation group, both as a source address of the transmitted frame and as a destination address of the received frame. The MAC address of the aggregator 250 can be one of the MAC addresses of one of the associated link aggregation groups.

Decentralized Flexible Network Interconnect (DRNI)

Link aggregation forms a link aggregation group that appears to the higher layer as one of a single logical link or one of a plurality of physical links. The link aggregation groups have their respective ends terminated in an aggregation system. The DRNI extends the concept of link aggregation such that at either or both ends of a link aggregation group, a single aggregation system is replaced by an entry website each composed of one or more aggregation systems.

The DRNI is formed by interconnecting two or more systems that are interconnected by respective running links by using a decentralized relay to form an entry website. Each aggregation system in the portal (ie, each portal system) runs link aggregation with a single aggregator. The decentralized relay enables the portal system to jointly terminate a link aggregation group. For all other aggregation systems to which the portal is connected, the link aggregation group appears to terminate in a separate simulated aggregation system formed by the portal system.

Update conversation configuration one group embodiment

3 is a flow chart illustrating one of the procedures for updating a dialog configuration of an aggregate in accordance with an embodiment of the present invention. The operation of this and other flow charts will be explained with reference to the exemplary embodiments of other figures (e.g., the embodiment illustrated in Figure 11 ). However, it should be understood that the operation of the flowcharts can be performed by embodiments of the present invention and not by reference to the embodiments discussed herein, and that the embodiments of the invention discussed with reference to these other figures may be different Reference is made to the operation of the operations discussed in the flowcharts.

The process illustrated in FIG. 3 can be implemented in a network that includes one or more network devices deployed in one or more link aggregation groups, such as network devices 120 and 122 of FIG. 1A , and A network device including the portals 112 and 114 of FIG. 1B is included. The program is for updating a conversational configuration of one of the link aggregation groups when one or more conversations are transmitted in a link aggregation group, wherein each conversation is associated with one of the services or an application in the network.

At block 301, the program begins in operation with an implementation that verifies a Session Sensitive Link Aggregation Control Protocol (LACP). A dialog-sensitive LACP implementation needs to be operational, that is, LACP needs to be able to coordinate the collection and distribution of dialog sensitive frames for a pair of actors and partner network devices. For example, the verification of block 301 can be performed by the actor and the partner network device by means of verifying that the session sensitive LACP implementation is separately capable of transmitting and receiving an LACPDU indicating the algorithm (for assigning the frame to various conversations). And executed. That is, the verification includes verifying that one of the algorithms used by a network device (an actor network device) can be sent to the partner network device through an implementation of a session sensitive LACP. In an alternative or additional embodiment, the verification includes verifying that the dialog identifier summary is consistent with the dialog service map summary, as discussed in further detail below herein. Without this verification, the network device is unaware of whether it can pass the session sensitivity information through LACP and ignores the procedure for receiving the session sensitive LACP information. When the verification fails, a network device issues a notification of one of the management actions.

After verifying that the implementation of a session sensitive LACP is in operation, the program flows to block 303. At block 303, the network device determines that the operation through the enhanced LACPDU is possible based at least in part on a compatibility check. The enhanced LACPDU is used to update the LACPDU of the session configuration information through the link aggregation group, and it cannot operate under all conditions. The compatibility check determines whether a set of operational parameters of the network device associated with the aggregation device matches a set of operational parameters of the partner network device associated with a match at a partner network device. The partner network device is in communication with the network device to couple one of the remote network devices. If the set of operational parameters match each other, then the process 300 continues. Optionally, if the group operating parameters do not match, a notification can be sent to one of the link aggregation groups management systems, and one of the network operators can resolve the mismatch.

Enhanced LACPDUs are different from traditional LACPDUs. a traditional LACPDU (such as a character One of the LACPDUs of version 1 of IEEE Standard 802.1AX has a frame size of 128 octets. If each of the 128 octets is used to indicate a state of a conversation, the legacy LACPDU may only contain at most 128 x 8 = 1024 conversations. However, a link aggregation group can support more than 1024 conversations. For example, some embodiments may need to support up to 4096 conversations, such embodiments of a conventional LACPDU are not sufficient, and a different type of LACPDU (referred to as an enhanced LACPDU) is utilized for program 300. In one embodiment, an enhanced LACPDU includes fields for a trick algorithm TLV, a dialog ID digest TLV, a conversation mask, and/or a conversation service mapping TLV.

After confirming that the operation through the enhanced LACPDU is possible, then the process proceeds to block 305 where one of the link aggregation groups of the network device is updated to one of the conversation configuration states. The update is based on one of the aggregations of the dialog configuration state is incorrect. The dialog configuration status indicates that one of the dialog lists is transmitted through the aggregate. For example, when each conversation is identified by means of a dialog identifier (ID), one of the conversations configuration states may contain a set of dialog IDs that indicate the set of conversations through the UI.

In some cases, the aggregated conversation state of the network device may lose synchronization with the aggregation of the partner network devices. For example, one of the link aggregation groups at the network device can be set to transmit/receive the conversations identified as conversations 1 through 5, so the conversation configuration status of the aggregation is indicated by the conversations 1 to 5 of the aggregation. However, the matching of the link aggregation group at the partner network device can be set to identify the transmission/reception as conversations 1 through 7 (for example, due to some other defect at the partner network device outside the service) Dialogue. Since the conversational configuration state of the network device is not synchronized with the partner network device, it is considered incorrect. A similar problem occurs when another node of the same link aggregation group at the network device is set to transmit/receive a session identified as conversations 5-7. In this case, the conversation configuration state of the aggregation is not synchronized with the other link aggregation group, and the dialog 5 cannot pass the order of the frames and the dialog of maintaining the conversation. In other words, the synchronization failure can be simply characterized as failure or failure of one of the allocation algorithms (or related programs) on one side of the LAG to ensure The words are only configured to a single port. Once the conversation configuration state of the aggregation is determined to be incorrect, the conversation configuration state of the aggregation is updated. For example, it is updated to match the matching session configuration state at the partner network device or the other session configuration state of the same link aggregation group at the matching network device.

Embodiment of a TLV for delivering a conversation configuration state of an aggregate

The conversation configuration state of an aggregation needs to be represented in the data format transmitted through LACP. In one embodiment of the invention, the conversation configuration state of the aggregate has been communicated using the TLV format. 4A illustrates a dialog mask TLV for a convergent frame in accordance with an embodiment of the present invention. The dialog mask TLV 400 contains four fields: TLV type 402, dialog mask length 404, dialog mask state 406, and UI operation dialog mask 408. In other embodiments, the fields may not be positioned in the order illustrated in Figure 4A, and other embodiments may contain more or fewer fields.

The TLV type 402 indicates the nature of the information carried in the TLV tuple. In one embodiment, the dialog mask TLV is identified by the integer 0x06. The dialog mask length 404 (labeled Conversation_Mask_Length in Figure 4A) indicates the length of the TLV tuple in octets. The total length of the dialog mask TLV is 515 octets, so the field contains the value 515. In a different embodiment, the dialog mask length 404 contains more than or less than one of 515 values.

The dialog mask state (labeled Conversation_Mask_State in Figure 4A ) indicates one of the dialog mask states. 4B illustrates one of the conversation mask status fields within one of the conversation masks TLVs in accordance with one embodiment of the present invention. The dialog mask state 450 (one embodiment of the dialog mask state 406) contains eight bits (one octet), of which seven of the eight bits are reserved for future use (retained 411 to 414). A remaining bit indicates whether the dialog mask used by the frame allocator, which is aggregated by one of the link aggregation groups of a network device, is associated with the link aggregation group of a partner network device. The dialog box used by the frame divider is the same one of the flags. Therefore, the flag is a synchronization flag, which is referred to as ActPar_Sync 410 in FIG. 4B . In one embodiment, the synchronization flag is a Boolean value, and if the message mask used by the aggregation of the frame device of the local network device is used, the frame of the session is aggregated with the partner network device. If the conversation mask used by the allocator is the same, it indicates true, otherwise it indicates false.

The Operational Conversation Mask 408 (labeled Port_Oper_Conversation_Mask in Figure 4A ) contains a Boolean vector value indicating whether the indexed Session Identifier (ID) is transmitted through a particular aggregation. In one embodiment, the Boolean vector value is constructed by a priority selection protocol. The priority selection protocol instructs a given conversation to proceed to a single aggregation of one of the link aggregation groups. Based on this information, the operational dialog mask can be constructed to indicate which of the conversations indexed by the conversation identifier is transmitted on the aggregate.

4C illustrates one of the link aggregation groups of one of the link aggregation groups at the network device in accordance with an embodiment of the present invention. The dialog mask 470 (labeled Port_Oper_Conversation_Mask in Figure 4C ) is an embodiment of the operation dialog mask 408 and contains 4096 bits (512 octets x 8 bits / octets = 4096) Bits, and each bit indicates whether a given conversation is transmitted (or received) through the aggregation; it is transmitted if it is a mask of the allocator and is received if it is a mask of the collector, An example of transmission is given here). As illustrated, reference 420 at bit 0 is for dialog 0, and reference 421 at bit 1 is for dialog 1 (ie, dialog ID = 1, this applies equally to other dialogs), and at bit 2 Reference 422 and reference 423 at bit 3 are for dialog 2 and dialog 3, respectively. Finally, reference 424 at bit 4095 indicates whether the dialog 4095 is transmitted on the aggregate. In one embodiment, the Boolean value of a conversation indicates true when the conversation is transmitted through the aggregation. When a link aggregation group can support up to 4096 conversations (addressable by 12 bits), the 512 octet conversation mask 470 can indicate all permutations of possible conversations transmitted over the link aggregation. Primarily, some embodiments may support more than 4096 conversations or less than 4096 conversations, and thus may implement a length of operation dialog mask to accommodate different maximum number of conversations.

Note that the Conversation Mask TLV 400 contains 515 octets and is much longer than the 128 octets of the length of the LACPDU in Release 1 of the IEEE 802.1 AX standard. Thus, in one embodiment of the invention, transmitting a dialog mask TLV requires a "long" LACPDU.

In another embodiment, a dialog mask is implemented using a plurality of TLVs. 12A-12C illustrate one embodiment in which a dialog mask is implemented using three TLVs (Dialog Mask 1 to Mask 3 TLV) for a convergent chirp in accordance with an embodiment of the present invention. Referring to FIG. 12A , similar to the dialog mask TLV 400 of FIG. 4A , the dialog mask 1 TLV 1200 contains four fields: TLV type 1202, dialog mask 1 length 1204, dialog mask state 1206, and UI operation dialog mask 1 1208.

The TLV type 1202 identifies the type of information carried in the TLV tuple. In one embodiment, the dialog mask 1 TLV may be identified by the integer 0x06. The dialog mask 1 length 1204 (labeled Conversation_Mask_1_Length in Figure 12A ) indicates the length of the TLV tuple in octets. In an exemplary embodiment, the length of the dialog mask 1 TLV is 195 octets, so field 1204 contains a value of 195. In one embodiment, the dialog mask state 1206 and the UI dialog mask 1208 are similar to the structure of the dialog mask state 406 and the UI dialog mask 408 described above with respect to FIGS. 4B and 4C , respectively . Structured field.

Figure 12B illustrates a Conversation Mask 2 TLV for a polymeric unit in accordance with an embodiment of the present invention. Conversation Mask 2 The TLV 1210 contains three fields: a TLV Type 1212, a Conversation Mask 2 Length 1214, and a Operational Conversation Mask 2 1216. These fields provide similar functionality to the corresponding fields of the dialog mask 1 TLV 1200, respectively.

Figure 12C illustrates a Conversation Mask 3 TLV for a convergent cymbal in accordance with an embodiment of the present invention. Conversation Mask 3 The TLV 1220 also contains three fields: a TLV Type 1222, a Conversation Mask 3 Length 1224, and a Operational Conversation Mask 3 1226. These fields provide similar functionality to the corresponding fields of the dialog mask 1 TLV 1210, respectively. In an exemplary embodiment, the length of the dialog mask 3 is 130 octets, and the total length of the three combined dialog masks is 512 octets. For the operation dialog mask, the first two dialog masks already contain 384 octets (ie, 192 octets each), leaving only the 130 octets required for the third dialog mask. The tuple - equals the size of the dialog mask described above with reference to Figures 4A-4C. Thus, those skilled in the art will appreciate that this alternative embodiment with three dialog mask TLVs can be used instead of a single TLV, and further, the TLV can be divided into any number of individual TLVs according to the same principles discussed herein. . Similarly, where embodiments are discussed herein with reference to a single dialog masking TLV, it will be understood that alternative embodiments having multiple dialog mask TLVs are also contemplated.

5A is a diagram of an embodiment of a TLV that may be included in an enhanced LACPDU to exchange information about the status of a summary of conversation IDs maintained by each aggregation system. The TLV is referred to herein as a conversational service mapping TLV. The TLV contains a group field 502, 505, and 506 having the following field definitions: TLV_type 502, which contains a value indicating that the TLV type is one of the conversation service mapping digests. A summary is one of the data cryptographic or similar processing to produce an identifier that can be used to uniquely (or almost exclusively) identify the processed data, thereby achieving error checking and archival content comparison (eg, the content of the two files is different) In the case of the case, the summary will be different). This field indicates the nature of the information carried in this TLV tuple. In one embodiment, the 埠Dialog Service Map Summary TLV may be identified by an integer value of 0x0A. The second field is Port_Conversation_Service Mapping Digest_Length field 505. This field indicates the length of this TLV tuple (in octets). In one embodiment, the 埠Dialog Service Map Summary TLV uses a length value of 18 (0x12). The third field is Actor_Conversation_Serice_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-session ID mappings maintained by the network device. There are 4096 aAggAdminServiceConversationMap[] variables indexed by the dialog ID: aAggAdminServiceConversationMap[0] to aAggAdminServiceConversationMap [4095]. In general, each variable contains a unique set of service IDs within the array. If the service ID indicates a VID, only a single VID is applicable, and in the case where the service ID indicates an I-SID, more than one I-SID is possible. The MD5 digest value can be compared by the partner system to determine if there is a difference between the mappings maintained by each of the partner systems.

Figure 5B is a diagram of one embodiment of an aggregate management service session map. The schema illustrates a field for an aggregated management service dialog map that is mapped to an array of one of the conversation ID indices and that contains a service ID or an integer representing one of the service IDs. In one embodiment, the Aggregated Management Service Dialog Map (aAggAdminServiceConversationMap[]) is an array of one of 4096 integers, such as a 32-bit or 64-bit integer. In other embodiments, the array can have any size, number, or value type. The Aggregated Management Service Dialog Map can be used to translate the Service ID into a Dialog ID, and vice versa. A dialog ID can be used to index into the array to reply to the service ID. The array can be traversed to discover a service ID and the corresponding index is the session ID.

Figure 13 illustrates a set of TLVs required to support dialog sensitivity collection and distribution functionality in accordance with an embodiment of the present invention. The set of TLVs includes an algorithm TLV, a dialog ID digest TLV, a dialog mask 1 to a mask 3 TLV, and a dialog service mapping TLV. Each of the TLVs has been discussed herein. In an exemplary embodiment, the algorithm TLV 1302 has a type field value of 0x04. The dialog ID summary TLV has a type field value of 0x05.埠 Dialog Mask 1 to Mask 3 have type field values 0x06 to 0x08, respectively. In one embodiment, the set of TLVs form an enhanced LACPDU to implement the embodiments of the invention as illustrated in Figures 3-6 and discussed herein.

Another set of embodiments for updating the conversation configuration

6 is another flow diagram illustrating one of the procedures for updating a dialog configuration of an aggregate in accordance with an embodiment of the present invention. The program can be implemented in a network that includes one or more network devices deploying a link aggregation group, such as network devices 120 and 122 of FIG. 1A . The program can also be implemented at portals 112 and 114 of Figure 1B . Note that the routine 600 is illustrated at blocks 602 through 616, and the blocks are covered by the dashed lines of blocks 301 through 305 to indicate that the program 600 is an embodiment of the present invention that implements the program 300.

Referring to Figure 6 , at block 602, the program begins with initializing session sensitivity LACP. In one embodiment, the initializing includes recording, at a network device, a preset algorithm for a partner network device as a current operational algorithm of the partner network device (eg, in the network) The device uses a function of recordDefaultPortAlgorithm() to record the default algorithm as the current operating parameter of the partner network device). The initializing may include recording, at the network device, a default dialog for one of the partner network devices, a session identifier (ID), as a current operational parameter of the session summary of the partner network device (eg, on the network) The path device uses a function of recordDefaultConversationPortDigest() to record the preset dialog 埠 conversation ID digest as the current operational parameter of the buddy network device). Initializing may further include recording, at the network device, a preset dialog mask for one of the partner network devices as a current operational dialog mask of the partner network device (eg, using recordDefaultConversationMask() at the network device A function to record the preset dialog mask as the current operating parameter of the partner network device). Additionally, initializing can include recording, at the network device, a default conversation service mapping summary for one of the partner network devices as a current operational conversation service mapping summary for the partner network device (eg, using recordDefaultConversationServiceMappingDigest at the network device) () A function to record the preset dialog service map summary as the current operational parameters of the partner network device). In the case of recording the operating parameters of the partner network device using the preset values, the session sensitive LACP is initialized.

At block 603, the program continues with the network device receiving information about the UI algorithm from the partner network device, a summary of the dialog ID, and/or a summary of the dialog service mapping. The received information will be used to record the parameter values as operational values of the network device. This information is received at the network device as a TLV embedded in the LACPDU. The information recognition algorithm of the algorithm is carried in a recordPortAlgorithmTLV, and the carried value is recorded as the current operating parameter value of the partner network device (for example, the operation parameter is Partner_Port_Algorithm). The information about the dialog ID summary is carried in a recordConversationPortDigestTLV, and the carried value is recorded as the current operational parameter value of the partner network device (for example, the operation parameter is Partner_Conversation_PortList_Digest). In addition, the information about the dialog service mapping summary is carried in a recordConversationServiceMappingDigestTLV, and the carried value is recorded as the current operating parameter value of the partner network device (for example, the operation parameter is Partner_Admin_Conversation_PortList_Digest). Upon receiving the information, the sensitivity of verification dialogue is put in operation, as shown in Figure 3 of the block 301 as illustrated. Similar to block 303 of FIG. 3 , routine 600 flows to blocks 604 through 606 and performs operations to determine the operational level through the enhanced LACPDU based at least in part on a compatibility check.

Referring to Figure 6 , at block 604, the network device determines if the algorithm used by the network device is the same as the partner network device for a link aggregation group. The operation algorithm of the network device may store for a link aggregation group with one variable such as Actor_Port_Algorithm, and the operation network algorithm of the partner network device may store for one of the partner link aggregation variables such as Partner_Port_Algorithm. The network device compares the two variables and determines if they are consistent. For example, a function such as Differ_Port_Algorithms may be used, where Differ_Port_Algorithms returns a Boolean indicating that the UI algorithm used by the network device at the two ends of the same link aggregation group and the partner network device is the same or different. If the two variables are inconsistent, a notification is sent as appropriate to notify the operator of one of the link aggregation groups to resolve the exception.

If the two variables match, the flow proceeds to block 605 where the network device determines whether the session ID digest used by the network device is associated with the partner network device for the link aggregation group. the same. The operational session ID summary of the network device may be stored in a summary such as Actor_Conversation_PortList_Digest, and the operational session ID summary of the partner network device may be stored in a summary such as Partner_Conversation_PortList_Digest. The network device compares the two digests and determines if they are consistent. For example, a function such as Differ_Port_Conversation_Digests may be used, where Differ_Port_Conversation_Digests returns a Boolean indicating that the conversation summary used by the network device at the two ends of the same link aggregation group and the partner network device is the same or different. If the two digests are inconsistent, a notification is sent as appropriate to notify the operator of one of the link aggregation groups to resolve the exception.

If the two variables are identical, then flow proceeds to block 606 where the network device determines whether the session service map digest used by the network device is the same as the partner network device for the link aggregation group. The operational session service map summary of the network device may be stored in a summary such as Actor_Conversation_Service_Mapping_Digest, and the operational session service map summary of the partner device may be stored in a summary such as Partner_Conversation_Service_Mapping_Digest. The network device compares the two digests and determines if they are consistent. For example, a function such as Differ_Conversation_Service_Digests may be used, where Differ_Conversation_Service_Digests returns a Boolean indicating that the conversation service mapping summary used by the network device and the partner network device at both ends of the same link aggregation group is the same or different. If the two digests are inconsistent, a notification is sent as appropriate to notify the operator of one of the link aggregation groups to resolve the exception.

Note that in some embodiments of the invention, the order of the decisions of blocks 604 through 606 may be different than illustrated in FIG . Additionally, certain embodiments of the present invention may deploy more or less compatibility checks, as illustrated.

Once the operational parameters of the network device and the partner network device for the same link aggregation group are determined (however, some of the parameters may be considered as management parameters) are compatible and both display long LACPDUs ( Also known as version 2 LACPDU), it is possible to process the received session sensitive information by long LACPDU processing. Each long LACPDU is longer than 128 octets. As discussed above herein, an enhanced LACPDU needs to update the dialog configuration information because a legacy LACPDU can support only up to 1024 conversations. The long LACPDU is an embodiment of an enhanced LACPDU, and other embodiments of the enhanced LACPDU are possible in supporting the disclosed invention. In general, the enhanced LACPDU can carry the control information required to exchange the dialog configuration information on the link aggregation group link between the local network device and a partner network device. For example, some embodiments may not use long LACPDUs when one of the LACP implementations supports no more than 1024 conversations. In other embodiments, long LACPDUs are used. Since each LACPDU is longer than 128 octets, and thus it can support more conversations than the traditional LACPDU of 128 octets. For example, a long LACPDU may transmit one of the dialog mask TLVs illustrated in FIG. 4A that may indicate a dialog configuration state of up to 4096 conversations. Long LACPDUs consume more network resources for processing and transmission, and always allowing their transmission is not efficient. Thus, block 608 can set a timer to provide the network device with a time window for transmitting long LACPDUs. Once the timer expires, the network device no longer transmits long LACPDUs and the program ends without updating the session configuration. In the case where the timer is set long for the LACPDU, enhanced transmission network means determines the LACPDU (this embodiment of the present invention using the LACPDU length) of the operating system may, as shown in Figure 3 of the block 303 as illustrated. Similar to block 305 of FIG. 3 , routine 600 flows to blocks 608 through 622 and updates a dialog state of the aggregate.

Referring to FIG. 6 , at block 608, the network device receives one or more long LACPDUs from the partner network device indicating one of the different operational session configuration states at the partner network device. The operational dialog configuration state at the partner network device is as an operational dialog mask for the partner network device delivered by the received long LACPDU. A received long LACPDU may contain an operational dialog configuration state embedded within a single dialog mask TLV. Embodiment, the operating state of the dialogue partner network device configuration of a plurality of dialogue is embedded within the mask TLV In another embodiment, a mask such as a dialogue to the mask 3, as shown in Figure 12A to 12C as illustrated.

In one embodiment, a function (such as recordReceivedConversationMaskTLV) is executed for an embodiment with multiple dialog mask TLVs. The function records the parameter value of ActPar_Sync carried in a TLV mask 1 TLV as the current operation parameter value of Partner_ActPar_Sync, which is concatenated by dialog mask 1 TLV, 埠 conversation mask 2 TLV and 埠The dialog mask 3 values of Port_Oper_Conversation_Mask_1, Port_Oper_Conversation_Mask_2, and Port_Oper_Conversation_Mask_3 carried by the TLV, and the function records the concatenation as the current value of the buddy operation mask variable. When the dialog configuration state is operated at the comparison partner network device and the local network device, at block 616, the function compares the variable operation dialog mask with the partner operation dialog mask.

The network device may not receive a long LAC PDU, but at block 612, one of the operational states of the detected link aggregation group is changed or one of the management configurations is changed. The network device can contain one of each of the aggregated groups of variables to track one of the operational states of each of the changes. For example, a network device can set a ChangeActorOperDist variable for each frame, and the variable is set to true when the frame assignment state changes. This variable can be expressed for all aggregates as ChangeAggregationPorts corresponding to the logical OR of the ChangeActorOperDist variable. The ChangeActorOperDist variable for each 亦可 can also track management configuration changes. For example, if a new management value (which contains a management value for a merging/selection priority list of a reference 埠 conversation ID) selected by aAggConversationAdminPort[] is detected, aAggAdminServiceConversationMap[] tracks one of the new management values (which contains a set of service IDs), and the variable can be set to true. Thus, also at block 612, the network device updates its operational dialog configuration state. In one embodiment, the update is until its operational dialog mask is updated. In either case, at block 616, one of the network device updates Collect conversation masks. In one embodiment, the collection dialog mask is an operational Boolean vector. It may be indexed by the dialog ID indicating whether the indexed session ID is allowed to arrive at the aggregator upon receipt through a polymerization. The network device then checks and sees if its operational dialog mask matches the operational dialog mask used by the partner network device. In one embodiment, the verification is until the Partner_Oper_Conversation_Mask variable at the network device is checked.

In one embodiment, the network device is set differently depending on whether or not all of the aggregations in the network device have been updated (in the case of an portal site, including the portal site (IPP)). One collects the conversation mask. If all the dialog masks have been updated, the network device sets the collection dialog mask equal to the updated operation dialog mask (updated, the operation dialog mask can be updated based on the current dialog list). A function (for example, updateConversationMask) is obtained). If the update of the other conversation masks in the network device continues, the network device sets the collection session mask equal to the correspondence between the current collection session mask and the updated operation dialog mask. The Boolean vector of the result of a logical AND operation (for example, via the updateConversationMask function).

Collecting network device indicating dialogue session with the dispensing shield mask is not synchronized (for example, one using a mask TLV dialogue session status field of ActPar_Sync mask bits, as illustrated in FIG. 4B). As discussed herein above, the network device can contain one variable for each of a group of aggregates to track one of the operational states of each of the changes, such as one for each of the ChangeActorOperDist variables, where ChangeActorOperDist Track the operation status of the network device at the distribution frame. The network device will set the variable to false to indicate that there is no frame assignment state change.

When the operational dialog mask matches the matching operational dialog mask at the partner network device, the process proceeds to block 622, and because the two network devices (buddies) have the same operational dialog mask, the long LACPU is sent. The program will stop. When the operational dialogue mask does not match the associated operational dialogue mask at the partner network device, the program proceeds To block 617, an out of sync is detected.

The network device then sets a timer for transmitting an updated long LACPDU to the remote network device at block 618. It will update the local settings to true when the dialog mask is out of sync (for example, use updateLocal to indicate the local dialog mask that needs to be updated).

Example of updating a dialog mask

7 is a flow chart illustrating one of the dialog masks for immediately updating a converged 在 after receiving a long LACPDU, in accordance with an embodiment of the present invention. Method 700 can be implemented at an aggregation controller of a network device. At block 705 in FIG. 7 , a long LAC PDU is received at the network device containing one of the different conversational configuration states at the partner network device. When the long LACPDU contains a dialog mask of one of the partner network devices different from the conversation mask at the aggregation port (ie, the partner network device has sent a different dialog mask), the network device checks by, for example, Partner_Oper_Conversation_Mask A partner operates the dialog mask variable to determine if the partner network device has sent a different dialog mask. The partner operation dialog mask variable is one of the variables associated with each link aggregation. In one embodiment, the variable is stored in a storage device within the network device.

In one embodiment, a mask through a dialogue partner TLV transfer operation dialogue mask, as illustrated in FIG. 4A. When a new dialog mask TLV is received, the partner operation dialog mask embedded in the new dialog mask TLV updates the partner operation dialog mask variable for the aggregate. Thus, the partner operation dialog mask variable for link aggregation is synchronized with the dialog mask for operation of the link aggregation group at the partner network device. The network device compares the buddy operation dialog mask variable with the 埠 operation dialog mask, and a difference triggers block 616.

Referring to FIG. 7 , at block 707, the aggregated dialog mask of the aggregate is updated based on an update dialog mask function (eg, the updateConversationMask function).

At block 708, the network device sets the dialog mask used at the network device to be different than one of the dialog masks used at the partner network device. In one embodiment, a dialog mask state value (such as the ActPar_Sync bit at reference 410 of Figure 4B ) is set to indicate a non-conformance.

Although FIG. 7 illustrates an operational sequence, in other embodiments of the invention, the sequence of operations may vary. For example, in another embodiment of the invention, blocks 707 through 708 may be ordered differently.

Note that, although the discussion regarding FIG. 7 of the polymerization port, but the portal 700 against a resilient distributed network interconnection (DRNI) system embodiment of the method, the network devices are also embodiments of the polymerization system DRNI port, as shown in Figure 1B Shown in the middle.

8A- 8D illustrate a sequence of one of the dialog masks for updating an aggregate in accordance with an embodiment of the present invention. Each graph contains the partner dialog mask variable associated with an aggregate and the values of the collection mask, allocation mask, and dialog mask state associated with the aggregate. In Figure 8A , the polymerized germanium operates in a normal state. The collection dialog mask and the assignment dialog mask are the same, both are 01010101...00. In this example, the link aggregation group supports up to 4096 conversations, so the collection dialog mask and allocation dialog mask contains 4096 bits (512 octets). To simplify the illustration, only the first 10 bits and the last two bits of the mask are illustrated, so the discussion focuses on dialogs 0 through 9 (conversation ID: 0 to 9) and dialogs 4094 and 4095 (conversation ID: 4094 and 4095). . As illustrated, the aggregates process dialogs 1, 3, 5, and 7. The UI allocates and collects frames for the same conversations 1, 3, 5 and 7. The buddy dialog mask variable is the same as the collect dialog mask and the assignment dialog mask and it indicates the match of the link aggregation group at the remote network device, the transport dialogs 1, 3, 5 and 7. Therefore, the dialog mask state indicates that the collection dialog mask and the assignment dialog mask are the same as the partner conversation mask variable by setting an ActPar_Sync bit to 1, so the dialog mask state is 10000000.

In Figure 8B , an abnormality occurs in the link aggregation group and the partner dialog mask variable is updated to a different value. The triggering event can be a link failure, a link aggregation system failure at one of the portal sites, or some other event. The exception may trigger transmission of one of one or more enhanced LACPDUs (such as long LACPDUs) and receive an enhanced LACPDU at the network device. The embedded TLV (such as the dialog mask TLV 400 illustrated in Figure 4A) is used to update the partner dialog mask variables associated with the aggregate. One of the hint partner dialog mask variables is emphasized by a bottom line to change the bit value, and the same token is applied to Figures 8C-8D . The Partner Conversation Mask variable now instructs the partner network device to transfer the conversations 0 through 3 to the aggregation. It no longer transmits conversations 5 and 7, but adds conversations 0 and 2.

The network device then stores the partner dialog mask variables and maintains the aggregation, collection, and distribution of the dialogs of dialogs 1, 3, 5, and 7 as before. Since the conversation mask used by the local network device (actor) is different from the conversation mask of the remote system (partner), the dialog mask state represented by the ActPar_Sync bit is reset to zero and a variable (updateLocal) is used. Set to 1 to indicate that the local dialog mask needs to be recalculated.

In FIG. 8C , a long LACPDU has been obtained, and if all the ports of the local network device have not been updated to match the same conditions as the partner, then one between the current collection session mask and the updated operation dialog mask is obtained. The logical AND operation (for example, through an update operation, such as executing the updateConversationMask function) updates the collection dialog mask and assigns the conversation mask. Therefore, the collection dialog mask and the assignment dialog mask are updated to 01010000..00 (ie, the aggregation is only collected from the common dialogs 1, 3 frames). Then, in Figure 8D , all ports on the local network device have been updated to match the same conditions as the partners and are correspondingly reported to have the same Actor_Oper_Port_State. A value is assigned if the connection on the remote partner is degraded, which sets the ActPar_Sync bit to 1, indicating that the partner at the partner network device has completed synchronization of the collection dialog mask with the assignment dialog mask. The collection dialog mask can then be set to be the same as the assignment dialog mask and follow the partner dialog mask variables to collect only the dialogs 0 to 3.

9 is a flow diagram of one embodiment of a procedure for session sensitivity collection for a link aggregation group. The illustrated procedure is implemented along with the frame collection procedure. That is, the procedure is for the handling of frames containing conventional data traffic as opposed to the handling of LACPDUs as discussed herein above. Moreover, as set forth above herein, the frame collection program collects the frames from the aggregated frame and based on the algorithm used with the frame distributor of the partner system. In the case where dialog sensitivity collection and distribution is enabled, the illustrated program performs a dialog configuration for each aggregate. The dialog is configured to a particular frame such that a frame arriving at a given session of a non-configured aggregate becomes disordered due to a dialog reconfiguration to another aggregate or similar problem.

The program may begin in response to receiving a frame via one of the link aggregation groups associated with the network device executing the program (block 901). The network device that communicates the group communication via the link may be part of a DRNI portal or similar network configuration. The received frame can be any type of communication format, such as an Ethernet frame or similar communication unit. The frame can be received via the aggregation port and passed to the frame collector of the network device. In one embodiment, the dialog sensitivity frame collection can be enabled and disabled by a management function or configuration. In other embodiments, dialog sensitivity frame collection is always implemented. In the case where the dialog sensitivity frame collection is configurable, the frame collector may check whether session sensitivity frame collection is currently enabled (block 903). If dialog sensitivity 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 aggregators according to the aggregation algorithm or distribution procedure used by the partner system.

Where session sensitivity collection is enabled, the session identifier can be determined for the received frame (block 907). The session identifier can be determined using any program or technique that utilizes information within the received frame such that the same program or technique is utilized by both the frame allocator and the frame collector to definitively obtain the same session identifier. In an exemplary embodiment, the service identifier is retrieved from the received frame. The service identifier can be any field or field combination in the received frame, such as a virtual area network (VLAN) identifier (VID) field or a backbone service instance identifier (I-SID). The service identifier can then be translated into a conversation identifier. The translation may use any local data structure, such as a lookup table, that maps the array or similar data structure to the mapping service identifier and the session identifier.

The resulting session identifier can then be compared to a conversation mask or similar data structure that tracks a conversation that has been configured to a particular aggregation (block 911). In the case of finding a match, The received frame is configured to be part of a conversation through which the received frame is received and thus in an appropriate order, and the frame collector can pass the frame to the aggregator client. However, if a match is not found in the dialog mask or similar tracking structure, the received frame is received out of order on the error aggregate and then discarded (block 913).

10 is a flow diagram of another embodiment of a procedure for session sensitivity collection of a link aggregation group. This embodiment provides an exemplary embodiment of the procedure set forth above with respect to FIG. The initialization in response to receiving the frame (block 901) may be based on a MAC aggregation of the network device receiving a frame indicator or identifier, wherein the aggregation is associated with a link aggregation group (block 1001). A link aggregation group can be defined between the aggregation system and the two partner systems of the DRNI portal. The frame can be stored in any memory device, buffer, cache, scratchpad or network processor or similar storage location within the network device. An indicator or similar identifier provides location information for accessing the frame.

The received frame can be any type of communication format, such as an Ethernet frame or similar communication unit. The frame can be received via the aggregation port and transmitted to the frame collector of the network device via the control parser/multiplexer and the aggregator/multiplexer, wherein the frame collector is one of the network devices. The network processor performs one of the subassemblies of one of the link aggregation sublayers. In one embodiment, the dialog sensitivity frame collection can be enabled and disabled by a management function or configuration. In other embodiments, dialog sensitivity frame collection is always implemented. In the case where the dialog sensitivity frame collection is configurable, the frame collector can check whether a flag or similar status flag is set in one of the configurations of the aggregator or the like (for example, an "enable error dialog" The "flag" is discarded and it is checked whether the dialog sensitivity frame collection is currently enabled (block 903) (block 1003). If the dialog sensitive frame collection is not enabled, the received frame, frame indicator or similar frame identifier is forwarded to the aggregator client (blocks 905, 1005). The frame collector collects received frames from all aggregators based on the aggregation algorithm or distribution procedure used by the partner system.

The frame can be processed to use a total of between the frame collector and the frame distributor. An associated session identifier is determined using any function of the decisive program (e.g., a DeterminePortConversationID function) (block 907). In an exemplary embodiment, the function may determine the session identifier by accessing the frame to retrieve a service ID (block 907), wherein the frame content and format are first reviewed for comparison by frame The header information and frame dialogs assign configuration information to determine a service ID format and location (block 1007). The frame format and configuration information may indicate that the service ID is in the form of a 12-bit VID field, a 24-bit I-SID field or the like or a combination thereof depending on the frame format. The configuration specifies any field or field group that will be used as the service ID of the received frame. The program then continues to retrieve the service ID from the frame by using the service ID type and location information (block 1009). For example, a frame indicator or location information may take the form of an address and an offset that enable the frame collector to access and retrieve one of the values at the specified location, respectively.

The retrieved service ID can then be used to obtain (i.e., translate it into) a corresponding dialog identifier (block 909). The translator can take the form of a lookup using one of the dialog service mapping tables (i.e., the aAggAdminServiceConversationMap[] array, which uses a dialog identifier as an index and stores the service ID). The lookup may use the service ID as an index, traverse a data structure to match the service ID, or perform a similar lookup operation on the dialog service map summary. The lookup operation returns the corresponding session identifier of the received frame.

A determination can then be made as to whether the received frame has one of the session identifiers that have been configured to one of the conversations via which the received frame was received (block 911). The check can be distinguished by accessing a dialog mask of the aggregate received through its frame, wherein the dialog mask is used to track a bit map or similar data structure of the dialog configured to the aggregate (block 1013) ). If the corresponding bit of the session identifier is set to a Boolean truth value, the frame is associated with one of the dialogs appropriately configured to the aggregation and can be forwarded to the aggregator client (block 1005). However, if the corresponding bit in the dialog mask is set to a Boolean false, the frame is discarded (blocks 913, 1015), which is due to the frame and the unconfigured to be received through the frame. Associated with a dialog indicating that the frame was reconfigured due to a program or class It seems to be changed and sent incorrectly or out of order.

11 is a diagram of an embodiment of a network device for implementing a session sensitivity collection of a link aggregation group in a network. The network device can handle the conversation, where each conversation is for one of the services or an application in the network. Network device 1180 can implement a link aggregation sublayer 1170, as set forth above with respect to FIG. 2, and supports the link aggregation functions set forth above herein. The network device 1180 can include a network processor 1100, a set 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 can implement the aggregation function and link aggregation sublayer 1170 using any number or type of processors and in any configuration. In other embodiments, the aggregation function and the link aggregation sublayer and related components are implemented via a set of network processors, a set of line cards, and their constituent general purpose and special application processors or a network device architecture. Distribute things.

The device 1140 can connect to the network device via one of physical media such as Ethernet, fiber optics, or similar media having any number of other network devices. There may be any number and variety of ports in the network device 1180. Any combination or subgroup of 埠 1140 can be organized and managed as a link aggregation group or a DRNI portal, where the network device acts as a converged system.

A set of storage devices 1150 in network device 1180 can be any type of memory device, cache memory, scratchpad, or similar storage device for use as a working memory and/or persistent storage device. Any number and type of storage devices 1150 can be utilized to store data for network devices containing programmed data and received data services to be processed by network device 1180. In one embodiment, a summary database 1152 or a conversation service mapping summary of conversation lists transmitted through aggregators, a dialog mask, a similar organization of dialog configuration states, and similar data structures as described herein above may be stored herein. In a data structure. Other data structures stored in storage device 1150 may include aAggAdminServiceConversationMap[] and similar data structures. In other embodiments These data structures can be considered to be independent and can be distributed via any number of individual storage devices 1150 within network device 1180.

A set of network processors 1100 can implement aggregation functions and link aggregation sublayers 1170 as set forth above herein. The aggregation function may include an aggregator client 1172 and a link aggregation sublayer 1170. The link aggregation sublayer may include a control parser/multiplexer 1102, an aggregation controller 1106, a frame collector 1125, and a frame allocator 1120. And the client interface 1111. As further explained herein above, the aggregator client 1172 can provide higher level functionality of the network device, such as layer 3 functionality and similar higher level functionality.

As further described above herein, the aggregation controller 1106 can implement link aggregation control and link aggregation control protocol functions. These features manage the configuration and configuration of link aggregation groups, DRNI portals, and the like. The control parser and multiplexer 1102 identifies and forwards the LACPDUs and other data traffic received on the aggregation and sends the LACPDUs to the aggregation controller 1106 and sends other data traffic to the link aggregation sublayer 1170.

As further explained above herein, the link aggregation sublayer 1170 manages the collection and distribution of frames in accordance with the allocation algorithm. Within link aggregation sublayer 1170, frame collector 1125 receives the frames and organizes the frames according to a distribution algorithm that is shared across the link aggregation group and the partner system. The frame allocator 1120 prepares and selects an outbound frame for transmission via a set of aggregates in accordance with the allocation algorithm. A client interface 1111 receives the frame from the aggregator client 1172 and transmits the frame to the aggregator client 1172. The inbound frame auto-frame collector 1125 passes to the aggregator client 1172, and the outbound frame auto-frame allocator 1120 passes to the aggregator client 1172.

As discussed above with respect to dialog sensitivity collection for a link aggregation group, the frame collector 1125 is configured to: determine a session identifier for a received frame (eg, for use in an example implementation) In the example, the self-frame captures a service identifier and translates the service identifier into one of the dialog identifiers, the DetermineConversationID function, however, any deterministic procedure shared between the frame collector and the frame allocator can be utilized; Comparison The dialog identifier is configured to communicate with the dialog; the message frame is discarded in response to the session identifier not matching one of the dialog configurations; and the frame is forwarded to an aggregator client in response to the match identifier matching one of the dialog configurations . In addition, in an exemplary embodiment, the frame collector 1125 may check whether session sensitivity collection is enabled; may receive a frame indicator from one of the associations associated with the link aggregation group; Comparing the frame header information with the frame dialog assignment configuration to determine a service identifier format and location and capturing the service identifier from the frame at the determined location and capturing the service identifier from the frame; Translating the service identifier into a dialog identifier to obtain a dialog identifier, and translating the service identifier into a dialog identifier; comparing the dialog identifier by using the dialog identifier as an index to access one of the aggregated dialog masks The dialog is configured with a dialog; and a frame miss can be found in response to a position in the dialog mask identified by using the dialog identifier as an index.

In one embodiment, the aggregation controller 1106 verifies that one of the dialog sensitive link aggregation control protocol (LACP) implementations is in operation. The verification is performed by the aggregation controller 1106 initializing an implementation of the LACP and then receiving at least one of: (1) one of the session identifiers for assigning the frame to a partner network device One of the algorithm identifiers; (2) a conversation identifier digest from one of the partner network devices; and (3) a conversation service mapping digest from one of the partner network devices. The received parameters may be stored in storage device 1150 (eg, summary database 1152).

The aggregation controller 1106 then determines that the operation of the enhanced LACPDU is possible after verifying that an LACP implementation is operational. As discussed herein above, the enhanced LACPDU can be used to update the dialog configuration information, and the determination is based on a set of operational parameters of the network device 1180 and another set of matching operational parameters of one of the network devices 1180. A compatibility check between. The partner network device is one of the other ends of the link aggregation group of the network device 1180, the remote network device. In one embodiment, the enhanced LACPDU is a long LACPDU, which means that it is longer than 128 octets.

In one embodiment, the compatibility check includes: (1) determining a first algorithm for assigning a frame to the session identifier at the network device and for assigning the frame to the self-partner network The second algorithm of one of the session identifiers received by the road device is identical; (2) determining that the first session identifier digest of one of the network devices is consistent with the second session identifier digest received by the self-partner network device; and 3) Determining that a first dialog service map digest is consistent with a second dialog service map digest received from the partner network device. If the compatibility check passes, the aggregation controller 1106 processes the received collection sensitivity information and sets a timer to provide a time window for transmitting the enhanced LACPDU. If the timer expires and the enhanced LACPDU is not received, the partner's default configuration parameters are set and another verification/compatibility check cycle needs to be initiated.

If the compatibility check fails, the enhanced LACPDU cannot be used and manual intervention may be required, so the aggregation controller 1106 may issue a notification to indicate that the compatibility check failed.

When the compatibility check passes, the aggregation controller 1106 can be configured to update the dialog configuration state based on one of the one of the link aggregation groups. In one embodiment, a conversational configuration state of an aggregate is represented by a dialog mask of the aggregate. The Convergence dialog mask can be represented by a Conversation Mask Type/Length/Value (TLV) containing (1) a TLV type field, (2) a dialog mask length field, and (3) A dialog mask status field and (4) an operation dialog mask field. The structure of each field has been discussed above in this document. Note that, the dialogue session mask by one or more TLV indicates the mask, as shown in FIGS. 4A to 4C and 12A to 12C as illustrated and discussed herein above.

Thus, in some embodiments, the aggregation controller can be considered to include: a verification unit for verifying that one of the dialog sensitive link aggregation control protocol (LACP) implementations is in operation; a decision unit, It is possible to determine the operation through the enhanced link aggregation control protocol data unit LACPDU, where the enhanced LACPDU can be used for updating. Conversation configuration information, wherein the determining is based at least in part on a compatibility check between the first set of operational parameters of one of the network devices and the second set of operational parameters of one of the partner network devices, and wherein the partner network device is a remote network device of one of the link aggregation groups communicatively coupled with the network device; and an update unit for aggregating one of the first session configuration states based on one of the link aggregation groups The first session configuration state is updated by a decision, wherein the first conversation configuration state of the aggregation of the link aggregation groups indicates that one of the first conversation lists is transmitted through the aggregation.

Updating the session configuration state may be based on a first session configuration state of the aggregation of the link aggregation group at the network device, different from one of the second session configuration states received from the partner network device, wherein The second dialog configuration state indicates that one of the second conversation lists is received through the link aggregation group. Alternatively, updating the session configuration state may be based on one of the changes in one of the operational states of the aggregation group at the network device. Note that the network device can set a timer to provide the network device with a time window for transmitting long LACPDUs. Once the timer expires, the network device is prevented from transmitting an enhanced LACPDU (e.g., a long LACPDU as discussed herein above) and the process of updating the dialog configuration ends. In the case where the timer is set for a long LACPDU, network devices using the operating system first determines enhanced LACPDU it possible, as in FIG. 3 of the block 303 as illustrated.

For the sake of clarity, certain terms have been changed between this document and the priority document. However, all changes to the terms are related to equivalent terms. As used herein and in the priority document, "data stream" is understood to mean an ordered sequence of frames, which is also equivalent to a "conversation". Referring to a link aggregation group "level", which introduces a dichotomy between "link level" and link aggregation group "level", and a session identifier identifies a link aggregation group bit The statement of one of the conversations is equivalent to the indication that the conversation identifier identifies a conversation at a given link aggregation group. In the case of detailing "each frame" in a group frame received by a network device, a specific "received frame" is in the frame.

Although the invention has been described in terms of several exemplary embodiments, those skilled in the art It will be appreciated that the invention is not limited to the embodiments described, but may be practiced in the spirit and scope of the appended claims. Accordingly, the description is to be regarded as illustrative rather than limiting.

Claims (29)

A method implemented by a network device for updating a session configuration on a link of a link aggregation group, wherein the network device is communicatively coupled to the aggregation port through the links of the link aggregation group The network device processes the dialog, and each of the dialogs consists of an ordered sequence of frames, the method comprising the steps of: verifying (301) one of the dialog sensitive link aggregation control protocol LACP implementations It is possible to determine (303) the operation of the LACPDU through the enhanced link aggregation control protocol data unit LACPDU, wherein the enhanced LACPDU can be used to update the session configuration information, wherein the determination is based at least in part on one of the network devices a compatibility check between a set of operational parameters and a second set of operational parameters of a partner network device, and wherein the partner network device is communicatively coupled to the link device a remote network device; and updating (305) the first session configuration state based on a determination that one of the first aggregation configuration states of the one of the link aggregation groups is incorrect The first dialog configuration state of the aggregate of the link aggregation group indicates that one of the first conversation lists is transmitted through the aggregation. The method of claim 1, wherein the step of verifying a session-sensitive LACP includes the steps of: initializing (602) the implementation of the session-sensitive LACP at the network device; and receiving (603) At least one of: an algorithm identifier for assigning a frame to a session identifier at the partner network device; A dialog identifier summary from the partner network device; and a dialog service map summary from the partner network device. The method of claim 1 or 2, wherein the compatibility check between the first set of operational parameters of the network device and the second set of operational parameters of the partner network device comprises: determining (604) for Assigning the frame to one of the session identifiers at the network device, the first algorithm is identical to the second algorithm for assigning the frame to the session identifier received from the partner network device; (605) the first session identifier digest of one of the network devices is identical to the second session identifier digest received from the partner network device; and determining (606) a first session service mapping digest and from the partner network The road device receives one of the second dialog service map summaries consistently. The method of claim 1 or 2, wherein the enhanced LACPDUs are long LACPDUs, and wherein each of the long LACPDUs has a length exceeding 128 octets. The method of claim 1 or 2, wherein the first dialog configuration state of the aggregate is represented by a dialog mask of the aggregate. The method of claim 5, wherein the conversation mask of the aggregation is represented by one or more conversation mask types/length/values (TLVs). The method of claim 6, wherein the dialog mask TLV comprises: a TLV type field; a dialog mask length field; a dialog mask status field; and an operation dialog mask field. The method of claim 7, wherein the dialog mask status field includes a first dialog mask indicating that the first conversation mask of the network device matches one of the partner network devices. Is it consistent with a bit, which collects the conversation cover The hood and the assignment dialog mask respectively indicate a list of conversations collected by a collection function and distributed by an assignment function. The method of claim 7, wherein the operation dialog mask field indicates a conversation configuration state of the aggregated link. The method of claim 1 or 2, wherein the determining that the first session configuration state is incorrect is based on at least one of: the aggregation of the link aggregation group at the network device The first session configuration state is different from one of the second session configuration states of the aggregation received from the partner network device, wherein the second session configuration state indicates that one of the second group configuration states is received through the link aggregation group a list of dialogs; and one of an operational state or a management configuration of the aggregated group at the network device is changed, wherein the operational state is associated with each of the aggregated groups at the network device . The method of claim 1 or 2, further comprising: setting a timeout timer after the determination by the operating systems of the enhanced LACPDUs, wherein suppressing the enhancements after a timeout period These operations of the LACPDU. The method of claim 1 or 2, wherein each session is for a service or an application in a network. A network device (1180) configured to be communicatively coupled to an aggregate via a link aggregation group, wherein the network device is configured to process a conversation, and wherein each session is comprised of a An ordered sequence of frames, the network device comprising: a set of aggregates (1140) configured to receive a frame via the links of the link aggregation group; and a network processor ( 1100), comprising: an aggregation controller (1106) configured to verify a dialog sensitive link aggregation One of the implementations of the Control Agreement (LACP) is in operation; the aggregation controller is further configured to determine the operational nature of the Enhanced Link Aggregation Control Protocol Data Unit (LACPDU), wherein the enhanced LACPDUs are available Updating the dialog configuration information, wherein the determining is based on a compatibility check between the first set of operational parameters of the one of the network devices and the second set of operational parameters of one of the partner network devices, and wherein the partner network The device is a remote network device of the link aggregation group communicatively coupled to the network device; and the aggregation controller is further configured to aggregate one of the aggregation groups based on the link aggregation group The first session configuration state is updated by determining one of the dialog configuration status incorrectly, wherein the first conversation configuration state of the aggregation of the link aggregation group indicates that one of the first conversation lists is transmitted through the aggregation. The network device of claim 13, further comprising: a storage device (1150) configured to store a dialog configuration state of the dialog list transmitted through the aggregate. The network device of claim 13 or 14, wherein the network processor further comprises: a link aggregation sublayer, comprising: a control parser and a multiplexer configured to process the LACPDU, and Aggregation of link aggregation groups, receiving the frames and transmitting the frames to the aggregates of the link aggregation group; a client interface configured to receive from the partner network device Dialing a sensitive frame and transmitting the dialog sensitive frames to the partner network device; a frame allocator configured to be allocated from the partner network device toward the aggregated frame; and a frame collector configured to collect frames from the aggregates toward the partner network device; and an aggregator client configured to interact with the link aggregation sublayer to process the message frame. The network device of claim 13 or 14, wherein the aggregation controller verifies that the implementation of the session sensitive LACP is in operation by: initializing the session sensitive LACP at the network device The embodiment; and receiving at least one of: an algorithm identifier for assigning a frame to a session identifier at the partner network device; a session identifier A summary from the partner network device; and a conversation service mapping summary from the partner network device. The network device of claim 13 or 14, wherein the aggregation controller performs between the first set of operational parameters of the network device and the second set of operational parameters of the partner network device by: The compatibility check: determining a first algorithm for assigning a frame to the session identifier at the network device and a session identifier for assigning the frame to the network device received from the partner One of the second algorithms is consistent; determining that the first session identifier digest of the network device is consistent with the second session identifier digest received from the partner network device; and determining a first session service mapping digest and self The partner network device receives one of the second dialog service map summaries consistently. The network device of claim 13 or 14, wherein the enhanced LACPDUs are LACPDUs, wherein each long LACPDU has a length exceeding 128 octets. The network device of claim 13 or 14, wherein the first conversation configuration of the aggregation The status is represented by a dialog mask of the aggregate. The network device of claim 19, wherein the conversation mask of the aggregation is represented by one or more conversation mask types/length/values (TLVs). The network device of claim 20, wherein the dialog mask TLV comprises: a TLV type field; a dialog mask length field; a dialog mask status field; and an operation dialog mask field. The network device of claim 21, wherein the dialog mask status field includes a second dialog indicating that the first conversation mask of the network device is matched to one of the partner network devices. A bit of a mask that is consistent, wherein the collection dialog mask and the assignment dialog mask respectively indicate a list of conversations collected by the collection function of the aggregation and assigned by one of the aggregations. The network device of claim 21, wherein the operation dialog mask field indicates a conversation configuration state of the aggregated link. The network device of claim 13 or 14, wherein the determining that the first session configuration state is incorrect is based on at least one of: the aggregation of the link aggregation group at the network device The first session configuration state is different from one of the second session configuration states of the aggregation received from the partner network device, wherein the second session configuration state indicates that one of the group aggregations is received through the link a second dialog list; and one of the operational status or management configuration of the aggregated group at the network device is changed, wherein the operational status is associated with each of the aggregated groups at the network device Associated. The network device of claim 13 or 14, wherein the link aggregation controller sets a timeout after the determination by the operating system of the enhanced LACPDU The operation of suppressing the transmission of the enhanced LACPDU after a timeout period. The network device of claim 13 or 14, wherein each session is for a service or an application in a network. A non-transitory computer readable storage medium having instructions stored therein, the instructions, when executed by a processor, causing the processor to perform a session on a link implemented by a network device for updating a link aggregation group A configured operation, wherein the network device is configured to be communicatively coupled to the aggregate via the links of the link aggregation group, wherein the network device is configured to process the conversation, and wherein each conversation Consisting of an ordered sequence of frames, the operations comprising the steps of: verifying (301) one of the Session Sensitive Link Aggregation Control Protocol (LACP) implementations, and determining (303) the enhanced link The operation of the Aggregation Control Protocol Data Unit (LACPDU) is operative, wherein the enhanced LACPDUs are operable to update the dialog configuration information, wherein the determining is based at least in part on a first set of operational parameters of the network device and a partner network a compatibility check between one of the second set of operational parameters of the circuit device, and wherein the partner network device is one of the link aggregation groups communicatively coupled to the network device And updating (305) the first session configuration state based on one of the first aggregation configuration states of one of the link aggregation groups, wherein the aggregation of the link aggregation group The first conversation configuration state indicates that one of the first conversation lists is transmitted through the aggregation. A computer program with instructions that, when executed by a processor, cause the processor to perform operations performed by a network device to update a dialog configuration on a link of a link aggregation group, wherein the network The way the device is configured to be communicatively coupled to the aggregate through the links of the link aggregation group, wherein the network The apparatus is configured to process a conversation, and wherein each conversation consists of an ordered sequence of frames, the operations comprising the steps of: verifying (301) an implementation of a Session Sensitive Link Aggregation Control Protocol (LACP) In operation, it is possible to determine (303) the operation through the Enhanced Link Aggregation Control Protocol Data Unit (LACPDU), wherein the enhanced LACPDUs can be used to update the dialog configuration information, wherein the determination is based at least in part on the network. a compatibility check between one of the first set of operational parameters and one of the second set of operational parameters of one of the partner network devices, and wherein the partner network device is communicatively coupled to the network device a remote network device of one of the link aggregation groups; and updating (305) the first session configuration state based on one of the first conversation configuration states of one of the link aggregation groups The first dialog configuration state of the aggregate of the link aggregation group indicates that one of the first conversation lists is transmitted through the aggregation. A carrier comprising a computer program as claimed in claim 28, wherein the carrier is one of an electronic signal, an optical signal, a radio signal or a computer readable storage medium.