BR112015026779B1 - Método para suportar uma interconexão de rede resiliente distribuída em um grupo de agregação de link em um dispositivo de rede, dispositivo de rede e meio de armazenamento legível em máquina não transitório relacionados - Google Patents

Método para suportar uma interconexão de rede resiliente distribuída em um grupo de agregação de link em um dispositivo de rede, dispositivo de rede e meio de armazenamento legível em máquina não transitório relacionados Download PDF

Info

Publication number
BR112015026779B1
BR112015026779B1 BR112015026779-3A BR112015026779A BR112015026779B1 BR 112015026779 B1 BR112015026779 B1 BR 112015026779B1 BR 112015026779 A BR112015026779 A BR 112015026779A BR 112015026779 B1 BR112015026779 B1 BR 112015026779B1
Authority
BR
Brazil
Prior art keywords
portal
gateway
tlv
network device
port
Prior art date
Application number
BR112015026779-3A
Other languages
English (en)
Other versions
BR112015026779A2 (pt
Inventor
Panagiotis Saltsidis
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of BR112015026779A2 publication Critical patent/BR112015026779A2/pt
Publication of BR112015026779B1 publication Critical patent/BR112015026779B1/pt

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0869—Validating the configuration within one network element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H04L45/245—Link aggregation, e.g. trunking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/46—Cluster building
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/25—Routing or path finding in a switch fabric
    • H04L49/253—Routing or path finding in a switch fabric using establishment or release of connections between ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/354—Switches specially adapted for specific applications for supporting virtual local area networks [VLAN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03—Protocol definition or specification 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS
    • H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
    • H04L2012/5652—Cell construction, e.g. including header, packetisation, depacketisation, assembly, reassembly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/342—Signalling channels for network management communication between virtual entities, e.g. orchestrators, SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H04L41/344—Out-of-band transfers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/06—Generation of reports
    • H04L43/065—Generation of reports related to network devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)

Abstract

ESTRUTURA DE UNIDADE DE DADOS DE PACOTE (PDU) PARA SUPORTAR PROTOCOLO DE CONTROLE DE RETRANSMISSÃO DISTRIBUÍDA (DRCP). É revelado um método que suporta interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link em um dispositivo de rede. O método começa com encapsular uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, em que a DRCPDU inclui uma estrutura de unidade de dados de protocolo (PDU). A estrutura PDU inclui um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminador indicando término da estrutura PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas a um link intra-portal (IPP), um TLV de informação de portas nativas e um TLV de informação de portas vizinhas. O método continua com a transmissão do quadro encapsulando a DRCPDU a partir do dispositivo de rede para um dispositivo de rede vizinho.

Description

CAMPO
[0001] As modalidades da presente invenção se referem, em geral, à agregação de link e mais particularmente se referem a métodos e aparelho para implementar Interconexão de Rede Resiliente Distribuída (DRNI) para um Grupo de Agregação de Link (LAG).
ANTECEDENTES
[0002] Como ilustrado na figura 1A, agregação de link é uma configuração de rede e processo usados para agregar múltiplos links entre um par de nós 120, 122 na rede para habilitar transmissão de dados de usuário em cada dos links que participam em um Grupo de agregação de Link (LAG) 101 (vide, por exemplo, padrão 802.1 AX do Institute of Electrical e Electronics Engineers (IEEE)). A agregação de múltiplas conexões de rede desse modo pode aumentar a capacidade de transmissão além do que uma conexão única pode suportar, e/ou pode ser usado para fornecer resiliência em caso de uma falha de um dos links. A “Interconexão de Rede Resiliente distribuída” (DRNI) 102 (vide Cláusula 8 de IEEE P802.1AX- REV™/D1.0, intitulado “Draft Standard for Local e Metropolitan Area Networks - Link aggregation”, datado de 1 de fevereiro de 2013, que é incorporado a título de referência na íntegra) especifica extensões para agregação de link para ser capaz de usar agregação de link em uma interface de rede mesmo entre mais de dois nós, por exemplo, entre quatro nós K, L, M e O como ilustrado na figura 1B.
[0003] Como mostrado na figura 1B, um LAG é formado entre Rede 150 e Rede 152. Mais especificamente, um LAG é formado entre nós ou “portais” virtuais de LAG 112, 114. O primeiro nó ou portal virtual de LAG 112 inclui um primeiro nó (K) e um segundo nó (L). O segundo nó ou portal virtual de LAG 114 inclui um terceiro nó (M) e um quarto nó (O). Esses nós podem ser também mencionados como “Sistemas de portal”. Observe que tanto o primeiro como o segundo nós ou portais virtuais de LAG 112, 114 podem incluir um único nó ou mais de dois nós em um portal. Nós de LAG K e M são conectados como nós de pares, e Nós de LAG L e O são também conectados como nós de pares. Como utilizado nesse pedido, um “nó virtual de LAG” se refere a um portal DRNI na documentação de IEEE discutida acima (isto é, dois ou mais nós que aparecem como um único nó para seus respectivos pares). Adicionalmente, a declaração que de nó ou portal virtual 112 “inclui” dois nós K, L significa que o nó ou portal virtual 112 é emulado pelos nós K, L, isso pode ser mencionado como um “sistema emulado”. Similarmente, a declaração de que nó ou portal virtual 114 “inclui” dois nós M, O significa que o nó ou portal virtual 114 é emulado pelos nós M, O. Observe que o grupo de agregação de link 161 também é formado entre links K-M e L-O.
[0004] Múltiplos nós que participam no LAG parecem ser o mesmo nó ou portal virtual com um ID de sistema único para seu partner de par no LAG. O ID de sistema é usado para identificar cada nó (por exemplo, nó K, nó L, nó M e nó O). O ID de sistema é incluído nas Unidades de Dados de protocolo para Controle de agregação (LACPDUs) enviadas entre os nós de partner individuais do LAG (por exemplo, entre K e M ou entre L e O). O ID de sistema pode ser gerado com base em identificadores dos nós constituintes de um portal utilizando qualquer identificador individual ou qualquer combinação dos mesmos. Um ID de sistema comum e exclusivo para o nó ou portal virtual LAG correspondente pode ser consistentemente gerado. Desse modo, como mostrado na figura 1B, o nó K e nó L pertencem à mesma Rede 150 e fazem parte do mesmo Portal DRNI 112 (isto é, o mesmo nó virtual de LAG) e utilizam um ID de sistema comum de “K” para o nó virtual de LAG emulado 112. Similarmente, os nós M e O da Rede 152 são vistos como um nó ou portal virtual de LAG único 114 com um ID de sistema “M” por nós K e L.
[0005] A figura 1B também mostra uma alocação de link de DRNI de um serviço específico (vide link em negrito entre K e M na figura 1B). O link alocado é o link de trabalho entre dois nós de trabalho K e M para o serviço específico, enquanto o link não alocado pode ser aprovisionado como o link de proteção entre dois nós de proteção L e O. A alocação de serviço de uma interface pode envolver uma Rede de área local virtual (VLAN), e um identificador para o serviço pode ser um Identificador de VLAN (VID), como um VID de serviço (isto é, “S-VID”) (tipicamente identificando serviços em interfaces de Rede para rede (NNIs)) ou um VID de cliente (isto é, “CVID”) (tipicamente identificando serviços em Interfaces de usuário para rede (UNIs)). (Observe que VIDs de estrutura são indistinguíveis de S-VIDs visto que têm o mesmo Ethertype.) No exemplo da figura 1B, o serviço é alocado ao link superior (entre nós superiores K, M). O link superior é desse modo escolhido como o link “de trabalho” e o link inferior (entre nós L, O) é o link “reserva” ou link de “proteção”. A alocação de link de serviço, isto é, utilizando o mesmo link físico para transmissão de quadro tanto nas direções para frente como para trás é altamente desejável.
[0006] Embora a figura 1B mostre portais de DRNI 112 e 114 contendo, cada, dois nós, portais de DRNI não são limitados desse modo. Cada portal pode conter um a três nós. A figura 1C ilustra um DRNI em uma modalidade alternativa. Com referência à figura 1C, o grupo de agregação de link 131 contém o portal 142 (um dispositivo de rede 130) em uma extremidade, e o portal 144 (dois dispositivos de rede 132 e 134) na outra extremidade. Observe também que a figura 1C mostra uma alocação de link de DRNI de um serviço específico (vide link em negrito entre dispositivos de rede 130 e 134). O link alocado é o link de trabalho entre dois nós de trabalho (dispositivos de rede 130 e 134) para o serviço específico, enquanto o link não alocado pode ser aprovisionado como o link de proteção entre dois nós de proteção (dispositivos de rede 130 e 132). O nó de trabalho é um nó único nessa configuração, porém pode conter conjuntos diferentes de portas de agregação para conectar os links de trabalho e proteção entre os portais 142 e 144.
[0007] Provedores de serviço utilizam várias modalidades de grupos de agregação de link (como ilustrado nas figuras 1A-C e outros sistemas de DRNI alternativos) para fornecer serviços para usuários finais. O modo como fornecer serviços, particularmente através de um sistema de DRNI é um desafio.
SUMÁRIO
[0008] É revelado um método de suportar uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link em um dispositivo de rede. O dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos de rede remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intra-portal (IPL). O método começa com o encapsulamento de uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, em que a DRCPDU inclui uma estrutura de PDU, em que a estrutura de PDU inclui um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminado indicando uma extremidade da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas a IPP, um TLV de informação de portas de casa indicando um estado atual do dispositivo de rede em associação ao DRNI, e um TLV de informação de portas de vizinho indicando um estado atual do dispositivo de rede de vizinho em associação ao DRNI. O método continua com a transmissão do quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através da IPP.
[0009] Um dispositivo de rede suportando uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link. O dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos de rede remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intra-portal (IPL). O dispositivo de rede compreende portas acopladas ao link de agregação ou físico do grupo de agregação de link e um processador de rede acoplado às portas. O processador de rede executa uma função DRNI, onde a função DRNI é operativa para causar encapsulamento de uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, e adicionalmente operativa para causar transmissão do quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através da IPP. A estrutura de PDU inclui um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminador indicando uma extremidade da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas a IPP, um TLV de informação de portas de casa indicando um estado atual do dispositivo de rede em associação a DRNI, e um TLV de informação de portas de vizinho indicando um estado atual do dispositivo de rede vizinho em associação a DRNI.
[0010] Um meio de armazenamento legível em máquina não transitório é revelado, que tem instruções armazenadas no mesmo, que quando executadas por um processador, fazem com que o processador execute operações em um dispositivo de rede para suportar uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link. O dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intra-portal (IPL). As operações incluem encapsular uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, em que a DRCPDU inclui uma estrutura de PDU, em que a estrutura de PDU inclui um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV de terminador indicando uma extremidade da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas à IPP, um TLV de informação de portas de casa indicando um estado atual do dispositivo de rede em associação a DRNI, e um TLV de informação de portas de vizinho indicando um estado atual do dispositivo de rede de vizinho em associação à DRNI. As operações continuam com transmissão do quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através da IPP.
[0011] Um programa de computador que suporta uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link em um dispositivo de rede é revelado. O programa de computador compreende instruções que, quando executadas pelo menos em um processador, faz com que pelo menos um processador realize o método discutido acima.
[0012] Através das modalidades da invenção, um nó DRCP (por exemplo, um dispositivo de rede) troca informações com seu nó vizinho e desse modo estabelece e permite operações de DRCP do portal. Desse modo, modalidades da invenção fornecem um modo eficiente para o nó trocar informações com seu nó vizinho.
BREVE DESCRIÇÃO DOS DESENHOS
[0013] A invenção pode ser entendida melhor com referência a seguinte descrição e desenhos em anexo que são usados para ilustrar modalidades da invenção. Nos desenhos:
[0014] A figura 1A é um diagrama de uma modalidade de um Grupo de agregação de link entre dois dispositivos de rede.
[0015] A figura 1B é um diagrama de uma modalidade de dois portais conectando duas redes através de um Grupo de agregação de link.
[0016] A figura 1C é um diagrama de outra modalidade de dois portais conectando duas redes através de um Grupo de agregação de link.
[0017] A figura 2 é um diagrama de uma modalidade de uma Subcamada de agregação de link.
[0018] A figura 3A é um diagrama de uma modalidade de um sistema de retransmissão distribuída básico.
[0019] A figura 3B é um diagrama de uma modalidade de um sistema emulado criado a partir de dois sistemas de portal.
[0020] A figura 4 é um diagrama de uma modalidade de duas funções DR de uma retransmissão distribuída.
[0021] A figura 5 é um diagrama de estrutura de dados de DRCPDU.
[0022] A figura 6A é um diagrama de estado de protocolo de Controle de retransmissão distribuída (DRCP).
[0023] A figura 6B é um diagrama de uma modalidade de DRCP.
[0024] A figura 6C é um campo de estado de topologia de uma estrutura DRCPDU de acordo com uma modalidade da invenção.
[0025] A figura 7 é um fluxograma ilustrando relações entre máquinas de estado.
[0026] A figura 8 é um fluxograma ilustrando uma máquina de estado para uma máquina de recebimento.
[0027] A figura 9 é um fluxograma ilustrando uma máquina de estado para transmissão periódica.
[0028] A figura 10 é um fluxograma ilustrando uma máquina de sistema de portal.
[0029] A figura 11 é um fluxograma ilustrando DRNI e operação de máquina de Agregador.
[0030] A figura 12 é um fluxograma ilustrando status de máquina IPP DRNI.
[0031] A figura 13 é um diagrama de uma modalidade de um dispositivo de rede implementando DRNI.
[0032] A figura 14 é outro diagrama de estrutura de dados de DRCPDU de acordo com uma modalidade da invenção.
[0033] A figura 15 é outro fluxograma ilustrando relações entre máquinas de estado de acordo com uma modalidade da invenção.
[0034] A figura 16 é outro fluxograma ilustrando uma máquina de estado para uma máquina de recebimento de acordo com uma modalidade da invenção.
[0035] A figura 17 é outro fluxograma ilustrando uma máquina de estado para transmissão periódica de acordo com uma modalidade da invenção.
[0036] A figura 18 é outro fluxograma ilustrando uma máquina de sistema de portal de acordo com uma modalidade da invenção.
[0037] A figura 19 é um fluxograma ilustrando operações de um nó de DRCP após perder comunicação com seu nó vizinho de acordo com uma modalidade da invenção.
[0038] A figura 20 é um fluxograma ilustrando a operação de um nó DRCP em coordenação com seu nó vizinho após receber múltiplos fluxos de tráfego de acordo com uma modalidade da invenção.
[0039] A figura 21 é um diagrama de topologia de portal de acordo com uma modalidade da invenção.
[0040] A figura 22 é um diagrama de uma máquina de estado de recepção de porta de agregador de acordo com uma modalidade da invenção.
[0041] A figura 23 é um diagrama de uma máquina de estado de distribuição de gateway de acordo com uma modalidade da invenção.
[0042] A figura 24 é um diagrama de uma máquina de estado de recepção IPP N de acordo com uma modalidade da invenção.
[0043] A figura 25 é outro diagrama de estrutura de dados DRCPDU de acordo com uma modalidade da invenção.
[0044] A figura 26A ilustra uma máscara de conversação TLV para uma porta de agregação de acordo com uma modalidade da invenção.
[0045] A figura 26B ilustra um campo de estado de máscara de conversação em uma máscara de conversação TLV de uma porta de agregação de acordo com uma modalidade da invenção.
[0046] A figura 27 ilustra a operação de um nó DRCP em coordenação com seu nó vizinho após uma condição de falha de comunicação para uma modalidade da invenção.
[0047] A figura 28 ilustra uma operação de nó DRCP após uma falha de comunicação de acordo com uma modalidade da invenção.
[0048] A figura 29 é outro campo de estado de topologia de uma estrutura de DRCPDU de acordo com uma modalidade da invenção.
[0049] A figura 30 ilustra uma máquina de comcompartilhamentor IPL/rede de acordo com uma modalidade da invenção.
[0050] A figura 31 ilustra um método para comcompartilhamentomento de IPL/rede em um nó de acordo com uma modalidade da invenção.
[0051] A figura 32 ilustra um método de comunicar através de um quadro contendo estrutura de DRCPDU de acordo com uma modalidade da invenção
[0052] A figura 33 ilustra um método para sincronizar com um vizinho em um nó de um grupo de agregação de link de DRNI de acordo com uma modalidade da invenção.
[0053] A figura 34 ilustra um método para atualizar estados operacionais de um nó em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção.
[0054] A figura 35 ilustra um método para configuração de um conjunto de IDs de conversação para agregador ou gateway em um nó de DRCP em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção.
[0055] A figura 36 ilustra um método para configuração de um conjunto de IDs de conversação em um nó DRCP em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção.
DESCRIÇÃO DETALHADA
[0056] Na descrição a seguir, inúmeros detalhes específicos são expostos. Entretanto, entende-se que modalidades da invenção podem ser postas em prática sem esses detalhes específicos. Em outras instâncias, circuitos, estruturas e técnicas bem conhecidas não foram mostradas em detalhe para não obscurecer a compreensão dessa descrição.
[0057] Será reconhecido, entretanto, por uma pessoa versada na técnica que a invenção pode ser posta em prática sem tais detalhes específicos. Em outras instâncias, estruturas de controle, circuitos de nível de porta e sequências de instrução de software total não foram mostrados em detalhe para não obscurecer a invenção. Aqueles com conhecimentos comuns na técnica, com as descrições inclusas, serão capazes de implementar funcionalidade apropriada sem experimentação indevida.
[0058] Referências no relatório descritivo a “uma modalidade”, “uma modalidade de exemplo”, etc., indicam que a modalidade descrita pode incluir uma característica, estrutura ou aspecto específico, porém toda modalidade pode não necessariamente incluir a característica, estrutura ou aspecto específico. Além disso, tais frases não estão se referindo necessariamente à mesma modalidade. Além disso, quando uma característica, estrutura ou aspecto específico é descrito com relação a uma modalidade, é submetido que esteja compreendida no conhecimento de uma pessoa versada na técnica para afetar tai aspecto, estrutura ou característica com relação a outras modalidades quer ou não explicitamente descritas.
[0059] Termos
[0060] Os seguintes termos podem ser usados na descrição.
[0061] Ator: a entidade local (isto é, nó ou dispositivo de rede) em uma permuta de Protocolo de Controle de agregação de link (LACP).
[0062] Chave de agregação: Um parâmetro associado a cada Porta de agregação e com cada Agregador de um Sistema de agregação identificando aquelas Portas de agregação que podem ser agregadas juntas. Portas de agregação em um Sistema de agregação que comcompartilhamentom o mesmo valor de Chave de agregação são potencialmente capazes de agregar juntas.
[0063] Porta de agregação: Um ponto de acesso de serviço (SAP) em um Sistema de agregação que é suportado por um Agregador.
[0064] Sistema de agregação: uma entidade exclusivamente identificável compreendendo (entre outras coisas) um agrupamento arbitrário de uma ou mais portas de agregação para fins de agregação. Uma instância de um link agregado ocorre sempre entre dois sistemas de agregação. Um dispositivo físico pode compreender um sistema de agregação de sinal ou mais de um sistema de agregação.
[0065] Cliente de agregação: a entidade em camadas imediatamente acima da Subcamada de agregação de link, para a qual a Subcamada de agregação de link fornece uma instância dos Serviços de Subcamada interna (ISS).
[0066] Conversação: um conjunto de quadros transmitidos de uma estação extrema para outra, onde todos os quadros formam uma sequencia ordenada, e onde as estações extremas de comunicação exigem que a ordenação seja mantida entre o conjunto de quadros permutados.
[0067] ID de conversação: um identificador utilizando valores (por exemplo, na faixa de 0 4095) para identificar conversações.
[0068] Equipamento de terminal de dados (DTE): qualquer fonte ou destino de dados conectados à rede de área local.
[0069] Retransmissão distribuída (DR): uma entidade funcional, distribuída sobre um Portal por uma Função de DR em cada dos Sistemas de agregação compreendendo um Portal, que distribui quadros de saída a partir dos Gateways para Agregadores, e distribui quadros de entrada a partir de Agregadores para Gateways.
[0070] Interconexão de Rede resiliente distribuída (DRNI): Agregação de link expandida para incluir cada de um Portal e um Sistema de agregação, ou dois (ou mais) Portais.
[0071] Função de DR: a parte de uma Retransmissão distribuída residindo em um Sistema de portal único.
[0072] Gateway: uma conexão, tipicamente virtual (não um link físico entre sistemas) conectando uma Retransmissão distribuída a um sistema, consistindo em um Link de gateway e duas portas de Gateway.
[0073] ID de conversação de gateway: o valor de ID de conversação que é usado para selecionar quadros passando através de um Gateway. ID de conversação de gateway: O valor de ID de conversação que é usado para selecionar quadros que passam através de um Gateway.
[0074] Serviço de subcamada interna (ISS): uma versão aumentada do serviço MAC, definido em IEEE Std 802.1 AC-2012.
[0075] Link intra-portal (IPL): um link usado para conectar as Funções DR compreendendo uma Retransmissão distribuída.
[0076] Grupo de agregação de link (LAG): um grupo de links que parece para um Cliente de agregador como se fosse um único link. Um Grupo de agregação de link pode conectar dois Sistemas de agregação, um Sistema de agregação e um Portal, ou dois Portais. Uma ou mais conversações podem ser associadas a cada link que faz parte de um Grupo de agregação de link.
[0077] Partner: a entidade remota (isto é, nó ou dispositivo de rede) em uma permuta de protocolo de Controle de agregação de link.
[0078] Identificador de conversação de Porta (ID): um valor de identificador de conversação que é usado para selecionar quadros que passam através de uma Porta de agregação.
[0079] Portal: Uma extremidade de um DRNI; incluindo um ou mais Sistemas de agregação, cada com links físicos que juntos compreendem um Grupo de agregação de link. Os Sistemas de agregação de Portal cooperam para emular a presença de um único Sistema de agregação ao qual o Grupo de agregação de link inteiro é ligado.
[0080] Número do sistema de portal: um número inteiro (por exemplo, de 1 até 3, inclusive) identificando exclusivamente um sistema de Portal em seu Portal.
[0081] Algoritmo de seleção: o algoritmo usado para atribuir quadros a IDs de conversação e IDs de conversação a Portas de agregação e gateways.
[0082] ID de serviço: um valor extraído a partir de um cabeçalho de quadro (VID, I-SID, etc.) que identifica a instância de serviço com a qual aquele quadro está associado.
[0083] Instância de serviço: uma instância de serviço é um conjunto de Pontos de acesso de serviço (SAPs) de modo que um primitivo Data.Request apresentado a um SAP possa resultar em um primitivo Data.Indication ocorrendo em um ou mais dos outros SAPs naquele conjunto. No contexto de operadores e clientes, um cliente específico tem acesso a todos os SAPs de tal conjunto pelo operador.
[0084] Valor/comprimento/tipo (TLV): uma codificação de comprimento variável, curto de um elemento de informação consistindo em campos de tipo sequencial, comprimento e valor onde o campo de tipo identifica o tipo de informação, o campo de comprimento indica o comprimento do campo de informação em octetos, e o campo de valor contém a própria informação. O valor de tipo é localmente definido e necessita ser exclusivo no protocolo definido nesse padrão.
[0085] Na descrição e reivindicações a seguir, os termos “acoplado” e “conectado” juntamente com seus derivados, podem ser usados. Deve ser entendido que esses termos não são destinados como sinônimos entre si. “Acoplado” é usado para indicar que dois ou mais elementos, que podem estar em contato físico ou elétrico entre si, ou não, cooperam ou interagem entre si. “Conectado” é usado para indicar o estabelecimento de comunicação entre dois ou mais elementos que são acoplados entre si. Um “Conjunto”, como utilizado aqui se refere a qualquer número inteiro positivo de itens incluindo um item.
[0086] Um dispositivo eletrônico (por exemplo, uma estação final, um dispositivo de rede) armazena e transmite (internamente e/ou com outros dispositivos eletrônicos através de uma rede) código (composto de instruções de software, por exemplo, um programa de computador compreendendo instruções) e dados utilizando meio legível em máquina, como meio legível em máquina não transitório (por exemplo, meio de armazenamento legível em máquina como discos magnéticos; discos ópticos; memória somente de leitura; dispositivos de memória flash; memória de mudança de fase) e meio de transmissão legível em máquina transitório (por exemplo, elétrica, óptica, acústica ou outra forma de sinais programados - como ondas portadoras, sinais infravermelhos). Além disso, tais dispositivos eletrônicos incluem hardware, como um conjunto de um ou mais processadores acoplados a um ou mais outros componentes - por exemplo, um ou mais meio de armazenamento legível em máquina não transitório (para armazenar código e/ou dados) e conexões de rede (para transmitir código e/ou dados usando sinais de programação), bem como dispositivos de entrada/saída de usuário (por exemplo, um teclado, uma tela sensível a toque, e/ou um display) em alguns casos. O acoplamento do conjunto de processadores e outros componentes é tipicamente através de uma ou mais interconexões nos dispositivos eletrônicos (por exemplo, barramentos e possivelmente pontes). Desse modo, um meio legível em máquina não transitório de um dado dispositivo eletrônico tipicamente armazena instruções para execução em um ou mais processadores daquele dispositivo eletrônico. Uma ou mais partes de uma modalidade da invenção podem ser implementadas utilizando combinações diferentes de software, firmware e/ou hardware.
[0087] Como utilizado aqui, um dispositivo de rede (por exemplo, um roteador, comutador, ponte) é uma peça de equipamento de ligação em rede, incluindo hardware e software, que comunicativamente interconecta outro equipamento na rede (por exemplo, outros dispositivos de rede, estações finais). Alguns dispositivos de rede são “dispositivos de rede múltiplos serviços” que fornecem suporte para múltiplas funções de ligação em rede (por exemplo, roteamento, junção, comutação, agregação de Camada 2, controle de borda de sessão, Qualidade de serviço, e/ou gerenciamento de assinante) e/ou fornecer suporte para múltiplos serviços de aplicativo (por exemplo, dados, voz e vídeo). Estações finais de assinante (por exemplo, servidores, estações de trabalho, laptops, netbooks, palm tops, telefones celulares, smartphones, fones de multimídia, fones de Protocolo de Voz através da internet (VOIP), equipamento de usuário, terminais, tocadores de mídia portáteis, unidades de GPS, sistemas de jogos, conversores de sinais de frequência) serviços/conteúdo de acesso fornecidos através da Internet e/ou serviços/conteúdo fornecido em redes privadas virtuais (VPNs) sobreposto na (por exemplo, tunelado através) da Internet. O conteúdo e/ou serviços são tipicamente fornecidos por uma ou mais estações finais (por exemplo, estações finais de servidor) que pertencem a um provedor de conteúdo ou serviço ou estações finais participando em um serviço de par-para-par (P2P), e podem incluir, por exemplo, webpages públicas (por exemplo, conteúdo livre, fronts de armazenagem, serviços de busca), webpages privadas (por exemplo, webpages acessadas com senha/nome de usuário que fornecem serviços de e-mail), e/ou redes jurídicas através de VPNs. Tipicamente, estações finais de assinante são acopladas (por exemplo, através de equipamento de local de cliente acoplado a uma rede de acesso (cabeada ou sem fio)) a dispositivos de rede de borda, que são acoplados (por exemplo, através de um ou mais dispositivos de rede de núcleo) a outros dispositivos de rede de borda, que são acoplados a outras estações finais (por exemplo, estações finais de servidor).
[0088] Dispositivos de rede são comumente separados em um plano de controle e um plano de dados (às vezes mencionado como um plano de envio ou um plano de mídia). No caso do dispositivo de rede ser um roteador (ou estar implementando funcionalidade de roteamento), o plano de controle tipicamente determina como dados (por exemplo, pacotes) devem ser roteados (por exemplo, o próximo hop para os dados e a porta de saída para aqueles dados), e o plano de dados está encarregado de enviar aqueles dados. Por exemplo, o plano de controle tipicamente inclui um ou mais protocolos de roteamento (por exemplo, um protocolo de gateway exterior como Protocolo de Gateway de borda (BGP) (RFC 4271), Protocolo(s) de Gateway interior (IGP) (por exemplo, Percurso mais curto aberto primeiro (OSPF) (RFC 2328 e 5340), Sistema intermediário para sistema intermediário (IS-IS) (RFC 1142), Protocolo de Informação de roteamento (RIP) (versão 1 RFC 1058, versão 2 RFC 2453, e RFC da próxima geração 2080)), Protocolo de distribuição de rótulo (LDP) (RFC 5036), Protocolo de reserva de recurso (RSVP) (RFC 2205, 2210, 2211, 2212, bem como Engenharia de tráfego-RSVP (TE): Extensões para RSVP para Túneis LSP RFC 3209, Sinalização de Comutação de Rótulo de multiprotocolos generalizado (GMPLS) RSVP-TE RFC 3473, RFC 3936, 4495 e 4558)) que comunicam com outros dispositivos de rede para permutar rotas e selecionar aquelas rotas com base em uma ou mais métricas de roteamento. Além disso, o plano de controle também inclui tipicamente protocolos de controle de camada 2 ISO como Protocolo de árvore de abrangência rápida (RSTP), Protocolo de árvore de abrangência múltipla (MSTP) e SPB (Junção de percurso mais curto), que foram padronizados por vários órgãos padrão (por exemplo, SPB foi definido em IEEE Std. 802 1 aq-2012).
[0089] Rotas e adjacências são armazenadas em uma ou mais estruturas de roteamento (por exemplo, Base de informação de roteamento (RIB), Base de informação de rótulo (LIB), uma ou mais estruturas de adjacência) no plano de controle. O plano de controle programa o plano de dados com informações (por exemplo, informações de rota e adjacência) com base na(s) estrutura(s) de roteamento. Por exemplo, o plano de controle programa as informações de rota e adjacência em uma ou mais estruturas de envio (por exemplo, Base de Informação de envio (FIB), Base de informação de envio de rótulo (LFIB) e uma ou mais estruturas de adjacência) no plano de dados. O plano de dados utiliza essas estruturas de envio e adjacência ao envio de tráfego.
[0090] Cada dos protocolos de roteamento baixa entradas de rota para uma RIB principal com base em certas métricas de rota (as métricas podem ser diferentes para protocolos de roteamento diferentes). Cada dos protocolos de roteamento pode armazenar as entradas de rota, incluindo as entradas de rota que não são baixadas para a RIB principal, em uma RIB local (por exemplo, uma RIB local OSPF). Um módulo de RIB que gerencia a RIB principal seleciona rotas a partir das rotas baixadas pelos protocolos de roteamento (com base em um conjunto de métricas) e baixa essas rotas selecionadas (às vezes mencionadas como entradas de rota ativas) para o plano de dados. O módulo de RIB também pode fazer com que rotas sejam redistribuídas entre protocolos de roteamento. Para envio de camada 2, o dispositivo de rede pode armazenar uma ou mais tabelas de junção que são usadas para enviar dados com base nas informações de camada 2 nesses dados.
[0091] Tipicamente, um dispositivo de rede inclui um conjunto de um ou mais cartões de linha, um conjunto de um ou mais cartões de controle, e opcionalmente um conjunto de um ou mais cartões de serviço (às vezes mencionado como cartões de recurso). Esses cartões são acoplados juntos através de um ou mais mecanismos de interconexão (por exemplo, uma primeira malha total acoplando os cartões de linha e uma segunda malha total acoplando todos os cartões). O conjunto de cartões de linha compõe o plano de dados, enquanto o conjunto de cartões de controle fornece o plano de controle e permuta pacotes com dispositivos de rede externos através dos cartões de linha. O conjunto de cartões de serviço pode fornecer processamento especializado (por exemplo, serviços de Camada 4 a camada 7 (por exemplo, firewall, Segurança de protocolo de Internet (IPsec) (RFC 4301 e 4309), Sistema de detecção de intrusão (IDS), par-para-par (P2P), Controlador de Borda de sessão de voz através de IP (VoIP), Gateways sem fio móveis (Nó de suporte (GGSN) de Serviço de Rádio de Pacote geral de Gateway (GPRS), Núcleo de pacote desenvolvido (EPC Gateway)). Como exemplo, um cartão de serviço pode ser usado para terminar túneis IPsec e executar os algoritmos de autenticação e criptografia inerentes.
[0092] Como utilizado aqui, um nó envia pacotes IP com base em algumas das informações de cabeçalho de IP no pacote IP; onde informações de cabeçalho de IP incluem endereço de IP de fonte, endereço de IP de destino, porta de fonte, porta de destino (onde “porta de fonte” e “porta de destino” se refere aqui a portas de protocolo, ao contrário de portas físicas de um dispositivo de rede), protocolo de transporte (por exemplo, protocolo de datagrama de usuário (UDP) (RFC 768, 2460, 2675, 4113, e 5405), Protocolo de Controle de transmissão (TCP) (RFC 793 e 1180), e valores de serviços diferenciados (DSCP) (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290, e 3317). Nós são implementados em dispositivos de rede. Um nó físico é implementado diretamente no dispositivo de rede, ao passo que um nó virtual é um software, e possivelmente hardware, abstração implementada no dispositivo de rede. Desse modo, múltiplos nós virtuais podem ser implementados em um único dispositivo de rede.
[0093] Uma interface de rede pode ser física ou virtual; e um endereço de interface é um endereço IP atribuído a uma interface de rede, seja uma interface de rede física ou interface de rede virtual. Uma interface de rede física é hardware em um dispositivo de rede através do qual uma conexão de rede é feita (Por exemplo, sem fio, através de um controlador de interface de rede sem fio (WNIC) ou através de plugar um cabo em uma porta conectada a um controlador de interface de rede (NIC)). Tipicamente, um dispositivo de rede tem múltiplas interfaces de rede física. Uma interface de rede virtual pode ser associada a uma interface de rede física, com outra interface virtual, ou ser independente (por exemplo, uma interface de loopback, uma interface de protocolo de ponto a ponto). Uma interface de rede (física ou virtual) pode ser numerada (uma interface de rede com um endereço IP) ou não numerada (uma interface de rede sem um endereço de IP). Uma interface de loopback (e seu endereço de loopback) é um tipo específico de interface de rede virtual (e endereço IP) de um nó (físico ou virtual) frequentemente usado para fins de gerenciamento; onde tal endereço IP é mencionado como o endereço de loopback nodal. O(s) endereço(s) IP atribuído(s) à(s) interface(s) de rede de um dispositivo de rede, é(são) mencionado(s) como endereços IP daquele dispositivo de rede; em um nível mais granular, o(s) endereço(s) IP atribuído(s) à(s) interface(s) de rede atribuída(s) a um nó implementado em um dispositivo de rede, pode(m) ser mencionado(s) como endereços IP daquele nó.
[0094] Alguns dispositivos de rede fornecem suporte para implementar VPNs (Redes privadas virtuais) (por exemplo, VPNs de camada 2 e/ou VPNs de camada 3). Por exemplo, o dispositivo de rede onde a rede de um provedor e a rede de um cliente são aplicadas são respectivamente mencionadas como PEs (Borda de Provedor) e CEs (Borda de Cliente). Em uma VPN de camada 2, envio é tipicamente realizada na(s) CE(s) em qualquer extremidade do VPN e tráfego é enviado através da rede (por exemplo, através de uma ou mais PEs acopladas por outros dispositivos de rede). Circuitos de camada 2 são configurados entre as CEs e PEs (por exemplo, uma porta Ethernet, um circuito virtual permanente ATM (PVC), um PVC de retransmissão de quadro). Em uma VPN de camada 3, roteamento é tipicamente realizado pelas PEs. Como exemplo, um dispositivo de rede de borda que suporta múltiplos contextos pode ser implantando como uma PE; e um contexto pode ser configurado com um protocolo de VPN, e desse modo esse contexto é mencionado como um contexto de VPN.
[0095] Alguns dispositivos de rede fornecem suporte para VPLS (Serviço LAN Privado virtual) (RFC 4761 e 4762). Por exemplo, em uma rede VPLS, serviços/conteúdo de acesso a estações extremas de assinante fornecidos através da rede VPLS por acoplar a CEs, que são acoplados através de PRs acoplados por outros dispositivos de rede. Redes VPLS podem ser usadas para implementar aplicativos de rede triple play (por exemplo, aplicativos de dados (por exemplo, acesso a Internet em alta velocidade), aplicativos de vídeo (por exemplo, serviço de televisão como IPTV (Televisão de Protocolo de Internet)), VoD (serviço de (Vídeo em demanda)) e aplicativos de voz (por exemplo, serviço de VoIP (Protocolo de Voz através da internet)), serviços de VPN, etc. VPLS é um tipo de VPN de camada 2 que pode ser usado para conectividade de multipontos. Redes VPLS também permitem que estações externas de assinantes que são aplicadas a CEs em locais geográficos separados comuniquem entre si através de uma Rede de área remota (WAN) como se fossem diretamente fixados entre si em uma Rede de área local (LAN) (mencionada como uma LAN emulada).
[0096] Em redes VPLS, cada CE tipicamente fixa, possivelmente através de uma rede de acesso (cabeada e/ou sem fio) a um módulo de ponte de uma PE através de um circuito de fixação (por exemplo, um link virtual ou conexão entre a CE e a PE). O módulo de ponte da PE se fixa em uma LAN emulada através de uma interface de LAN emulada. Cada módulo de ponte atua como uma “Instância de comutação virtual” (VSI) por manter uma tabela de envio que mapeia endereços de MAC para pseudowires e circuitos de fixação. PEs enviam quadros (recebidos de CEs) para destinos (por exemplo, outras CEs, outras PEs) com base no campo de endereço de destino MAC incluído naqueles quadros.
[0097] Subcamada de agregação de link
[0098] A figura 2 é um diagrama de uma modalidade de Subcamada de agregação de link 200. O cliente de agregador 202 comunica com um conjunto de portas de agregação 292, 294, 296 através do agregador 250. Em uma modalidade, o agregador 250 apresenta uma interface de Serviço de subcamada interna (ISS) de IEEE Std 802.1Q padrão para o cliente de agregador 202. O agregador 250 se liga a uma ou mais portas de agregação incluindo Portas de agregação 292, 294, 296. O agregador 250 distribui transmissões de quadro a partir do cliente de agregador 202 para Portas de agregação 292, 294, 296, e para coletar quadros recebidos a partir de Portas de agregação 292, 294, 296 e passa as mesmas para o cliente de agregador 202, de forma transparente.
[0099] A ligação de portas de agregação 292, 294, 296 ao agregador 250 é gerenciada por controle de agregação de link 210, que é responsável por determinar quais links podem ser agregados, agregar os mesmos, ligar portas de agregação a um agregador apropriado, e monitorar condições para determinar quando uma alteração em agregação é necessária. Tal determinação e ligação podem ser sob controle manual através de manipulação direta das variáveis de estado de agregação de link (por exemplo, através de chaves de agregação) por um gerenciador de rede. Além disso, determinação automática, configuração, ligação e monitoramento podem ocorrer através do uso de Protocolo de Controle de agregação de link (LACP 214. LACP 214 usa permutas de pares através dos links para determinar, em uma base contínua, a capacidade de agregação dos vários links, e continuamente fornece o nível máximo de capacidade de agregação obtenível entre um dado par de Sistemas de agregação.
[0100] Um Sistema de agregação pode conter múltiplos agregadores, servindo a múltiplos clientes de agregador. Uma dada porta de agregação se ligará (no máximo) a um único agregador em qualquer momento. Um cliente de agregador é servido por um único agregador de cada vez.
[0101] Ordenação de quadro é mantida para certas sequências de permutas de quadro entre clientes de agregador (conhecidos como conversações). O distribuidor de quadro 234 assegura que todos os quadros de uma dada conversação são passados para uma única porta de agregação. Para uma dada conversação, o coletor de quadros 224 é necessário passar quadros para o cliente agregador 202 na ordem que os mesmos são recebidos da porta de agregação. O coletor de quadro 224 é de outro modo livre para selecionar quadros recebidos das portas de agregação 292, 294, 296 em qualquer ordem. Uma vez que não há meio para que os quadros sejam ordenados erroneamente em um único link, isso assegura que ordenação de quadro seja mantida para qualquer conversação. As conversações podem ser movidas entre portas de agregação em um Grupo de agregação de link, tanto para equilíbrio de carga como para manter disponibilidade no evento de falhas de link.
[0102] Portas de agregação 292, 294, 296 são individualmente atribuídas endereços de controle de acesso de meio (MAC), que são exclusivos através do Grupo de Agregação de link e a qualquer rede de área local unido (LAN) (por exemplo, uma em conformidade com IEEE 802.1Q LAN unido) a qual o Grupo de Agregação de Link é conectado. Esses endereços de MAC são usados como os endereços de fonte para permutas de quadro que são iniciadas por entidades na própria Subcamada de agregação de link 270 (isto é, LACP 214 e permutas de protocolo de Marcador).
[0103] O agregador 250 (e outros agregadores se implantados) é atribuído um endereço MAC, exclusivo através do Grupo de Agregação de link e a LAN unida (por exemplo, um em conformidade com IEEE 802.1Q LAN unida) a qual o Grupo de agregação de link é conectado. Esse endereço é usado como o endereço MAC do Grupo de agregação de Link a partir da perspectiva do cliente de agregador 202, tanto como um endereço de fonte para quadros transmitidos como o endereço de destino para quadros recebidos. O endereço MAC de agregador 250 pode ser um dos endereços MAC de uma porta de agregação no Grupo de agregação de link associado.
[0104] Interconexão de rede resiliente distribuída (DRNI)
[0105] Agregação de link cria um Grupo de agregação de link que é uma coleção de um ou mais links físicos que parecem, em camadas mais elevadas, como sendo um único link lógico. O Grupo de agregação de link tem duas extremidades, cada terminando em um Sistema de agregação. DRNI expande o conceito de agregação de link de modo que, em qualquer uma ou ambas as extremidades de um grupo de agregação de link, o único Sistema de agregação é substituído por um Portal, cada composto de um ou mais Sistemas de agregação.
[0106] DRNI é criada utilizando uma retransmissão distribuída para interconectar dois ou mais sistemas, cada rodando agregação de link, para criar um portal. Cada Sistema de agregação no Portal (isto é, cada Sistema de Portal) roda agregação de link com um único agregador. A retransmissão distribuída habilita os Sistemas de portal a terminarem conjuntamente um Grupo de agregação de link. Para todos os outros Sistemas de Agregação aos quais o Portal é conectado, o Grupo de agregação de link parece terminar em um Sistema de agregação emulado criado pelos Sistemas de portal.
[0107] A intenção é criar DRNI por introduzir uma Retransmissão distribuída para interconectar dois ou três sistemas, cada rodando Agregação de link, para criar um Portal. Cada sistema no Portal (isto é, cada Sistema de portal) roda Agregação de link com um único Agregador. A retransmissão distribuída é destinada a habilitar os Sistemas de Portal a terminarem conjuntamente um Grupo de agregação de link. Para todos os outros Sistemas aos quais o Portal é conectado, o Grupo de agregação de Link parecerá terminar em um Sistema emulado separado criado pelos Sistemas de portal. O IEEE 802.1AX-VER/D1.0 acima mencionado não fornece informação suficiente com relação a como a Retransmissão distribuída deve funcionar.
[0108] Retransmissões distribuídas
[0109] DRNI é criada utilizando uma Retransmissão distribuída para interconectar dois ou três Sistemas, cada rodando Agregação de link, para criar um Portal. Cada Sistema no Portal (isto é, cada Sistema de Portal) roda Agregação de link com um único Agregador. A Retransmissão distribuída habilita os sistemas de Portal a terminarem conjuntamente um Grupo de Agregação de Link. Para todos os outros Sistemas aos quais o portal é conectado, o Grupo de Agregação de link parece terminar em um Sistema emulado separado criado pelos Sistemas de Portal.
[0110] A figura 3A ilustra um sistema de retransmissão distribuída básica como o ponto de partida para descrever a Retransmissão distribuída. Os links de rede mostrados na figura 3A, e discutidos aqui correspondem a links físicos ou lógicos que são visíveis a e estão sob o controle de protocolos de rede. Nesse diagrama, os Sistemas A e B são individualmente caracterizados por executar uma “Função 1,” que é um tipo de função de retransmissão de pacote, por exemplo, um roteador ou uma ponte. “Função 1” pode ser também uma operação de servidor de arquivo, em cujo caso as duas “portas” externas em cada Sistema provavelmente não estariam presentes. Cada sistema roda uma única instância de uma Subcamada de Agregação de link. Em uma modalidade, é desejado que as portas sombreadas sejam associadas em um Portal com uma Retransmissão distribuída.
[0111] A figura 3A é um exemplo, não o caso geral. Em geral, a Retransmissão distribuída suporta: a) Os protocolos necessários e procedimentos apenas para as configurações listadas abaixo são fornecidos por esse pedido. b) Funções de Agregação de link, cada subsumindo um ou mais MACs. c) Conexões entre os Sistemas de Portal da Retransmissão distribuída.
[0112] A finalidade de introduzir a camada funcional de Retransmissão distribuída nesse exemplo é fazer com que esses dois Sistemas de Portal pareçam, para os sistemas conectados a eles, estar na configuração ilustrada na figura 3B. Parece existir um terceiro Sistema C emulado, conectado aos Sistemas de Portal originais por um link que foi inserido entre a Função 1 e Agregação de Link. Isto é, os Sistemas de Portal A e B conspiram para se comportar, até onde quaisquer outros sistemas aos quais são conectados possam discernir, como se o Sistema emulado C efetivamente existisse, como mostrado na figura 3B. Embora a figura 3B seja um exemplo, ilustra os princípios da Retransmissão distribuída: d) A Retransmissão distribuída no Sistema emulado C é uma retransmissão de (N+1)-porta para N Sistemas de portal, com N Portas de gateway conectadas aos Sistemas de Portal, e uma única Subcamada de Agregação de link Emulado associada aos Sistemas de Portal originais. e) As Portas de agregação (também mencionadas aqui como MACs) foram movidas para o Sistema emulado, e desse modo parece, para todos os outros Sistemas, estarem igualmente distantes dos Sistemas de Portal reais compreendendo a Retransmissão distribuída.
[0113] As construções efetivas usadas pelos dois Sistemas de Portal para criar o Sistema emulado C são ilustradas na figura 4. A figura 4 mostra as duas Funções DR da Retransmissão Distribuída, uma Função DR em cada Sistema A e B. Esse exemplo ilustra os princípios restantes da Retransmissão distribuída: f) Em cada Sistema A e B, as portas que devem ser associadas ao Sistema C são movidas para uma posição abaixo da Subcamada de agregação de link de função DR. g) Um link virtual e seus MACs virtuais de terminação, chamado um “Gateway”, é construído para conectar cada Função de DR a sua Função 1. h) Entre cada par de Funções DR no Portal é construído um Link intraportal (IPL), terminado em cada extremidade por uma Porta intra-portal (IPP). (Esse pode existir em muitas formas; vide a discussão abaixo). i) Há um “algoritmo de gateway” que decide através de qual Gateway um quadro pode passar para dentro ou para fora da Retransmissão distribuída emulada. j) Similarmente, um “algoritmo de Porta” decide através de quais Portas de agregação do Sistema de portal um quadro pode passar para dentro ou para fora da Retransmissão distribuída emulada. k) Como mencionado acima, pode haver três Sistemas participando para criar um portal e um Sistema emulado C. Nesse caso, a Retransmissão distribuída no Sistema emulado C tem uma Porta de gateway adicional, um para cada Sistema de portal, e IPLs para interconectar as Funções DR. l) As Funções DR, como especificado abaixo, trabalham juntas para mover quadros entre os Gateways, o IPL, e as subcamadas de Agregação de link.
[0114] Operação e procedimentos de retransmissão distribuída
[0115] A função DR em cada Sistema de portal (figura 4) pretende ter (sujeito a falhas operacionais) três tipos de portas: A) Portas intra-portais, no máximo uma (talvez complexo em alguma modalidade) Porta IPL conectada a cada do(s) outro(s) Sistema(s) de Portal que pertence(m) ao mesmo portal; B) Exatamente uma Porta de Gateway virtual com um Link virtual para uma Portal de Gateway virtual no Sistema de Portal no qual a função DR reside; e C) Exatamente uma Porta de agregador (a porta que é suportada pela instância ISS identificada pelo prefixo Agg) para a subcamada de Agregação de link com qualquer número de Portas de agregação, destinadas a conectar a outros sistemas em um modo como aqueles outros Sistemas acreditam que estão conectados a um único Sistema emulado.
[0116] Na figura 3B, os Links intra-portais e Portas IPL não são visíveis, e a Retransmissão distribuída do Sistema de agregação emulado C tem um Gateway para cada dos sistemas em seu Portal.
[0117] A finalidade da Retransmissão distribuída emulada é passar todo quadro recebido a partir de uma Porta de agregação (“quadro para cima”) para um Gateway, ou descartar o mesmo, e todo quadro recebido a partir de um Gateway (“quadro para baixo”) para uma Porta de agregador, ou descartar o mesmo. As Funções de DR compreendendo a Retransmissão distribuída às vezes devem enviar um quadro através de um ou dois Links intra-portais para obter o mesmo para o Gateway correto ou Porta de agregador. Uma Função DR faz a escolha de se deve descartar ou passar um quadro para seu Gateway, Porta de agregador, ou um de seus IPLs por atribuir cada quadro a dois IDs de conversação, um ID de conversação de gateway e um ID de conversação de Porta, e configurar os Gateways, Portas de agregação, e IPLs em termos desses IDs de conversação.
[0118] O “algoritmo de Gateway” mencionado consiste em duas partes, um algoritmo para atribuir qualquer quadro dado para um ID de conversação de gateway, e uma atribuição de IDs de conversação de gateway para Gateways (por exemplo, utilizando Drni_Gateway_Conversation).
[0119] Se o Sistema de portal for uma Ponte VLAN realizando aprendizagem, o mapeamento de um quadro para um ID de conversação de Gateway será baseado em seu ID VLAN, de outro modo o processo de aprendizagem quebra através de toda rede. Para Implementações de DRNI nesses casos pode haver um mapa de um para um de ID VLAN para ID de conversação.
[0120] Similarmente, o “algoritmo de Porta” do item j na seção “Retransmissões distribuídas” acima consiste em um algoritmo para atribuir qualquer quadro dado para um ID de conversação de Porta, e uma atribuição de IDs de conversação de porta para Portas de agregação (utilizando um AggConversationAdminPort[], por exemplo).
[0121] Meios são especificados abaixo para assegurar que todas as Funções DR em um dado Portal usem o mesmo algoritmo de Gateway e o mesmo algoritmo de Porta para atribuir quadros a seus IDs de conversação respectivos, e assegurar que qualquer ID de conversação de gateway dado seja atribuído a no máximo um dos Gateways, e qualquer ID de conversação de Porta dado a no máximo uma das Portas de agregação de um portal, em qualquer momento dado.
[0122] É permitido, porém não exigido, que o algoritmo de Gateway e o algoritmo de Porta utilizem o mesmo meio para atribuir um quadro a um ID de conversação, de modo que o ID de conversação de Gateway seja igual ao ID de conversação de Porta.
[0123] O algoritmo de Porta é sempre aplicado a um quadro à medida que entra na função DR a partir do Gateway para determinar se deve enviar o mesmo para a Porta de Agregador ou para uma IPP específica. O algoritmo de gateway é sempre aplicado a um quadro à medida que entra a partir da porta de agregador para determinar se deve enviar o mesmo para o Gateway ou para uma IPP específica. Os dois algoritmos têm de ser aplicados, e seus resultados comparados, para enviar um quadro que entra uma função DR a partir de um IPL, como mostrado na tabela 1. Tabela 1. Função DR: envio de quadro recebido do Link intra-portal n
Figure img0001
A) [1] “Qualquer” significa que a saída a partir do algoritmo de Porta não é usada; o algoritmo de Gateway determina para qual porta o quadro é enviado. B) [2] Funções DR em Sistemas de portal diferentes têm configurações incompatíveis, ou há um defeito. Descartar quadro para evitar looping. C) a Tabela 1 assume uma de três configurações: • Dois Sistemas de portal conectados por um único IPL; • Três sistemas de portal conectados linearmente por dois IPLs; ou • Três sistemas de portal conectados circularmente por três IPLs. D) O algoritmo de Gateway é executado nas duas direções através do Gateway; isto é um quadro entrando na Função DR a partir de um Gateway é descartado se o algoritmo de Gateway, aplicado àquele quadro, não enviasse o mesmo de volta para o Gateway. Isso é necessário para evitar que quadros recebidos de um Gateway sejam enviados através de um IPL e passados de volta para dentro da rede através de outro Gateway. E) Se o algoritmo de Gateway indicar que o quadro deve passar através do Gateway, deve ser um quadro para cima, porque um quadro para baixo não pode entrar no Portal a partir de qualquer outra Função DR, pelo item D) acima. F) De outro modo, se o algoritmo de Gateway indicar que o quadro veio do IPL ao qual seria enviado, então é um quadro para baixo, e assim é enviado utilizando o algoritmo de Porta. (Se o algoritmo de porta enviasse o mesmo de volta na porta na qual chegou, há algum tipo de defeito ou configuração errônea, e o quadro é descartado.) G) De outro modo, o algoritmo de Gateway indica que o quadro não veio do IPL ao qual seria enviado, assim deve ser um quadro para cima, e o quadro é dirigido de acordo com o algoritmo de Gateway.
[0124] OBSERVAÇÃO - O algoritmo de Porta e Protocolo de Controle de retransmissão distribuída da Retransmissão distribuída juntos determina o mapeamento de IDs de conversação de Porta para Portas de agregação individuais, e as variáveis em seu controle determinam a operação do Distribuidor de quadro e Coletor de quadro. Entretanto, isso não altera o percurso de dados e controle como descrito, uma vez que a Retransmissão distribuída passa todos os dados para ou a partir das Portas de agregação através do Agregador.
[0125] A aplicação dos algoritmos de Gateway e Porta em quadros entrando uma Função DR a partir de um Gateway e uma Porta de agregador, como mostrado na Tabela 2 e Tabela 3 respectivamente. T abela 2. Função DR: envio de quadro recebido de meu Gateway
Figure img0002
Tabela 3. Função DR: envio de quadro recebido a partir de uma de minhas Portas de agregação
Figure img0003
[0126] Topologia de portal
[0127] A topologia mais geral de Portal é três Sistemas de Portal conectados em um anel por três Links intra-portais como ilustrado na figura 21. Outras topologias suportadas de acordo com outras modalidades da invenção são subconjuntos disso, incluindo: • Três sistemas de portal conectados em uma cadeia por dois IPLs, • Dois sistemas de Portal conectados por um único IPL, • Um Sistema de portal sem IPLs ativos.
[0128] Os termos Casa, vizinho e Outro vizinho são usados para identificar os Sistemas de Portal a partir do ponto de vista de uma dada Porta intra-portal. A Casa é o sistema contendo o IPP. O vizinho é o sistema conectado ao IPP. O Outro vizinho é o sistema conectado ao outro IPP (se presente) no sistema de Casa. Com referência à figura 21, usando IPP B1 para um exemplo, seu sistema de casa é B, seu vizinho imediato é A (porque está conectado a IPP B1 através de IPL AB), e seu outro vizinho é C (porque está conectado a IPP B2 através de IPL BC). Observe que o Outro vizinho de IPP A2 é também C (porque está conectado a IPP A1 através de IPL AC), assim comparando os IDs dos Outros vizinhos de IPs B1 e A2 verifica que não há mais de três sistemas em um anel ou cadeia.
[0129] Link intra-portal
[0130] Um Link intra-portal (IPL) é um link de ponto a ponto lógico único entre Funções de DR em dois Sistemas diferentes. Uma Função DR tem no máximo um IPL para cada dos outros Sistemas compreendendo uma extremidade de um Grupo de agregação de Link DRNI. IPLs e links de rede podem comcompartilhamentor um link físico ou agregação de link (agregação de link sendo um agregado de um conjunto de links).
[0131] Um IPL pode ser físico (por exemplo, uma LAN Ethernet 802.3) ou lógico (por exemplo, uma instância de serviço de estrutura 802.1Q ou um pseudowire IETF). Um Link intra-portal pode comcompartilhamentor um link físico com outros Links intra-portais ou links de rede. Um Link intra-portal pode ser um Grupo de agregação de link, e desse modo consiste em um número de links físicos.
[0132] Será frequentemente o caso em redes implantadas que dois Sistemas serão configurados tanto com um link de rede normal conectando os mesmos, como um IPL, como ilustrado na figura 4. Reduziria a utilidade de DRNI se todo Portal exigisse seu próprio IPL físico separado, especialmente se um par de Sistemas for configurado para suportar múltiplos Portais. DRNI suporta um número de métodos pelos quais os Sistemas podem distinguir quadros em um link de rede a partir de quadros em um IPL específico: • Físico. Um link físico separado pode ser usado para suportar qualquer link de rede específico ou IPL. • Agregado. Uma Porta de Agregador separada pode ser usada para suportar um IPL. • Comcompartilhamentodo em tempo. Um link de rede e um ou mais IPLs podem usar o mesmo link físico (ou Porta de agregador) porém em tempos diferentes. Isso requer que os Sistemas desabilitem o uso do link de rede quando o IPL é exigido para conectividade, ou então que o uso dos Links de agregação e a seleção de Gateways seja ajustado para eliminar a necessidade de usar um IPL quando o link de rede é exigido. Essa técnica é descrita aqui. • Comcompartilhamentodo em etiqueta. Um link de rede e um ou mais IPLs podem usar o mesmo link físico (ou porta de agregador), utilizando IDs de serviço diferentes. Comcompartilhamentomento de etiqueta é descrito aqui. • Lógica. Os quadros no link de rede e o(s) IPL(s) podem ser encapsulados, como descrito aqui.
[0133] Um Sistema implementando a DRNI pode suportar o uso de links físicos separados para IPLs e links de rede, e pode suportar quaisquer dos outros métodos.
[0134] Em cada extremidade do link físico comcompartilhamentodo ou Porta de agregador, há uma porta virtual para cada função (link de rede ou um IPL específico) para o qual o link ou Porta de agregador é usado. Quaisquer dos métodos acima podem ser usados simultaneamente entre dois Sistemas, por escolha administrativa, desde que as duas extremidades de qualquer link físico dado ou Porta de agregador utilizem o mesmo método.
[0135] Comcompartilhamentomento de IPL/rede por tempo
[0136] O objetivo de comcompartilhamentomento de IPL/rede por tempo é suportar DRNI sem exigir links físicos separados para uma conexão de rede e IPL, e sem exigir qualquer modificação de quadro. Ao comcompartilhamentor um link, é necessário ser capaz de determinar para cada quadro se aquele quadro é destinado a estar atravessando a conexão de rede ou o IPL. Essa determinação pode ser feita sem modificar o quadro (por exemplo, sem traduzir o VLAN ID ou adicionar uma etiqueta ou encapsulamento) se a qualquer momento dado o link físico for conhecido como sendo somente usado como um link de rede ou somente suado como um IPL. O fato de se o link é usado como um link de rede ou um IPL em qualquer momento dado é estabelecido pelo protocolo de controle usado para estabelecer uma topologia ativa isenta de loop, totalmente conectada para cada VLAN na rede.
[0137] Se o link não for incluído na topologia ativa de uma VLAN (por exemplo, foi bloqueada pela operação do protocolo de controle de rede), é disponível para ser usado como o IPL. Nesse caso o link é usado pela DRNI apenas como se fosse um IPL dedicado (não comcompartilhamentodo).
[0138] Se o link for incluído na topologia ativa de uma VLAN, então não há IPL disponível para aquela VLAN. Nesse caso a DRNI é incapaz de passar um quadro entre uma Porta de agregação em um Sistema de Portal e um Gateway em outro Sistema de portal. Portanto, para qualquer quadro dado, DRNI é limitado a ter o Gateway e a Porta de agregação no mesmo Sistema de portal.
[0139] OBSERVAÇÃO 1 - o fato de que o link comcompartilhamentodo pode ser não disponível para a transferência de quadros entre um Gateway e uma Porta de agregação específica não limita a capacidade de permutar DRCPDUs no link comcompartilhamentodo.
[0140] Há dois casos a considerar em atender a restrição que para qualquer quadro dado o Gateway e a Porta de agregação estão no mesmo Sistema de portal. O caso direto é quando os IDs de conversação de Porta são acordados e simétricos através da DRNI, e todos os quadros com um ID VLAN dado mapeiam para os IDs de conversação de porta que selecionam Portas de agregação no mesmo Sistema de portal. Então aquele Sistema de portal é selecionado como o Gateway para aquele ID VLAN, e não há necessidade de quaisquer quadros de dados para atravessar o IPL. Em qualquer outra circunstância o único modo para assegurar que o Gateway e uma Porta de agregação específica estejam no mesmo Sistema de portal é que quando um quadro é recebido em qualquer porta diferente da porta IPL/rede comcompartilhamentoda, aquele Sistema de Portal é considerado o Gateway para aquele quadro e em cada Sistema de Portal todos os IDs de conversação de Porta mapeiam para uma Porta de agregação fixada naquele sistema. Nesse modo, um Sistema de portal que recebe qualquer quadro em uma porta de rede (não sendo a IPP ou a Porta de agregação) é responsável por enviar aquele quadro para a Porta de agregação se necessário. Um sistema de portal que recebe um quadro na IPP nunca envia aquele quadro para a Porta de agregação. Nesse caso, a seleção de gateway não pode necessariamente ser baseada em VID, assim quando os Sistemas de Portal são 802.1Q Bridges o processo de aprendizagem no link IPL/rede comcompartilhamentoda é comprometido. Como as questões de aprendizagem são limitadas a essa porta, podem ser remediadas por sincronizar os endereços aprendidos na DRNI com o outro Sistema de Portal.
[0141] Comcompartilhamentomento de IPL/rede por etiqueta
[0142] Se a distribuição de quadro por serviço for empregada, e se o número de serviços necessários para suportar o link de rede, mais o número de serviços necessários para suportar um ou mais IPLs, for menor que o número de serviços fornecidos pelo formato de quadro usado (por exemplo, 4094 S-VLAN IDs), então a tradução VID pode ser usada para separar os quadros nos links lógicos diferentes.
[0143] O método é selecionado por configurar o aDrniEncapsulationMethod com o valor 2. Se habilitado, como indicado pela variável Enabled_EncTag_shared que é controlada pela máquina de comcompartilhamentomento IPL/rede, todo quadro que deve ser transportado pelo IPL para o Sistema de Portal vizinho e é associado a um ID de conversação de gateway, é traduzido para usar um valor configurado em aDrniIPLEncapMap e todo quadro, que deve ser transportado por link de rede, comcompartilhamentodo com o IPL, e é associado a um ID de conversação de Gateway, é traduzido para usar um valor configurado em aDrniNetEncapMap.
[0144] Comcompartilhamentomento de IPL/rede por encapsulamento
[0145] Esse método habilita comcompartilhamentomento de um IPL com um link de rede usando técnicas de encapsulamento (por exemplo, uma Instância de serviço de Estrutura 802.1Q, um B-VLAN, um pseudowire IETF, etc.).
[0146] O método é selecionado por configurar o aDrniEncapsulationMethod com um valor representando o método de encapsulamento que é usado para transportar quadros IPL (quadros de dados passando através de um IPL, isto é, quadros que não portam DRCPDU) para o Sistema de Portal vizinho quando o IPL e o link de rede estão comcompartilhamentondo o mesmo link físico. Esse valor consiste em Identificador exclusivo de Organização (OUI) de três octetos identificando a organização que é responsável por esso encapsulamento e um octeto seguinte usado para identificar o método de encapsulamento definido por aquela organização. Se habilitado, como indicado pela variável Enabled_EncTag_Shared que é controlada pela máquina de comcompartilhamentomento IPL/rede, todo quadro, que deve ser transmitido no IPL para o Sistema de Portal de vizinho e é associado a um ID de conversação de Gateway, é encapsulado com um método especificado por aDrniEncapsulationMethod para usar um valor configurado em aDrniIPLEncapMap e todo quadro, que é recebido pelo IPL é desencapsulado e mapeado para um ID de conversação de Gateway utilizando a mesma tabela.
[0147] Máquina de estado de função de DR
[0148] As máquinas de estado de função de DR implementarão as regras de enviar especificadas nas Tabelas 1-3. Essas regras de enviar podem ser resumidas como a seguir: a) Para quadros entrando através de uma Porta de agregação, quadros para cima, o algoritmo de Gateway decide se deve transmitir o mesmo para o link de Gateway ou para a IPP de acordo com seu ID de conversação de Gateway. Se o ID de conversação de gateway de quadro casar com o ID de conversação de Gateway operacional do sistema de portal, o quadro será enviado para o Gateway, de outro modo será enviado para a IPP. b) Para quadros que entram através de um Gateway, quadros para baixo, o algoritmo de Porta decide se deve transmitir os mesmos para a Porta de agregação ou para a IPP de acordo com seu ID de conversação de Porta. Se o ID de conversação de porta de quadro casar com o ID de conversação de Porta operacional do sistema de portal, o quadro será enviado para a Porta de agregação, de outro modo será enviado para a IPP. c) Um quadro para cima oferecido a uma IPP é somente transmitido se o Sistema de portal para esse ID de conversação de gateway situar-se atrás daquela IPP, de outro modo é descartado. d) Um quadro para baixo oferecido para uma IPP é somente transmitido se o Sistema de portal alvo para esse ID de conversação de Porta situar-se atrás daquela IPP, de outro modo é descartado.
[0149] Algumas das variáveis de Agregação de link usadas por uma Retransmissão distribuída têm de ser formadas em um modo específico, de modo que múltiplos Sistemas de portal possam cooperar para criar um único sistema emulado: e) Os dois bits menos significativos da Prioridade de porta no ID de porta para cada Porta de agregação em uma Porta de agregador de Retransmissão distribuída são definidos no valor de DRF_Portal_System_Number. O restante dos bits é atribuído a um valor exclusivo na função DR. f) Os dois bits mais significativos da Chave administrativa para cada Porta de agregação e Agregador associado em uma Porta de agregador de Retransmissão distribuída são definidos para o valor de DRF_Portal_System_Number. O restante dos bits pode ser usado como descrito para refletir as características físicas das Portas de agregação.
[0150] Interfaces de serviço
[0151] Uma vez que uma Função DR usa várias instâncias do ISS, é necessário introduzir uma convenção denotação de modo que o leitor possa estar claro com relação a qual interface está sendo encaminhado a qualquer momento dado. Um prefixo é portanto atribuído a cada primitivo de serviço, indicando qual das interfaces está sendo invocada. Os prefixos são como a seguir: a) Agg:, para primitivos emitidos na interface entre a Função DR e a subcamada de Agregação de link. b) Porta:, para primitivos emitidos no Gateway. c) MacIppN:, para primitivos emitidos na interface entre as entidades MAC que suportam o IPL n e o Multiplexor/Analisador de controle DRCP. d) DRCPCtrlMuxN:, para primitivos emitidos na interface entre Multiplexor/Analisador de controle DRCP N e a entidade de controle DRCP (onde N está identificando o IPP associado ao Multiplexor/analisador de controle DRCP). e) IppN:, para primitivos emitidos na interface da Função DR suportada pelo Multiplexor/analisador de controle DRCP N (onde N está identificando o IPP associado ao Multiplexor/analisador de controle DRCP).
[0152] Variáveis de função Por-DR
[0153] A seguinte discussão foca em uma variedade de variáveis de função pré- DR de acordo com uma modalidade da invenção.
[0154] DA: Endereço de destino
[0155] AS: Endereço de fonte
[0156] Mac_service_data_unit
[0157] Prioridade: os parâmetros do primitivo M_UNITDATA.indication.
[0158] BEGIN: Uma variável booleana que é definida como TRUE (VERDADEIRA) quando o Sistema é inicializado ou reinicializado, e é definida como FALSE (FALSA) quando a (re-)inicialização foi concluída.
[0159] Valor: booleano
[0160] Drni_Portal_System_Gateway_Conversation: vetor Booleano operacional, indexado por ID de Conversação de Gateway, indicando se o ID de conversação de Gateway indexado é permitido passar através do Gateway dessa função (TRUE = passa). Seus valores são computados pela função updatePortalSystemGatewayConversation em uma modalidade. Em outra modalidade, essa variável é construída a partir de Drni_Gateway_Conversation, por definir em FALSE, todas as entradas de ID de Conversação de Gateway indexadas que são associadas a outros Sistemas de Portal no Portal e, das entradas de ID de Conversação de Gateway indexadas restantes, todas que não estão em acordo com outros Sistemas de Portal.
[0161] Valor: sequência de valores booleanos, indexados por ID de Conversação de Gateway.
[0162] Drni_Portal_System_Port_Conversation: vetor Booleano operacional, indexado por ID de Conversação de Porta, indicando se o ID de conversação de Porta indexado é permitido ser distribuído através do Agregador dessa função DR (TRUE = passa). Seus valores são computados pelo updatePortalSystemPortConversation em uma modalidade. Em outra modalidade, essa variável é construída a partir de Drni_Port_Conversation, por definir em FALSE todas as entradas de ID de Conversação de Porta que são associadas a outros Sistemas de Portal no Portal e, das entradas de ID de Conversação de Gateway indexadas restantes, todas que não estão em acordo com outros Sistemas de Portal.
[0163] Valor: sequência de valores Booleanos, indexados pelo ID de conversação de Porta.
[0164] Mensagens
[0165] Agg:M_UNITDATA.indication
[0166] Gate:M_UNITDATA.indication
[0167] IppN:M_UNITDATA.indication
[0168] Agg:M_UNITDATA.request
[0169] Gate:M_UNITDATA.request
[0170] IppN:M_UNITDATA.request
[0171] Os primitivos de serviço costumavam passar um quadro recebido para um cliente com os parâmetros especificados.
[0172] Se comcompartilhamentomento de IPL/rede por etiqueta, ou comcompartilhamentomento de IPL/rede por métodos de encapsulamento forem usados, os primitivos de serviço IppN:M_UNITDATA.indication e IppN:M_UNITDATA.request necessitam ser manipulados através da operação de funções que são controladas pela máquina de comcompartilhamentomento IPL/rede.
[0173] Função DR: Máquina de estado de recepção de porta de agregador
[0174] A Função DR: a máquina de estado de recepção de Porta de agregador pode implementar a função especificada na figura 22 com seus parâmetros associados de acordo com uma modalidade da invenção. Há uma Função DR: a máquina de estado de recepção de Porta de agregador por Sistema de Portal e há tantos estados PASS_T0_IPP_N quantos IPPs em um Sistema de Portal, cada identificado pelo índice n. O prefixo “n.” no diagrama é usado para identificar o IPP específico n com o qual a variável associada está relacionada.
[0175] Função DR: Máquina de estado de distribuição de gateway
[0176] A função DR: máquina de estado de estado de Gateway pode implementar a função especificada na figura 23 com seus parâmetros associados de acordo com uma modalidade da invenção. Há uma Função DR: máquina de estado de distribuição de Gateway por Sistema de Portal e há tantos estados PASS_T0_IPP_N quantos IPPs em um Sistema de Portal, cada identificado pelo índice n. O prefixo “n.” no diagrama é usado para identificar o IPP específico n com o qual a variável associada está relacionada.
[0177] Função DR: Máquina de estado de Recepção N IPP
[0178] A função DR: a máquina de estado de Gateway de recepção N IPP pode implementar a função especificada na figura 24 com seus parâmetros associados de acordo com uma modalidade da invenção. Há uma Função DR: máquina de estado de recepção N IPP por Sistema de Portal e há tantos estados PASS_T0_IPP_N quantos IPPs em um Sistema de Portal, cada identificado pelo índice m. O prefixo “n.” ou “m” no diagrama é usado para identificar o IPP n ou IPP m específico com o qual a variável associada está relacionada.
[0179] Protocolo para controle de retransmissão distribuída
[0180] A finalidade do Protocolo para controle de retransmissão distribuída (DRCP) é: A) Estabelecer comunicação entre Sistemas de Portal através de um Link Intra-portal; B) Verificar a configuração consistente de Sistemas de portal; C) Determinar a identidade a ser usada para o sistema emulado; D) Distribuir os estados atuais dos Sistemas de Portal e suas Portas de agregação entre si; E) Computar o percurso resultante de qualquer quadro exigido para passar através de cada IPL, e permutar as informações com Sistemas de Portal adjacentes como necessário para assegurar contra enviar loops e fornecimento de quadro duplicata. F) Permutar informações entre Sistemas de Portal para suportar funções distribuídas não especificadas nesse relatório descritivo;
[0181] O resultado da operação de DRCP é manter as variáveis que controlam enviar de quadros pela Retransmissão distribuída.
[0182] DRCP troca informações para assegurar que os Sistemas de Portal possam trabalhar juntos. A primeira classe de tais informações inclui os objetos gerenciados e variáveis que devem ser compatíveis para passar quaisquer dados (item A acima). Em uma modalidade, esses incluem: G) aAggPortAlgorithm: Todos os Sistemas de Portal devem usar o mesmo algoritmo de Porta. H) aDrniGaewayAlgorithm: todos os Sistemas de Portal devem usar o mesmo algoritmo de Gateway. I) aDrniPorta1Id: todos os Sistemas de Portal devem ter o mesmo valor para aDrniPorta1Id, para assegurar que são todos supostos pertencer ao mesmo Portal. J) Para aSDrniPortalTopology: todos os Sistemas de Portal têm de ter o mesmo valor para aDrniPortal Toopology e no caso de um Portal de três Sistemas de Portal conectados em um anel, o mesmo “Link de quebra de Loop”, aDrniLoopBreakLink necessita ser configurado consistentemente através do Portal. K) aDrniPortalSystemNumber: Todos os Sistemas de Portal devem ter valores aDrniPortalSystemNumber diferentes, e todos esses valores devem estar na faixa 1..3, para assegurar que informações possam ser rotuladas de modo significativo. L) aAggActorAdminKey: os dois bits mais significativos da Chave administrativa para cada Agregador em uma Porta de agregador de Retransmissão distribuída são definidos no valor de DRF_Portal_System_Number. O restante dos bits reflete as características físicas das Portas de agregação associadas e têm de ser iguais para todos os Sistemas de Portal no Portal.
[0183] A segunda classe de objetos gerenciados (item B) controla através de qual Gateway e quais portas de agregação cada ID de Conversação passa. Para esses objetos gerenciados, se a informação sobre um ID de conversação for configurada diferentemente em diferentes Sistemas de Portal, somente aquele ID de conversação é afetado. Portanto, o Portal pode operar normalmente, e os mecanismos que asseguram contra fornecimento duplicata ou envio de loops bloquearão a passagem de quaisquer quadros que pertencem a IDs de conversação configurados erroneamente. Para detectar a configuração errônea, de modo que o bloqueio não seja permanente, as Funções DR podem notificar o administrador de rede se as configurações diferirem. Uma vez que essas configurações são bem grandes, uma soma de verificação de seu conteúdo é trocada, em vez das próprias configurações. Esse método detecta diferenças em uma probabilidade elevada, porém não uma certeza. Em uma modalidade, esses objetos gerenciados incluem: L) aDrniConvAdminGateway[]: a lista que é usada para dinamicamente determinar qual ID de conversação flui através de qual Gateway. M) aAggConversationAdminPort[]: a lista que é usada para dinamicamente determinar qual ID de conversação flui através de qual Porta de agregação.
[0184] DRCP usa suas informações nas quais os Sistemas de Portal esperados estão conectados ou não através de IPLs para determinar a identidade da Retransmissão distribuída emulada (item C acima nessa seção).
[0185] Os estados operacionais atuais de todos os Sistemas de Portal e suas Portas de agregação são trocados de modo que cada das Funções DR possa determinar para qual Gateway de Sistema de Portal ou Porta de agregador cada quadro deve ser fornecido (item D acima nessa seção). Cada Função DR computa um vetor especificando exatamente quais IDs de conversação de Porta e quais IDs de conversação de gateway podem passar através de cada Gateway, Porta de agregação ou IPP. Em cada IPP, essa informação é trocada (item E acima nessa seção). Se houver uma diferença entre vetores de duas Funções DR para qualquer ID de conversação dada, as variáveis de saída são definidas de modo que a Função DR bloqueará quadros com aquele ID de conversação. Isso evita looping ou fornecimento duplicata de qualquer quadro.
[0186] Estabelecimento do Portal e retransmissão distribuída
[0187] A criação de Portais automaticamente não é de direção especificada. Em vez disso, DRCP compara as intenções do administrador de rede, como definido por objetos gerenciados, com a topologia física dos Sistemas configurados, e se as configurações dos Sistemas conectados forem compatíveis, DRCP estabelece e habilita a operação do Portal. Para estabelecer uma Retransmissão distribuída através de um Portal, um administrador de rede configura os seguintes objetos gerenciados: A) pode haver muitos Sistemas em uma rede, e alguns ou todos os Sistemas de Portal selecionados podem participar em outros portais. A determinação de quais outros Sistemas de Portal pertencem ao Portal desse Sistema de Portal é realizada por configurar variáveis como aDrniPortalId e aDrniSystemNumber. B) Como descrito acima, qualquer instância de ponto a ponto do Serviço MAC pode ser atribuída para ser um Link Intra-portal. As instâncias específicas atribuídas ao uso de uma Função DR são configuradas em um aDrniIntraPortalLinkList, por exemplo. C) Qual Agregador em cada Sistema de Portal deve ser atribuído a essa Função DR é configurado em aDrniAggregator em uma modalidade. D) Os métodos a serem usados pelas Funções DR para atribuir quadros a IDs de conversação de Gateway e IDs de conversação de Porta são configurados em dois objetos gerenciados, aDrniGatewayAlgoritm e aAggPortAlgorithm em uma modalidade. E) As atribuições inicial e de backup de IDs de conversação para Gateways e Portas de agregação para cobrir modos de falha são configuradas em vários objetos gerenciados: aDrniConvAdminGateway[], e aAggConversationAdminPorta[] em uma modalidade.
[0188] Transmissão, Endereçamento e Identificação de Protocolo de DRCPDU
[0189] Unidades de Dados de Protocolo de Controle de retransmissão distribuídas (DRCPDUs) são transmitidas e recebidas utilizando o serviço fornecido por uma entidade LLC que usa, por sua vez, uma instância única do Serviço MAC fornecido em um MSAP associado a uma IPP. Cada DRCPDU é transmitida como uma solicitação de serviço MAC única, e recebida como uma indicação de serviço MAC única, com os seguintes parâmetros: • endereço de destino • endereço de fonte • MSDU (Unidade de dados de serviço MAC) • prioridade
[0190] A MSDU de cada solicitação e indicação compreende um número de octetos que fornece identificação de protocolo EtherType seguida pela DRCPDU própria.
[0191] OBSERVAÇÃO 1 - para fins desse padrão, o termo “entidade LLC” inclui entidades que suportam discriminação de protocolo usando o campo EtherType como especificado em IEEE Std 802.
[0192] OBSERVAÇÃO 2 - o formato completo de um quadro DRCP depende não somente do formato de DRCPDU, como especificado aqui, mas também dos procedimentos dependentes de método de acesso de meio usados para suportar o Serviço MAC.
[0193] Endereço MAC de destino
[0194] O endereço de destino para cada solicitação de serviço MAC usada para transmitir uma DRCPDU pode ser um endereço de grupo selecionado por Objetos gerenciados de IPP. Seus valores default podem ser o endereço de grupo de Ponte não TPMR (Retransmissão de Controle de Acesso de Meio de duas portas (MAC)) mais próximo.
[0195] Endereço MAC de fonte: o endereço de fonte para cada solicitação de serviço MAC usada para transmitir uma DRCPDU pode ser um endereço individual associado a IPP MSAP (Ponto de acesso de serviço MAC) no qual a solicitação é feita.
[0196] Prioridade: a prioridade associada a cada solicitação de serviço MAC deve ser o default associado a IPP MSAP.
[0197] Encapsulamento de DRCPDUs em quadros
[0198] Uma DRCPDU é codificada no parâmetro mac_service_data de uma M- UNITDATA.request ou M_UNITDATA.indication. Os primeiros octetos da mac_service_data_unit são um identificador de protocolo, seguido pela DRCPDU, seguido por octetos de preenchimento, se algum, como exigido pelo serviço MAC subjacente.
[0199] Onde a instância ISS usada para transmitir e receber quadros é fornecida por um método de controle de acesso de mídia que pode suportar codificação EtherType diretamente (por exemplo, é um MAC IEEE 802.3), o identificador de protocolo tem dois octetos de comprimento. Todas as DRCPDUs são identificadas pelo EtherType especificado. Onde a instância de ISS é fornecida por um método de acesso de meio que não pode suportar diretamente codificação EtherType (por exemplo, é um MAC IEEE 802.11) o TPID é codificado de acordo com a regra para um Protocolo de acesso de sub-rede (cláusula 10 de IEEE Std 802) que encapsula quadros Ethernet sobre LLC e compreende o cabeçalho SNAP (AA-AA-03 hexadecimal) seguido pelo SNAP PID (hexadecimal 00-00-00) seguido pelo EtherType de Protocolo (hexadecimal xx-xx).
[0200] Estrutura de DRCPDU e codificação
[0201] Transmissão e representação de octetos
[0202] Todas as DRCPDUs compreendem um número integral de octetos. Os bits em cada octeto são numerados de 0 a 7, onde 0 é o bit de ordem baixa. Quando octetos consecutivos são utilizados para representar um valor numérico, o octeto mais significativo é transmitido primeiramente, seguido por octetos menos significativos sucessivamente.
[0203] Quando a codificação de (um elemento de) uma DRCPDU é mostrada em um diagrama: A) octetos são transmitidos do topo para baixo. B) Em um octeto, bits são mostrados com bit 0 à esquerda e bit 7 à direita, e são transmitidos da esquerda para a direita. C) quando octetos consecutivos são usados para representar um número binário, o octeto transmitido primeiramente tem o valor mais significativo. D) quando octetos consecutivos são usados para representar um endereço MAC, o bit menos significativo do primeiro octeto é atribuído o valor do primeiro bit do endereço MAC, o bit mais significativo seguinte o valor do segundo bit do endereço MAC, e assim por diante até o oitavo bit. Similarmente, os bits menos significativos até mais significativos do segundo octeto são atribuídos o valor do nono até décimo sétimo bits do endereço MAC, e assim por diante para todos os octetos do endereço MAC.
[0204] Encapsulamento de DRCPDUs em quadros
[0205] Uma DRCPDU é codificada no parâmetro mac_service_data_unit de uma M_UNIDATA.request ou M_UNITDATA. Indication em uma modalidade. Os primeiros octetos do mac_service_data_unit são um identificador de protocolo, seguido pela DRCPDU, seguido pelos octetos de preenchimento, se algum, como exigido pelo serviço MAC subjacente.
[0206] Onde a instância ISS usada para transmitir e receber quadros é fornecida por um método de controle de acesso de meio que pode suportar codificação EtherType diretamente (por exemplo, é um MAC IEEE 802.3),o identificador de protocolo tem dois octetos em comprimento, e o valor é o EtherType de protocolo (hexadecimal xx-xx).
[0207] Onde a instância ISS é fornecida por um método de acesso de meio que não pode diretamente suportar codificação EtherType (por exemplo, é um IEEE 802.11 MAC), o TPID é codificado de acordo com a regra para um Protocolo de acesso de sub-rede (cláusula 10 de IEEE Std 802) que encapsula quadros de Ethernet sobre LLC, e compreende o cabeçalho SNAP (hexadecimal AA-AA-03) seguido pelo SNAP PID (hexadecimal 00-00-00) e EtherType (hexadecimal xx-xx).
[0208] Estrutura de DRCPDU
[0209] A figura 5 ilustra uma modalidade da estrutura DRCPDU de acordo com a invenção. Os campos são definidos como a seguir: A) Subtipo. O campo Subtipo identifica o Protocolo lento específico sendo encapsulado. DRCPDUs carregam o valor de Subtipo 0x0X. Nota A) não está presente se a escolha não for o uso do Protocolo Lento EtherType para identificar operação DRCP. B) Número de versão. Isso identifica a versão DRCP; implementações em conformidade com uma modalidade carregam o valor 0x01. C) TLV_type = informação de portal. Esse campo indica a natureza da informação carregada nesse TLV-tuple. Informações de DRNI são identificadas pelo valor 0x01 em uma modalidade. D) Portal_Information_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple, informações de Ator utilizam um valor de comprimento de 18 (0x12) em uma modalidade, e E) Aggregator_Priority. A prioridade atribuída ao ID de sistema de Ator (por programa de gerenciamento ou administração) do Agregador anexado à Função DR, codificado como um número inteiro não assinado a partir de um aAggActorSystemPriority em uma modalidade. F) Aggregator_ID. O componente de endereço MAC de ID de sistema de ator do Agregador anexado à Função DR a partir de uma modalidade. G) Portal_Priority. A prioridade atribuída ao ID de Portal (por programa de administração ou gerenciamento), codificada como um número inteiro não assinado a partir de aDrniPortalPriority em uma modalidade. H) Portal_ID. O componente de endereço MAC de IDs de portal a partir de aDrniPortalId em uma modalidade. I) TLV_Type = informação de configuração de portal. Esse campo indica a natureza da informação carregada nesse TLV-tuple. Informações de configuração de portal são identificadas pelo valor 0x02 em uma modalidade. J) Portal_Configuration_Information_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple, Informações de Configuração de portal utilizam um valor de comprimento de 46 (0x2E) em uma modalidade. K) Topology_State. Variáveis relacionadas á topologia dessa Função DR para o IPP, codificadas como bits individuais em um único octeto, como segue e como ilustrado na figura 6C: 1) Portal_System_Number é codificado em bits 0 e 1. É o Número de sistema de portal dessa Função DR a partir de aDrniPortalSystemNumber. 2) Portal_Topology é codificado em bits 2 e 3. É a Topologia de Portal dessa Função DR como configurado em aDrniPortalTopology. 3) Neighbor_Conf_Portal_System_Number é codificado em bits 4 e 5. É o Número de sistema de portal configurado do Sistema de Portal que é ligado a esse IPP. 4) Loop_Break_Link é codificado no bit 6. Esse sinalizador indica que o IPL ligado a esse IPP é configurado como um Link de quebra de loop. TRUE indica que o IPL é configurado em aDrniLoopBreakLink e é codificado como um 1; de outro modo, o sinalizador é codificado como um 0. 5) Bit 7 é reservado para uso futuro. É definido em 0 em transmissão e é ignorado em recebimento. K2) Topology_State. Em uma modalidade alternativa, o estado de topologia pode ser codificado em um octeto diferente, como segue e como ilustrado na figura 29. 6) Portal_System_Number é codificado nos bits 0 e 1. O Número de Sistema de Portal dessa Função DR a partir de aDrniPortalSystemNumber em uma modalidade. 7) Neighbor_Conf_Portal_System_Number é codificado em bits 2 e 3. O Número de sistema de portal configurado do Sistema de portal que é ligado a esse IPP em uma modalidade. 8) Bits 4 a 6 são reservados para uso futuro. São definidos em 0 na transmissão e são ignorados no recebimento em uma modalidade. 9) Other_Non_Neighbor codificado em bit 7. TRUE (codificado como 1) indica que o TLV de Informação de outras portas não é associado a um Vizinho imediato desse Sistema de Portal. FALSE (codificado como 0) indica que o TLV de Informação de outras portas é um Vizinho imediato no outro IPP nesse Sistema de Portal em uma modalidade. L) Oper_Aggregator_Key. O valor de Chave de Agregador operacional atual do Agregador ligado à Função DR. M) Port_Algorithm. O algoritmo de Porta usado por essa Função DR e Agregador a partir de um AggPortAlgorithm em uma modalidade. N) Gateway_Algorithm. O algoritmo de Gateway usado por essa Função DR a partir de aDrniGatewayAlgorithm em uma modalidade. O) Porta_Digest. Um resumo das atribuições de ID de conversação de Porta para Porta de agregação priorizadas da Função DR a partir de um AggConversationAdminPort[] em uma modalidade. P) Gateway_Digest. Um resumo das atribuições de ID de Conversação de Gateway para Gateway prioridades a partir de aDrniConvAdminGateway[] em uma modalidade. Q) TLV_type = estado DRCP. Esse campo indica a natureza da informação carregada nesse TLV-tuple. Estado de DRCP é identificado pelo valor 0x03 em uma modalidade. R) DRCP_State_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple, Estado de DRCP utiliza um valor de comprimento de 3 (0x03) em uma modalidade. S) DRCP_State. As variáveis de DRCP dessa Função DR para o IPP, codificadas como bits individuais em um único octeto, como a seguir e como ilustrado na figura 6B: 1) Home_Gateway. Em uma modalidade, é codificado no bit 0. Esse sinalizador indica o estado de operação do Gateway dessa Função DR. TRUE indica operacional e é codificado como um 1 e não operacional é codificado como um 0. 2) Neighbor_Gateway é codificado no bit 1 em uma modalidade. Esse sinalizador indica o estado de operação do Gateway de Funções DR do Vizinho. TRUE indica operacional e é codificado como um 1 e não operacional é codificado como um 0. 3) Other_Gateway é codificado no bit 2 em uma modalidade. Esse sinalizador indica o estado operacional de um potencial de Gateway de outras Funções DR. TRUE indica operacional e é codificado como um 1 e não operacional é codificado como um 0. 4) IPP_Activity é codificado no bit 3 em uma modalidade. Esse sinalizador indica a Atividade DRCP do Vizinho nesse IPP. Vizinho DRCP ativo é codificado como um 1 e nenhuma atividade DRCP é codificada como 0. 5) DRCP_Timeout é codificado em bit 4 em uma modalidade. Esse sinalizador indica o valor de controle de tempo de espera com relação a esse link. tempo de espera curto é codificado como um 1 e tempo de espera longo é codificado como um 0. 6) Gateway Sync é codificado no bit 5 em uma modalidade. Se TRUE (codificado como um 1), essa Função DR considera que os Sistemas de Partner vizinho desse IPP têm seus Gateways IN_SYNC; isto é, a listagem de vetor operacional desse Sistema de Portal que o Gateway do Sistema de Portal (se algum) está passando cada ID de conversação de Gateway está em acordo com o vetor operacional dos Vizinhos de IPP. Se FALSE (codificado como um 0), então esse IPP está atualmente OUT_OF_SYNC; isto é, a listagem de vetor operacional dos Vizinhos desse IPP que o Gateway do sistema de portal (se algum) está passando cada ID de Conversação de Gateway está em desacordo. 7) Sinc. De porta é codificado no bit 6. Se TRUE (codificado como um 1), essa Função DR considera que os Sistemas de Partner de vizinho desse IPP têm suas Portas de agregador IN_SYNC; isto é, a listagem de vetor operacional desse Sistema de Portal que a Porta de agregação do Sistema de Portal (se alguma) está passando cada ID de conversação de Porta está em acordo com o vetor operacional dos Vizinhos desse IPP. Se FALSE (codificado como um 0), então esse IPP está atualmente OUT_OF_SYNC; isto é, a listagem de vetor operacional dos Vizinhos desse IPP que a Porta de agregação do Sistema de Portal (se alguma) está passando cada ID de conversação de Porta está em desacordo. 8) Expirado é codificado no bit 7. Se TRUE (codificado como um 1) esse sinalizador indica que a máquina de recepção de Função DR está no estado EXPIRED ou DEFAULTED; se FALSE (codificado como um 0), esse sinalizador indica que a máquina de Recepção de Função DR não está no estado EXPIRED nem DEFAULTED.
[0210] Os valores recebidos de estado Expirado não são usados pelo DRCP; entretanto, conhecer seus valores pode ser útil ao diagnosticar problemas de protocolo. Observe, também que a ordem dos campos e o comprimento dos campos podem ser diferentes em uma modalidade diferente, porém ainda estar em conformidade com o espírito da presente invenção. T) TLV_type = Informações de Portas de casa. Esse campo indica a natureza das informações carregadas nesse TLV-tuple. Informações de Portas de casa são identificadas pelo valor inteiro 0x04 em uma modalidade. U) Home_Ports_Information_Length. Esse campo indica o comprimento (em octetos) desse TLV_tuple, informações de Portas de casa utilizam um valor de comprimento de 4 vezes o número das Portas de agregação desse Sistema de Portal que são incluídas. V) Home_Admin_Aggregator_Key. O valor de Chave de agregador administrativo do Agregador anexado a essa Função DR a partir de aAggActorAdminKey. W) Home_OPer_Partner_Aggregator_Key. A Chave de Agregador Partner operacional associada a ID LAG de Agregador desse Sistema de Portal. X) Portas de casa ativas. A lista de Portas de agregação ativas em ordem crescente de Número de Porta. A lista é controlada pela operação de LACP (listando todas as Portas nesse Sistema de Portal para qual LACP está declarando Actor_Oper_Port_State.Distributing = TRUE). Y) TLV_type = Informações de Portas de vizinhos. Esse campo indica a natureza da informação carregada por esse TLV_tuple. Informação de Portas de vizinho é identificada pelo valor inteiro 0x05. Z) Neighbor_Ports_Information_Length. Esse campo indica o comprimento (em octetos) desse TLV_tuple, informações de Portas de vizinho utilizam um valor de comprimento de 4 vezes o número das Portas de agregação de Vizinho que são incluídas. Aa) Neighbor_Admin_Aggregator_Key. O valor de Chave de Agregador administrativo do Agregador ligado ao Sistema de Portal Vizinho. Ab) Neighbor_Oper_Partner_Aggregator_Key. A Chave de Agregador partner operacional associado ao ID LAG do Agregador do Sistema de portal de vizinho. Ac) Portas vizinhas ativas. A lista de Portas de agregação ativas em ordem crescente de Número de Porta. A lista é controlada pela operação de LACP (listando todas as Portas no Sistema de Portal vizinho imediato para o qual LACP está declarando Actor_Oper_Port_State.Distributing = TRUE). Ad) TLV_type = Informações de outras Portas. Esse campo indica a natureza da informação carregada nesse TLV-tuple. As informações de Outras Portas são identificadas pelo valor número 0x06. Esse TLV é somente usado se a Topologia de Portal contiver três Sistemas de Portal. Ae) Other_Ports_Information_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple. Informações de outras Portas utilizam um valor de comprimento de 4 vezes o número das Portas de agregação do outro Sistema de Portal que são incluídas. Af) Other_Admin_Aggregator_Key. O valor de Chave de Agregador administrativo do Agregador ligado ao outro Sistema de Portal vizinho. Ag) Other_Oper_Partner_Aggregator_Key. A Chave de Agregador de Partner operacional associada ao ID LAG de Agregador do outro Sistema de Portal vizinho. Ah) Outras Portas ativas. A lista de Portas de agregação ativas em ordem crescente de Número de portal. A lista é controlada pela operação de LACP (listando todas as Portas em um outro Sistema de Portal opcional para o qual LACP está declarando Actor_Oper_Port_State.Distributing = TRUE). Ai) TLV_type = Outras informações. Esse campo indica a natureza das informações carregadas nesse TLV-tuple. Outras informações são identificadas pelo valor inteiro 0x0x em uma modalidade. Aj) TLV_type = Terminador. Esse campo indica a natureza das informações carregadas nesse TLV-tuple. Informações de Terminador (fim da mensagem) são identificadas pelo valor inteiro 0x00 em uma modalidade. Ak) Terminator_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple. Informações de terminador utilizam um valor de comprimento de 0 (0x00) em uma modalidade.
[0211] Observe, o uso de um Terminator_Length de 0 é intencional. Em esquemas de codificação de TLV é prática comum para a codificação de terminador ser 0 tanto para o tipo como para o comprimento.
[0212] Observe também, a implementação de Versão 1 é assegurada para ser capaz de receber PDUs versão N com sucesso, embora PDUs versão B possam conter informações adicionais que não podem ser interpretadas (e serão ignoradas) pela Versão 1. Um fator crucial em assegurar compatibilidade para trás é que qualquer versão futura do protocolo é necessária não redefinir a estrutura ou semântica de informação definida para a versão anterior; pode somente adicionar novos elementos de informação ao conjunto anterior. Consequentemente, em uma PDU versão N, uma implementação de versão 1 pode esperar encontrar as informações de versão 1 exatamente nos mesmos lugares que em uma PDU de versão 1, e pode esperar interpretar essa informação como definido para a versão 1.
[0213] Observe que a DRCPDU aumenta em tamanho com o número de Portas de agregação. Um máximo de (1500 - 88) / 4 = 353 Portas de agregação espalhadas através de Sistemas de Portal de um Portal são suportadas. O número mínimo de Portas de agregação que necessita ser suportado por um Portal é dois.
[0214] A tabela abaixo fornece uma lista dos TLVs que são aplicáveis para DRCP. Tabela 4. Valores de campo de tipo de DRCP TLVs
Figure img0004
[0215] As modalidades fornecem, desse modo, encapsulamento de DRCPDUs em quadros, em que cada DRCPDU compreende um campo indicado estado DRCP, como variáveis DRCP para um IPP. O campo pode ser um octeto. O campo pode incluir ainda, codificado nos bits diferentes do octeto, informações mencionado um ou mais dos seguintes: Home_Gateway; Neighbor_Gateway; Other_Gateway; IPP_Activity; DRCP_Timeout; Gateway Sync; Port Sync; Expired.
[0216] A figura 14 ilustra outra modalidade da estrutura de DRCPDU de acordo com a invenção. Embora a estrutura de DRCPDU na figura 14 seja similar àquela da figura 5, vários campos são diferentes. Por exemplo, o Home_Ports_Information_Length é 2 + 4 * PN na figura 14, não 2 + 2 * PN como na figura 5. Similarmente, vários outros campos da estrutura de DRCPDU na figura 14 contêm comprimentos diferentes daqueles da estrutura de DRCPDU na figura 5, e aas duas estruturas de DRCPDU também contêm campos não presentes na outra modalidade. Em cada estrutura de DRCPDU de exemplo, os campos têm nomes descritivos para o conteúdo dos campos. Alguns dos campos diferentes contêm informações similares, porém foram renomeados ou reorganizados. Uma pessoa versada na técnica entenderia que outras estruturas de DRCPDU similares são possíveis compatíveis com os princípios e estruturas descritas aqui.
[0217] A figura 25 ilustra outra modalidade da estrutura de DRCPDU de acordo com a invenção. A estrutura de DRCPDU na figura 25 é similar àquela das figuras 5 e 14 com várias diferenças. Por exemplo, os comprimentos de informação de Porta (para casa, vizinho e outras portas) são diferença. Além disso, a estrutura de DRCPDU na figura 25 inclui um estado de topologia, e vários campos para chaves de agregador como Oper_Aggregator_Key, Home_Admin_Aggregator_Key, Home_Oper_Partner_Aggregator_Key, Neighbor_Admin_Aggregator_Key, Other_Admin_Aggregator_Key, e Other_Oper_Partner_Aggregator_Key discutidos acima.
[0218] A figura 32 ilustra um método de comunicar através de um quadro incluindo a estrutura DRCPDU de acordo com uma modalidade da invenção. O método 3200 pode ser implementado em um nó DRCP (por exemplo, um dispositivo de rede) de um portal DRCP (mencionado como um portal local) como uma parte de uma DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C.
[0219] Em 3202, um nó DRCP de um portal encapsula uma DRCPDU em um quadro. A DRCPDU inclui uma estrutura incluindo (1) um campo de tipo (mencionado como subtipo) indicando a PDU é para DRCP, (2) um campo de versão indicando o número de versão da DRCPDU, e (3) um conjunto de TLVs. O conjunto de TLVs inclui um TLV de terminador, um TLV de informação de portal, um TLV de configuração de portal, um TLV de estado de DRCP, um TLV de informação de portas de casa, e um TLV de informação de portas de vizinho. Quando um portal inclui mais de dois nós, a estrutura de PDU pode incluir outro TLV de portas em uma modalidade.
[0220] Em uma modalidade, o conjunto de TLVs inclui ainda pelo menos um de TLV de método de comcompartilhamentomento de IPL/rede, TLV de encapsulamento de comcompartilhamentomento de IPL/rede, um ou mais TLVs reservados para IEEE 802.1, e TLVs específicos de organização, cada TLV sendo discutido aqui.
[0221] Cada do conjunto de TLVs inclui um campo de tipo TLV. Em uma modalidade, o campo de tipo TLV de cada inclui valores especificados na tabela 4 ilustrada acima. Cada dos TLVs inclui campos que pode definir valores discutidos acima. Por exemplo:
[0222] . o TLV de terminador indica o fim da estrutura de PDU. Em uma modalidade, inclui um campo do tipo TLV e um campo de comprimento de terminador, onde o campo de comprimento de terminador indica um comprimento de zero como discutido acima.
[0223] . O TLV de informação de portal indica características do portal, do qual o nó DRCP pertence. Em uma modalidade, as características são indicadas em (1) um campo de prioridade de agregador indicando uma prioridade atribuída ao agregador do nó, (2) um campo de identificador de agregador (ID) indicando um ID do agregador, (3) um campo de prioridade de portal indicando uma prioridade atribuída ao portal, e (4) um campo de endereço de portal indicando um componente de endereço MAC associado ao dispositivo de rede como discutido acima.
[0224] . o TLV de informação de configuração de portal indica informação de configuração do portal, ao qual o nó DRCP pertence. Em uma modalidade, a informação de configuração é indicada em (1) um campo de estado de topologia indicando um estado de topologia do portal como ilustrado nas figuras 6C e 29, (2) um campo de chave de agregador operacional indicando uma chave de agregador operacional do nó, (3) um campo de algoritmo de portal indicando um algoritmo de portal usado, (4) um campo de algoritmo de gateway indicando um algoritmo de gateway usado, (5) um campo de resumo de porta indicando um resumo de porta usado para identificador de conversação de porta (ID) para atribuição de porta de agregação, e (6) um campo de resumo de gateway indicando um resumo de gateway usado para ID de conversação de gateway para atribuição de gateway como discutido acima. • o TLV de estado DRCP indica variáveis associadas ao IPP. Em uma modalidade, o estado de DRCP inclui valores codificados como ilustrado na figura 6B como discutido acima. • o TLV de informação de portas de casa indica status atual do nó em associação ao nó DRCP. Em uma modalidade, o status atual do nó é indicado em (1) um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo do agregador anexado, (2) um campo de chave de agregador de partner operacional indicando uma chave de agregador de partner operacional associado ao ID LAG de agregador de nó, (3) um campo de porta de agregação ativa indicando uma lista de portas de agregação ativa no nó como discutido acima. • o TLV de informação de portas de vizinho indica status atual do nó vizinho em associação ao DRNI. Em uma modalidade, o status atual do nó vizinho é indicado em (1) um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo do agregador ligado ao dispositivo de rede vizinho, (2) um campo de chave de agregador de partner operacional indicando uma chave de agregador de partner operacional associado ao ID LAG de agregador de nó vizinho, e (3) um campo de porta de agregação ativa indicando uma lista de portas de agregação ativa em um sistema de portal vizinho imediato associado ao IPP como discutido acima. • o TLV de informação de outras portas indica status atual do outro nó vizinho associado ao DRNI quando o local inclui mais de dois nós. Em uma modalidade, o status atual do outro nó vizinho é indicado em (1) um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo do agregador anexado ao outro nó, (2) um campo de chave de agregador de partner operacional indicando uma chave de agregador de partner operacional associado ao ID LAG do agregador de outro nó vizinho, e (3) uma lista de portas de agregação ativa no outro nó vizinho no IPP como discutido acima. • o TLV de método de comcompartilhamentomento de IPL/rede indica um método de comcompartilhamentomento de IPL e rede associado ao nó; e • o TLV de encapsulamento de comcompartilhamentomento de IPL/rede indica informação referente à encapsulamento do método de comcompartilhamentomento.
[0225] Em 3206, o nó DRCP envia o quadro para seu nó vizinho do portal através do IPP, em que o nó vizinho usa a informação encapsulada para controlar envio de quadros.
[0226] Como discutido acima, através do método 3200, o nó troca informações com seu nó vizinho e desse modo estabelece e habilita operações de DRCP do portal. O método 3200 provê um modo eficiente para o nó trocar informações com seu nó de vizinhança.
[0227] TLV de comcompartilhamentomento de IPL/rede
[0228] Esses TLVs são somente exigidos quando o método de comcompartilhamentomento de IPL/rede usado é um do comcompartilhamentomento de IPL/rede por etiqueta, ou comcompartilhamentomento de IPL/rede por encapsulamento para assegurar configuração compatível entre os Sistemas de Portal. O método de comcompartilhamentomento de IPL/rede por tempo requer a troca do TLV de Método de comcompartilhamentomento de IPL/rede porém não o TLV de encapsulamento de comcompartilhamentomento de IPL/rede.
[0229] NOTA - Nenhum TLVs de comcompartilhamentomento de IPL/rede é necessário quando o método de comcompartilhamentomento de IPL/rede usado é o método físico ou agregado discutido aqui.
[0230] A tabela a seguir fornece uma lista dos TLVs que são aplicáveis para métodos de comcompartilhamentomento de IPL/rede. Tabela 5. Valores de campo de tipo de TLVs de comcompartilhamentomento de IPL/rede
Figure img0005
[0231] TLV de método de comcompartilhamentomento de IPL/rede
[0232] A estrutura de TLV de método de comcompartilhamentomento de IPL/rede pode ser mostrada como a tabela abaixo e como adicionalmente descrito nas seguintes definições de campo: Tabela 6: TLV de método de comcompartilhamentomento de IPL/rede
Figure img0006
[0233] TLV_type = TLV de método de comcompartilhamentomento de IPL/rede. Esse campo indica a natureza da informação carregada nesse TLV-tuple. Os TLVs de comcompartilhamentomento de IPL/rede são identificados pelo valor de inteiro 0x07.
[0234] Network/IPL_Sharing_Method_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple. Os TLVs de comcompartilhamentomento de IPL/rede utilizam um valor de comprimento de 6 (0x06). DRF_Home_Network/IPL_Sharing_Method. Esse campo contém o valor que representa o método de comcompartilhamentomento de IPL/rede que é usado para transportar quadros IPL para o Sistema de Portal vizinho nesse IPP quando o IPL e link de rede estão comcompartilhamentondo o mesmo link físico. Consiste no Identificador exclusivo de organização de três octetos (OUI) identificando a organização que é responsável por esso encapsulamento e um octeto seguinte usado para identificar o método de encapsulamento definido por aquela organização. Sempre definido igual à aDrniEncapsulationMethod. Um valor de 1 indica que comcompartilhamentomento de IPL/rede por tempo é usado. Um valor de 2 indica que o método de encapsulamento usado é igual ao usado por quadros de rede e que comcompartilhamentomento de IPL/rede por etiqueta é usado. A tabela abaixo provê as codificações de método de encapsulamento IEEE OUI (01-80-C2). Tabela 7. Métodos de encapsulamento de IEEE
Figure img0007
[0235] TLV de encapsulamento de comcompartilhamentomento de IPL/rede
[0236] A estrutura de TLV de encapsulamento de comcompartilhamentomento de IPL/rede pode ser como mostrada abaixo e como adicionalmente descrito nas seguintes definições de campo. Tabela 8. TLV de encapsulamento de comcompartilhamentomento de IPL/rede
Figure img0008
Figure img0009
[0237] TLV_type = TLV de encapsulamento de comcompartilhamentomento de IPL/rede. Esse campo indica a natureza da informação carregada nesse TLV-tuple. Os TLVs de comcompartilhamentomento de IPL/rede são identificados pelo valor inteiro 0x08.
[0238] Network/IPL_Sharing_Encapsulation_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple. Os TLVs de comcompartilhamentomento de IPL/rede utilizam um valor de comprimento de 34 (0x22).
[0239] DRF_Home_Network/IPL_IPLEncap_Digest. Esse campo contém o valor do resumo M5 computado a partir de aDrniIPLEncapMap para troca com o Sistema de Portal vizinho no IPL.
[0240] DRF_Home_Network/IPL_NetEncap_Digest. Esse campo contém o valor do resumo MD5 computado a partir de aDrniNetEncapMap para troca no link de rede comcompartilhamentodo.
[0241] DrniEncapsulationMethod
[0242] ATRIBUTO
[0243] SINTAXE APROPRIADA
[0244] UMA SEQUÊNCIA DE OCTETOS consistindo em um Identificador Exclusivo de organização (OUI) e um octeto seguinte.
[0245] COMPORTAMENTO DEFINIDO COMO
[0246] Esse objeto gerenciado é aplicável somente quando comcompartilhamentomento por tempo de IPL/rede ou comcompartilhamentomento por etiqueta de IPL/rede ou comcompartilhamentomento por encapsulamento de IPL/rede é suportado. O objeto identifica o valor representando o método de encapsulamento que é usado para transportar quadros de IPL para o Sistema de Portal vizinho quando o IPL e link de rede estão comcompartilhamentondo o mesmo link físico. Consiste em Identificador Exclusivo de Organização (OUI) de três octetos identificando a organização que é responsável por esso encapsulamento e um octeto seguinte usado para identificar o método de encapsulamento definido por aquela organização. A Tabela sobre métodos de encapsulamento de IEEE provê as codificações de método de encapsulamento IEEE OUI (01-80-C2). Um valor default de 0x01-80-C2-00 indica que o IPL está usando um link de agregação ou físico separado. Um valor de 1 indica que comcompartilhamentomento por tempo de IPL/rede é usado. Um valor de 2 indica que o método de encapsulamento suado é igual ao usado por quadros de rede e que o comcompartilhamentomento por etiqueta de IPL/rede é usado.
[0247] DrnIPLEncapMap
[0248] ATRIBUTO
[0249] SINTAXE APROPRIADA
[0250] UMA SEQUÊNCIA DE NÚMEROS INTEIROS, indexada por ID de conversação de gateway.
[0251] COMPORTAMENTO DEFINIDO COMO
[0252] Esse objeto gerenciado é aplicável somente quando comcompartilhamentomento por etiqueta de IPL/rede ou comcompartilhamentomento por encapsulamento de IPL/rede é suportado. Cada entrada representa o valor do identificador usado para um quadro IPL associado ao ID de conversão de gateway para o método de encapsulamento especificado aqui.
[0253] aDrniNetEncapMap
[0254] ATRIBUTO
[0255] SINTAXE APROPRIADA
[0256] UMA SEQUÊNCIA DE NÚMEROS INTEIROS, indexada por ID de conversação de gateway.
[0257] COMPORTAMENTO DEFINIDO COMO
[0258] Esse objeto gerenciado é aplicável somente quando comcompartilhamentomento por etiqueta de IPL/rede é suportado. Cada entrada representa o valor traduzido do identificador usado para um quadro de rede associado ao ID de conversação de Gateway quando o método especificado aqui é o método de comcompartilhamentomento por etiqueta de IPL/rede especificado aqui e os quadros de rede necessitam comcompartilhamentor o espaço de etiqueta usado por quadros IPL.
[0259] aAggPortAlgorithm
[0260] ATRIBUTO
[0261] SINTAXE APROPRIADA
[0262] UMA SEQUÊNCIA DE OCTETOS consistindo em um Identificador exclusivo de organização (OUI) de três octetos e um octeto seguinte.
[0263] COMPORTAMENTO DEFINIDO COMO
[0264] Esse objeto identifica o algoritmo usado pelo Agregador para atribuir quadros as um ID de conversação de porta.
[0265] aAggActorSystemID
[0266] ATRIBUTO
[0267] SINTAXE APROPRIADA
[0268] MACAddress
[0269] COMPORTAMENTO DEFINIDO COMO:
[0270] Um valor de endereço MAC de leitura-gravação de 6 octetos usado como um identificador exclusivo para o Sistema que contém esse Agregador.
[0271] NOTA - a partir da perspectiva dos mecanismos de Agregação de link descritos na clausula 6, somente uma única combinação de ID de sistema de Ator e Prioridade de sistema são considerados, e nenhuma distinção é feita entre os valores desses parâmetros para um Agregador e a(s) Porta(s) de agregação que são associadas ao mesmo (isto é, o protocolo é descrito em termos da operação de agregação em um único Sistema). Entretanto, os objetos gerenciados fornecidos para o Agregador e a Porta de agregação permitem, ambos, gerenciamento desses parâmetros. O resultado disso é permitir que uma única peça de equipamento fosse configurada por gerenciamento para conter mais de um Sistema a partir do ponto de vista da operação de Agregação de link. Isso pode ser de uso específico na configuração de equipamento que tem capacidade de agregação limitada.
[0272] aAggActorSystemPriority
[0273] ATRIBUTO
[0274] SINTAXE APROPRIADA
[0275] NÚMERO INTEIRO
[0276] COMPORTAMENTO DEFINIDO COMO:
[0277] Um valor de leitura-gravação de 2 octetos indicando o valor de prioridade associado ao ID do sistema de Ator.
[0278] TLV específico de organização
[0279] Qualquer organização pode definir TLVs para uso em DRCP. Esses TLVs são fornecidos para permitir organizações diferentes, como IEEE 802.1, ITU-T, IETF, bem como fornecedores de equipamentos e software individuais, para definir TLVs que anunciam informações para Sistemas de Portal de vizinho. A estrutura de TLV específica de organização será como mostrado na tabela abaixo e como adicionalmente descrito nas seguintes definições de campo:
Figure img0010
[0280] TLV_tuple = TLV específico de organização. Esse campo indica a natureza da informação carregada nesse TLV-tuple. O TLV específico de organização é identificado pelo valor inteiro 0x0F.
[0281] Network/IPL_Sharing_Encapsulation_Length. Esse campo indica o comprimento (em octetos) desse TLV-tuple. O TLV específico de organização utiliza um valor de comprimento de LL.
[0282] OUI. Esse campo contém o Identificador exclusivo de Organização, obtenível a partir de IEEE.
[0283] Subtipo. Esse campo contém um valor de subtipo, de modo que um OUI adicional não será necessário se mais TLVs específicos de organização forem exigidos por um proprietário de um OUI.
[0284] Valor. Esse campo contém a informação que necessita ser comunicada para os Sistemas de Portal de vizinho.
[0285] Visão geral de máquina de estado DRCP
[0286] A operação do protocolo é controlada por um número de máquinas de estado, cada uma das quais executa uma função distinta. Essas máquinas de estado são para a maior parte descrita em uma base por IPP; quaisquer desvios a partir da descrição por Porta de agregação são destacados no texto. Eventos (como expiração de um temporizador ou DRCPDUs recebidas) podem causar transições de estado e também fazer com que medidas sejam tomadas; essas ações podem incluir a necessidade de transmissão de uma DRCPDU contendo informações novas ou repetidas. Transmissões acionadas por evento e periódicas são controladas pelo estado de uma variável Necessário para transmitir (NTT), gerada pelas máquinas de estado como necessário.
[0287] As máquinas de estado são como a seguir: A) Máquina de recebimento (vide a figura 8). Essa máquina de estado recebe DRCPDUs a partir do Sistema de portal de vizinho nesse IPP, grava as informações contidas, e faz intervalo usando tempos de espera curtos ou tempos de espera longos, de acordo com a definição de DRCP_Timeout. Avalia as informações de entrada a partir do Sistema de Portal vizinho para determinar se a Casa e Vizinho ambos concordam as informações de protocolo trocadas até o ponto em que o Sistema de portal de casa possa ser agora seguramente usado, em Portal com outros Sistemas de portal ou como um Portal individual; em caso negativo, confirma NTT para transmitir informação de protocolo nova para o Sistema de Portal vizinho. Se a informação de protocolo a partir dos Sistemas de Portal de vizinho fizer intervalo, a máquina de Recebimento instala valores de parâmetro default para uso pelas outras máquinas de estado. B) Máquina de transmissão periódica (PTS - vide a figura 9). Essa máquina de estado determina o período em que o Sistema de Portal de casa e seus vizinhos trocarão DRCPDUs para manter o Portal. C) Máquina de sistema de Portal (PS - vide a figura 10). Essa máquina de estado é responsável por atualizar o status operacional de todos os Gateways e Portas de agregação no Portal com base em informações locais e DRCPDUs recebidas nos IPPs de sistema de portal de casa. Essa máquina de estado é por Sistema de Portal. D) Máquinas de agregador e Gateway de DRNI (DGA - vide a figura 11). Essas máquinas de estado são responsáveis por configurar os IDs de conversação de gateway que são permitidos passar através do Gateway dessa função de DR e IDs de conversação de porta que são permitidos ser distribuídos através do Agregador dessa função DR. Essas máquinas de estado são por Sistema de portal. E) Máquina IPP DRNI (IPP - vide a figura 12). Essas máquinas de estado são responsáveis por configurar os IDs de conversação de Gateway e os IDs de conversação de Porta que são permitidos passar através dos IPPs dessa função de DR. F) Máquina de transmissão (TX - vide a subseção máquina de Transmissão abaixo). Essa máquina de estado trata da transmissão de DRCPDUs, tanto na demanda a partir das outras máquinas de estado, como em uma base periódica.
[0288] A figura 7 ilustra as relações entre essas máquinas de estado e o fluxo de informações entre as mesmas de acordo com uma modalidade da invenção. O conjunto de setas rotulado Informação de estado de vizinho representa novas informações de vizinho, contidas em uma DRCPDU de entrada ou fornecidas por valores default administrativos, sendo alimentados a cada máquina de estado pela máquina de Recebimento. O conjunto de setas rotulado Informações de estado de casa representa o fluxo de informações de estado de Casa atualizada entre as máquinas de estado. A transmissão de DRCPDUs ocorre como um resultado da máquina Periódica determinando a necessidade de transmitir uma DRCPDU periódica, ou como resultado de alterações nas informações de estado de Casa que necessitam ser comunicadas para os vizinhos. A necessidade de transmitir uma DRCPDU é sinalizada para a máquina de Transmissão por confirmar NTT. As setas restantes representam variáveis comcompartilhamentodas na descrição de máquina de estado que permitem que uma máquina de estado faça com que eventos ocorram em outra máquina de estado.
[0289] A figura 15 ilustra as relações entre essas máquinas de estado e o fluxo de informações entre as mesmas de acordo com outra modalidade da invenção. A modalidade alternativa opera em um modo similar de acordo com os princípios e estrutura descritos aqui e ilustradas no diagrama da figura 15. Desse modo, a descrição genericamente se aplica a ambas as modalidades exceto onde observado.
[0290] Essas máquinas de estado utilizam um conjunto de constantes, variáveis, mensagens e funções como detalhado abaixo.
[0291] Gerenciamento para interconexão de rede resiliente distribuída
[0292] Atributos de retransmissão distribuída
[0293] aDrniPortalId
[0294] ATRIBUTO
[0295] SINTAXE APROPRIADA: UMA SEQUÊNCIA DE 8 OCTETOS que casa com a sintaxe de um endereço MAC de 48 bits
[0296] COMPORTAMENTO DEFINIDO COMO: um identificador de leitura- gravação de um Portal específico. aDrniPortalId tem de ser exclusivo entre pelo menos todos os Sistemas de Portal em potencial para os quais um dado Sistema de Portal pode ser ligado através de um IPL. Também usado como o ID de sistema de Ator para o sistema emulado.
[0297] DrniDescription
[0298] ATRIBUTO
[0299] SINTAXE APROPRIADA:
[0300] Um PrintableString, 255 caracteres no máx.
[0301] COMPORTAMENTO DEFINIDO COMO:
[0302] Uma série de texto legível por ser humano contendo informações sobre a Retransmissão de distribuição. Essa série é somente para leitura. O conteúdo é específico do fornecedor.
[0303] aDrniName
[0304] ATRIBUTO
[0305] SINTAXE APROPRIADA:
[0306] Um PrintableString, 255 caracteres no máx.
[0307] COMPORTAMENTO DEFINIDO COMO:
[0308] Uma série de texto legível por ser humano contendo um nome localmente significativo para a Retransmissão distribuída. Essa série é somente para leitura.
[0309] aDrniPortalAdd
[0310] ATRIBUO
[0311] SINTAXE APROPRIADA:
[0312] UMA SEQUÊNCIA DE 6 OCTETOS que casam com a sintaxe de um endereço MAC de 48 bits.
[0313] COMPORTAMENTO DEFINIDO COMO:
[0314] Um Identificador de leitura-gravação de um Portal específico. aDrniPortalAddr tem de ser exclusivo entre pelo menos todos os Sistemas de Portal em potencial aos quais um Sistema de Portal dado poderia ser ligado através de um IPL. Também usado como o ID de sistema de Ator (6.3.2) para o sistema emulado.
[0315] aDrniPortalPriority
[0316] ATRIBUTO
[0317] SINTAXE APROPRIADA: NÚMERO INTEIRO
[0318] COMPORTAMENTO DEFINIDO COMO: um valor de leitura-gravação de 2 octetos indicando o valor de prioridade associado ao ID de Portal. Também usado como Prioridade de sistema de Ator para o sistema emulado.
[0319] aDrniPortalTopology
[0320] ATRIBUTO
[0321] SINTAXE APROPRIADA
[0322] NÚMERO INTEIRO
[0323] COMPORTAMENTO DEFINIDO COMO:
[0324] Um valor de leitura-gravação indicando a topologia do Portal. O valor 3 representa um Portal de três Sistemas de Portal conectados em um anel por três Links Intra-Portal, o valor 2 representa um Portal de três Sistemas de Portal conectados em uma cadeia por dois IPLs, o valor 1 representa um Portal de dois Sistemas de portal conectados por um IPL único e o valor 0 representa um Portal de um Sistema de portal único sem IPLs ativos. O valor default é 1.
[0325] aDrniPortalSystemNumber
[0326] ATRIBUTO
[0327] SINTAXE APROPRIADA: um Número do Sistema de Portal, que é um número inteiro na faixa 1 até 3 inclusive.
[0328] COMPORTAMENTO DEFINIDO COMO: um identificador de leitura- gravação desse Sistema de Portal específico em um Portal. Deve ser exclusivo entre os Sistemas de portal com o mesmo aDrniPortalId.
[0329] aDrniIntraPortalLinkList
[0330] ATRIBUTO
[0331] SINTAXE APROPRIADA: UMA SEQUÊNCIA DE NÚMEROS INTEIROS que casa com a sintaxe de um Identificador de interface.
[0332] COMPORTAMENTO DEFINIDO COMO: Lista de leitura-gravação dos Links Intra-portal atribuídos a essa Retransmissão distribuída. O Número de porta de cada IPL é configurado para grande parte do Número do Sistema de portal do Sistema de Portal anexado.
[0333] aDrniLoopBreakLink
[0334] ATRIBUTO
[0335] SINTAXE APROPRIADA
[0336] UM NÚMERO INTEIRO que casa com a sintaxe de um Identificador de Interface.
[0337] COMPORTAMENTO DEFINIDO COMO
[0338] Um identificador de leitura-gravação que casa com um dos Identificadores de Interface do aDrniIntraPortalLinkList. Seu valor identifica a interface (“Link de quebra de loop”) que necessita quebra o loop de dados, no caso de um Portal de três Sistemas de Portal conectados em um anel, quando todos os IPLs são operacionais. Esse objeto gerenciado é somente usado quando o valor em aDrniPortalTopology é 3.
[0339] aDrniAggregator
[0340] ATRIBUTO
[0341] SINTAXE APROPRIADA: Um NÚMERO INTEIRO que casa com a sintaxe de um Identificador de interface
[0342] COMPORTAMENTO DEFINIDO COMO: Identificador de interface de leitura-gravação da Porta de Agregador atribuída a essa Retransmissão distribuída.
[0343] aDrniConvAdminGateway[]
[0344] ATRIBUTO
[0345] SINTAXE APROPRIADA: um conjunto de SEQUÊNCIA DE NÚMEROS INTEIROS que casa com a sintaxe de Número de sistema de Portal.
[0346] COMPORTAMENTO DEFINIDO COMO: há 4096 variáveis de aDrniConvAdminGateway[], aDrniConvAdminGateway[0] até aDrniConvAdminGateway[4095], indexadas por ID de conversação de gateway. Cada contém o valor administrativo atual da lista de prioridade de seleção de Gateway para a Retransmissão distribuída. Essa lista de prioridade de seleção, uma sequência de números inteiros para cada ID de conversação de gateway, é uma lista de Números de sistema de Portal na ordem de preferência, mais alta para mais baixa, para o Gateway de Sistema de Portal preferido correspondente para realizar aquela Conversação.
[0347] NOTA - até o ponto em que o administrador de rede falha em configurar os mesmos valores para as variáveis aDrniConvAdminGateway[] em todas as Funções DR de um Portal, quadros podem ser dirigidos erroneamente. O Protocolo de Controle de retransmissão distribuída (DRCP, 9.4) evita contra esse tipo de configurações errôneas.
[0348] aDrniGatewayAlgorithm
[0349] ATRIBUTO
[0350] SINTAXE APROPRIADA: UMA SEQUÊNCIA DE OCTETOS consistindo em um Identificador exclusivo de organização (OUI) e um ou mais octetos seguintes.
[0351] COMPORTAMENTO DEFINIDO COMO: esse objeto identifica o algoritmo usado pela Função DR para atribuir quadros para um ID de conversação de Gateway.
[0352] Constantes
[0353] A seguinte discussão foca em uma variedade de constantes aplicáveis de acordo com uma modalidade da invenção. Todos os temporizadores especificados nessa seção têm uma tolerância de implementação de ± 250 ms.
[0354] Fast_Periodic_Time: o número de segundos entre transmissões periódicas utilizando tempos de espera curtos.
[0355] Valor: Número inteiro; 1
[0356] Slow_Periodic_Time: O número de segundos entre transmissões periódicas utilizando tempos de espera longos.
[0357] Valor: número inteiro; 30
[0358] Short_Timeout_Time: O número de segundos antes de invalidar informações de LACPDU recebidas ao utilizar tempos de espera curtos (3 x Fast_Periodic_Time).
[0359] Valor: Número inteiro; 3
[0360] Long_Timeout_Time: O número de segundos antes de invalidar informações de LACPDU recebidas ao utilizar tempos de espera longos (3 x Slow_Periodic_Time).
[0361] Valor: Número inteiro; 90
[0362] Aggregate_Wait_Time: O número de segundos para retardar agregação, para permitir que múltiplos links agreguem simultaneamente.
[0363] : Número inteiro; 2
[0364] Variáveis associadas à retransmissão distribuída
[0365] A seguinte discussão foca em uma variedade de variáveis associadas às retransmissões distribuídas de acordo com uma modalidade da invenção.
[0366] Drni_Aggregator_Priority: A Prioridade de sistema do agregador associado a esse Portal. Sempre definir igual à aAggActorSystemPriority. Transmitido em DRCPDUs.
[0367] Valor: número inteiro; Atribuído por programa de Sistema ou administrador.
[0368] Drni_Aggregator_ID: O componente de endereço MAC do Identificador de sistema do Agregador associado a esse Portal. Sempre definido igual à aAggActorSystemID e é transmitido em DRCPDUs.
[0369] Valor: 48 bits
[0370] Drni_Gateway_Conversation: vetor operacional listando qual Gateway do Sistema de portal (se algum) está passando cada ID de conversação de Gateway.
[0371] Valor: sequência de números de sistema de portal (0 para nenhum), indexada por ID de conversação de gateway.
[0372] Valor computado a partir de aDrniConvAdminGateway[] e Drni_Portal_System_State[] após inicialização e sempre que o objeto gerenciado ou variável mudar.
[0373] Drni_Port_Conversation: vetor operacional listando qual Sistema de portal (se algum) está passando cada ID de conversação de porta.
[0374] Valor: sequência de Números de sistema de portal (0 para nenhum), indexada por ID de conversação de Porta.
[0375] Valor computado a partir de aAggConversationAdminPort[] e Drni_Portal_System_State[] após inicialização e sempre que o objeto gerenciado ou variável mudar.
[0376] Drni_Portal-Priority: a Prioridade de sistema do Portal. Sempre definido igual à aDrniPortalPriority. Transmitido em DRCPDUs.
[0377] Valor: número inteiro.
[0378] Atribuído por programa de sistema ou administrador.
[0379] Drni_PortalID (ou Drni_Portal_Addre em algumas modalidades). O componente de endereço MAC do Identificador de sistema do Portal. Sempre definido igual à aDrniPortalId. Transmitido em DRCPDUs.
[0380] Valor: 48 bits.
[0381] Atribuído por programa de sistema ou administrador.
[0382] Drni_Portal_topology: a topologia configurada do Portal. Sempre definido igual à aDrniPortalTopology. Transmitido em DRCPUDs.
[0383] Valor: um número inteiro na faixa [0...3]
[0384] Atribuído por programa de Sistema ou administrador
[0385] Variáveis de acordo com Função DR
[0386] ChangeDRFPorts: essa variável rastreia o estado operacional do Gateway e todas as portas de agregação associadas a esse Sistema de Portal e é definida em TRUE quando qualquer um deles muda. Essa variável pode também ser definida em TRUE se novos valores para o Drni_Conversation_GatewayList[] ou Drni_Conversation_PortList[] forem iniciados.
[0387] Valor: booleano
[0388] ChangePortal: essa variável é definida em TRUE quando o DRF_Neighbor_Oper_DRCP_State.IPP_Activity em qualquer IPP nesse Sistema de Portal mudar.
[0389] Drni_Conversation_GatewayList[]: um conjunto de 4096 listas, indexado por ID de conversação de Gateway, que determina qual Gateway nesse Portal carrega qual ID de conversação de Gateway. Cada item no conjunto é uma lista de Gateways nesse Portal, em ordem de prioridade a partir do mais desejado para o menos desejado, para carregar o ID de Conversação de Gateway indexado. Atribuído por programa de sistema ou administrador. Sempre definido igual à aDrniConvAdminGateway[].
[0390] Drni_Conversation_PortList[]: um conjunto de 4096 listas, indexado por ID de conversação de porta, que determina qual Porta de agregação nesse Portal carrega qual ID de Conversação de Porta. Cada item no conjunto é uma lista de Portas de agregação nesse Portal, em ordem de prioridade a partir do mais desejado para o menos desejado, para carregar o ID de conversação de Porta indexado. Atribuído por programa de sistema ou administrador. Sempre definido igual à aAggConversationAdminPort[].
[0391] Valor: sequência de IDs de Porta
[0392] Drni_Portal_System_State[]: Os estados de todos os Sistemas de Portal nesse Portal, indexados por Número de sistema de portal.
[0393] Valor: Estado de operação de indicação de sinalizador booleano de Gateway (TRUE indica operacional), uma Lista (talvez vazia) dos IDs de Porta das Portas de agregação operacional naquele Sistema de Portal, e a identidade do IPP, se alguma, do qual o estado do Sistema de Portal foi obtido. Essa variável é definida pela função updatePortalState. Transmitido em DRCPDUs.
[0394] DRF_Home_Admin_Aggregator_Key: o valor de Chave de agregador administrativo associado a esse Agregador do Sistema de Portal. Transmitido em DRCPDUs.
[0395] Valor: número inteiro.
[0396] Em uma modalidade, DRF_Home_Admin_Aggregator_Key é atribuído por programa de Sistema ou administrador. O DRF_Home_Admin_Aggregator_Key é configurado e deve ser diferente para cada Sistema de Portal. Especificamente os dois bits mais significativos devem ser diferentes em cada Sistema de Portal. Os 14 bits mais baixos podem ser de qualquer valor, não necessitam ser iguais em cada Sistema de portal, e têm um default de zero.
[0397] Atribuído por programa de Sistema ou administrador.
[0398] DRF_Home_Conversation_GatewayList_Digest: um resumo de aDrniConvAdminGateway[], configurado nessa função DR, para troca com os Sistemas de Portal de vizinho. Essa variável é referenciada pela DRCPDU.
[0399] Valor: resumo MD5.
[0400] DRF_Home_Converation_PortList_Digest: um resumo de aAggConversationAdminPort[], configurado nessa Função DR, para troca com os Sistemas de Portal de vizinho. Transmitido em DRCPDUs.
[0401] Valor: resumo MD5
[0402] DRF_Home_Gateway_Algorithm: o algoritmo de gateway usado por essa Função de DR para atribuir quadros a IDs de conversação de Gateway. Sempre definido igual ao aDrniGatewayAlgorithm. Transmitido em DRCPDUs.
[0403] Valor: 4-octeto (OUI de 3 octetos identificando a organização que é responsável por definir esse algoritmo seguido por dois octetos identificando esse algoritmo específico). Em outra modalidade, 5 octetos são usados.
[0404] DRF_Home_Port_Algorithm: o algoritmo de Porta usado por essa Função DR para atribuir quadros a IDs de conversação de Porta. Sempre definido igual ao aAggPortAlgorithm de agregado associado. Transmitido em DRCPDUs.
[0405] Valor: 4-octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse algoritmo seguido por dois octetos identificando esse algoritmo específico). Em outra modalidade, 5 octetos são usados.
[0406] DRF_Home_Oper_Aggregator_Key: o valor de Chave de Agregador operacional associado ao Agregador desse Sistema de portal. Seu valor é computado pela função de updateKey. Transmitido em DRCPDUs.
[0407] Valor: inteiro
[0408] DRF_Home_Oper_Partner_Aggregator_Key: a Chave de Agregador de Partner operacional associada ao ID LAG de Agregador desse Sistema de Portal. Transmitido em DRCPDUs.
[0409] Valor: inteiro
[0410] DRF_Home_State: o estado operacional dessa Função DR. Transmitido em DRCPDUs.
[0411] Valor: estado de operação de indicação de sinalizador booleano do Gateway desse Sistema de Portal (TRUE indica operacional) e uma Lista (talvez vazia) dos IDs de Porta das Portas de Agregação operacional nesse sistema de portal.
[0412] DRF_Neighbor_Admin_Conversation_GatewayList_Digest: o valor para o Algoritmo do Sistema de Portal de Vizinho, atribuído por programa de Sistema ou administrador para uso quando a informação do Vizinho é desconhecida. Seu valor default é o resumo MD5 computado a partir de aDrniConvAdminGateway[].
[0413] Valor: resumo MD5.
[0414] DRF_Neighbor_Admin_Converation_PortList_Digest: o valor para o Algoritmo do Sistema de Portal de vizinho, atribuído pelo programa de administrador ou Sistema para uso quando a informação do vizinho é desconhecida. Seu valor default é o resumo MD5 computado a partir de um AggConversationAdminPort[].
[0415] Valor: resumo MD5
[0416] DRF_Neighbor_Admin_Gateway_Algorithm: o valor para o algoritmo de gateway dos Sistemas de vizinho, atribuídos pelo programa de sistema ou administrador para uso quando a informação do vizinho é desconhecida. Seu valor default é definido igual à aDrniGatewayAlgortihm.
[0417] Valor: 4 octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse algoritmo para definir esse algoritmo seguido por dois octetos identificando esse algoritmo específico). Em outra modalidade, 5 octetos são usados.
[0418] DRF_Neighbor_Admin_DRCP_State: valor default para os parâmetros de estado de DRCP do Portal vizinho, atribuídos por programa de sistema ou administrador para uso quando a informação do Partner é desconhecida ou expirada. O valor consiste no seguinte conjunto de variáveis, como descrito em uma modalidade: • HomeGateway • NeighborGateway • OtherGateway • IPPActivity • Timeout • GatewaySync • PortSync • Expired
[0419] Valor: 8 bits
[0420] DRF_Neighbor_Admin_Port_Algorithm: O valor para o algoritmo de porta dos Sistemas de Vizinho, atribuído por programa de Sistema ou administrador para uso quando a informação de Vizinho é desconhecida. Seu valor default é definido igual à aAggPortAlgorithm.
[0421] Valor: 4-octetos (OUI de 3-octetos identificando a organização para definir esse algoritmo seguido por dois octetos (identificando esse algoritmo específico)). Em outra modalidade, 5 octetos são usados.
[0422] DRF_Portal_System_Number: Um identificador exclusivo para esse Sistema de Portal no Portal.
[0423] Valor: Um número inteiro na faixa [1..3] em uma modalidade.
[0424] Copiado de aDrniPortalSystemNumber. Transmitido em DRCPDUs.
[0425] PSI (estado de portal isolado): Essa variável é definida em TRUE pela função updateDRFHomeState quando o Sistema de Portal é isolado a partir dos outros Sistemas de Portal no mesmo Portal.
[0426] Valor: Booleano.
[0427] Variáveis de acordo com IPP
[0428] A seguinte discussão foca em uma variedade de variáveis conforme IPP de acordo com uma modalidade da invenção.
[0429] Ipp_Gateway_Conversation_Direction: Lista Operacional de quais IDs de Conversação de Gateway estão passando através de Gateways alcançáveis através desse IPP. É definido pela operação de DRCP.
[0430] Valor: Vetor de sinalizadores Booleanos indexados por ID de conversação de Gateway; TRUE = algum Gateway alcançável através desse IPP é habilitado para esse ID de conversação de Gateway.
[0431] Para cada ID de conversação de Gateway, o valor é TRUE e somente se a) as variáveis Drni_Gateway_Conversation e Drni_Portal_System_State[] indicarem que o Sistema de Portal alvo para esse ID de Conversação de gateway situar atrás desse IPP, e b) Drni_Gateway_Conversation e Ipp_Other_Gateway_Conversation estão em acordo com relação a qual Sistema de Portal deve obter esse ID de conversação de Gateway. Ipp_Gateway_Conversation_Direction é inicializado para FALSE e recomputado sempre que qualquer de suas variáveis de contribuição mudar. Para quadros recebidos nesse IPP, TRUE significa que o quadro é um quadro Down, finalmente destinado para um Agregador (ou descartar), e FALSE significa que o quadro é um quadro Up, finalmente destinado para um Gateway (ou descartar). Para quadros oferecidos para transmissão nesse IPP, TRUE indica que o quadro pode passar, e FALSE que não pode. Essa variável não é usada para controlar quadros Down.
[0432] Ipp_Port_Conversation_Passes: Lista operacional de quais IDs de Conversação de Porta são permitidos serem transmitidos através desse IPP.
[0433] Valor: Vetor de sinalizadores Booleanos indexados por ID de conversação de Porta.
[0434] Essa variável é examinada somente quando um quadro Down é oferecido para transmissão nesse IPP. Para cada ID de conversação de Porta, o valor é TRUE (ID passa) se e somente se a) as variáveis Drni_Port_Conversation e Drni_Portal_System_State[] indicarem que o Sistema de Portal alvo para esse ID de conversação de Porta situa-se atrás desse IPP, e b) Ipp_Other_Port_Conversation_Portal_System estão em acordo com relação a qual Sistema de Portal deve obter esse ID de conversação de Porta. Ipp_Port_Conversation_Passes é inicializado para FALSE re computado sempre que quaisquer de suas variáveis de contribuição mudar.
[0435] ChangePortal: Essa variável é ajustada em TRUE quando DRF_Neighbor_Oper_DRCP_State.IppActivity em qualquer IPP nesse Sistema de Portal muda.
[0436] Valor: booleano
[0437] CC_Time_Shared: Um Booleano indicando que Sistemas de Portal de casa e vizinho nesse IPP são compativelmente configurados para usar comcompartilhamentomento de Network/IPL por tempo.
[0438] Valor: booleano
[0439] CC_EncTag_Shared: Um Booleano indicando que os Sistemas de Portal de casa e vizinho nesse IPP são compativelmente configurados para usar comcompartilhamentomento de Network/IPL por etiqueta ou comcompartilhamentomento de Network/IPL por encapsulamento como determinado pelo método de Network/IPL selecionado do aDrniEncapsulationMethod.
[0440] Valor: booleano
[0441] Differ_Conf_Portal: Um Booleano indicando que os parâmetros de portal configurado usados pelo Sistema de Portal de vizinho imediato nesse IPP são diferentes a partir dos esperados.
[0442] Valor: booleano
[0443] Differ_Portal: Um Booleano indicando que a DRCPDU recebida nesse IPP é associada a um Portal diferente.
[0444] Valor: booleano
[0445] DRF_Home_Conf_Neighbor_Portal_System_Number: O valor de configuração desse Sistema de Portal para o Número de Sistema de Portal do Sistema de Portal de vizinho ligado a esse IPP. Sempre definido igual ao valor atribuído a pelo menos dois bits significativos do componente de prioridade do ID de porta desse IPP. Transmitido em DRCPDUs.
[0446] Valor: um número inteiro na faixa [1...3].
[0447] DRF_Home_Loop_Break_Link: Um Booleano indicando que o IPL ligado a esse IPP é configurado em aDrniLoopBreakLink como um Link de quebra de loop. Transmitido em DRCPDUs.
[0448] Valor: booleano
[0449] DRF_Home_Network/IPL_IPLEncap_Digest: Um resumo de aDrniIPLEncapMap, configurado nesse IPP, para troca com o Sistema de Portal de vizinho no IPL. Transmitido no TLV de encapsulamento de comcompartilhamentomento de IPL/rede.
[0450] Valor: resumo MD5
[0451] DRF_Home_Network/IPL_NetEncap_Digest: Um resumo de aDrniNetEncapMap, configurado nesse IPP, para troca no link de rede comcompartilhamentodo. Transmitido no TLV de Encapsulamento de comcompartilhamentomento de IPL/rede.
[0452] Valor: resumo MD5
[0453] DRF_Home_Network/IPL_Sharing_Method: O método de comcompartilhamentomento de IPL/rede usado por essa Função DR para comcompartilhamentor esse IPP com dados de rede. Sempre definido igual ao aDrniEncapsulationMethod. Transmitido no TLV de Método de comcompartilhamentomento de IPL/rede quando o aDrniEncapsulationMethod não é definido no valor NULO default.
[0454] Valor: 4-octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse método específico).
[0455] DRF_Home_Oper_DRCP_State: Os valores operacionais dos parâmetros de estado DECP desse Sistema de Portal como relatado nesse IPP. Isso consiste no seguinte conjunto de variáveis, como descrito acima: • HomeGateway • NeighborGateway • OtherGateway • IPPActivity • Timeout • GatewaySync • PortSync • Expired
[0456] Valor: 8 bits
[0457] DRF_Neighbor_Admin_Aggregator_Key: em uma modalidade, é definido como o valor de Chave de Agregador administrativo do Sistema de Portal de vizinho nesse IPP. Transmitido em DRCPDUs.
[0458] Valor: número inteiro
[0459] DRF_Neighbor_Aggregator_Priority: O último recebido, Prioridade de sistema do agregador de vizinho, nesse IPP.
[0460] Valor: número inteiro
[0461] DRF_Neighbor_AggregatorID: O último recebido, componente de endereço MAC de ID do Sistema de agregador do Sistema de Portal de vizinho, nesse IPP.
[0462] Valor: 48 bits
[0463] DRF_Neighbor_Aggregator_Priority: O último recebido, Prioridade de sistema do Agregador do Sistema de Portal de vizinho, nesse IPP.
[0464] Valor: número inteiro
[0465] DRF_Neighbor_Conversation_GatewayList_Digest: O resumo de ID de conversação de gateway último recebido do Sistema de Portal de vizinho nesse IPP.
[0466] Valor: resumo MD5
[0467] DRF_Neighbor_Conversation_PortList_Digest: O resumo de conversação de Porta último recebido do sistema de Portal de vizinho nesse IPP
[0468] Valor: resumo MD5
[0469] DRF_Neighbor_Gateway_Algorithm: O valor do algoritmo usado pelo Sistema de Portal de vizinho para atribuir quadrados para IDs de conversação de gateway recebidos nesse IPP.
[0470] Valor: 4-octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse algoritmo seguido por dois octetos identificando esse algoritmo específico). Em outra modalidade, 5 octetos são usados.
[0471] DRF_Neighbor_Loop_Break_Link: Um Booleano indicando que o IPL ligado a esse IPP é identificado pelo Sistema de Portal de vizinho nesse IPP como um Link de quebra de loop.
[0472] Valor: booleano
[0473] DRF_Neighbor_Network/IPL_IPLEncap_Digest: O resumo último recebido de aDrniIPLEncapMap do Sistema de Portal de vizinho nesse IPP.
[0474] Valor: resumo MD5
[0475] DRF_Neighbor_Network/IPL_NetEncap_Digest: O resumo último recebido de aDrniNetEncapMap, para troca no link de rede comcompartilhamentodo do Sistema de Portal de vizinho nesse IPP.
[0476] Valor: resumo MD5
[0477] DRF_Neighbor_Network/IPL_Sharing_Method: O método de comcompartilhamentomento de IPL/rede último recebido usado do Sistema de Portal de vizinho nesse IPP.
[0478] Valor: 4-octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse método seguido por um octeto identificando esse método específico).
[0479] DRF_Neighbor_Oper_Aggregator_Key: o valor de Chave de Agregador operacional último recebido do Sistema de Portal de vizinho nesse IPP.
[0480] Valor: número inteiro
[0481] DRF_Neighbor_Oper_Partner_Aggregator_Key: O valor de Chave de Agregador de Partner operacional do Sistema de Portal de vizinho nesse IPP. Transmitido em DRCPDUs.
[0482] Valor: número inteiro
[0483] DRF_Neighbor_Oper_DRCP_State: O valor operacional da visão do Sistema de Portal dos valores atuais dos parâmetros de estado DRCP do Vizinho. A Função DR de casa define essa variável no valor recebido a partir do Sistema de Portal de vizinho em uma DRCPDU. O valor consiste no seguinte conjunto de variáveis, como descrito acima: • HomeGateway • NeighborGateway • OtherGateway • IPPActivity • Timeout • GatewaySync • PortSync • Expired
[0484] Valor: 8 bits
[0485] DRF_Neighbor_Conf_Portal_System_Number: O valor do Número de Sistema de portal da configuração do Sistema de Portal de vizinho para esse Sistema de Portal que foi recebido por último nesse IPP.
[0486] Valor: Um inteiro na faixa [1...3].
[0487] DRF_Neighbor_Port_Algorithm: O valor do algoritmo usado pelo Sistema de Portal de vizinho para atribuir quadros aos IDs de conversação de Porta recebidos nesse IPP.
[0488] Valor: 4-octetos (OUI de 3 octetos identificando a organização que é responsável por definir esse algoritmo seguido por dois octetos identificando esse algoritmo específico). Em outra modalidade, 5 octetos são usados.
[0489] DRF_Neighbor_Portal_System_Number: O identificador recebido por último do Sistema de Portal de vizinho nesse IPP.
[0490] Valor: Um inteiro na faixa [1...3].
[0491] DRF_Neighbor_Portal_Topology: O identificador recebido por último da Topologia de Portal do vizinho nesse IPP.
[0492] Valor: Um inteiro na faixa [0...3].
[0493] DRF_Neighbor_State: O estado operacional do Sistema de Portal de vizinho imediato nesse IPP.
[0494] Valor: sinalizador booleano indicando o estado operacional do Gateway do Sistema de Portal de Vizinho (TRUE indica operacional) e uma Lista (talvez vazia) dos IDs de Porta das Portas de agregação operacional nesse IPP.
[0495] Drni_Neighbor_ONN
[0496] O sinalizador OMN recebido por último do Sistema de Portal de vizinho nesse IPP carregado no campo de Estado de Topologia.
[0497] Valor: número inteiro
[0498] DRF_Other_Neighbor_Admin_Aggregator_Key: o valor de Chave de Agregador Administrativo do outro Sistema de Portal de vizinho associado a esse IPP. Transmitido em DRCPDUs.
[0499] Valor: número inteiro
[0500] DRF_Other_Neighbor_Oper_Partner_Aggregator_Key: O valor de Chave de agregador de partner operacional do outro Sistema de Portal de vizinho associado a esse IPP. Transmitido em DRCPDUs.
[0501] Valor: número inteiro
[0502] DRF_Other_Neighbor_State: O estado operacional do outro Sistema de Portal de vizinho nesse IPP.
[0503] Valor: sinalizador booleano indicando o estado operacional do Gateway do outro Sistema de Portal de vizinho (TRUE indica operacional) e uma Lista (talvez vazia) dos IDs de Porta das Portas de Agregação operacional nesse IPP.
[0504] Drni_Neighbor_Portal_Addr: O componente de endereço MAC recebido por último do ID do Sistema de Portal do Sistema de Portal de vizinho nesse IPP.
[0505] Valor: 48 bits
[0506] Drni_Neighbor_Portal_Priority: A Prioridade de sistema recebida por última do Sistema de Portal de vizinho nesse IPP.
[0507] Valor: número inteiro
[0508] Drni_Neighbor_PortalID: O componente de endereço MAC recebido por último do ID de Sistema de Portal do Sistema de Portal de vizinho nesse IPP.
[0509] Valor: 48 bits
[0510] Drni_Neighbor_State[]: O valor operacional recebido por último do Drni_Portal_System_State[] usado pelo Sistema de Portal vizinho nesse IPP.
[0511] Valor: Para cada Sistema de Portal, o sinalizador Booleano indicando o estado operacional do Gateway do Sistema de Portal atual (TRUE indica operacional) e uma Lista (talvez vazia) dos IDs de Porta das Portas de agregação operacional nesse Sistema de Portal como relatado pelo Sistema de Portal de vizinho nesse IPP.
[0512] Enabled_Time_Shared: Um Booleano indicando que o Sistema de Portal de casa e de vizinho nesse IPP são compativelmente configurados e os métodos de comcompartilhamentomento de Rede/IPL por tempo especificados aqui são habilitados.
[0513] Valor: booleano
[0514] Enabled_EncTag_Shared: Um Booleano indicando que o Sistema de Portal de casa e vizinho nesse IPP são compativelmente configurados para usar os métodos de manipulação de etiqueta de comcompartilhamentomento de IPL/rede por etiqueta ou comcompartilhamentomento de IPL/rede por encapsulamento, como determinado pelo método de IPL/rede, selecionado pelo aDrniEncapsulationMethod.
[0515] Valor: booleano
[0516] Ipp_Other_Gateway_Conversation: O vetor operacional listando qual Gateway do Sistema de Portal (se algum) está passando cada ID de conversação de gateway como relatado pelo Vizinho imediato nesse IPP.
[0517] Valor: sequência de Números de sistema de Portal (0 para nenhum), indexado por ID de conversação de Gateway. Valor computado a partir de aDrniConvAdminGateway[] e DRF_Neighbor_State[] após inicialização e sempre que o objeto gerenciado mudar ou GatewayConversationUpdate for FALSE.
[0518] Ipp_Other_Port_Conversation_Portal_System: O vetor operacional listando qual Sistema de Portal (se algum) está passando cada ID de conversação de Porta como relatado pelo Vizinho imediato nesse IPP.
[0519] Valor: sequência de Números de Sistema de portal (0 para nenhum) indexado por ID de conversação de Porta. Valor computado a partir de aAggConversationAdminPort[] e DRF_Neighbor_State[] após inicialização e sempre que o objeto gerenciado mudar ou PortConversationUpdate for FALSE.
[0520] IPP_port_enabled: Uma variável indicando que o link foi estabelecido e o IPP é operável.
[0521] Valor: booleano
[0522] TRUE se o IPP for operável (MAC_Operational == TRUE).
[0523] FALSE de outro modo.
[0524] NOTA — O meio pelo qual o valor da variável IPP_port_enabled é gerado pelo MAC subjacente é dependente de implementação.
[0525] Ipp_Portal_System_State[]: A lista dos estados dos Sistemas de Portal alcançáveis através desse IPP que foi recebido por último em uma DRCPDU a partir desse IPP. Essa variável é atualizada pela função updatePortalSystem.
[0526] Valor: Para cada Sistema de portal, o sinalizador booleano indicando o estado operacional do Gateway do Sistema de Portal atual alcançável através desse IPP (TRUE indica operacional) e uma Lista (talvez vazia) dos IDs de Porta das Portas de agregação operacionais naquele Sistema de Portal.
[0527] Nessa lista, o estado de Sistema de Portal imediatamente adjacente é o primeiro estado na lista. A lista pode ter no máximo dois estados do Sistema de Portal.
[0528] NTTDRCPDU: TRUE indica que há novas informações de protocolo que devem ser transmitidas nesse IPP, ou que o Sistema de Portal de vizinho necessita ser lembrado das informações antigas. FALSE é usado de outro modo.
[0529] ONN
[0530] Outro sinalizador não de vizinho. Esse valor é atualizado pela função updatePortalState e é aplicável somente em Portais consistindo em três Sistemas de Portal. Transmitido em DRCPDUs.
[0531] Valor: booleano
[0532] TRUE indica que o TLV de Informação de outras Portas não é associado a um Vizinho imediato desse Sistema de Portal. FALSE (codificado como 0) indica que o TLV de Informação de outras Portas é um vizinho imediato no outro IPP nesse Sistema de portal.
[0533] DRCP_current_while_timer
[0534] Esse temporizador é usado para detectar se informação de protocolo recebido expirou. Se DRF_Home_Oper_DRCP_State.DRCP_Timeout for definido em tempo de espera curto, o temporizador é iniciado com o valor Short_Timeout_Time. De outro modo, é iniciado com o valor Long_Timeout_Time.
[0535] DRCP_periodic_timer (time_value)
[0536] Esse temporizador é usado para gerar transmissões periódicas. É iniciado utilizando o valor Slow_Periodic_Time ou Fast_Periodic_Time, como especificado na máquina de estado de Transmissão periódica.
[0537] Constantes
[0538] Todos os temporizadores especificados nessa sub-cláusula têm uma tolerância de implementação de ± 250 ms.
[0539] Drni_Fast_Periodic_Time
[0540] O número de segundos entre transmissões periódicas usando tempos de espera curtos.
[0541] Valor: número inteiro
[0542] 1
[0543] Drni_Slow_Periodic_Time
[0544] O número de segundos entre transmissões periódicas usando Intervalos longos.
[0545] Valor: número inteiro
[0546] 30
[0547] Drni_Short_Timeout_Time
[0548] O número de segundos antes de invalidar informações de DRCPDU recebidas ao usar tempos de espera curtos (3 x Fast_Periodic_Time).
[0549] Valor: número inteiro
[0550] 3
[0551] Drni_Long_Timeout_Time
[0552] O número de segundos antes de invalidar informações de DRCPDU recebidas ao usar tempos de espera Longos (3 x Slow_Periodic_Time).
[0553] Valor: número inteiro
[0554] 90
[0555] Variáveis usadas para gerenciar a operação das máquinas de estado
[0556] A seguinte discussão foca em uma variedade de Variáveis usadas para gerenciar a operação das máquinas de estado de acordo com uma modalidade da invenção.
[0557] BEGIN: Essa variável indica a inicialização (ou reinicialização) da entidade de protocolo DRCP. É definida em TRUE quando o Sistema é inicializado ou reinicializado, e é definida em FALSE quando a (re-)inicialização foi concluída.
[0558] Valor: booleano
[0559] DRCP_Enabled
[0560] Essa variável indica que o IPP associado está operando o DRCP. Se o link não for um link de ponto a ponto, o valor de DRCP_Enabled será FALSE. De outro modo, o valor de DRCP_Enabled será TRUE.
[0561] Valor: booleano
[0562] GatewayConversationUpdate: Essa variável indica que as distribuições de ID de Conversação por Gateway necessitam ser atualizadas.
[0563] Valor: booleano
[0564] IppGatewayAllUpdate: Essa variável é o ou lógico das variáveis IppGatewayUpdate para todos os IPPs nesse Sistema de Portal.
[0565] Valor: booleano
[0566] IppGatewayUpdate: Essa variável indica que as distribuições de ID de conversação por Gateway no IPP associado necessitam ser atualizadas. Há uma variável IppGatewayUpdate por IPP nesse Sistema de Portal.
[0567] Valor: booleano
[0568] IppPortAllUpdate: Essa variável é o ou lógico das variáveis IppPortUpdate para todos os IPPs nesse Sistema de Portal.
[0569] Valor: booleano
[0570] IppPortUpdate: Essa variável indica que as distribuições de ID de conversação por Porta no IPP associado necessitam ser atualizadas. Há uma variável de IppPortUpdate por IPP nesse Sistema de Portal.
[0571] Valor: booleano
[0572] PortConversationUpdate: Essa variável indica que as distribuições de ID de Conversação por Porta necessitam ser atualizadas.
[0573] Valor: booleano
[0574] Funções
[0575] A seguinte discussão foca em uma variedade de funções de acordo com uma modalidade da invenção.
[0576] extractGatewayConversationI D
[0577] Essa função extrai um valor de ID de Conversação de Gateway por aplicar o Algoritmo de gateway aos valores dos parâmetros do primitivo de serviço que é invocado na entidade de Retransmissão de função DR no recebimento de um primitivo ISS em uma da porta da Função DR. A relação dos valores de parâmetro dos primitivos de ISS e os primitivos de serviço nas portas de entidade de Retransmissão da Função DR é fornecida pelas funções de suporte associadas naquelas portas e sua configuração.
[0578] NOTA— Essas funções de suporte podem ser tão simples quanto às funções de suporte EISS especificadas em 6.9 de IEEE Std 802.1Q-2011, para o caso de um DRNI suportado em uma Porta de rede de cliente ou uma Porta de Rede de provedor em uma Ponte de provedor (cláusula 15 em IEEE Std 802.1Q), ou mais complexas como as funções de suporte EISS especificadas em 6.10 ou 6.11 em IEEE Std 802.1Q-2011, para o caso de DRNI suportado em uma Porta de instância de Provedor ou uma Porta de Estrutura de cliente respectivamente em uma Ponte de Borda de estrutura (cláusula 16 em IEEE Std 802.1Q) ou como as funções de suporte de Interface de serviço etiquetado-C ou as funções de suporte de Interface de Serviço de cliente remoto especificado em 15.4 ou 15.6 em IEEE Std 802.1Q- 2013 para o caso de DRNI suportado em uma Porta de borda de cliente ou uma Porta de acesso remoto respectivamente em uma Ponte de borda de provedor.
[0579] Valor: número inteiro na faixa de 0 até 4095.
[0580] extractPortConversationlD
[0581] extractPortConversationID
[0582] Essa função extrai um valor de ID de conversação de porta por aplicar o Algoritmo de Porta aos valores dos parâmetros do primitivo de serviço que é invocado no Agregador no recebimento de um primitivo de ISS em uma da porta da outra Função DR. A relação dos valores de parâmetro nos primitivos de ISS no Agregador e os primitivos de serviço correspondentes na porta da Função DR é fornecida pela função de suporte associada no Agregador e a porta de Função DR e suas configurações. Verifique a NOTA acima.
[0583] .
[0584] Valor: número inteiro na faixa de 0 a 4095.
[0585] InitializeDRNIGatewayConversation
[0586] Essa função define a Drni_Portal_System_Gateway_Conversation em uma sequência de zeros, indexado por ID de conversação de Gateway.
[0587] InitializeDRNIPortConversation
[0588] Essa função define a Drni_Portal_System_Port_Conversation em uma sequência de zeros, indexado por ID de conversação de Porta.
[0589] InitializeIPPGatewayConversation
[0590] Essa função define a Ipp_Gateway_Conversation_Direction em uma sequência de zeros, indexado por ID de conversação de Gateway.
[0591] InitializeIPPPortConversation
[0592] Essa função define a Ipp_Port_Conversation_Passes em uma sequência de zeros, indexado por ID de conversação de Porta.
[0593] recordDefaultDRCPDU
[0594] Essa função define valores de parâmetro default para o Sistema de Portal de vizinho no IPP, fornecido pelo administrador, nos valores de parâmetro operacional do Sistema de Portal de vizinho atual como a seguir: • DRF_Neighbor_Port_Algorithm = DRF_Neighbor_Admin_Port_Algorithm; • DRF_Neighbor_Gateway_Algorithm = DRF_Neighbor_Admin_Gateway_Algorithm; • DRF_Neighbor_Conversation_PortList_Digest • = DRF_Neighbor_Admin_Conversation_PortList_Digest; • DRF_Neighbor_Conversation_GatewayList_Digest • = DRF_Neighbor_Admin_Conversation_GatewayList_Digest; • DRF_Neighbor_Oper_DRCP_State = DRF_Neighbor_Admin_DRCP_State; • DRF_Neighbor_Aggregator_Priority = aAggPortPartnerAdminSystemPriority; • DRF_Neighbor_Aggregator_ID = aAggPortPartnerAdminSystemID; • Drni_Neighbor_Portal_Priority = aAggPortPartnerAdminSystemPriority; • Drni_Neighbor_Portal_Addr = aAggPortPartnerAdminSystemID; • DRF_Neighbor_Portal_System_Number • = DRF_Home_Conf_Neighbor_Portal_System_Number; • DRF_Neighbor_Portal_Topology = Drni_Portal_Topology; • DRF_Neighbor_Loop_Break_Link = DRF_Home_Loop_Break_Link, e; • DRF_Neighbor_Conf_Portal_System_Number = DRF_Portal_System_Number.
[0595] Além do Sistema de Portal de vizinho no IPP: • The DRF_Neighbor_State é definido em NULL (o sinalizador booleano para o Gateway do Sistema de Portal de vizinho é definido em FALSE e a lista das Portas de agregação operacional no Sistema de Portal de vizinho nesse IPP é esvaziada) e se aDrniPortalTopology for configurado para conter três Sistemas de Portal, o DRF_Other_Neighbor_State também é definido em NULO (o sinalizador booleano para o Gateway do outro Sistema de Portal de vizinho é definido em FALSE e a lista das Portas de Agregação operacional no outro Sistema de Portal de vizinho nesse IPP é de controle). Nenhuma informação de estado de Sistema de Portal é disponível para qualquer Sistema de portal nesse IPP; • The DRF_Neighbor_Admin_Aggregator_Key nesse IPP é definido em zero; • The DRF_Other_Neighbor_Admin_Aggregator_Key nesse IPP é definido em zero; • The DRF_Neighbor_Oper_Partner_Aggregator_Key nesse IPP é definido em zero; • O DRF_Other_Neighbor_Oper_Partner_Aggregator_Key nesse IPP é definido em zero, e; • a variável ChangePortal é definida em TRUE.
[0596] Finalmente define CC_Time_Shared e CC_EncTag_Shared em FALSE.
[0597] recordNeighborState
[0598] Esta função registra os valores de parâmetro para o Drni_Portal_System_State[] e DRF_Home_Oper_DRCP_State carregados em uma DRCPDU recebida no IPP, como os valores de parâmetro atuais para Drni_Neighbor_State[] e DRF_Neighbor_Oper_DRCP_State associados a esse IPP respectivamente e define DRF_Neighbor_Oper_DRCP_State.IPP_Activity em TRUE.
[0599] Também registra as variáveis abaixo como a seguir: • Os valores de parâmetro para o Home_Gateway no DRF_Home_Oper_DRCP_State e o Active_Home_Ports no TLV de Informação de Portas de casa, carregado em uma DRCPDU recebida no IPP, são usados como os valores atuais para o DRF_Neighbor_State nesse IPP e associa essa informação de estado de Sistema de Portal nesse IPP ao Sistema de Portal identificado por DRF_Neighbor_Portal_System_Number; • Os valores de parâmetro para o Other_Gateway no DRF_Home_Oper_DRCP_State e o Other_Neighbor_Ports no TLV de Informação de outras Portas, carregado em uma DRCPDU recebida no IPP, são usados como os valores atuais para o DRF_Other_Neighbor_State nesse IPP e associa essa informação de estado de Sistema de Portal identificado pelo valor atribuído aos dois bits mais significativos do DRF_Other_Neighbor_Admin_Aggregator_Key carregado no TLV de Informação de Outras portas na DRCPDU recebida. Se nenhum outro TLV de Informação de outras Portas for carregado na DRCPDU recebida e a Topologia de Portal contiver três Sistemas de Portal, o DRF_Other_Neighbor_State é definido em NULO (Other_Gateway é definido em FALSE e a lista das Portas de Agregação operacional no outro Sistema de Portal vizinho nesse IPP é esvaziado) e nenhuma informação de estado de Sistema de Portal é disponível nesse IPP para o Sistema de Portal vizinho distante no IPP; • DRF_Neighbor_Admin_Aggregator_Key = DRF_Home_Admin_Aggregator_Key; • DRF_Neighbor_Oper_Partner_Aggregator_Key = DRF_Home_Oper_Partner_Aggregator_Key; • DRF_Other_Neighbor_Admin_Aggregator_Key = DRF_Other_Neighbor_Admin_Aggregator_Key, e; • DRF_Other_Neighbor_Oper_Partner_Aggregator_Key N= DRF_Other_Neighbor_Oper_Partner_Aggregator_Key. • Tanto DRF_Other_Neighbor_Admin_Aggregator_Key como DRF_Other_Neighbor_Oper_Partner_Aggregator_Key são definidos em MULO quando a DRCPDU recebida não contiver o TLV de Informação de outras portas.
[0600] Além disso, se comcompartilhamentomento de Rede/IPL por tempo for suportada, a função registra o valor de parâmetro para o DRF_Home_Network/IPL_Sharing_Method carregado no TLV de Método de comcompartilhamentomento de Rede/IPL recebido como o valor de parâmetro atual para o DRF_Neighbor_Network/IPL_Sharing_Method e se esse for igual ao DRF_Home_Network/IPL_Sharing_Method do sistema, define CC_Time_Shared em TRUE, de outro modo define CC_Time_Shared em FALSE.
[0601] Adicionalmente, se comcompartilhamentomento de Rede/IPL por etiqueta ou Comcompartilhamentomento de Rede/IPL por encapsulamento for suportado, a função registra os valores de parâmetro relacionado de comcompartilhamentomento de Rede/IPL do Sistema de Portal de vizinho carregados nos TLVs de comcompartilhamentomento de Rede/IPL recebidos a partir de um IPP, como os valores de parâmetro operacional atual para o Sistema de Portal de vizinho imediato nesse IPP como a seguir:
[0602] DRF_Neighbor_Network/IPL_Sharing_Method = DRF_Home_Network/IPL_Sharing_Method, carregado no TLV de Método comcompartilhamentomento de Rede/IPL recebido;
[0603] DRF_Neighbor_Network/IPL_IPLEncap_Digest = DRF_Home_Network/IPL_IPLEncap_Digest, carregado no TLV de encapsulamento de comcompartilhamentomento de Rede/IPL recebido; e
[0604] DRF_Neighbor_Network/IPL_NetEncap_Digest = DRF_Home_Network/IPL_NetEncap_Digest carregado no TLV de encapsulamento de comcompartilhamentomento de Rede/IPL recebido.
[0605] Compara, então, os valores recentemente atualizados do Sistema de Portal de vizinho com as expectativas desse Sistema de Portal e se
[0606] DRF_Neighbor_Network/IPL_Sharing_Method == DRF_Home_Network/IPL_Sharing_Method, e
[0607] DRF_Neighbor_Network/IPL_IPLEncap_Digest == DRF_Home_Network/IPL_IPLEncap_Digest, e
[0608] DRF_Neighbor_Network/IPL_NetEncap_Digest == DRF_Home_Network/IPL_NetEncap_Digest, então
[0609] define CC_EncTag_Shared em TRUE;
[0610] de outro modo se uma ou mais das comparações mostrar que os valores diferem,
[0611] define CC_EncTag_Shared em FALSE.
[0612] Compara então o estado operacional de Gateway para cada Sistema de portal como relatado pelo Drni_Portal_System_State[] desse Sistema de Portal com o estado operacional de Gateway para o mesmo Sistema de Portal como relatado pelo Drni_Neighbor_State[] e se qualquer um desses diferir define GatewayConversationUpdate em TRUE e DRF_Home_Oper_DRCP_State.Gateway_Sync em FALSE, de outro modo GatewayConversationUpdate permanece inalterado e DRF_Home_Oper_DRCP_State.Gateway_Sync é definido em TRUE.
[0613] Compara também a lista dos IDs de Porta das Portas de Agregação operacional para cada Sistema de Portal como relatado pelo Drni_Portal_System_State[] desse Sistema de portal para a lista dos IDs de Porta das Portas de agregação operacional para os mesmos Sistemas de Portal como relatado pelo Drni_Neighbor_State[] e se algum desses diferir define PortConversationUpdate em TRUE e DRF_Home_Oper_DRCP_State.Port_Sync em FALSE, de outro modo PortConversationUpdate permanece inalterado e DRF_Home_Oper_DRCP_State.Port_Sync é definido em TRUE.
[0614] recordPortalConfValues
[0615] Esta função registra os valores de parâmetro configurados do Sistema de Portal de vizinho carregados em uma DRCPDU recebida a partir de um IPP, como os valores de parâmetro operacional atuais para o Sistema de Portal de vizinho imediato nesse IPP como a seguir:
[0616] DRF_Neighbor_Portal_System_Number = DRF_Portal_System_Number;
[0617] DRF_Neighbor_Portal_Topology = Drni_Portal_Topology;
[0618] DRF_Neighbor_Conf_Portal_System_Number = DRF_Home_Conf_Neighbor_Portal_System_Number;
[0619] DRF_Neighbor_Loop_Break_Link = DRF_Home_Loop_Break_Link;
[0620] DRF_Neighbor_Oper_Aggregator_Key = DRF_Home_Oper_Aggregator_Key;
[0621] DRF_Neighbor_Port_Algorithm = DRF_Home_Port_Algorithm;
[0622] DRF_Neighbor_Conversation_PortList_Digest = DRF_Home_Conversation_PortList_Digest;
[0623] DRF_Neighbor_Gateway_Algorithm = DRF_Home_Gateway_Algorithm; e
[0624] DRF_Neighbor_Conversation_GatewayList_Digest = DRF_Home_Conversation_GatewayList_Digest.
[0625] Compara então os valores recentemente atualizados do Sistema de Portal de vizinho com as expectativas desse Sistema de portal e se
[0626] DRF_Neighbor_Portal_System_Number == DRF_Home_Conf_Neighbor_Portal_System_Number, and
[0627] DRF_Neighbor_Portal_Topology == Drni_Portal_Topology, e
[0628] DRF_Neighbor_Loop_Break_Link == DRF_Home_Loop_Break_Link, e
[0629] DRF_Neighbor_Conf_Portal_System_Number == DRF_Portal_System_Number, e
[0630] DRF_Neighbor_Oper_Aggregator_Key == DRF_Home_Oper_Aggregator_Key, e
[0631] DRF_Neighbor_Port_Algorithm == DRF_Home_Port_Algorithm, e
[0632] DRF_Neighbor_Conversation_PortList_Digest == DRF_Home_Conversation_PortList_Digest, e
[0633] DRF_Neighbor_Gateway_Algorithm == DRF_Home_Gateway_Algorithm, e
[0634] DRF_Neighbor_Conversation_GatewayList_Digest == DRF_Home_Conversation_GatewayList_Digest então,
[0635] A variável Differ_Conf_Portal é definida em FALSE;
[0636] De outro modo se uma ou mais das comparações mostrar que os valores diferem,
[0637] a variável Differ_Conf_Portal é definida em TRUE e os pares associados de variáveis tendo os valores diferentes são disponíveis em aDrniIPPDebugDifferPortalReason.
[0638] recordPortalValues
[0639] Esta função registra os valores de parâmetro para o Drni_Aggregator_Priority, Drni_Aggregator_ID, Drni_Portal_Priority, e Drni_PortalID, carregado em uma DRCPDU recebida de um IPP, como os valores de parâmetro operacional atual para o Sistema de Portal de vizinho imediato nesse IPP, como a seguir:
[0640] DRF_Neighbor_Aggregator_Priority = Drni_Aggregator_Priority;
[0641] DRF_Neighbor_Aggregator_ID = Drni_Aggregator_ID;
[0642] Drni_Neighbor_Portal_Priority = Drni_Portal_Priority, e;
[0643] Drni_Neighbor_Portal_Addr = Drni_Portal_Addr.
[0644] Compara então os valores recentemente atualizados do Sistema de Portal de vizinho com as expectativas desse Sistema de Portal e se
[0645] DRF_Neighbor_Aggregator_Priority == Drni_Aggregator_Priority e
[0646] DRF_Neighbor_Aggregator_ID == Drni_Aggregator_ID e
[0647] Drni_Neighbor_Portal_Priority == Drni_Portal_Priority e
[0648] Drni_Neighbor_Portal_Addr == Drni_Portal_Addr então,
[0649] a variável Differ_Portal é definida em FALSE;
[0650] De outro modo se uma ou mais das comparações mostrar que os valores diferem,
[0651] a variável Differ_Portal é definida em TRUE e o conjunto associado de variáveis tendo os valores diferentes é disponível em aDrniIPPDebugDifferPortalReason.
[0652] reportToManagement
[0653] Esta função alerta o Sistema de Gerenciamento da existência em potencial de um erro de configuração de Sistema de Portal devido ao recebimento de uma DRCPDU configurada erroneamente e envia para o mesmo as informações conflitantes a partir da DRCPDU recebida configurada erroneamente.
[0654] setDefaultPortalSystemParameters
[0655] Esta função define as variáveis desse Sistema de Portal em valores definidos administrativos como a seguir: • Drni_Aggregator_Priority = aAggActorSystemPriority; • Drni_Aggregator_ID = aAggActorSystemID; • Drni_Portal_Priority = aDrniPortalPriority; • Drni_Portal_Addr = aDrniPortalAddr; • DRF_Portal_System_Number = aDrniPortalSystemNumber; • DRF_Home_Admin_Aggregator_Key = aAggActorAdminKey; • DRF_Home_Port_Algorithm = aAggPortAlgorithm; • DRF_Home_Gateway_Algorithm = aDrniGatewayAlgorithm; • DRF_Home_Conversation_PortList_Digest = o resumo MD5 em aDrniConvAdminGateway[]; • DRF_Home_Conversation_GatewayList_Digest = o resumo MD5 em aAggConversationAdminPort[], e; • DRF_Home_Oper_DRCP_State = DRF_Neighbor_Admin_DRCP_State.
[0656] Além disso, define o Drni_Portal_System_State[] como se todos os Gateways no Portal fossem relatados como FALSE e nenhuma Porta de agregação em qualquer Sistema de Portal é relatada como operacional.
[0657] setGatewayConversation
[0658] Esta função define Drni_Gateway_Conversation nos valores computados a partir de aDrniConvAdminGateway[] e Drni_Portal_System_State[] atual como a seguir:
[0659] Para todo ID de conversação de Gateway indexado, um Número de sistema de Portal é identificado por escolher o Número de sistema de portal de prioridade mais elevada na lista de Números de sistema de Portal fornecidos por aDrniConvAdminGateway[] quando somente os Gateways operacionais, como fornecidos pelos sinalizadores Booleanos de Gateway da variável Drni_Portal_System_State[], são incluídos.
[0660] setIPPGatewayConversation
[0661] Esta função define Ipp_Other_Gateway_Conversation nos valores computados a partir de aDrniConvAdminGateway[] e Drni_Neighbor_State[] como a seguir:
[0662] Para todo ID de conversação de Gateway indexado, um Número de sistema de portal é identificado por escolher o Número de sistema de portal de prioridade mais elevada na lista de Números de sistema de portal fornecida por aDrniConvAdminGateway[] quando somente os Gateways operacionais, como fornecidos pelos sinalizadores booleanos de Gateway da variável Drni_Neighbor_State[] variável, são incluídos.
[0663] setIPPGatewayUpdate
[0664] Essa função define um IppGatewayUpdate em todo IPP nesse Sistema de Portal como TRUE.
[0665] setIPPPortConversation
[0666] Esta função define Ipp_Other_Port_Conversation_Portal_System nos valores computados a partir de aAggConversationAdminPort[] e Drni_Neighbor_State[] como a seguir:
[0667] Para todo ID de conversação de Porta indexado, um Número de sistema de portal é identificado por escolher o Número de sistema de portal de prioridade mais elevada na lista de Números de sistemas de portal fornecidos por aAggConversationAdminPort[] quando somente as Portas de agregação operacional, como fornecido pelas Listas associadas da variável Drni_Neighbor_State[], são incluídas.
[0668] setIPPPortUpdate
[0669] Essa função define um IppPortUpdate em todo IPP nesse sistema de portal em TRUE.
[0670] setPortConversation
[0671] Esta função define Drni_Port_Conversation nos valores computados a partir de aAggConversationAdminPort[] e Drni_Portal_System_State[] atual como a seguir:
[0672] Para todo ID de conversação de Porta indexado, um Número de sistema de portal é identificado por extrair os dois bits menos significativos do componente de prioridade do ID de Porta de prioridade mais elevada (6.3.4) na lista de IDs de Porta fornecida por aAggConversationAdminPort[] quando somente as Portas de Agregação operacional, como fornecido pelas Listas associadas da variável Drni_Portal_System_State[], são incluídas.
[0673] updateDRFHomeState
[0674] Esta função atualiza o DRF_Home_State com base no estado operacional das portas locais como a seguir:
[0675] O Gateway é definido em TRUE ou FALSE com base em mecanismos que são usados para identificar o estado operacional do Gateway local (TRUE indica operável e conectividade não está bloqueada pela operação do protocolo de controle de rede);
[0676] A lista de Portas de agregação operacional é criada por incluir somente aqueles IDs de Porta de agregação para os quais o Agregador ligado reporta os mesmos como tendo Actor_Oper_Port_State.Distributing == TRUE (condição que exclui os casos onde as Portas de agregação associadas são não operáveis (port_enabled = FALSE), em um estado EXPIRADO, ou não no LAG), e o PSI é definido em TRUE se DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE em todos os IPPS nesse Sistema de Portal, de outro modo PSI é definido em FALSE.
[0677] Além disso, se PSI == TRUE e Gateway == FALSE então Actor_Oper_Port_State.Sync é definido em FALSE em todas as Portas de agregação nesse Sistema de Portal.
[0678] A função também define:
[0679] GatewayConversationUpdate em TRUE se o estado operacional de Gateway ou as listas configuradas para Drni_Conversation_GatewayList[] mudaram e define PortConversationUpdate em TRUE se houve qualquer alteração na lista das Portas de agregação operacional como relatado por alterações nas variáveis Actor_Oper_Port_State.Distributing associadas ou nas listas configuradas para o Drni_Conversation_PortList[], de outro modo;
[0680] GatewayConversationUpdate e PortConversationUpdate permanecem inalterados.
[0681] update I PPGatewayConversationDirection
[0682] Esta função computa um valor para Ipp_Gateway_Conversation_Direction como a seguir:
[0683] Para cada ID de conversação de Gateway, o valor é TRUE se e somente se: a) as variáveis Drni_Gateway_Conversation e Ipp_Portal_System_State[] indicarem que o Sistema de Portal alvo para esse ID de conversação de Gateway situar-se atrás desse IPP, e b) Drni_Gateway_Conversation e Ipp_Other_Gateway_Conversation estão em acordo com relação a qual Sistema de portal deve obter esse ID de conversação de Gateway.
[0684] Além disso, se Drni_Gateway_Conversation e Ipp_Other_Gateway_Conversation estiverem em desacordo para qualquer ID de conversação de Gateway:
[0685] define DRF_Home_Oper_DRCP_State.Gateway_Sync em FALSE, e;
[0686] NTTDRCPDU em TRUE.
[0687] De outro modo:
[0688] DRF_Home_Oper_DRCP_State.Gateway_Sync e NTTDRCPDU são deixados inalterados.
[0689] Ipp_Gateway_Conversation_Direction é inicializado em FALSE e recomputado sempre que quaisquer de suas variáveis de contribuição mudar.
[0690] updateIPPPortConversationPasses
[0691] Esta função computa um valor para Ipp_Port_Conversation_Passes como a seguir:
[0692] Para cada ID de conversação de Porta, o valor é TRUE (ID passa) se e somente se: a) as variáveis Drni_Port_Conversation e Ipp_Portal_System_State[] indicarem que o Sistema de Portal alvo para esse ID de conversação de Porta situar-se atrás desse IPP, e b) Drni_Port_Conversation e Ipp_Other_Port_Conversation_Portal_System estão em acordo com relação a qual Sistema de Portal deve obter esse ID de conversação de Porta.
[0693] Além disso, se Drni_Port_Conversation e Ipp_Other_Port_Conversation_Portal_System estiverem em desacordo para qualquer ID de conversação de Porta:
[0694] define DRF_Home_Oper_DRCP_State.Port_Sync em FALSE, e;
[0695] NTTDRCPDU em TRUE.
[0696] De outro modo:
[0697] DRF_Home_Oper_DRCP_State.Port_Sync e NTTDRCPDU são deixados inalterados.
[0698] Ipp_Port_Conversation_Passes é inicializado em FALSE e recomputado sempre que qualquer de suas variáveis de contribuição mudar.
[0699] updateKey
[0700] Esta função atualiza a Chave de agregador operacional, DRF_Home_Oper_Aggregator_Key, como a seguir:
[0701] se enable_long_pdu_xmit == TRUE então:
[0702] DRF_Home_Oper_Aggregator_Key é definido no valor de DRF_Home_Admin_Aggregator_Key por substituir seus dois bits mais significativos pelo valor 01; de outro modo DRF_Home_Oper_Aggregator_Key é definido no valor não zero numérico do conjunto compreendendo os valores do DRF_Home_Admin_Aggregator_Key, o DRF_Neighbor_Admin_Aggregator_Key e o DRF_Other_Neighbor_Admin_Aggregator_Key, em cada IPP.
[0703] updateNTT
[0704] Esta função define NTT em TRUE se qualquer do DRF_Home_Oper_DRCP_State.GatewaySync, ou DRF_Home_Oper_DRCP_State.PortSync, ou DRF_Neighbor_Oper_DRCP_State.GatewaySync, ou DRF_Neighbor_Oper_DRCP_State.PortSync for FALSE.
[0705] updatePortalState
[0706] Em todas as operações associadas a esta função, informações fornecidas pelo DRF_Other_Neighbor_State em um IPP são consideradas somente se Drni_Neighbor_ONN no mesmo IPP for FALSE;
[0707] Esta função atualiza o Drni_Portal_System_State[] como a seguir: A informação para esse Sistema de portal, DRF_Home_State, indexado pelo Número de sistema de portal, é incluída em Drni_Portal_System_State[]. Para cada dos outros Sistemas de Portal no Portal, se qualquer da outra Informação de estado de Sistema de Portal for disponível a partir de dois IPPs nesse Sistema de portal, então:
[0708] Para aquele Sistema de portal, somente a Informação de estado de Sistema de Portal fornecida pelo DRF_Neighbor_State no IPP tendo o outro Sistema de portal como um Sistema de portal de vizinho, indexado pelo Número de sistema de portal, será incluído no Drni_Portal_System_State[].
[0709] De outro modo se a Informação de estado de Sistema de Portal for disponível somente a partir de um IPP único nesse Sistema de portal, então:
[0710] A Informação de estado daquele Sistema de Portal, indexado pelo Número de sistema de portal associado será incluída no Drni_Portal_System_State[] independentemente de se aquela informação está sendo fornecida pelo DRF_Neighbor_State ou DRF_Other_Neighbor_State nesse IPP. Se a informação for um Sistema de portal for disponível somente a partir do DRF_Other_Neighbor_State nesse IPP então ONN é definido em TRUE nesse IPP.
[0711] Todo Sistema de portal incluído na Topologia de Portal para a qual Informação de estado de Sistema de Portal não está disponível a partir de qualquer dos IPPs, tem sua Informação de estado de Sistema de Portal associada Drni_Portal_System_State[] definida em NULO (o Gateway é definido em FALSE e a lista das Portas de agregação operacional no Sistema de portal é esvaziada).
[0712] Esta função atualiza também o Ipp_Portal_System_State[] para cada IPP nesse Sistema de portal como a seguir:
[0713] Se qualquer outra Informação de estado de Sistema de Portal for disponível a partir de dois IPPs, então:
[0714] Se o Sistema de portal de casa que não tem nenhum IPL configurado como um Link de quebra de loop, então, para todo IPP no Sistema de portal, somente a Informação de estado de Sistema de Portal fornecida pelo DRF_Neighbor_State naquele IPP será incluída no Ipp_Portal_System_State[] associado, indexado pelo Número de sistema de portal associado de outro modo;
[0715] o DRF_Neighbor_State em um IPP, indexado pelo Número de sistema de portal associado, será incluído como um primeiro estado no Ipp_Portal_System_State[] correspondente e qualquer outro estado adicional associado a outro Sistema de portal relatado na DRCPDU recebida nesse IPP, indexado pelo Número de sistema de portal associado, será incluído como o segundo estado no Ipp_Portal_System_State[] somente se Drni_Neighbor_ONN no mesmo IPP for FALSE
[0716] [Similarmente ao Drni_Portal_System_State[], todo Sistema de portal incluído na Topologia de Portal para o qual Informação de estado de Sistema de Portal não está disponível a partir de qualquer dos IPPs, tem sua Informação de estado de Sistema de Portal associada Ipp_Portal_System_State[] definida em NULO (o Gateway é definido em FALSE e a lista das Portas de agregação operacional no Sistema de portal é esvaziada).]
[0717] updatePortalSystemGatewayConversation
[0718] Esta função define o Drni_Portal_System_Gateway_Conversation para o resultado de lógica e operação entre o vetor Booleano construído a partir do Drni_Gateway_Conversation, por definir em FALSE todas as entradas de ID de Conversação de Gateway indexadas que são associadas aos outros Sistemas de Portal no Portal, e o vetor Booleano construído a partir de todos os IPPs Ipp_Other_Gateway_Conversation, por definir em FALSE todas as entradas de ID de conversação de Gateway indexadas que são associadas aos outros Sistemas de Portal no Portal.
[0719] updatePortalSystemPortConversation
[0720] Esta função define o Drni_Portal_System_Port_Conversation para o resultado da lógica e operação entre o vetor Booleano construído a partir do Drni_Port_Conversation, por definir em FALSE todas as entradas de ID de Conversação de Porta indexadas que são associadas a outros Sistemas de Portal no Portal, e o vetor Booleano construído a partir do Ipp_Other_Port_Conversation_Portal_System, por definir em FALSE todas as entradas de ID de Conversação de Porta indexadas que são associadas aos outros Sistemas de Portal no Portal.
[0721] Temporizadores
[0722] A seguinte discussão foca em uma variedade de temporizadores aplicáveis de acordo com uma modalidade da invenção.
[0723] current_while_timer: Esse temporizador é usado para detectar se informação de protocolo recebida expirou. Se Actor_Oper_State.LACP_Timeout for definida em tempo de espera curto, o temporizador é iniciado com o valor Short_Timeout_Time. De outro modo, é iniciado com o valor Long_Timeout_Time.
[0724] periodic_timer (time_value): Esse temporizador é usado para gerar transmissões periódicas. É iniciado utilizando o valor Slow_Periodic_Time ou Fast_Periodic_Time, como especificado na máquina de estado de Transmissão periódica.
[0725] wait_while_timer: Esse temporizador fornece histerese antes de executar uma alteração de agregação, para permitir que todos os links que unirão ao Grupo de agregação de link façam isso. É iniciado utilizando o valor Aggregate_Wait_Time.
[0726] Mensagens
[0727] Em uma modalidade, somente uma mensagem é utilizada:
[0728] IppM:M_UNITDATA.indication(DRCPDU): essa mensagem é gerada pelo Analisador de Controle de DRCP como resultado do recebimento de uma DRCPDU.
[0729] DRCPCtrlMuxN:M_UNITDATA.indication(DRCPDU)
[0730] Essa mensagem é gerada pelo Multiplexor/Analisador de Controle de DRCP como um resultado do recebimento de uma DRCPDU.
[0731] Nota: as duas mensagens são mensagens similares para duas modalidades diferentes.
[0732] Operações de máquina de estado
[0733] Voltando para a operação do processo de máquina de estado geral, o fluxograma da figura 7 define um conjunto de operações que se baseiam, em uma modalidade, nas funções, variáveis e mensagens descritas acima. O processo pode ser iniciado em resposta ao recebimento de uma DRCPDU. Essa DRCPDU é incialmente passada para a unidade de recebimento (bloco 702). O conjunto de setas rotulado Informação de Estado de vizinho representa novas informações de Vizinho, contidas em uma DRCPDU de entrada ou fornecidas por valores default administrativos, sendo alimentados para cada máquina de estado pela Máquina de recebimento de DRCPDU. O conjunto de setas rotulado Informações de Estado de casa representa o fluxo de informações de estado de Casa atualizadas entre as máquinas de estado. A transmissão de DRCPDUs ocorre como resultado da máquina Periódica determinando a necessidade de transmitir uma DRCPDU periódica, ou como resultado de alterações nas informações de estado de Casa que necessitam ser comunicadas aos Vizinhos. A necessidade de transmitir uma DRCPDU é sinalizada para a máquina de Transmissão por confirmar NTTDRCPDU. As setas restantes representam variáveis comcompartilhamentodas na descrição de máquina de estado que permitem que uma máquina de estado faça com que eventos ocorram em outra máquina de estado.
[0734] A máquina de recebimento gera uma NTTDRCPDU, executa uma operação de alteração de porta, atualização de conversação de gateway e atualização de conversação de porta.
[0735] A máquina periódica 704 recebe a informação de estado de vizinho e retorna informação de estado de casa. A máquina periódica (bloco 704) gera uma NTTDRCPDU.
[0736] A Máquina de sistema de portal (bloco 706) é responsável por atualizar o status operacional de todos os Gateways e Portas de agregação no Portal com base em informação local e DRCPDUs recebidas nos IPPs do Sistema de portal de casa. Essa máquina de estado é de acordo com Sistema de portal.
[0737] As máquinas de Agregador e Gateway DRNI (708) são responsáveis por configurar os IDs de conversação de gateway que são permitidos passar através do Gateway dessa função DR e os IDs de conversação de porta que são permitidos ser distribuídos através do Agregador dessa Função DR. Essas máquinas de estado são de acordo com o Sistema de portal.
[0738] As máquinas de IPP DRNI (710) são responsáveis por configurar os IDs de conversação de gateway e os IDs de conversação de Porta que são permitidos passar através dos IPPs dessa Função DR.
[0739] A máquina de transmissão (712) trata da transmissão de DRCPDUs, tanto em demanda a partir das outras máquinas de estado como em uma base periódica.
[0740] Máquina de recebimento de DRCPDU
[0741] A máquina de recebimento pode implementar a função especificada na figura 8 com seus parâmetros associados como discutido acima. O processo pode ser inicializado bloco 802 quando a funcionalidade é habilitada e o recordDefaultDRCPDU() é executado e onde o DRF_Neighbor_Oper_DRCP_State.IPP_Activity é falso. Um estado expirado (bloco 804) é então entrado e no recebimento de uma a DRCPDU, a máquina de estado entra no estado PORTAL_CHECK (bloco 808). A função recordPortalValues verifica se a DRCPDU é associada a esse Portal. Em caso negativo, o evento é relatado para o sistema de gerenciamento e nenhum processamento adicional da DRCPDU é feito por quaisquer máquinas de estado desse Portal. Se o recordPortalValues identificar a DRCPDU recebida entrará no estado COMPATIBILITY CHECK (Bloco 809) para ser verificado pela função recordPortalConfValues. Isso compara os valores administrativamente configurados que são associados a esse portal om a informação recebida e se diferirem o sistema entrará no estado REPORT_TO_MANAGEMENT (Bloco 810) e a DRCPDU configurada erroneamente será relatada para o sistema de gerenciamento. A máquina de recebimento sai do estado REPORT_TO_MANAGEMENT quando uma nova DRCPDU é recebida (ou a IPP é desabilitada).
[0742] Se a DRCPDU recebida for configurada de acordo com os valores esperados para esse Portal a máquina recebida entrará o estado CURRENT (Bloco 812).
[0743] As modalidades podem desse modo compreender as etapas de: receber uma DRCPDU; verificar se a DRCPDU recebida é associada ao portal; comparar valores configurados associados ao portal com valores da DRCPDU recebida; e enviar um relatório no caso dos valores comparados diferirem.
[0744] Em uma modalidade, no recebimento de uma DRCPDU, a máquina de estado entra no estado PORTAL_CHECK. A função recordPortalValues verifica se a DRCPDU é associada a esse Portal. Em caso negativo, a máquina de estado entrará o estado REPORT_TO_MANAGEMENT e a DRCPDU recebida será reportada ao sistema de gerenciamento. Enquanto no estado REPORT_TO_MANAGEMENT, o Sistema sairá para o estado PORTAL_CHECK se uma nova DRCPDU for recebida ou para o estado EXPIRADO se o DRCP_current_while_timer expirar. Se o recordPortalValues identificar a DRCPDU recebida como associada a esse Portal, entrará o estado COMPATIBILITY_CHECK para ser verificado pela função recordPortalConfValues. Isso compara os valores administrativamente configurados que são associados a esse portal com as informações recebidas e se diferirem o Sistema entrará o estado REPORT_TO_MANAGEMENT e a DRCPDU configurada erroneamente será reportada ao sistema de gerenciamento. Se o Sistema de portal continuar a receber DRCPDUs que não casam com as expectativas administrativamente configuradas por um período mais longo que duas vezes o tempo de espera Curto a máquina de estado fará transição para o estado DEFAULTED e os parâmetros operacionais atuais para o(s) Sistema(s) de portal nesse IPP serão sobrescritos com valores administrativamente configurados e uma atualização do Sistema de portal será acionada.
[0745] Se a DRCPDU recebida for configurada de acordo com os valores esperados para esse Portal a máquina de Recebimento de DRCPDU entra no estado CURRENT.
[0746] A função recordNeighborState registra a informação de Estado de Portal de vizinho contida na DRCPDU nas variáveis operacionais do Estado de Portal de vizinho e atualiza sua própria variável de estado de Portal de casa. Se diferirem, acionamentos são definidos para notificar o Vizinho, porém também variáveis de evento local são atualizações de acionamento definidas na máquina de Sistema de Portal local (PS - vide a figura 10), a máquina de Agregador e Gateway de DRNI (DGA - vide a figura 11) e a máquina de IPP DRNI (IPP - vide a figura 12).
[0747] No processo de executar as funções de recordPortalValues, recordPortalConfValues, e recordNeighborState, uma máquina de Recebimento em conformidade com esse relatório descritivo pode não validar o Número de versão, TLV_type, ou campos Reservados em DRCPDUs recebidas. As mesmas ações são tomadas independentes dos valores recebidos nesses campos. Uma máquina de recebimento pode avaliar os campos Portal_Information_Length, Portal_Configuration_Information_Length, DRCP_State_Length, ou Terminator_Length. Esses comportamentos, juntamente com a limitação em aperfeiçoamentos de protocolo futuros, são discutidos acima.
[0748] As regras expressas acima permitem que Dispositivos de versão 1 sejam compatíveis com revisões futuros do protocolo.
[0749] A função updateNTT é usada para determinar se transmissões de protocolo adicionais são necessárias; NTTDRCPU é definida em TRUE se a visão do Vizinho da variável de Estado de Portal operacional de casa não for atualizada. Então o temporizador current_while é iniciado. O valor usado para iniciar o temporizador é Short_Timeout_Time ou Long_Timeout_Time, dependendo do valor operacional de tempo de espera do Ator.
[0750] Se nenhuma DRCPDU for recebida antes que o temporizador current_while expire, a máquina de estado transita para o estado EXPIRED. O DRF_Neighbor_Oper_DRCP_State.IPP_Activity é definido em FALSE, o valor operacional atual da variável de tempo de espera de vizinho é definido em Short tempo de espera, e o temporizador current_while é iniciado com um valor de Short_Timeout_Time. Esse é um estado transiente; as definições de tempo de espera permitem que o Sistema de Portal de casa transmita DRCPDUs rapidamente em uma tentativa para restabelecer comunicação com o Vizinho.
[0751] Se nenhuma DRCPDU for recebida antes que o temporizador current_while timer expire novamente, a máquina de estado transita para o estado DEFAULTED. A função recordDefaultDRCPDU sobrescreve os parâmetros operacionais atuais para os Sistemas de Portal de vizinho com valores administrativamente configurados e aciona uma atualização de Sistema de portal e a condição é reportada para o sistema de gerenciamento.
[0752] Se o IPP tornar-se inoperável, a máquina de estado entra o estado INITIALIZE. DRF_Neighbor_Oper_DRCP_State.IPP_Activity é definido em FALSE a função recordDefaultDRCPDU faz com que os valores administrativos dos parâmetros de Partner sejam usados como os valores operacionais atuais. Essas ações forçam a máquina PS a desprender os Sistemas de portal de vizinho a partir do Portal e os filtros de ID de conversação de Porta e Gateway sejam recomputados.
[0753] A máquina de recebimento também pode implementar a função especificada na figura 16 com seus parâmetros associados. A máquina d recebimento na figura 16 segue alguns percursos de fluxo diferentes em comparação com a figura 8. Os termos e funções da máquina de recebimento alternativa na figura 16 são análogos àqueles da figura 8. Uma pessoa versada na técnica entenderia que outras implementações são possíveis compatíveis com os princípios e estruturas das máquinas de recebimento ilustradas.
[0754] A Figura 33 ilustra um método para sincronizar com um vizinho em um nó de um grupo de agregação de link de DRNI de acordo com uma modalidade da invenção. O método 3300 pode ser implementado em um nó DRCP (por exemplo, um dispositivo de rede) de um portal DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C. Observe que etapas opcionais são indicadas como um quadrado pontilhado como ilustrado na figura 33.
[0755] Na referência 3302, o nó é inicializado para operar DRCP em um IPP acoplado a um nó vizinho utilizando um IPL. O nó e o nó vizinho são incluídos em um portal, que pode conter um nó vizinho adicional em uma modalidade. O nó é acoplado ao nó vizinho através do IPP utilizando o IPL. Em uma modalidade, a inicialização compreende definir valores de parâmetro default para o nó vizinho no IPP para ser os parâmetros operacionais atuais do nó vizinho fornecido por um administrador do portal. Os parâmetros incluem algoritmo de porta como DRF_Neighbor_Port_Algorithm (para ser definido como sendo DRF_Neighbor_Admin_Port_Algorithm), algoritmo de gateway de porta de vizinho como DRF_Neighbor_Gateway_Algorithm (para definido como sendo DRF_Neighbor_Admin_Gateway_Algorithm), e outros discutidos aqui acima referentes à função de recordDefaultDRCPDU. Em uma modalidade, a inicialização inclui ainda definir a atividade de IPP do nó vizinho como sendo inativa através da definição de DRF_Neigbhor_Oper_DRCP_State.IPP_Activity como sendo falso.
[0756] Na referência 3304, o nó determina que DRCP seja habilitado no IPP. A verificação inclui determinar uma variável (por exemplo, IPP_port_enabled) indicando que o IPP está operando DRCP. Em uma modalidade, a determinação é através da verificação de duas variáveis para o IPP. Uma é uma variável indicando que o IPP está operando DRCP (por exemplo, através de DRCP_enabled discutido acima), e a outra é uma variável indicando que o IPL foi estabelecido e o IPP é operável (por exemplo, através de IPP_port_enabled discutido acima).
[0757] Na referência 3306, o nó entra em um estado expirado. NO estado expirado, o nó executa o seguinte em uma modalidade: define o parâmetro de estado de DRCP do nó como sendo expirado (por exemplo, definindo DRF_Home_Oper_DRCP_State.Expired discutido acima como sendo verdadeiro), também define a atividade de IPP do nó vizinho como sendo inativo através da definição de DRF_Neigbhor_Oper_DRCP_State.IPP_Activity como sendo falso. Define um temporizador para expirar se nenhuma DRCPDU for recebida. Em uma modalidade, a definição do temporizador é realizada através da definição de DRF_Neighbor_Oper_DRCP_State.DRCP_Timeout = tempo de espera curto e iniciar DRCP_current_while_timer (Timeout curto).
[0758] Após o temporizador expirar, o fluxo vai para a referência 3352, aonde o nó vai para um estado defaulted. Em uma modalidade, no estado defaulted, o nó define valores de parâmetro default para o nó vizinho no IPP como sendo os parâmetros operacionais atuais do nó vizinho fornecido por um administrador do portal através de uma função como recordDefaultDRCPDU discutido acima. Também, o estado default inclui reportar o status para a gerência através de uma função como reportToManagement discutido acima.
[0759] Na referência 3307, o nó recebe uma DRCPDU na referência 3307. a DRCPDU contém a estrutura de PDU ilustrada na figura 5, onde a estrutura de PDU tem TLVs como aqueles listados na Tabela 4. A estrutura de PDU contém TLV de informação de porta de casa e TLV de estado de DRCP. Em uma modalidade, o recebimento da DRCPDU é indicado em uma mensagem gerada pelo multiplexor/analisador de controle de DRCP como um resultado do recebimento da DRCPDU como DRCPCtrolMuxN:M_UNITDATA.indication(DRCPDU).
[0760] A seguir o nó determina que a DRCPDU recebida seja associada ao portal na referência 3308. Em uma modalidade, a determinação inclui verificar uma variável (por exemplo, Differ_Portal como discutido acima) que indica a DRCPDU de recebimento sendo associada ao portal ou não. Em uma modalidade, a determinação inclui executar uma função (Por exemplo, recordPortalValues) que registra valores de parâmetro carregados na DRCPDU recebida como os valores de parâmetro operacional atual correspondente para o nó de vizinho na IPP. Valores de parâmetro de portal, como discutido acima em definição de recordPortaValues, incluem prioridade de agregador (por exemplo, Drni_Aggregator_Prioirty), ID de agregador (por exemplo, Drni_Aggregator_ID), prioridade de portal de vizinho (Drni_Portal_Priority), e endereço de portal (por exemplo, Drni_Portal_Addr) em uma modalidade.
[0761] Se a DRCPDU recebida não for associada ao portal, o nó pode reportar opcionalmente o status para o gerenciamento através de uma função como reportToManagement discutido acima. Se posteriormente o nó receber outra DRCPDU, o fluxo retorna para a referência 3308 para determinar novamente a associação. Similarmente, quando o nó está no estado default na referência 3352 e recebe uma DRCPDU, o fluxo vai para a referência 3308 para determinar a associação.
[0762] Após determinar que a DRCPDU recebida seja associada ao portal, o fluxo vai para a referência 3310, onde o nó determinara que a DRCPDU recebida seja compatível com o nó. A determinação inclui que determinar valores administrativamente configurados associados ao portal é compatível com os valores recebidos a partir da DRCPDU. A verificação inclui executar uma função (por exemplo, recordPortalConfValues) que registra os valores de parâmetro configurados do nó de vizinho carregados na DRCPDU recebida como os valores de parâmetro operacional atual correspondente para o nó vizinho no IPP em uma modalidade. Observe que os valores de parâmetro configurado em uma função como recordPortalConfValue são diferentes dos valores de parâmetro de portal como recordPortalValue, e o diferente é discutido acima nas definições de recordPortalConfValues e recordPortalValues.
[0763] Se a DRCPDU recebida não for compatível com o nó, o nó pode opcionalmente reportar o status para gerenciamento através de uma função como reportToManagement discutido acima. Se posteriormente o nó receber outra DRCPDU, o fluxo retorna para a referência 3308 para determinar a associação novamente. Enquanto executa a função como reportToManagement, o nó define outro temporizador a expirar se nenhuma DRCPDU for recebida e inicia o temporizador. Após o temporizador expirar, o fluxo retorna à referência 3306.
[0764] Após determinar que a DRCPDU recebida seja compatível com o nó, o nó registra a informação de estado do nó vizinho contida na DRCPDU recebida como variáveis operacionais de estado de nó vizinho na referência 3312. Em uma modalidade, uma função (e.g. recordNeighborState) registra os valores de parâmetro como estado de Sistema de portal (por exemplo, Drni_Portal_System_State) e estado de DRCP de operação de nó de casa (por exemplo, DRF_Home_Oper_DRCP_State) carregado na DRCPDU recebida como as variáveis operacionais de nó vizinho correspondente como Drni_Neigbhor_State e DRF_Neighbor_Oper_DRCP_State.
[0765] Opcionalmente, quando as variáveis operacionais de estado de vizinho registradas diferem daquela das variáveis operacionais de estado de nó, o nó define um ou mais acionamentos para notificar o nó de vizinho na referência 3314. Em uma modalidade, uma função (por exemplo, updateNTT) é usada para determinar se a transmissão de protocolo adicional é necessária como discutido acima.
[0766] O método discutido aqui provê um modo eficiente para um nó DRCP processar informação incorporada em uma DRCPDU recebida a partir de um nó de DRCP vizinho. A informação é processada em estágios e é determinado que uma DRCPDU recebida seja associada ao portal do nó DRCP e é compatível com o nó antes de registrar a informação de estado de nó de vizinho. Além disso, um temporizador é inserido para evitar que o nó fique preso em um estado espera.
[0767] Máquina de transmissão periódica de DRCP
[0768] A máquina de Transmissão periódica de DRCP pode implementar a função especificada na figura 9 com seus parâmetros associados discutidos acima.
[0769] A máquina de Transmissão periódica de DRCP estabelece o desejado dos Sistemas de Portal de vizinho e de casa trocar DRCPDUs periódicas em um IPP para manter um Portal, e estabelece com que frequência aquelas transmissões periódicas devem ocorrer. Transmissões periódicas ocorrerão se qualquer participante assim desejar. As transmissões ocorrem em uma taxa determinada pelo Sistema de portal de vizinho; essa taxa é ligada à velocidade na qual o Sistema de portal de vizinho fará intervalo de informações recebidas.
[0770] A máquina de estado tem quatro estados. São como a seguir:
[0771] NO_PERIODIC (Bloco 902). Enquanto nesse estado, transmissões periódicas são desabilitadas e a função parar periodic_timer é executada. FAST_PERIODIC (Bloco 904). Enquanto nesse estado, transmissões periódicas são habilitadas em uma taxa de transmissão rápida. Esse estado é entrado a partir do estado NO_Periodic (bloco 902) em resposta a uma transição incondicional (UCT). O estado Fast_Periodic pode fazer transição para a transmissão Periódica (Bloco 910) e os estados slow_periodic (Bloco 905). Um estado SLOW_PERIODIC 906 pode ser entrado a partir de FAST_PERIODIC 904 quando o tempo de espera longo é determinado. Enquanto nesse estado, transmissões periódicas são habilitadas em uma taxa de transmissão lenta. Se o temporizador periódico expirar então o estado faz transição para o PERIODIC_TX (Bloco 910). PERIODIC_TX. Esse é um estado transitório entrado no término de periodic_timer que confirma NTT e então sai para FAST_PERIODIC ou SLOW_PERIODIC dependendo da definição de DRCP_Timeout do vizinho.
[0772] Se transmissões periódicas forem habilitadas, a taxa na qual as mesmas ocorrem é determinada pelo valor da variável DRF_Neighbor_Oper_DRCP_State.Timeout. Se essa variável for definida em tempo de espera curto, então o valor fast_periodic_time é usado para determinar o intervalo de tempo entre transmissões periódicas. De outro modo, slow_periodic_time é usado para determinar o intervalo de tempo.
[0773] Desse modo, as modalidades fornecem um processo que compreende as etapas de inicializar em um estado não periódico no qual as transmissões são desabilitadas, fazer transição para um estado periódico rápido, iniciar um temporizador para o tempo periódico rápido, fazer transição para um estado periódico lento ou um estado de transmissão periódica em resposta a um tempo de espera longo ou um vizinho tendo a definição de tempo de espera periódico rápido, respectivamente, fazer transição a partir de um tempo de espera periódico lento para um estado de transmissão periódica em resposta a uma definição de tempo de espera curto no vizinho ou um término de temporizador, e fazer transição a partir do estado de transmissão periódica para o estado periódico rápido ou periódico curto em resposta a definição de tempo de espera vizinho mudando para um tempo de espera curto ou definição de tempo de espera longo, respectivamente.
[0774] A máquina de Transmissão Periódica de DRCP também pode implementar a função especificada na figura 17 com seus parâmetros associados. A figura 17 contém termos diferentes (por exemplo, DRCP_periodic_timer e NTTDRCPDU, não periodic_timer e NTT respectivamente como na figura 9), porém os fluxos são iguais de outro modo. Os termos e funções da máquina de transmissão alternativa na figura 17 são análogos àqueles da figura 9. Uma pessoa versada na técnica entenderia que outras implementações são possíveis compatíveis com os princípios e estruturas das máquinas de transmissão ilustradas.
[0775] Máquina de sistema de portal
[0776] A Máquina de sistema de portal pode implementar a função especificada na figura 10 com seus parâmetros associados discutidos acima. Esse processo pode inicializar em um estado de inicializar Sistema de portal (Bloco 1002). As funções setDefaultPortalSystemParameters e updateKey são executadas. No caso de Mudar Portal ou ChangeDRFPorts serem verdadeiros o processo faz transição para o estado de atualização de Sistema de portal (Bloco 1004). No estado de atualização de Sistema de portal, o ChangePortal é definido em false, changeDRFPorts definido em False, atualizar DRF homestate, e execução de updatekey. A próxima atualização é acionada quando Mudar portal ou mudar DRFPorts é atualizado em verdadeiro.
[0777] Desse modo, as modalidades fornecem um processo que compreende as etapas de inicializar para um estado de inicialização de portal onde parâmetros de Sistema de portal default são criados e uma chave é atualizada, fazer transição para um estado de atualização de Sistema de portal em resposta a uma variável ChangePortal ou ChangeDRFPorts sendo booleana verdadeira, definir em um estado de atualização de Sistema de portal a variável de ChangePortal em falsa, a variável de changeDRFPorts em falsa, executar um updateDRFHomeState, e atualizar a chave, e entrar novamente no estado de atualização de sistema de portal após detectar uma variável ChangePortal ou ChangeDRFPorts como sendo verdadeira.
[0778] Na inicialização as variáveis do Sistema de portal são definidas em seus valores default para esse Portal como configurado por suas definições administrativas. Em particular os estados operacionais default de todos os Gateways, Portas de agregação, e IPPs, no Portal são definidos em FALSE. Além disso com base nesses valores default, a Chave operacional a ser usada pelo Agregador associado é calculada como sendo o valor de Chave administrativa atribuída a esse Sistema de Portal.
[0779] Qualquer mudança local no estado operacional do Gateway de Sistema de Portal, ou no estado de distribuição de qualquer das Portas de agregação anexadas como reportado pelo Agregador associado, ou qualquer mudança no estado operacional dos Sistemas de portal de vizinho, como reportado pela máquina de estado RX, aciona uma transição para o estado PORTAL_SYSTEM_UPDATE. Isso fazer com que a função updateDRFHomeState reavalie uma variável que fornece o próprio estado do Sistema de portal (DRF_Home_State) com base na informação local atualizada sobre o estado operacional do Gateway e todas as Portas de agregação no Agregador do Sistema de portal. Qualquer mudança no estado operacional do Gateway do Sistema de portal é refletida para a GatewayConversationUpdate que é usada para acionar transições de estado nas máquinas de estado das portas e IPP. Similarmente, qualquer mudança no estado operacional das Portas de agregação associadas à Porta de agregador desse Sistema de portal é refletida para a PortConversationUpdate que é usada para acionar transições de estado nas mesmas máquinas de estado. Finalmente, a função updateKey atualiza a chave operacional, a ser usada pelo Agregador do Sistema de portal, por selecionar o valor não zero numérico mais baixo do conjunto compreendendo os valores das chaves administrativas de todos os Sistemas de Portal ativos no Portal.
[0780] A máquina de estado retorna para o estado PORTAL_SYSTEM_UPDATE sempre que o estado operacional de qualquer das portas de Função DR mudar.
[0781] A Máquina de sistema de portal também pode implementar a função especificada na figura 18 com seus parâmetros associados. A figura 18 é similar à figura 10 exceto que o sistema executa atualização de Estado de Portal utilizando a função UpdatePortalState na figura 18. Os termos e funções da máquina de Sistema de Portal alternativa na figura 18 são análogos àqueles da figura 10. Uma pessoa versada na técnica entenderia que outras implementações são possíveis compatíveis com os princípios e estruturas das máquinas de Sistema de Portal ilustradas.
[0782] A figura 34 ilustra um método para atualizar estados operacionais de um nó em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção. O método 3400 pode ser implementado em um nó DRCP (por exemplo, um dispositivo de rede) de um portal de DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C. Observe que as etapas operacionais são indicadas como um quadrado pontilhado como ilustrado na figura 34.
[0783] Na referência 3402, o nó inicializa para agregação de link. A inicialização inclui definir variáveis do nó para o portal que pertence como configurado por definições administrativas. A inicialização é realizada por executar uma função (por exemplo, setDefaultPortalSystemParameters na figura 10) em uma modalidade. A função define a variável de nó em valores definidos administrativos como enumerado na definição de setDefaultPortalSystemParameters discutido acima, que inclui uma prioridade de sistema do agregador do nó (por exemplo, Drni_Aggregator_Priority), um identificador de sistema do nó (por exemplo, Drni_Aggregator_ID), uma prioridade de sistema do portal (por exemplo, Drni_Portal_Priority), um identificador para o nó no portal (por exemplo, DRF_Portal_System_Number), um valor de chave de agregador administrativo associado ao agregador (por exemplo, DRF_Home_Admin_Aggregator_Key), um algoritmo de porta usado por uma função DR do nó para atribuir quadros a IDs de conversação de porta (por exemplo DRF_Home_Port_Algorithm), um algoritmo de gateway usado pela função DR do nó para atribuir quadros a IDs de conversação de gateway (por exemplo, DRF_Home_Gateway_Algorithm) e etc.
[0784] Na referência 3404, o nó determina que um estado operacional associado ao portal seja mudado. A mudança de estado operacional pode ser indicada por uma variável Booleana que é definida em verdadeiro quando um valor operacional da visão do dispositivo de rede do valor da atividade de IPP do dispositivo de rede de vizinho é ativo. Em uma modalidade, uma variável como ChangePortal discutida acima é tal variável Booleana. A mudança de estado operacional pode ser também indicada por uma variável Booleana que é definida em verdadeira quando um estado operacional do gateway do nó mudar. A mudança de estado operacional também pode ser indicada por uma variável booleana que é definida em verdadeiro quando um dos estados operacionais de portas de agregação do nó associado ao primeiro portal mudar. Em uma modalidade, uma variável como ChangeDRFPorts discutido acima é tal variável Booleana para ambas as mudanças dos estados operacionais das portas de agregação e gateway.
[0785] Na referência 3406, o nó pode definir uma ou mais variáveis indicando nenhuma alteração de estado operacional associada ao portal. Em uma modalidade, isso é realizado por definir variáveis como ChangePortal e ChangeDRFPorts como sendo FALSE como ilustrado na figura 10. A definição permite alterações adicionais de atualização de acionamento de estado operacional de ChangePortal e ChangeDRFPorts de modo que o nó possa detectar a alteração.
[0786] Na referência 3408, o nó atualiza um conjunto de estados operacionais do nó para agregação de link em resposta à alteração de estado operacional, onde o conjunto de estado operacional inclui um estado operacional do gateway para o nó. Em uma modalidade, a atualização é realizada através de uma função executada updateDRFHomeState discutida acima. Em uma modalidade, a atualização também cria uma lista de portas de agregação operacional por incluir somente aqueles identificadores de porta de agregação (ID) que é operável (por exemplo, o agregador anexado reporta os mesmos como tendo Actor_Oper_Port_State.Distributing == TRUE (condição que exclui os casos onde as portas de agregação associada são não operáveis ou em um estado expirado, ou não no grupo de agregação de link)).
[0787] O método provê um modo eficiente para sincronizar estados operacionais do nó DRCP com nó DRCP de vizinho baseado em alterações do portal ao qual o nó DRCP pertence.
[0788] Máquina de agregador e gateway DRNI
[0789] A máquina de agregador e Gateway DRNI pode implementar a função especificada na figura 11 com seus parâmetros associados discutidos acima. Há duas máquinas de Agregador e Gateway de DRNI em um Sistema de Portal. Cada é associado a um tipo de ID de conversação: há um para IDs de Conversação de gateway e um para IDs de conversação de Porta. A figura 11A é o processo de gateway de DRNI que inicializa no estado de inicializar Gateway de DRNI (bloco 1102). Nesse estado a função InitializeDRNIGatewayConversation é executada e GatewayConversationUpdate é definido em FALSE e onde o GatewayConversationUpdate ocorre, o processo faz transição para o estado de Atualizar Gateway de DRNI (Bloco 1104). No estado de atualizar gateway de DRNI (Bloco 1104), o processo define o GatewayConversationUpdate em falso, um updatePortaState, operação de setGatewayConversation, e setIPPGatewayUpdate são executados e um updatePortalSystemGateway Conversation é executado. A atualização de gateway de DRNI é acionada em cada ocorrência da Atualização de GatewayConversation.
[0790] As modalidades do processo compreendem as etapas de inicializar em um estado de inicialização de gateway de DRNI, inicializar uma conversação de gateway de DRNI e GatewayCoversationUpdate em FALSE, fazer transição para um estado de atualizar gateway de DRNI após detectar que uma variável de atualização de conversação de gateway é verdadeira, definir updatePortalState, definir os acionamentos de atualização de gateway de IPP, definir a variável de atualização de conversação de gateway em falso, definir a conversação de gateway, atualizar uma conversação de gateway de sistema de portal e entrar novamente o estado de atualização de gateway de DRNI após a variável de Atualizar Conversação de gateway ser definida em verdadeira.
[0791] A figura 11B é o processo de atualização de porta de DRNI. Nesse processo o processo de atualização de porta de DRNI começa no estado de inicializar Porta de DRNI (bloco 1112). A função initializeDRNIPortConversation é executada e a PortCoversationUpdate é definida em FALSE e o processo continua em resposta a uma ocorrência da PortConversationUpdate, que faz transição do estado para o DRNIPortUpdate (Bloco 1114). No estado de Atualização de Porta de DRNI, o processo define a PortConversationUpdate em falso, o updatePortalState, o setPortConversation, as operações setIPPPortUpdate e a operação updatePortalSystemPortConversation são executadas. A atualização de porta de DRNI é acionada novamente quando há uma alteração no valor do PortConversationUpdate.
[0792] As modalidades do processo compreendem as etapas de inicializar em um estado de inicialização de porta de DRNI, inicializar uma conversação de porta de DRNI e o PortCoversationUpdate em FALSE, fazer transição para um estado de atualização de porta de DRNI após detecção da variável de Atualização de conversação de Porta ser verdadeira, definir os acionamentos de atualização de Porta de IPP, definir a variável de Atualização de Conversação de Porta em falso, definir a Conversação de Porta, atualizar a Conversação de Porta de sistema de portal e entrar novamente o estado de atualização de porta de DRNI em resposta à detecção de que a variável de Atualização de conversação de porta é verdadeira.
[0793] Essas máquinas de estado são responsáveis por configurar os IDs de conversação de Gateway e os IDs de conversação de Porta que são permitidos passar através desse Agregador e Gateway de Função DR com base nas regras de prioridade acordadas e operação de DRCP.
[0794] Em um acionamento a partir da máquina de estado de PS (figura 10) ou a máquina de estado de DRX (figura 8), declarando que um estado operacional de Gateway mudou, a máquina de estado entra no estado de DRNI_GATEWAY_UPDATE. Isso faz com que o parâmetro de acionamento (GatewayConversationUpdate) seja redefinido em FALSE. Então a função updatePortalState atualizará uma variável fornecendo os estados de todos os Sistemas de Portal (Drni_Portal_System_State[]) por combinar o DRF_Home_State atualizado com informações a partir do estado operacional das portas nos outros Sistemas de Portal como reportado pelas DRCPDUs recebidas nos IPPs do Sistema de portal e registradas pela máquina de estado de DRX (Figura 8) e define IppGatewayUpdate em todo IPP no Sistema de portal em TRUE para acionar atualização adicional nas máquinas de estado de IPP (Figure 12). Subsequentemente a função setGatewayConversation é invocada para identificar o Sistema de portal que é responsável por cada ID de Conversação de gateway com base nas prioridades de seleção acordadas e estado operacional de Gateways como sabido por esse Sistema de portal (com base no estado operacional de Gateway e no estado operacional declarado dos Sistemas de Portal de vizinho de seus próprios Gateways carregados pela DRCPDU mais recente recebida a partir daqueles Sistemas de Portal de vizinho). Finalmente, o ID de conversação de gateway indexado, vetor Booleano serão calculados com base no acordo entre a visão desse Sistema de portal nos IDs de conversação de Gateway que são permitidos passar através do Gateway do Sistema de portal e a visão de todos os Vizinhos nos IDs de conversação de gateway que são permitidos passar através do Gateway desse Sistema de portal [como declarado através de suas DRCPDUs e registrado pela máquina de estado DRX desse Sistema de portal (Figura 8)]. Isso assegura que nenhum ID de conversação de Gateway é permitido passar através do Gateway desse Sistema de portal a menos que acordo entre todos os Sistemas de Portal seja atingido.
[0795] A máquina de estado é inicializada tendo todos os IDs de conversação de Gateway descartados e transita para o estado DRNI_GATEWAY_UPDATE sempre que o acionamento GatewayConversationUpdate for definido.
[0796] O vetor booleano indexado por ID de conversação de porta é definido através de uma operação de máquina de estado similar a única diferença sendo que as regras de seleção de prioridade são baseadas nos IDs de conversação de Porta acordados e Algoritmo de porta em vez dos IDs de Conversação de gateway acordado e Algoritmo de gateway.
[0797] A figura 35 ilustra um método para configuração de um conjunto de IDs de conversação para agregador ou gateway no dispositivo de rede em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção. O método 3500 pode ser implementado em um nó DRCP (por exemplo, um dispositivo de rede) de um portal de DRCP (mencionado como portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C. observe que etapas opcionais são indicadas como um quadrado pontilhado como ilustrado na figura 35.
[0798] Na referência 3502, o nó inicializa um conjunto de IDs de conversação e a inicialização inclui definir entradas de um vetor booleano associado ao conjunto de IDs de conversação como sendo uma sequência de zeros. Os IDs de conversação são IDs de conversação de gateway ou IDs de conversação de porta. O vetor booleano inclui valores indicando processamento do conjunto de IDs de conversação através de um gateway ou um agregador do nó, que define em zeros (nenhum processamento) através da inicialização. Observe que um nó de DRCP contém um único gateway e um único agregador.
[0799] A inicialização pode ser realizada por uma função como InitializeDRNIGatewayConversation e InitializeDRNIPortConversation discutida acima. O vetor booleano pode ser Drni_Portal_System_Gateway_Conversation ou Drni_Portal_System_Port_Conversation para IDs de conversação de gateway e IDs de conversação de porta, respectivamente. Em uma modalidade, um indicador de um ID de conversação é o valor booleano da entrada (por exemplo, verdadeiro significa ser passado através do gateway ou distribuído através do agregador). A inicialização faz todos os valores serem zeros, desse modo não passa.
[0800] Na referência 3504, o nó determina que a distribuição do conjunto de IDs de conversação necessita ser atualizada. Em uma modalidade, fazer a determinação inclui uma variável Booleana (por exemplo, variáveis como GatewayConversationUpdate e PortConversationUpdate discutidas acima para IDs de conversação de gateway e IDs de conversação de porta respectivamente).
[0801] Na referência 3506, o nó define valores de um vetor operacional indexado pelos IDs de conversação, onde o vetor operacional lista qual nó do portal processa cada do conjunto de IDs de conversação. Em uma modalidade, o vetor operacional é Drni_Gateway_Conversation e Drni_Port_Conversation para IDs de conversação de gateway e IDs de conversação de porta respectivamente. For IDs de conversação de gateway, o vetor operacional lista qual nó do portal passado por cada ID de conversação de gateway. Para IDs de conversação de porta, o vetor operacional lista qual nó do portal passa por cada ID de conversação de porta.
[0802] Na referência 3508, o nó define valores do vetor booleano indexados pelos IDs de conversação, onde o vetor Booleano lista se o gateway único ou o agregador único do dispositivo de rede é associado a cada dos IDs de conversação. O vetor booleano operacional pode ser Drni_Portal_System_Gateway_Conversation ou Drni_Portal_System_Port_Conversation para IDs de conversação de gateway e IDs de conversação de porta respectivamente. Para IDs de conversação de gateway, cada entrada no vetor Booleano indica se um ID de conversação de gateway é permitido passar através do único gateway do nó. For IDs de conversação de porta, cada entrada no vetor Booleano indica se um ID de conversação de porta é permitido ser distribuído através do único agregador do nó.
[0803] A seguir, opcionalmente na referência 3510, o nó atualiza estados operacionais de todos os nós do portal. Em uma modalidade, a atualização é realizada por uma função como updatePortalState discutida acima.
[0804] Também opcionalmente na referência 3512, o nó define uma variável indicando que a distribuição do conjunto de IDs de conversação necessita ser atualizado. Em uma modalidade, a variável é setIPPGatewayUpdate e setIPPPortupdate (discutido acima) para IDs de conversação de gateway e IDs de conversação de porta respectivamente.
[0805] Desse modo, modalidades da invenção fornecem modos eficientes para configurar IDs de conversação de modo que as conversações associadas possam ser transmitidas adequadamente em um grupo de agregação de link contendo DRNI.
[0806] Máquina de IPP DRNI
[0807] A máquina de IPP DRNI pode implementar a função especificada nas figuras 12A-B com seus parâmetros associados discutidos acima. A figura 12A ilustra uma máquina de estado para atualizar a conversação de gateway de IPP de acordo com uma modalidade da invenção. O processo inicia no bloco 1202, onde um gateway de IPP é inicializado. Nessa modalidade, inicialização de gateway de IPP é obtida através de duas funções de inicialização. Através de IPPGatewayUpdate = FALSE, o dispositivo de rede define os acionamentos de Atualizar Gateway IPP em FALSE. Através da função InitializeIPPPortConversation(), o dispositivo de rede define passagens de conversação (como Ipp_Gateway_Conversation_Direction) para uma sequência de zeros, indexada novamente por ID de conversação de gateway.
[0808] Após inicialização, a máquina de estado vai para o bloco 1204, onde o gateway IPP é atualizado. A transmissão é acionada por uma alteração variável. A variável, IppGatewayUpdate, indica que distribuições de ID de conversação de gateway por IPP necessitam ser atualizadas. Em uma modalidade, IppGatewayUpdate é um valor booleano e após o valor booleano se transformar em TRUE, a máquina de estado vai para o bloco 1204. No bloco 1204, define conversação de gateway através da função setGatewayConversation. Como discutido acima, a função define valor de conversação de gateway DRNI para os valores computados a partir do valor administrativo atual da lista de prioridade de seleção de gateway para a retransmissão distribuída (através de uma variável como aDrniConvAdminGateway[]) e o estado de sistema de porta DRNI atual (por leitura de Drni_Portal_System_State[] em uma modalidade). Também no bloco 1204, o dispositivo de rede define conversação de gateway de IPP através da função setIPPGatewayConversation(). Adicionalmente, o dispositivo de rede atualiza orientação de conversação de gateway de IPP através da função updateIPPGatewayConversationDirection(), e finalmente o dispositivo de rede redefine IppGatewayUpdate em FALSE. O Bloco 1204 se repete sempre que uma atualização de conversação de gateway for necessária.
[0809] Desse modo, as modalidades do processo compreendem as etapas de inicializar em um estado de inicialização de gateway de IPP, inicializar o acionamento de atualização de gateway de IPP em FALSE, inicializar a conversação de gateway de IPP, fazer a transição para um estado de atualização de gateway de IPP após detectar que uma variável de Atualização de Gateway de IPP é verdadeira, definir a conversação de gateway, definir uma conversação de gateway de IPP, atualizar a orientação de conversação de gateway de IPP, definir a variável de atualização de Gateway de IPP em falso e entrar novamente o estado de atualização de gateway de IPP em resposta à detecção de que a variável de atualização de Conversação de gateway é verdadeira.
[0810] A figura 12B ilustra uma máquina de estado para atualizar conversação de porta de IPP de acordo com uma modalidade da invenção. O processo para atualizar porta de IPP é análogo ao processo para atualizar conversação de gateway desse modo o processo na figura 12B é similar à figura 12A com funções e variáveis para portas de IPP que são utilizadas para a atualização de conversação de porta de IPP.
[0811] As modalidades desse processo compreendem as etapas de inicializar em um estado de inicialização de porta de IPP, inicializar o acionamento de atualização de porta de IPP em FALSE, inicializar uma conversação de porta de IPP, fazer transição de um estado de atualização de porta de IPP em resposta à detecção de que uma variável de Atualização de Porta de IPP é verdadeira, definir uma conversação de porta, definir uma conversação de IPP, atualizar uma passagem de conversação de porta de IPP definindo a variável IppPortUpdate em falso e entrar novamente o estado de Atualização de porta de IPP em resposta à detecção de que PortConversationUpdate é verdadeiro.
[0812] Em Uma Modalidade, Essas Máquinas De Estado São Responsáveis Por Configurar Os Ids De Conversação De Gateway E Os Ids De Conversação De Porta Que São Permitidos Passar Através Dos Ipps Desse Sistema De Portal De Vizinho Com Base Nas Regras De Prioridade Acordadas E Operação De Drcp.
[0813] Em um acionamento a partir da máquina de estado DRX (figura 8), declarando que IppGatewayUpdate é definido em TRUE, a máquina de estado entra no estado IPP_GATEWAY_UPDATE. Isso fazer com que a função setGatewayConversation seja invocada. Isso identificará o Sistema de portal que é responsável por cada ID de conversação de Gateway com base nas prioridades de seleção acordadas e no estado operacional de Gateway como sabido por esse Sistema de portal (com base no estado operacional de Gateway local e no estado operacional declarado de Vizinhos de seus próprios Gateways carregados pela DRCPDU mais recente recebida a partir daqueles vizinhos). A seguir a função setIPPGatewayConversation identificará o Sistema de portal que é responsável por cada ID de conversação de gateway com base nas prioridades de seleção acordadas e estados operacionais de Gateways como declarado pelo Sistema de portal de vizinho nesse IPP (com base no estado operacional de Gateway do Sistema de portal de vizinho e estado operacional declarado do Sistema de portal de vizinho em sua visão sobre outros Gateways no Portal, carregados pela DRCPDU mais recente recebida a partir do Sistema de portal de vizinho nesse IPP). Subsequentemente, o vetor Booleano, indexado por ID de conversação de gateway será calculado com base no acordo entre a visão desse Sistema de portal sobre os IDs de conversação de gateway que são permitidos passar através do IPP do Sistema de portal e a visão do Sistema de portal de vizinho de IPP sobre os IDs de conversação de gateway que são permitidos passar através do mesmo IPP [como declarado através de suas DRCPDUs e registrado pela máquina de estado DRX desse Sistema de portal (Figura 8)]. Isso assegura que nenhum ID de conversação de Gateway é permitido passar através desse IPP a menos que um acordo entre esse Sistema de portal e o Sistema de portal de seu vizinho seja atingido. Finalmente, IppGatewayUpdate é redefinido em FALSE.
[0814] A máquina de estado é inicializada tendo todos os IDs de conversação de gateway descartados e transita para o estado IPP_GATEWAY_UPDATE sempre que o acionamento GatewayConversationUpdate for definido.
[0815] O vetor booleano indexado por ID de conversação de Porta é definido através de uma operação de máquina de estado similar, a única diferença sendo que as regras de seleção de prioridade são baseadas nos IDs de conversação de porta acordados e no Algoritmo de Porta, em vez dos IDs de conversação de gateway acordados e o Algoritmo de Gateway.
[0816] A figura 36 ilustra um método para configuração de um conjunto de IDs de conversação para IPP em um nó DRCP em uma interconexão de rede resiliente distribuída (DRNI) de acordo com uma modalidade da invenção. O método 3600 pode ser implementado em um nó DRCP (por exemplo, um dispositivo de rede) de um portal DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C.
[0817] Na referência 3602, o nó inicializa um conjunto de IDs de conversação e a inicialização inclui definir entradas de um vetor booleano associado ao conjunto de IDs de conversação para ser uma sequência de zeros. Os IDs de conversação são IDs de conversação de gateway ou IDs de conversação de porta. O vetor booleano inclui valores indicando processamento do conjunto de IDs de conversação através de um IPP do nó.
[0818] A inicialização pode ser realizada por uma função como InitializeIPPGatewayConversation e InitializeIPPPortConversation discutida acima. O vetor booleano pode ser Ipp_Gateway_Conversation_Direction ou Ipp_Port_Conversation_Passes para IDs de conversação de gateway e IDs de conversação de porta respectivamente. Em uma modalidade, um valor para um ID de conversação é o valor booleano da entrada. Por exemplo, um valor de TRUE para um ID de conversação de gateway indica que algum gateway é alcançável através desse IPP. A inicialização faz todos os valores serem zeros, desse modo não passam.
[0819] Na referência 3604, o nó determina que a distribuição do conjunto de IDs de conversação necessita ser atualizada. Em uma modalidade, fazer a determinação inclui verificar uma variável booleana. Em uma modalidade, a variável booleana é IppGatewayUpdate e IppPortUpdate para IDs de conversação de gateway e IDs de conversação de porta respectivamente. Em outra modalidade, as variáveis booleanas são GatewayConversationUpdate e PortConversationUpdate para IDs de conversação de gateway e IDs de conversação de porta respectivamente.
[0820] Na referência 3606, o nó define valores de um primeiro vetor operacional indexado pelos IDs de conversação, onde o vetor operacional lista qual nó do portal processa cada dos IDs de conversação como atribuído pelo nó. Em uma modalidade, o nó define os valores através de funções como setGatewayConversation e setPortConversation para definir o primeiro vetor operacional como Drni_Gateway_Conversation e Drni_Port_Conversation respectivamente. Para IDs de conversação de gateway, Drni_Gateway_Conversation lista o gateway de qual nó (se algum) passa cada ID de conversação de gateway. Para IDs de conversação de porta, Drni_Port_Conversation lista qual nó passa cada ID de conversação de porta.
[0821] Na referência 3608, o nó define valores de um segundo vetor operacional indexado pelos IDs de conversação, onde o vetor operacional lista qual nó do portal processa cada dos IDs de conversação como atribuído pelo nó de vizinho. Em uma modalidade, o nó define os valores através de funções como setIPPGatewayConversation e setIPPPortConversation para definir o segundo vetor operacional como Ipp_Other_Gateway_Conversation e Ipp_Other_Port_Conversation_Portal_System respectivamente. Como discutido acima, para IDs de conversação de gateway, Ipp_Other_Gateway_Conversation lista qual nó (isto é, Sistema de portal) (se algum) está passando cada ID de conversação de gateway como atribuído pelo nó de vizinho nesse IPP, o nó de vizinho sendo o nó de vizinho imediato quando o portal contém mais de dois nós. Similarmente, para IDs de conversação de porta, Ipp_Other_Port_Conversation_Portal_System lista qual nó está passando cada ID de conversação de porta como atribuído pelo nó de vizinho imediato nesse IPP.
[0822] Na referência 3610, o nó define valores do vetor booleano indexado pelos IDs de conversação, onde o vetor booleano lista se o IPP do nó é associado a cada dos IDs de conversação. Em uma modalidade, o vetor booleano é Ipp_Gateway_Conversation_Direction para IDs de conversação de gateway e Ipp_Port_Conversation_Passes para IDs de conversação de porta as discutido acima.
[0823] Desse modo, similar ao método 3500, as modalidades da invenção fornecem aqui modos eficientes para configurar IDs de conversação de modo que as conversações associadas possam ser transmitidas adequadamente em um grupo de agregação de link contendo DRNI.
[0824] Máquina de transmissão
[0825] Quando a Máquina de transmissão (não ilustrado) cria uma DRCPDU para transmissão, pode preencher os seguintes campos com os valores operacionais correspondentes para esse IPP de acordo com uma modalidade da invenção:
[0826] ID de agregador e prioridade. • ID de portal e prioridade. • Número de sistema de portal. • Estado de topologia. • Chave de agregador operacional. • algoritmo de porta. • algoritmo de gateway. • digest de porta. • digest de gateway. • Estado de DRCP. • As Portas de agregação operacional, a Chave de agregador administrativo e a Chave de agregador de Partner operacional do Sistema de portal de casa e qualquer outro Sistema de portal que sua capacidade para formar um portal foi verificada.
[0827] Quando a máquina periódica está no estado NO_PERIODIC, a máquina de transmissão: • não deve transmitir nenhuma DRCPDU, e • deve definir o valor de NTTDRCPDU em FALSE.
[0828] Quando a variável DRCP_Enabled é TRUE e a variável NTTDRCPDU é TRUE, a máquina de transmissão pode assegurar que uma DRCPDU adequadamente formatada seja transmitida [isto é, emitir um primitivo de serviço DRCPCtrlMuxN:M_UNITDATA.Request (DRCPDU)], sujeito à restrição de que não mais que um número específico de LACPDUs possa ser transmitido em qualquer intervalo de Fast_Periodic_Time. O número específico pode variar dependendo da implementação (por exemplo, dez ou vinte). Se NTTDRCPDU for definida em TRUE quando esse limite está em vigor, a transmissão pode ser retardada até tal momento em que a restrição não esteja mais em vigor. A variável NTTDRCPDU pode ser definida em FALSE quando a máquina de Transmissão transmitiu uma DRCPDU.
[0829] Se a transmissão de uma DRCPDU for retardada devido à restrição acima, a informação enviada na DRCPDU corresponde aos valores operacionais para o IPP no momento de transmissão, não no momento em que NTTDRCPDU foi primeiramente definido em TRUE. Em outras palavras, o modelo de transmissão de DRCPDU se baseia na transmissão de informação de estado que é atual no momento em que uma oportunidade de transmissão ocorre, ao contrário de enfileirar mensagens para transmissão.
[0830] Quando o DRCP_Enabledvariable é FALSE, a máquina de Transmissão pode não transmitir nenhuma DRCPDU e pode definir o valor de NTTDRCPDU em FALSE.
[0831] Máquina de comcompartilhamentomento de IPL/rede
[0832] A máquina de comcompartilhamentomento de IPL/rede pode implementar as funções especificadas na figura 30 com seus parâmetros associados. Há uma máquina de comcompartilhamentomento de IPL/rede por IPP em um Sistema de portal para o método de comcompartilhamentomento de IPL/rede suportado. Essa máquina é somente necessária quando os métodos comcompartilhamentodos em IPL/rede, comcompartilhamentomento por tempo de IPL/rede, comcompartilhamentomento por etiqueta de IPL/rede, ou comcompartilhamentomento por encapsulamento de IPL/rede é implementado.
[0833] A máquina de comcompartilhamentomento de IPL/rede, que corresponde ao método 3100 da figura 31 discutido abaixo, habilita a transmissão e manipulação dos quadros enviados no link de IPL/rede comcompartilhamentodo somente se as DRCPDUs recebidas na mesma porta reportam a mesma configuração de comcompartilhamentomento de IPL/rede pelo Sistema de portal de vizinho, desse modo resultando em link de rede e IPL múltiplo comcompartilhamentondo um mesmo link físico ou agregação de link.
[0834] A máquina de estado tem três estados. São como a seguir:
[0835] NO_MANIPULATED_FRAMES_SENT. Enquanto nesse estado, o IPL pode somente ser suportado por um Link de agregação ou físico.
[0836] TIME_SHARED_METHOD. Enquanto nesse estado, os métodos de comcompartilhamentomento por tempo de IPL/rede especificados acima são habilitados.
[0837] MANIPULATED_FRAMES_SENT. Enquanto nesse estado, os métodos de manipulação de etiqueta de comcompartilhamentomento por etiqueta de IPL/rede ou comcompartilhamentomento por encapsulamento de IPL/rede, como determinado pelo método de comcompartilhamentomento de IPL/rede selecionado o aDrniEncapsulationMethod, são habilitados.
[0838] O Sistema é inicializado no NO_MANIPULATED_FRAMES_SENT e quadros de IPL são enviados no link físico dedicado. Se o Sistema de portal de casa for configurado para modo de operação de comcompartilhamentomento por tempo de IPL/rede, indicado por um valor de 1 em aDrniEncapsulationMethod, o sistema transitará para o TIME_SHARED_METHOD se a máquina de estado DRX (DRX— Figura 8) definir CC_Time_Shared em TRUE (indicando que o Sistema de portal de vizinho nesse IPP também foi configurado para o modo de operação de comcompartilhamentomento por tempo de IPL/rede). O sistema permanece no estado TIME_SHARED_METHOD até que uma DRCPDU recebida defina CC_Time_Shared em FALSE, que aciona uma transição de estado para o estado NO_MANIPULATED_FRAMES_SENT e quadros de IPL são enviados no link físico dedicado.
[0839] Similarmente, se o Sistema de portal de casa for configurado para modo de operação de comcompartilhamentomento por etiqueta de IPL/rede ou modo por encapsulamento de IPL/rede, como indicado pelo valor em aDrniEncapsulationMethod, o sistema transitará para MANIPULATED_FRAMES_SENT se a máquina de estado DRX (DRX—Figura 8) definir CC_EncTag_Shared em TRUE (indicando que o Sistema de portal de vizinho nesse IPP foi também configurado para o modo de operação de comcompartilhamentomento por etiqueta de IPL/rede ou modo comcompartilhamentomento por encapsulamento de IPL/rede, respectivamente). O sistema permanece no estado MANIPULATED_FRAMES_SENT até que uma DRCPDU recebida defina CC_EncTag_Shared em FALSE, que aciona uma transição de estado para o estado NO_MANIPULATED_FRAMES_SENT e quadros de IPL são enviados no link físico dedicado.
[0840] A figura 31 ilustra um método para comcompartilhamentomento de IPL/rede em um nó de acordo com uma modalidade da invenção. O método 3100 pode ser implementado em um nó DRCP (também mencionado como um Sistema de portal de um portal, por exemplo, um dispositivo de rede) de um portal de DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C. Observe a etapa opcional é indicada como um quadrado pontilhado como ilustrado na figura 31.
[0841] Na referência 3102 um nó de DRCP (um Sistema de portal local) está em um estado de operação normal e quadros IPL são transmitidos sobre um link físico dedicado ou link de agregação em direção a um nó DRCP de vizinho (um Sistema de portal de vizinho). Na referência 3104 é determinado se o nó é configurado em consistência com o nó de vizinho. Por exemplo, isso pode ser realizado utilizando uma função de registro de parâmetro, como recordNeighborState, que pelo menos registra o valor de parâmetro carregado em um TLV usado para comcompartilhamentomento de IPL/rede a partir do nó de vizinho, por exemplo, campo DRF_Home_Network/IPL_sharing_method na tabela 6. O valor de parâmetro registrado pode ser então comparado com o valor de parâmetro correspondente atual usado pelo nó. No caso de comcompartilhamentomento de IPL/rede ser implementado no nó e no caso de valores de parâmetro ser consistentemente configurados nos nós, o método prossegue para a referência 3106 na qual quadros são transmitidos a partir do nó para o nó vizinho utilizando comcompartilhamentomento de IPL/rede.
[0842] Opcionalmente o nó continua usando o método de comcompartilhamentomento de IPL/rede até detectar uma alteração de comcompartilhamentomento de IPL/rede no nó vizinho na referência 3108. Por exemplo, um CC_Time_Shared ou CC_Enctag_Shared indica se os nós de casa / vizinho usam métodos de comcompartilhamentomento compatíveis. Quando os dois nós não usam método de comcompartilhamentomento compatível, o fluxo retorna para a referência 3102, onde o link dedicado ou link de agregação é usado.
[0843] As modalidades da invenção fornecem um modo eficiente para suportar comcompartilhamentomento de link inter-porta e rede em um grupo de agregação de link de modo que um link inter-porta possa comcompartilhamentor um link físico com outros links inter-portas ou links de rede.
[0844] Coordenação entre status DRCP e LACP: Um primeiro conjunto de modalidades
[0845] Em um Sistema de portal de DRNI como ilustrado nas figuras 1B-1C, status de DRCP e LACP deve ser consistente para o sistema funcionar adequadamente. Na figura 1C, a consistência é mais fácil de manter. Com referência à figura 1C, o link entre o dispositivo de rede 130 e dispositivo de rede 132 é o link de proteção (link 172) e o link entre o dispositivo de rede 130 e o dispositivo de rede 132 é o link de proteção (link 174) para um serviço. Um link IPL (não mostrado) entre dispositivos de rede 134 e 132 mantém seu status de DRCP em sincronização. A partir do ponto de vista de dispositivo de rede 130 (portal 142 com um nó único), é conectado a um sistema único (portal 144) e nenhuma informação em relação a dispositivos de rede 132 ou 134 individualmente é explicitamente comunicada para o dispositivo de rede 130.
[0846] Quando o link de IPL entre os dispositivos de rede 132 e 134 desce, ambos os dispositivos de rede 134 (atualmente o nó de trabalho) e 132 (atualmente o nó de proteção) tentam assumir como o nó que transmite tráfego - a partir de sua respectiva perspectiva, é o nó vizinho que não está operando adequadamente. O dispositivo de rede 132, como um nó de proteção, atualizará seu identificador de LAG (ID) para evitar ter a situação onde os dois links 130-132 e 130-134 (links 172 e 174 respectivamente) carregam tráfego duplicata. No portal 142, a determinação de qual link deve permanecer em um grupo de agregação de link (isto é, link de trabalho) se baseia em uma decisão pelo dispositivo de rede 130, que aplica operações de agregação de link normal para fazer a escolha. Particularmente, o dispositivo de rede 130 coloca o link 130-132 em espera para verificar se o link 130134 está ainda no grupo de agregação de link (isto é, link de trabalho carregando tráfego). Se o link 130-134 não estiver no grupo de agregação de link, habilita tráfego no link 130-132. Quando o link de IPL entre os dispositivos de rede 134 e 132 está para cima novamente, o status de DRCP é atualizado e o link 130-132 permanece bloqueado, e o status LACP mantém o link 130-132 como sendo o link de trabalho por todo o processo (desse modo, sem interrupção de tráfego).
[0847] Para um sistema de DRCP com cada portal contendo mais de um dispositivo de rede, manter consistência entre status de DRCP e LACP exige mais esforço. Informações adicionais necessitam ser permutadas entre portais e nós para manter os portais sincronizados. Em particular, pelo menos duas chaves de operação (uma para cada sistema de portal de partner operacional) podem ser introduzidas para coordenar a sincronização. Uma é uma chave de agregador de partner de operação. A chave de agregador de partner de operação é associada ao identificador de grupo de agregação de link de agregação de um nó (LAG ID) (o nó sendo um nó de partner). A chave de agregador de partner de operação é transmitida em DRCPDUs. Em uma modalidade, a chave de agregador de partner de operação é armazenada em uma variável denominada como DRF_Home_Oper_Partner_Aggregator_Key, que é definida como uma chave de agregador de partner de operação com LAG ID de um dispositivo de rede (nó de um portal) discutido acima. A outra é uma chave de operação para cada dos sistemas de portal de partner no portal de partner. A chave de portal de vizinho de operação também é associada ao LAG ID de um nó (o nó sendo um nó de vizinho). As chaves de portal de vizinhos de operação (vizinhos imediatos ou remotos) são transmitidas em DRCPDU. Em uma modalidade, a chave de agregador de vizinho de operação é armazenada em uma variável denominada DRF_Neighbor_Oper_Partner_Aggregator_Key (DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key no caso de um terceiro Sistema de portal), que é definido como o valor de chave de agregador de partner de operação recebido por último de um nó de vizinho (ou outro vizinho no caso de um terceiro sistema de portal) em sua porta intra-portal associada (IPP).
[0848] Para as chaves de agregador ser permutadas, a DRCPDU pode adicionar um novo campo para manter uma chave de operação de partner, tal campo a ser usado para carregar DRF_Home_Oper_Partner_Aggregator_Key de um nó na DRCPDU. Uma função para registrar valor de parâmetro configurado de nó de vizinho carregado em uma DRCPDU recebida de um IPP também pode ser atualizada. Tal função, como recordNeighborState discutida acima, pode ser usada para definir chaves de agregador de partner de operação recebidas como sendo a última chave de agregador de vizinho de operação conhecida (por exemplo, definir DRF_Neigbhor_Oper_Partner_Aggregator_Key igual à DRF_Home_Oper_Partner_Aggregator_Key) recebido. Observe que quando um portal contém mais de dois nós, há múltiplos DRF_Neigbhor_Oper_Partner_Aggregator_Key ou potencialmente DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key salvos, um para cada nó de vizinho.
[0849] Com referência à figura 1B, o link K-M é o link de trabalho e o link L-O é o link de proteção. Um link IPL cada existe entre nós K e L, e M e O para manter seu status de DRCP em sincronização.
[0850] Quando o link de IPL entre nós de rede M e O desce, os dois M (atualmente nó de trabalho) e O (atualmente nó de proteção) para um serviço tentar assumir como o nó que transmite tráfego - a partir de sua perspectiva respectiva, é o nó da vizinhança que não está operando. O nó O, como um nó de proteção, atualizará seu identificador LAG (ID) para evitar ter a situação onde os dois links K-M e L-O carregam tráfego duplicata. No portal 112, nós K e L necessitam tomar decisões independentemente sobre se devem descartar ou permitir tráfego em links K-M e L-O. a decisão pode ser tomada através da troca de DRCPDUs entre nós vizinhos em uma modalidade. Além disso, a lógica de seleção aplicada por cada nó pode ser modificada para considerar as informações permutadas. Os nós K e L podem ser atualizados para permitir que tráfego passe através de seus links associados K-M e L-O respectivamente somente quando sua chave de agregador de partner de operação é o valor mais baixo de um conjunto de valores incluindo sua chave de agregador de partner de operação e sua chave(s) de portal de vizinho de operação. Para a seleção funcionar, o nó como um nó de proteção pode atualizar seu valor de chave de operação (em uma modalidade, o valor de chave de operação é atualizando utilizando uma função de atualizar como função updateKey discutida acima), quando atualiza seu ID LAG.
[0851] A figura 19 ilustra as operações do nó DRCP após perder comunicação com seu nó de vizinho de acordo com uma modalidade da invenção. O método pode ser implementado em qualquer nó de DRCP acoplado a um ou mais nós de vizinhança. Em 1902, o nó de DRCP determina que não mais está em comunicação com seu(s) nó(s) de vizinhança. A perda de comunicação pode ser devido a IPP estar desabilitado ou com defeito, ou o nó de vizinhança estar desabilitado ou com defeito. Em 1904, o nó de DRCP então determina que é um nó atualmente não carregando tráfego. Observe que um nó de DRCP pode atuar como nó de trabalho ou proteção de um portal para um serviço. Se o nó de DRCP for um nó de trabalho, nenhuma ação adicional é necessária, continuará a carregar o tráfego ativo. Se o nó de DRCP for um nó de proteção, o método continua até 1906, onde o nó de DRCP atualiza sua chave de operação e carrega o tráfego ativo. A chave de operação atualizada é definida no valor não zero numérico mais baixo do conjunto compreendendo os valores de uma chave desse nó (por exemplo, a Admin_Aggregator_Key desse nó), uma chave do nó de vizinhança (por exemplo, a _Admin_Aggregator_Key do nó de vizinhança), e uma chave do outro nó de vizinhança (por exemplo, o Admin_Aggregator_Key do outro nó de vizinhança) (quando o portal contém 3 Sistemas de Portal), em cada IPP. A chave de operação atualizada é enviada para seu nó de partner.
[0852] De acordo com modalidades, é desse modo fornecido um método realizado por um dispositivo de rede em um portal compreendendo uma pluralidade de dispositivos de rede, isto é, o dispositivo de rede sendo acoplado a pelo menos um dispositivo de rede de vizinho. O método compreende determinar que o dispositivo de rede perdeu comunicação com um ou mais dispositivos de rede de vizinho. O dispositivo de rede então determina que não está carregando tráfego sobre um grupo de agregação de link para um dispositivo de rede de partner, isto é, que está atuando como um nó de proteção. Após determinar que o dispositivo de rede é um nó de proteção, o dispositivo de rede atualiza sua chave de operação e começa a carregar tráfego através do grupo de agregação de link.
[0853] A figura 20 ilustra a operação de um nó de DRCP na coordenação com seu nó vizinho após receber múltiplos fluxos de tráfego de acordo com uma modalidade da invenção. O método pode ser implementado em qualquer nó de DRCP acoplado a um ou mais nós de vizinhança. Em 2002, o nó de DRCP determina que recebe tráfego a partir de seu partner. O partner pode ser um portal contendo múltiplos nós ou um nó único. O nó de DRCP pode ser um nó único do portal, em cujo caso, o nó de DRCP aplica operações de agregação de link normal para fazer a escolha de selecionar qual tráfego permitir passar se receber múltiplo tráfego a partir de seu partner (por exemplo, permitir passagem de tráfego no link de trabalho atual após determinar que o link e porta de agregação correspondente estão ainda no grupo de agregação de link enquanto habilita tráfego no link de proteção atual após determinar que o link de trabalho não mais está no grupo de agregação de link). Por outro lado, em 2004, o nó de DRCP determina que é acoplado a pelo menos um nó de vizinho. Quando o nó de DRCP é acoplado a pelo menos um nó vizinho, o nó de DRCP permite a passagem de tráfego a partir de seu nó partner somente quando a chave de operação de partner recebida é a mais baixa das chaves de operação de partner de todos os nós de vizinhança do portal. Em uma modalidade, isso é para determinar que a DRF_Home_Oper_Partner_Aggregator_Key do nó é mais baixa que todas as DRF_Neighbor_Oper_Partner_Aggregator_Keys do portal.
[0854] De acordo com modalidades, é desse modo fornecido um método realizado por um dispositivo de rede. O método compreende determinar que o dispositivo de rede recebe tráfego a partir de um dispositivo de rede de partner através de um grupo de agregação de link. O método compreende ainda determinar que o dispositivo de rede é acoplado a pelo menos um dispositivo de rede vizinho, o dispositivo de rede e pelo menos um dispositivo de rede vizinho sendo parte de um portal. O método compreende ainda receber uma chave de operação do dispositivo de rede de partner e determinar se deve permitir que tráfego do dispositivo de rede de partner com base em uma comparação da chave de operação do dispositivo de rede de partner e chaves de operação dos dispositivos de rede do portal. Isso pode ser realizado por determinar que a chave de operação do dispositivo de rede de partner é mais baixa que as chaves de operação dos dispositivos de rede do portal.
[0855] A figura 27 ilustra a operação de um nó de DRCP na coordenação com seu nó vizinho após uma condição de falha de comunicação em uma modalidade da invenção. O método 2800 pode ser implementado em um nó de DRCP (por exemplo, um dispositivo de rede) de um portal de DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C, onde o nó é acoplado a um ou mais nós de vizinhança. Em 2702, o nó de DRCP determina que recebe tráfego a partir de seu partner. O partner pode ser um portal contendo múltiplos nós ou um nó único. O nó de DRCP pode ser um nó único do portal, em cujo caso, o nó de DRCP aplica operações de agregação de link normais para fazer a escolha de selecionar qual tráfego permitir passar se receber múltiplo tráfego a partir de seu partner (por exemplo, permitir passagem de tráfego no link de trabalho atual após determinar o link e porta de agregação correspondente ainda está no grupo de agregação de link enquanto habilita tráfego no link de proteção atual após determinar que o link de trabalho não mais está no grupo de agregação de link). Por outro lado, em 2704, o nó de DRCP determina que é acoplado a pelo menos um nó vizinho.
[0856] Em 2706, o nó de DRCP determina se a chave de operação recebida foi atualizada. Em uma modalidade, a atualização é devido a um IPL falho/com defeito. O nó de DRCP pode determinar que o sistema de partner está experimentando o IPL falho/com defeito se os dois bits mais significativos do Partner_Oper_Key recebido forem iguais ao valor 2 ou 3 e os dois bits menos significativos de Partner_Oper_Port_Priority da Porta de agregação forem iguais ao valor 2 ou 3.
[0857] Em 2708, o nó DRCP determina se está isolado ou não a partir de seu(s) nó(s) de vizinhança do mesmo portal. O nó de DRCP pode ser isolado a partir de seu(s) nó(s) de vizinhança devido a IPL falho/com defeito. Nesse caso, o nó de DRCP determina que as comunicações de IPL em portais locais e remotos são ambas falhas.
[0858] Em 2710, o nó de DRCP determina se está compreendido no Sistema de portal de prioridade mais elevada e atua para evitar tráfego duplicado se estiver. Em uma modalidade, o nó de DRCP determina se tem o identificador de sistema de portal de prioridade mais elevada do que seu portal de partner (por exemplo, na figura 1B, o portal 112 pode ser o portal de prioridade mais elevada que o portal 114, em cujo caso executa 2710), e abandona tráfego recebido se tiver o identificador de sistema de portal mais elevado.
[0859] De acordo com modalidades é desse modo fornecido um método executado por um dispositivo de rede. O método compreende determinar que o dispositivo de rede receba tráfego a partir de um dispositivo de rede de partner através de um grupo de agregação de link. O método compreende ainda determinar que o dispositivo de rede é acoplado a pelo menos um dispositivo de rede vizinho, o dispositivo de rede e pelo menos um dispositivo de rede vizinho sendo parte de um portal acoplado a pelo menos um nó vizinho. O método compreende ainda que o dispositivo de rede determine se a chave de operação recebida foi atualizada, e determina se é isolada ou não a partir de seu(s) nó(s) de vizinhança do mesmo portal. O método compreende ainda que o dispositivo de rede abandone tráfego recebido se tiver o identificador de sistema de portal mais elevado que seu portal partner. As modalidades da invenção fornecem, desse modo, um modo eficiente para coordenar status dos nós de vizinhança e nós de partner de modo que nenhum tráfego duplicado interrompa recepção de tráfego no grupo de agregação de link implementado DRCP.
[0860] Coordenação entre status de LACP e DRCP: um segundo conjunto de modalidades
[0861] Para coordenar entre status DRCP e LACP, um modo alternativo é atualizar algumas funções/variáveis existentes e operar diferentemente se o nó de DRCP tanto local como partner pode comunicar seu status de IPL.
[0862] A figura 26A ilustra um TLV de máscara de conversação para uma porta de agregação de acordo com uma modalidade da invenção. Observe que o TLV de máscara de conversação é igual ao ilustrado na figura 4A do pedido de patente US número 14/135,556, que é incorporado a título de referência na íntegra como mencionado aqui. A figura 26B é diferente da figura 4B do pedido de patente US no. 14/135.556 em que um campo, PSI (estado de portal isolado) na referência 2611 substitui um bit reservado. Esse sinalizador é somente aplicável para Sistemas de Portal e é usado para indicar se o Sistema de Portal é isolado dos outros Sistemas de portal no Portal ().TRUE (codificado como um 1) se DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE em todos os IPPs nesse Sistema de Portal. Seu valor é de outro modo FALSE (codificado como um 0).
[0863] Além disso, a função ReceivedConversationMaskTLV revelada no pedido de patente US no. 14/135.556 pode ser atualizada com a seguinte operação adicional: também registra o valor de parâmetro para o PSI carregado em uma Máscara de conversação de porta recebida como os valores de parâmetro operacional atuais para o Partner_PSI.
[0864] Adicionalmente, a função upddateConversationMaskTLV revelada no pedido de patente US no. 15/135.556 pode ser atualizada com a seguinte operação adicional: se essa função for implementada por um Sistema de portal de DRCP, com seu valor de DRF_Portal_System_Number definido em um valor que numericamente mais baixo que o Identificador de sistema de Partner, e PSI == Partner_PSI == TRUE, então Comp_Oper_Conversation_Mask é definido em NULL.
[0865] Por exemplo, com referência à figura 1B, quando ambos os IPLs em K/L e M/O falham, todos os nós transmitiriam tráfego - os nós ativos K e M transmitem tráfego visto que são nós ativos, e os nós de proteção L e M também transmitem tráfego visto que são isolados de nós ativos e agora se consideram como sendo ativos. Quando PSI é suportado nos dois portais 112 e 114, o PSI e PSI partner recebido seriam TRUE. Assumindo que o portal 112 é um portal de prioridade mais elevada (por exemplo, Identificador de sistema do Portal 112 é mais baixo que o Portal 114 desse modo sua prioridade é mais elevada), então o nó L determina que um número de sistema de portal (assumindo como sendo 2 visto que é um portal de dois nós, e o nó de trabalho K tem número de sistema de portal 1) não é o mais baixo, atualizará sua máscara de conversação de operação em mulo, e não transmite ou recebe tráfego.
[0866] A figura 28 ilustra a operação de um nó de DRCP após uma falha de comunicação de acordo com uma modalidade da invenção. O método 2800 pode ser implementado em um nó de DRCP (por exemplo, um dispositivo de rede) de um portal de DRCP (mencionado como um portal local) como uma parte de um DRNI como nós K-O da figura 1B e dispositivos de rede 132 e 134 da figura 1C. em 2802, o nó de DRCP determina que não mais está em comunicação com seu(s) nó(s) de vizinhança. A perda de comunicação pode ser devido a IPP ser desabilitado ou com defeito, ou o nó de vizinhança ser desabilitado ou com defeito. A perda de comunicação pode ser indicada no bit de PSI sendo definido em TRUE (que é enviado através de um TLV em uma LACPDU discutida acima) em uma modalidade.
[0867] Em 2804, o nó determina que seu nó partner não mais está em comunicação com o nó de vizinhança de partner. O nó partner pode enviar seu status PSI através de sua LACPDU e o PSI serão registrado pela função recordReceivedConversationMaskTLV de partner. Quando o nó partner não mais está em comunicação com seu nó de vizinhança, o status de PSI recebido será definido em TRUE, em cujo caso PSI == Partner_PSI == TRUE.
[0868] Em 2806, o nó determina que seu não é um portal de prioridade mais elevada do que aquela de seu nó partner. O Portal sendo um portal de prioridade mais elevada pode ser determinado com base nos identificadores do sistema de portal do nó e o nó partner em uma modalidade.
[0869] Em 2808, o nó determina que não é o nó de prioridade mais elevada de seu portal. A prioridade do nó em seu portal pode ser determinada por seu número de sistema de portal, que está entre 1 e 3 em uma modalidade (para um portal de até 3 nós). O nó determina que não é o nó de prioridade mais elevada de seu portal se seu número de sistema de portal não for 1 em uma modalidade.
[0870] Em 2810, o nó para transmissão e recepção de tráfego do grupo de agregação de link. Em uma modalidade, o nó define sua Comp_Oper_Conversation_Mask, que é o valor operacional da mascara de conversação de operação do nó computada por uma função de máscara de conversação de atualização (por exemplo, updateConversationMask).
[0871] De acordo com as modalidades, é desse modo fornecido um método realizado por um dispositivo de rede em um portal compreendendo uma pluralidade de dispositivos de rede, isto é, o dispositivo de rede sendo acoplado pelo menos a um dispositivo de rede de vizinho. O método compreende determinar que seu nó partner não mais está em comunicação com o nó de vizinhança de partner. O dispositivo de rede então determina que seu portal é um portal de prioridade mais elevada que aquela de seu nó partner. O dispositivo de rede então determina que não é o nó de prioridade mais elevada de seu portal, e para a transmissão e recepção de tráfego após a determinação. As modalidades da invenção fornecem, desse modo, um modo eficiente para coordenar status dos nós de vizinhança e nós de partner de modo que nenhum tráfego duplicado interrompa a recepção de tráfego no grupo de agregação de link contendo DRCP.
[0872] Modalidade de dispositivos de rede
[0873] A figura 13 é um diagrama de uma modalidade de exemplo de um dispositivo de rede para executar funcionalidade de DRNI descrita aqui. O dispositivo de rede 1380 pode ser um roteador ou dispositivo similar implementando uma subcamada de agregação de link 1370 como descrito acima em relação à figura 2 e suporta as funções de agregação de link descritas acima. O dispositivo de rede 1380 pode incluir um processador de rede 1300, um conjunto de portas 1340, um dispositivo de armazenagem 1350 e componentes de dispositivo de rede similares. Os componentes do dispositivo de rede são fornecidos como exemplo, e não limitação. O dispositivo de rede 1380 pode implementar as funções de agregação e a subcamada de agregação de link 1370 utilizando qualquer número ou tipo de processadores e com qualquer configuração. Em outras modalidades, as funções de agregação e subcamada de agregação de link e componentes relacionados são distribuídos sobre um conjunto de processadores de rede, um conjunto de cartões de linha e seu processador específico de aplicativo e propósito geral constituinte ou similar implementado em uma arquitetura de dispositivo de rede.
[0874] As portas 1340 podem conectar o dispositivo de rede através de um meio físico como Ethernet, fibra ótica, ou meio similar com qualquer número de outros dispositivos de rede. Qualquer número e variedade de portas podem estar presente no dispositivo de rede 1380. Qualquer combinação ou subconjunto das portas 1340 pode ser organizado e gerenciado como um Grupo de agregação de link ou um Portal de DRNI onde o dispositivo de rede funciona como um Sistema de agregação. Desse modo, portas podem ser portas de agregação para um ou mais grupos de agregação de link.
[0875] Um conjunto de dispositivos de armazenagem 1350 no dispositivo de rede 1380 pode ser qualquer tipo de dispositivos de memória, caches, registros ou dispositivos de armazenamento similares para uso como memória de trabalho e/ou armazenagem persistente. Qualquer número e variedade de dispositivos de armazenagem 1350 pode ser utilizado para armazenar os dados do dispositivo de rede incluindo dados programados e tráfego de dados recebidos a serem processados pelo dispositivo de rede 1380. Em uma modalidade, estruturas de dados de DRNI ou organização similar do resumo de mapeamento de serviço de conversação, máscaras de conversação, e estruturas de dados similares descritas acima podem ser armazenados em tal estrutura de dados. Outras estruturas de dados armazenadas no dispositivo de armazenagem 1350 podem incluir aquelas descritas acima. Em outras modalidades, essas estruturas de dados podem ser concebidas como sendo independentes e podem ser distribuídas sobre qualquer número de dispositivos de armazenagem separados 1350 no dispositivo de rede 1380.
[0876] Um conjunto de processadores de rede 1300 pode implementar as funções de DRNI e agregação e a subcamada de agregação de link 1370 descrita acima. As funções de agregação podem incluir cliente(s) de agregador 1372 e a Subcamada de agregação de link 1370, que pode incluir multiplexor/analisador de controle 1302, controlador de agregação 1306, coletor de quadro 1325, distribuidor de quadro 1320 e DRNI 1313.
[0877] O controlador de agregação 1306 como descrito adicionalmente acima, pode implementar controle de agregação de link e funções de protocolo de controle de agregação de link. Essas funções gerenciam a configuração e alocação de grupos de agregação de link, o Portal de DRNI e aspectos similares. O multiplexor e analisador de controle 1302 identificam e enviam LACPDUs a partir do outro tráfego de dados recebido nas portas de agregação e envia as LACPDUs para o controlador de agregação 1306 e outro tráfego de dados na subcamada de agregação de link 1370.
[0878] A subcamada de agregação de link 1370 como descrito acima, gerencia a coleta e distribuição dos quadros de acordo com o algoritmo de distribuição. Na subcamada de agregação de link 1370, o coletor de quadro 1325 recebe os quadros e organiza os mesmos de acordo com o algoritmo de distribuição comcompartilhamentodo com o sistema de partner através do grupo de agregação de link. Um distribuidor de quadro 1320 prepara e seleciona os quadros de saída para transmissão sobre um conjunto de portas de agregação de acordo com o algoritmo de distribuição. Uma interface de cliente recebe e transmite quadros para e a partir do(s) cliente(s) de agregador 1372. Quadros de saída são passados a partir do coletor de quadro 1325 para o(s) cliente(s) de agregador 1372. As funções de DRNI 1311 descritas acima são executadas pelo processador de rede 1311.
[0879] Embora a invenção tenha sido descrita em termos de várias modalidades de exemplo, aqueles versados na técnica reconhecerão que a invenção não é limitada às modalidades descritas, pode ser posta em prática em prática com modificação e alteração no espírito e escopo das reivindicações apensas. A descrição deve ser desse modo considerada como ilustrativa em vez de limitadora.

Claims (12)

1. Método de suportar uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link em um dispositivo de rede, em que o dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos de rede remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intra-portal (IPL), caracterizado pelo fato de compreender: encapsular (3202) uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, em que a DRCPDU inclui uma estrutura de unidade de dados de protocolo (PDU), e em que a estrutura de PDU inclui: um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminador indicando término da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas ao IPP, um TLV de informação de porta nativa indicando um status atual do dispositivo de rede em associação ao DRNI, e um TLV de informação de portas vizinhas indicando um status atual do dispositivo de rede vizinho em associação a DRNI; e transmitir (3206) o quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através do IPP.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o TLV terminador inclui: um campo do tipo TLV indicando um valor de zero; e um campo de comprimento do TLV indicando um valor de zero.
3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o TLV de informação de portal inclui: um campo do tipo TLV indicando um valor de hexadecimal um; um campo de comprimento para o TLV indicando um valor de 18 octetos; um campo de prioridade de agregador indicando uma prioridade atribuída a um agregador do dispositivo de rede; um campo de identificador de agregador indicando um identificador do agregador; um campo de prioridade de portal indicando uma prioridade atribuída ao primeiro portal; e um campo de endereço de portal indicando um componente de endereço MAC associado ao dispositivo de rede.
4. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o TLV de informação de configuração de portal inclui: um campo do tipo TLV indicando um valor de hexadecimal dois; um campo de estado de topologia indicando um estado de topologia do primeiro portal; um campo de comprimento para o TLV indicando um valor de 46 octetos; um campo de chave de agregador operacional indicando uma chave de agregador operacional do dispositivo de rede; um campo de algoritmo de portal indicando um algoritmo de portal usado; um campo de algoritmo de gateway indicando um algoritmo de gateway usado; um campo de compilação de porta indicando uma compilação de porta usada para identificador de conversação de porta (ID) para atribuição de porta de agregação; e um campo de compilação de gateway indicando uma compilação de gateway usada para identificador de conversação de gateway para atribuição de gateway.
5. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o TLV de estado de DRCP inclui: um campo do tipo TLV indicando um valor de hexadecimal três; um campo de comprimento para o TLV indicando um valor de três octetos; e um campo de estado de DRCP indicando variáveis associadas ao IPP.
6. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o TLV de informações de portas nativas inclui: um campo do tipo de TLV indicando um valor de hexadecimal quatro; um campo de comprimento para o TLV indicando um valor de quatro vezes um número das portas de agregação de dispositivo de rede que são incluídas no TLV; um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo de um agregador anexado; um campo de chave de agregador associado operacional indicando uma chave de agregador associado operacional, associado com o ID LAG de agregador do dispositivo de rede; e um campo de porta de agregação ativa indicando uma lista de portas de agregação ativas no dispositivo de rede.
7. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que TLV de informação de portas vizinhas inclui: um campo do tipo TLV indicando um valor de hexadecimal cinco; um campo de comprimento para o TLV indicando um valor de quatro vezes um número das portas de agregação do dispositivo de rede vizinho que são incluídas no TLV; um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo de um agregador fixado ao dispositivo de rede vizinho; um campo de chave de agregador associado operacional indicando uma chave de agregador associado operacional associado ao ID LAG de agregador do dispositivo de rede vizinho; e um campo de porta de agregação ativa indicando uma lista de portas de agregação ativas no dispositivo de rede vizinho associado ao IPP.
8. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que o conjunto de TLVs inclui ainda um TLV de informação de outras portas quando o primeiro portal inclui outro dispositivo de rede vizinho (mencionado como um terceiro dispositivo de rede do portal), e em que o TLV de informação de outras portas inclui: um campo do tipo TLV indicando um valor de hexadecimal seis; um campo de comprimento para o TLV indicando um valor de quatro vezes um número das portas de agregação do terceiro dispositivo de rede que são incluídas no TLV; um campo de chave de agregador administrativo indicando um valor de chave de agregador administrativo de um agregador fixado ao terceiro dispositivo de rede; um campo de chave de agregador associado operacional indicando uma chave de agregador associado operacional associado ao ID LAG de agregador do terceiro dispositivo de rede; e um campo de porta de agregação ativa indicando uma lista de portas de agregação ativa no terceiro dispositivo de rede associado ao IPP.
9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o conjunto de TLVs inclui ainda um TLV de método de compartilhamento de IPL/rede e um TLV de encapsulamento de compartilhamento de IPL/rede, em que o TLV de método de compartilhamento de IPL/rede indica método de compartilhamento de IPL e rede associado ao dispositivo de rede, e em que o TLV de encapsulamento de compartilhamento de IPL/rede indica informação referente à encapsulamento do método de compartilhamento.
10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o conjunto de TLVs inclui ainda um ou mais TLVs reservados para IEEE 802.1 e um TLV específico de organização.
11. Dispositivo de rede suportando uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link, em que o dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos de rede remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intra-portal (IPL), caracterizado pelo fato de compreender: portas (1340) acopladas ao link de agregação ou físico do grupo de agregação de link; um processador de rede (1300) acoplado às portas, executando uma função DRNI (1313), a função DRNI operativa para causar a encapsulamento de uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, e adicionalmente operativa para causar transmissão do quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através do IPP, em que a DRCPDU inclui uma estrutura de unidade de dados de protocolo (PDU), e em que a estrutura de PDU inclui: um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminador indicando término da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas ao IPP, um TLV de informação de porta nativa indicando um status atual do dispositivo de rede em associação ao DRNI, e um TLV de informação de portas vizinhas indicando um status atual do dispositivo de rede vizinho em associação a DRNI.
12. Meio de armazenamento legível em máquina não transitório tendo instruções armazenadas no mesmo, que quando executadas por um processador, fazem com que o processador execute operações em um dispositivo de rede para suportar uma interconexão de rede resiliente distribuída (DRNI) em um grupo de agregação de link, em que o dispositivo de rede e um dispositivo de rede vizinho são incluídos em um primeiro portal do grupo de agregação de link, em que o primeiro portal é acoplado através de links do grupo de agregação de link com um segundo portal incluindo um ou mais dispositivos de rede remotos, em que o dispositivo de rede é comunicativamente acoplado ao dispositivo de rede vizinho através de uma porta intra-portal (IPP) utilizando um link intraportal (IPL), caracterizado pelo fato de que as operações compreendem: encapsular (3202) uma unidade de dados de protocolo de controle de retransmissão distribuída (DRCPDU) em um quadro, em que a DRCPDU inclui uma estrutura de unidade de dados de protocolo (PDU), e em que a estrutura de PDU inclui: um campo de tipo indicando que a DRCPDU é para DRCP, um campo de versão indicando um número de versão do DRCP, e um conjunto de valores/comprimento/tipo (TLVs) incluindo: um TLV terminador indicando término da estrutura de PDU, um TLV de informação de portal indicando características do primeiro portal, um TLV de informação de configuração de portal indicando informação de configuração do primeiro portal, um TLV de estado de DRCP indicando variáveis associadas ao IPP, um TLV de informação de porta nativa indicando um status atual do dispositivo de rede em associação ao DRNI, e um TLV de informação de portas vizinhas indicando um status atual do dispositivo de rede vizinho em associação a DRNI; e transmitir (3206) o quadro encapsulando a DRCPDU a partir do dispositivo de rede para o dispositivo de rede vizinho através do IPP.
BR112015026779-3A 2013-04-23 2014-04-22 Método para suportar uma interconexão de rede resiliente distribuída em um grupo de agregação de link em um dispositivo de rede, dispositivo de rede e meio de armazenamento legível em máquina não transitório relacionados BR112015026779B1 (pt)

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US201361815204P 2013-04-23 2013-04-23
US201361839022P 2013-06-25 2013-06-25
US201361865126P 2013-08-12 2013-08-12
US61/865,126 2013-08-12
US201361902518P 2013-11-11 2013-11-11
US61/902,518 2013-11-11
US201361918610P 2013-12-19 2013-12-19
US61/918,610 2013-12-19
US201461941977P 2014-02-19 2014-02-19
US61/941,977 2014-02-19
US201461953360P 2014-03-14 2014-03-14
US61/953,360 2014-03-14
US14/257,360 US9497074B2 (en) 2013-04-23 2014-04-21 Packet data unit (PDU) structure for supporting distributed relay control protocol (DRCP)
PCT/IB2014/060913 WO2014174440A1 (en) 2013-04-23 2014-04-22 A packet data unit (pdu) structure for supporting distributed relay control protocol (drcp)

Publications (2)

Publication Number Publication Date
BR112015026779A2 BR112015026779A2 (pt) 2017-07-25
BR112015026779B1 true BR112015026779B1 (pt) 2023-04-11

Family

ID=51728923

Family Applications (5)

Application Number Title Priority Date Filing Date
BR112015026779-3A BR112015026779B1 (pt) 2013-04-23 2014-04-22 Método para suportar uma interconexão de rede resiliente distribuída em um grupo de agregação de link em um dispositivo de rede, dispositivo de rede e meio de armazenamento legível em máquina não transitório relacionados
BR112015026775A BR112015026775A2 (pt) 2013-04-23 2014-04-23 método e sistema para sincronização com vizinho em um grupo de agregação de link de interconexão de rede resiliente distribuída (drni)
BR112015026664A BR112015026664A2 (pt) 2013-04-23 2014-04-23 método e sistema para atualização de estados de interconexão de rede resiliente distribuída (drni)
BR112015026670A BR112015026670A2 (pt) 2013-04-23 2014-04-23 método e sistema para suportar operações de protocolo de controle de retransmissão distribuída (drcp) após falha de comunicação
BR112015026673A BR112015026673A2 (pt) 2013-04-23 2014-04-23 método e sistema para sincronização com vizinho em um grupo de agregação de link com interconexão de rede resiliente distribuída (drni)

Family Applications After (4)

Application Number Title Priority Date Filing Date
BR112015026775A BR112015026775A2 (pt) 2013-04-23 2014-04-23 método e sistema para sincronização com vizinho em um grupo de agregação de link de interconexão de rede resiliente distribuída (drni)
BR112015026664A BR112015026664A2 (pt) 2013-04-23 2014-04-23 método e sistema para atualização de estados de interconexão de rede resiliente distribuída (drni)
BR112015026670A BR112015026670A2 (pt) 2013-04-23 2014-04-23 método e sistema para suportar operações de protocolo de controle de retransmissão distribuída (drcp) após falha de comunicação
BR112015026673A BR112015026673A2 (pt) 2013-04-23 2014-04-23 método e sistema para sincronização com vizinho em um grupo de agregação de link com interconexão de rede resiliente distribuída (drni)

Country Status (24)

Country Link
US (12) US9497074B2 (pt)
EP (8) EP2989761A1 (pt)
JP (4) JP6074110B2 (pt)
KR (4) KR101706007B1 (pt)
CN (7) CN105308913B (pt)
AU (3) AU2014259015B2 (pt)
BR (5) BR112015026779B1 (pt)
CA (3) CA2910149A1 (pt)
CL (1) CL2015003149A1 (pt)
DK (1) DK2989759T3 (pt)
ES (3) ES2662111T3 (pt)
HK (2) HK1221096A1 (pt)
HU (1) HUE038567T2 (pt)
IL (2) IL241893B (pt)
MA (2) MA38596A1 (pt)
MX (3) MX350401B (pt)
MY (1) MY182277A (pt)
PH (2) PH12015502296B1 (pt)
PL (2) PL2989762T3 (pt)
RU (2) RU2620995C2 (pt)
SG (2) SG11201508359VA (pt)
TR (1) TR201802416T4 (pt)
WO (6) WO2014174440A1 (pt)
ZA (1) ZA201507972B (pt)

Families Citing this family (78)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9264298B2 (en) * 2012-03-02 2016-02-16 Telefonaktiebolaget L M Ericsson (Publ) Technique for bundling in link aggregation
US9232615B2 (en) 2012-07-03 2016-01-05 Smartlabs, Inc. Simulcast mesh dimmable illumination source
US9497132B2 (en) 2013-04-23 2016-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and system of implementing conversation-sensitive collection for a link aggregation group
KR101360848B1 (ko) 2013-04-23 2014-02-11 주식회사 쏠리드 광 네트워크 시스템
US9553798B2 (en) 2013-04-23 2017-01-24 Telefonaktiebolaget L M Ericsson (Publ) Method and system of updating conversation allocation in link aggregation
US9497074B2 (en) 2013-04-23 2016-11-15 Telefonaktiebolaget L M Ericsson (Publ) Packet data unit (PDU) structure for supporting distributed relay control protocol (DRCP)
CN104125088B (zh) 2013-04-28 2019-05-10 中兴通讯股份有限公司 Drni中同一端内系统之间交互信息的方法和系统
US9300484B1 (en) * 2013-07-12 2016-03-29 Smartlabs, Inc. Acknowledgement as a propagation of messages in a simulcast mesh network
CN104579728B (zh) * 2013-10-17 2019-02-26 中兴通讯股份有限公司 网元设备配置和管理方法、装置及网元设备
US9251700B2 (en) 2013-10-28 2016-02-02 Smartlabs, Inc. Methods and systems for powerline and radio frequency communications
US9654418B2 (en) 2013-11-05 2017-05-16 Telefonaktiebolaget L M Ericsson (Publ) Method and system of supporting operator commands in link aggregation group
US9529345B2 (en) 2013-12-05 2016-12-27 Smartlabs, Inc. Systems and methods to automatically adjust window coverings
US9866470B2 (en) * 2014-01-24 2018-01-09 Red Hat, Inc. Multiple active link aggregators
GB2524750B (en) * 2014-03-31 2021-04-21 Metaswitch Networks Ltd Spanning tree protocol
US9813290B2 (en) 2014-08-29 2017-11-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for supporting distributed relay control protocol (DRCP) operations upon misconfiguration
US9425979B2 (en) 2014-11-12 2016-08-23 Smartlabs, Inc. Installation of network devices using secure broadcasting systems and methods from remote intelligent devices
US9438573B2 (en) 2014-11-12 2016-09-06 Smartlabs, Inc. Systems and methods to securely install network devices using physical confirmation
US9531587B2 (en) 2014-11-12 2016-12-27 Smartlabs, Inc. Systems and methods to link network controllers using installed network devices
US9155153B1 (en) 2014-12-01 2015-10-06 Smartlabs, Inc. Sensor lighting control systems and methods
US9578443B2 (en) 2014-12-19 2017-02-21 Smartlabs, Inc. Smart home device adaptive configuration systems and methods
US9985796B2 (en) 2014-12-19 2018-05-29 Smartlabs, Inc. Smart sensor adaptive configuration systems and methods using cloud data
US11489690B2 (en) 2014-12-19 2022-11-01 Smartlabs, Inc. System communication utilizing path between neighboring networks
WO2017015899A1 (zh) * 2015-07-29 2017-02-02 华为技术有限公司 邻居建立的方法、设备和系统
WO2017156001A1 (en) * 2016-03-07 2017-09-14 Level 3 Communications, Llc Systems and methods for dynamically connecting network elements to enable a service
US10454766B2 (en) * 2016-04-21 2019-10-22 Super Micro Computer, Inc. Automatic configuration of a network switch in a multi-chassis link aggregation group
CN105959269B (zh) * 2016-04-25 2019-01-25 北京理工大学 一种基于身份的可认证动态群组密钥协商方法
US10178152B2 (en) * 2016-04-29 2019-01-08 Splunk Inc. Central repository for storing configuration files of a distributed computer system
US10218699B2 (en) * 2016-07-22 2019-02-26 Rockwell Automation Technologies, Inc. Systems and methods for adding a non-inherent component to a device key of a networked device
CN106375390B (zh) * 2016-08-29 2019-11-12 北京爱接力科技发展有限公司 一种物联网中数据传输方法、系统及其装置
JP2019530347A (ja) * 2016-09-26 2019-10-17 ホアウェイ・テクノロジーズ・カンパニー・リミテッド デバイスツーデバイスデータ伝送方法、装置、およびシステム
CN106656554A (zh) * 2016-10-14 2017-05-10 盛科网络（苏州）有限公司 Mlag环境下实现lacp的方法及装置
EP3535926B1 (en) * 2016-11-26 2021-04-28 Huawei Technologies Co., Ltd. System, method and devices for mka negotiation between the devices
CN106878164B (zh) * 2016-12-13 2020-04-03 新华三技术有限公司 一种报文传输方法和装置
US10856203B2 (en) 2017-01-19 2020-12-01 Qualcomm Incorporated Signaling for link aggregation setup and reconfiguration
US11337263B2 (en) 2017-01-19 2022-05-17 Qualcomm Incorporated Packet based link aggregation architectures
CN108667640B (zh) * 2017-03-29 2021-09-07 北京华为数字技术有限公司 通信方法及设备、网络接入系统
CN107547370B (zh) * 2017-09-25 2020-05-12 新华三技术有限公司 流量转发方法、装置及系统
CN107743101B (zh) * 2017-09-26 2020-10-09 杭州迪普科技股份有限公司 一种数据的转发方法及装置
CN111386677B (zh) * 2017-11-24 2022-02-01 德国电信股份有限公司 具有远程接入服务器的接入网
US11095617B2 (en) 2017-12-04 2021-08-17 Nicira, Inc. Scaling gateway to gateway traffic using flow hash
US11075888B2 (en) * 2017-12-04 2021-07-27 Nicira, Inc. Scaling gateway to gateway traffic using flow hash
CN108173757B (zh) * 2017-12-26 2020-08-11 新华三技术有限公司 端口状态设置方法及装置
US11140200B1 (en) 2017-12-29 2021-10-05 Juniper Networks, Inc. Distributing a network policy using connectivity fault management
US11190440B2 (en) * 2018-01-19 2021-11-30 Vmware, Inc. Methods and apparatus to configure and manage network resources for use in network-based computing
CN108322338B (zh) * 2018-01-23 2021-02-26 新华三技术有限公司 一种广播抑制方法和vtep设备
US11102142B2 (en) 2018-01-24 2021-08-24 Vmware, Inc. Methods and apparatus to perform dynamic load balancing for a multi-fabric environment in network-based computing
CN108199903B (zh) * 2018-01-25 2021-03-02 新华三技术有限公司 分布式聚合系统配置方法及装置
CN108337159B (zh) * 2018-01-31 2021-05-28 新华三技术有限公司 端口操作控制方法及装置
US10616319B2 (en) 2018-02-06 2020-04-07 Vmware, Inc. Methods and apparatus to allocate temporary protocol ports to control network load balancing
US10681649B2 (en) * 2018-02-19 2020-06-09 Qualcomm Incorporated Dynamic spatial reuse in distribution networks
US11347561B1 (en) 2018-04-30 2022-05-31 Vmware, Inc. Core to resource mapping and resource to core mapping
CN108737189B (zh) * 2018-05-25 2021-11-05 新华三技术有限公司 Dr设备角色更新方法及装置
JP7063145B2 (ja) * 2018-06-29 2022-05-09 住友電気工業株式会社 通信装置および通信装置の制御方法
CN109088752B (zh) * 2018-07-25 2022-02-11 新华三技术有限公司 内部控制链路端口动态配置方法及相关装置
CN110830925B (zh) * 2018-08-14 2021-10-19 华为技术有限公司 一种用户群组的会话管理方法及装置
CN109347734B (zh) * 2018-08-29 2021-05-07 新华三技术有限公司 一种报文发送方法、装置、网络设备和计算机可读介质
EP3853708B1 (en) * 2018-09-19 2024-03-06 Amazon Technologies, Inc. Scalable cell based packet processing service using client provided decision metadata
US10742569B2 (en) * 2018-11-12 2020-08-11 Cisco Technology, Inc. Efficient network link status handling
CN109688060B (zh) * 2018-12-29 2021-06-29 杭州迪普科技股份有限公司 链路分组配置方法、装置及路由器
HUE059579T2 (hu) 2019-05-02 2022-11-28 Ericsson Telefon Ab L M A PDU munkamenet(ek)re vonatkozó GPSI rendelkezés
CN114073043B (zh) * 2019-05-03 2023-09-05 诺基亚技术有限公司 以太网网桥端口管理的方法和装置
US11277343B2 (en) 2019-07-17 2022-03-15 Vmware, Inc. Using VTI teaming to achieve load balance and redundancy
KR20210000790U (ko) 2019-10-01 2021-04-09 송유진 가로수의 낙하물 수거망
US11563642B2 (en) * 2019-10-15 2023-01-24 Rockwell Collins, Inc. Smart point of presence (SPOP) aircraft-based high availability edge network architecture
US11431620B2 (en) * 2019-10-28 2022-08-30 Dell Products L.P. Control packet transmission system
US11509638B2 (en) 2019-12-16 2022-11-22 Vmware, Inc. Receive-side processing for encapsulated encrypted packets
CN111147332B (zh) * 2019-12-29 2022-04-29 北京浪潮数据技术有限公司 存储系统云备份的上传进度确定方法、系统及相关装置
CN113067771B (zh) * 2020-01-02 2022-11-01 上海诺基亚贝尔股份有限公司 管理虚拟链路聚合信道
CN111835560B (zh) * 2020-06-29 2024-02-09 新华三信息安全技术有限公司 一种分布式弹性网络互连系统及其部署方法
CN113872843B (zh) * 2020-06-30 2022-12-06 华为技术有限公司 一种路由生成方法、路由处理方法及装置
CN111953591A (zh) * 2020-07-17 2020-11-17 新华三技术有限公司 故障处理方法及装置
US11425605B1 (en) 2020-12-31 2022-08-23 Rockwell Collins, Inc. Automatic link establishment system and method for asymmetric link
CN114070636B (zh) * 2021-11-22 2023-08-11 迈普通信技术股份有限公司 安全控制方法、装置，交换机，服务器及网络系统
CN114221899B (zh) * 2021-11-30 2024-03-08 新华三技术有限公司合肥分公司 一种故障处理方法及装置
CN113867796B (zh) * 2021-12-02 2022-02-22 南湖实验室 利用多状态机提高读性能的协议转换桥及实现方法
US11863514B2 (en) 2022-01-14 2024-01-02 Vmware, Inc. Performance improvement of IPsec traffic using SA-groups and mixed-mode SAs
US11956213B2 (en) 2022-05-18 2024-04-09 VMware LLC Using firewall policies to map data messages to secure tunnels
CN115333974B (zh) * 2022-08-10 2023-08-11 杭州云合智网技术有限公司 Drni网络中基于vsi的环路检测方法及装置

Family Cites Families (100)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430183B1 (en) 1997-09-18 2002-08-06 International Business Machines Corporation Data transmission system based upon orthogonal data stream mapping
US6445715B1 (en) 1998-08-27 2002-09-03 Cisco Technology, Inc. Dynamic trunk protocol
US6553568B1 (en) 1999-09-29 2003-04-22 3Com Corporation Methods and systems for service level agreement enforcement on a data-over cable system
US6687751B1 (en) 2000-01-28 2004-02-03 3Com Corporation Multi-point link aggregation spoofing
US20020040389A1 (en) * 2000-10-03 2002-04-04 Wirespring Technologies, Inc. System and method for remotely-managed content distribution network
US7787447B1 (en) 2000-12-28 2010-08-31 Nortel Networks Limited Voice optimization in a network having voice over the internet protocol communication devices
US6910149B2 (en) 2001-09-24 2005-06-21 Intel Corporation Multi-device link aggregation
AU2003255869A1 (en) 2002-08-29 2004-03-19 Koninklijke Philips Electronics N.V. Reconfigurable electronic device having interconnected data storage devices
US7613201B1 (en) 2003-04-18 2009-11-03 Rmi Corporation Stacked network switch using resilient packet ring communication protocol
JP4195716B2 (ja) 2003-06-27 2008-12-10 ノキア コーポレイション 無線通信ネットワークでのパケット集約のための方法及び装置
US7301949B2 (en) * 2003-07-15 2007-11-27 Telefonaktiebolaget Lm Ericsson (Publ) Arrangements for connection-oriented transport in a packet switched communications network
US7602726B1 (en) 2003-08-11 2009-10-13 Cisco Technology, Inc. Method and system for optimizing link aggregation usage during failures
KR101000699B1 (ko) * 2004-04-19 2010-12-10 엘지전자 주식회사 무선링크 제어계층에서의 데이터 처리방법
US7941177B2 (en) 2004-09-15 2011-05-10 Samsung Electronics Co., Ltd Wireless terminal apparatus for automatically changing WLAN standard and method thereof
WO2006044820A2 (en) 2004-10-14 2006-04-27 Aventail Corporation Rule-based routing to resources through a network
EA200401599A1 (ru) * 2004-12-10 2005-10-27 Закрытое Акционерное Общество "Микротест-Инвест" Система, способы и устройства, предназначенные для интеграции распределенных приложений
KR100664312B1 (ko) * 2005-01-20 2007-01-04 삼성전자주식회사 홈 네트워크 환경에서 홈 디바이스 인증 방법 및 장치
US7639614B2 (en) 2005-04-12 2009-12-29 Fujitsu Limited Distribution-tuning mechanism for link aggregation group management
US7649846B2 (en) 2005-04-12 2010-01-19 Fujitsu Limited Purge mechanism in link aggregation group management
US8451713B2 (en) 2005-04-12 2013-05-28 Fujitsu Limited Special marker message for link aggregation marker protocol
CN100555992C (zh) 2005-04-12 2009-10-28 富士通株式会社 基于网络的择路方案
US20070091907A1 (en) 2005-10-03 2007-04-26 Varad Seshadri Secured media communication across enterprise gateway
KR100827126B1 (ko) 2005-11-07 2008-05-06 삼성전자주식회사 통신 시스템에서 멀티미디어 포탈 컨텐츠 제공 방법 및시스템
US8054830B2 (en) 2005-12-07 2011-11-08 Alcatel Lucent Managing the distribution of control protocol information in a network node
US8151339B2 (en) 2005-12-23 2012-04-03 Avaya, Inc. Method and apparatus for implementing filter rules in a network element
US8792497B2 (en) 2006-06-05 2014-07-29 Tellabs Operations, Inc. Method and apparatus for performing link aggregation
CN1913414A (zh) 2006-08-29 2007-02-14 华为技术有限公司 利用链路聚合实施保护的方法、设备和系统
JP4676403B2 (ja) 2006-08-30 2011-04-27 株式会社日立製作所 通信装置及び通信システム
US7782856B1 (en) 2006-10-12 2010-08-24 World Wide Packets, Inc. Forwarding data packets having tags conforming to different formats
US20080155112A1 (en) 2006-12-22 2008-06-26 Nokia Corporation System and method for updating information feeds
CN100512194C (zh) 2006-12-25 2009-07-08 华为技术有限公司 链路聚合方法、装置、mac帧收发方法和系统
WO2008106530A1 (en) 2007-02-27 2008-09-04 Azalea Networks Method and system for radio frequency management in a mesh network with a path distance factor
US20080291919A1 (en) 2007-05-25 2008-11-27 Futurewei Technologies, Inc. Traffic Distribution and Bandwidth Management for Link Aggregation
US7869432B1 (en) 2007-06-29 2011-01-11 Force 10 Networks, Inc Peer-to-peer link aggregation across a service provider network
CN101094157B (zh) 2007-08-20 2011-09-21 中兴通讯股份有限公司 利用链路聚合实现网络互连的方法
US20090073873A1 (en) * 2007-09-17 2009-03-19 Integrated Device Technology, Inc. Multiple path switch and switching algorithms
US8081620B2 (en) 2007-11-26 2011-12-20 Alcatel Lucent System and method for supporting link aggregation and other layer-2 protocols primarily over unidirectional links
US8077613B2 (en) * 2007-12-03 2011-12-13 Verizon Patent And Licensing Inc. Pinning and protection on link aggregation groups
US8284654B2 (en) * 2007-12-03 2012-10-09 Verizon Patent And Licensing Inc. Bandwidth admission control on link aggregation groups
US8243594B1 (en) 2007-12-10 2012-08-14 Force10 Networks, Inc. Coordinated control of multiple parallel links or link aggregations
US8264951B2 (en) 2007-12-19 2012-09-11 Alcatel Lucent Resilient PPP/ML-PPP services over multi-chassis APS protected routers
JP5176604B2 (ja) 2008-03-05 2013-04-03 富士通株式会社 通信装置および通信方法
US9747340B2 (en) 2008-06-19 2017-08-29 Microsoft Technology Licensing, Llc Method and system of using a local hosted cache and cryptographic hash functions to reduce network traffic
US20110299551A1 (en) 2008-12-18 2011-12-08 Raoul Fiorone Method and Apparatus for Transferring Data Packets Between a First Network and a Second Network
JP5168166B2 (ja) 2009-01-21 2013-03-21 富士通株式会社 通信装置および通信制御方法
CN101610564B (zh) 2009-04-29 2015-04-01 中兴通讯股份有限公司 一种下行控制信息的发送和检测方法
JP4883160B2 (ja) 2009-09-30 2012-02-22 富士通株式会社 通信装置およびフレーム送信方法
US8780911B2 (en) 2009-10-08 2014-07-15 Force10 Networks, Inc. Link aggregation based on port and protocol combination
CN101674208B (zh) 2009-10-28 2012-01-04 杭州华三通信技术有限公司 一种lacp mad检测的方法及设备
JP5645139B2 (ja) 2010-01-05 2014-12-24 日本電気株式会社 ネットワークシステム、コントローラ、ネットワーク制御方法
US20110194404A1 (en) 2010-02-11 2011-08-11 Nokia Siemens Networks Ethernet Solutions Ltd. System and method for fast protection of dual-homed virtual private lan service (vpls) spokes
JP5504952B2 (ja) 2010-02-17 2014-05-28 ソニー株式会社 通信装置及び通信方法、並びにコンピューター・プログラム
JP5513342B2 (ja) 2010-02-26 2014-06-04 アラクサラネットワークス株式会社 パケット中継装置
US8873551B2 (en) 2010-07-30 2014-10-28 Cisco Technology, Inc. Multi-destination forwarding in network clouds which include emulated switches
US8488608B2 (en) 2010-08-04 2013-07-16 Alcatel Lucent System and method for traffic distribution in a multi-chassis link aggregation
ES2728899T3 (es) 2010-08-16 2019-10-29 Nokia Solutions & Networks Oy Selección de canal para la agregación de portadoras
CN102412979B (zh) 2010-09-26 2015-09-02 杭州华三通信技术有限公司 降低链路聚合端口报文丢失的方法及通信设备
CN101984606A (zh) 2010-11-15 2011-03-09 中兴通讯股份有限公司 基于lacp的设备级冗余保护方法及系统
US8958337B1 (en) 2010-12-23 2015-02-17 Juniper Networks, Inc. Scalable method to support multi-device link aggregation
WO2012120557A1 (ja) 2011-03-07 2012-09-13 株式会社日立製作所 ネットワーク管理装置、ネットワーク管理方法及びネットワーク管理システム
US8839023B2 (en) 2011-03-10 2014-09-16 Cisco Technology, Inc. Transmitting network information using link or port aggregation protocols
JP5807672B2 (ja) 2011-03-15 2015-11-10 日本電気株式会社 移動管理システム、移動管理方法、アクセスｇｗ装置、移動管理制御装置、及びプログラム
US8649379B2 (en) 2011-03-15 2014-02-11 Force10 Networks, Inc. Method and apparatus for configuring a link aggregation group on a stacked switch
CN102752187B (zh) 2011-04-21 2018-02-13 中兴通讯股份有限公司 弹性网络接口的实现方法和系统
WO2012149105A1 (en) 2011-04-26 2012-11-01 Dell Force10 Multi-chassis link aggregation on network devices
US20130003549A1 (en) 2011-06-30 2013-01-03 Broadcom Corporation Resilient Hashing for Load Balancing of Traffic Flows
JP5765623B2 (ja) 2011-07-19 2015-08-19 日立金属株式会社 ネットワークシステム
US8705551B2 (en) 2011-07-27 2014-04-22 Fujitsu Limited Method and system for management of flood traffic over multiple 0:N link aggregation groups
CN103001781B (zh) * 2011-09-08 2017-02-08 中兴通讯股份有限公司 分布式链路聚合组的聚合链路选择/去选择的方法及装置
US9025601B2 (en) 2011-10-27 2015-05-05 Futurewei Technologies, Inc. Forwarding ASIC general egress multicast filter method
US9332479B2 (en) 2012-01-04 2016-05-03 Ofinno Technologies, Llc Network site for wireless communications
US8824506B2 (en) * 2012-01-05 2014-09-02 International Business Machines Corporation Fragmentation of link layer discovery protocol packets
US8995272B2 (en) 2012-01-26 2015-03-31 Brocade Communication Systems, Inc. Link aggregation in software-defined networks
US9264298B2 (en) * 2012-03-02 2016-02-16 Telefonaktiebolaget L M Ericsson (Publ) Technique for bundling in link aggregation
CN104160658B (zh) 2012-03-02 2017-10-27 瑞典爱立信有限公司 用于确保链路聚合中的一致性的方法和节点
US8750122B1 (en) 2012-03-22 2014-06-10 Avaya, Inc. Method and apparatus for layer 2 loop prevention in a multi-node switch cluster
US9049149B2 (en) 2012-03-30 2015-06-02 Fujitsu Limited Minimal data loss load balancing on link aggregation groups
CN102647355B (zh) 2012-04-12 2014-11-05 华为技术有限公司 Lacp协商处理方法、中继节点及系统
US9270579B2 (en) 2012-04-27 2016-02-23 Cisco Technology, Inc. Synchronization of traffic multiplexing in link aggregation
US8942089B2 (en) * 2012-05-08 2015-01-27 Cisco Technology, Inc. Method and apparatus for adaptive fast start in link aggregation
US9374298B2 (en) 2012-05-08 2016-06-21 Cisco Technology, Inc. Grace state and pacing in link aggregation
EP2850787B1 (en) 2012-05-15 2019-02-13 Telefonaktiebolaget LM Ericsson (publ) Methods and apparatus for detecting and handling split brain issues in a link aggregation group
US8804531B2 (en) 2012-05-21 2014-08-12 Cisco Technology, Inc. Methods and apparatus for load balancing across member ports for traffic egressing out of a port channel
US9143439B2 (en) 2012-07-23 2015-09-22 Cisco Technology, Inc. System and method for cluster link aggregation control in a network environment
US20140089492A1 (en) 2012-09-27 2014-03-27 Richard B. Nelson Data collection and control by network devices in communication networks
CN103731285B (zh) * 2012-10-11 2019-01-04 中兴通讯股份有限公司 分布式弹性网络互连drni的切换处理方法及装置
CN103780407B (zh) * 2012-10-18 2018-07-06 中兴通讯股份有限公司 分布式弹性网络互连(drni)中网关动态切换方法和装置
CN103780500B (zh) 2012-10-19 2019-06-11 中兴通讯股份有限公司 聚合组中流量双向同路的方法、装置以及系统
CN103780419B (zh) 2012-10-24 2018-12-21 中兴通讯股份有限公司 一种分布式链路聚合组业务切换方法和装置
US9313093B2 (en) * 2012-11-14 2016-04-12 Ciena Corporation Ethernet fault management systems and methods
US9313116B2 (en) 2013-02-13 2016-04-12 ViaviSolutions Inc. Enhanced retry method
US9444748B2 (en) 2013-03-15 2016-09-13 International Business Machines Corporation Scalable flow and congestion control with OpenFlow
US9104643B2 (en) 2013-03-15 2015-08-11 International Business Machines Corporation OpenFlow controller master-slave initialization protocol
US9553798B2 (en) 2013-04-23 2017-01-24 Telefonaktiebolaget L M Ericsson (Publ) Method and system of updating conversation allocation in link aggregation
US9497132B2 (en) 2013-04-23 2016-11-15 Telefonaktiebolaget Lm Ericsson (Publ) Method and system of implementing conversation-sensitive collection for a link aggregation group
US9497074B2 (en) 2013-04-23 2016-11-15 Telefonaktiebolaget L M Ericsson (Publ) Packet data unit (PDU) structure for supporting distributed relay control protocol (DRCP)
CN104125088B (zh) 2013-04-28 2019-05-10 中兴通讯股份有限公司 Drni中同一端内系统之间交互信息的方法和系统
US9654418B2 (en) 2013-11-05 2017-05-16 Telefonaktiebolaget L M Ericsson (Publ) Method and system of supporting operator commands in link aggregation group
US20150271086A1 (en) 2014-03-24 2015-09-24 Rajant Corporation Reducing Network Traffic By Intercepting Address Resolution Messages
US9813290B2 (en) 2014-08-29 2017-11-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for supporting distributed relay control protocol (DRCP) operations upon misconfiguration

Also Published As

Publication number Publication date
US10116498B2 (en) 2018-10-30
MX2015014761A (es) 2016-03-11
PL2989762T3 (pl) 2018-05-30
EP2989757A1 (en) 2016-03-02
KR101706007B1 (ko) 2017-02-22
CA2910159A1 (en) 2014-10-30
JP6046309B2 (ja) 2016-12-14
US10237134B2 (en) 2019-03-19
US20170126501A1 (en) 2017-05-04
KR101706006B1 (ko) 2017-02-22
EP2989758B1 (en) 2017-07-19
WO2014174440A1 (en) 2014-10-30
JP6074110B2 (ja) 2017-02-01
PH12015502297A1 (en) 2016-02-10
JP2016523021A (ja) 2016-08-04
MX351202B (es) 2017-10-05
EP3253009B1 (en) 2019-01-02
ES2662111T3 (es) 2018-04-05
IL241894B (en) 2018-04-30
PH12015502297B1 (en) 2016-02-10
AU2014259016B2 (en) 2017-03-30
US20140321268A1 (en) 2014-10-30
US9503316B2 (en) 2016-11-22
US9654337B2 (en) 2017-05-16
US20140313939A1 (en) 2014-10-23
HK1222266A1 (zh) 2017-06-23
CN105393505A (zh) 2016-03-09
BR112015026670A2 (pt) 2017-07-25
MX2015014762A (es) 2016-06-06
PL2989759T3 (pl) 2017-09-29
CN105308913A (zh) 2016-02-03
US20210359910A1 (en) 2021-11-18
ES2626391T3 (es) 2017-07-24
EP2989761A1 (en) 2016-03-02
IL241893B (en) 2018-04-30
CN105393505B (zh) 2019-06-21
CN105308914B (zh) 2019-02-15
EP2989760A1 (en) 2016-03-02
AU2014259015B2 (en) 2016-10-20
WO2014174444A1 (en) 2014-10-30
KR101706008B1 (ko) 2017-02-22
AU2014259017A1 (en) 2015-12-03
EP2989759A1 (en) 2016-03-02
RU2015149749A (ru) 2017-05-26
US10097414B2 (en) 2018-10-09
AU2014259017B2 (en) 2017-05-04
KR20170014016A (ko) 2017-02-07
WO2014174439A1 (en) 2014-10-30
MY182277A (en) 2021-01-18
WO2014174441A1 (en) 2014-10-30
US20170111219A1 (en) 2017-04-20
WO2014174442A1 (en) 2014-10-30
CN105308913B (zh) 2019-06-14
EP2989757B1 (en) 2018-01-17
EP3253009A1 (en) 2017-12-06
EP2989759B1 (en) 2017-03-15
BR112015026775A2 (pt) 2017-07-25
KR20160003013A (ko) 2016-01-08
US10257030B2 (en) 2019-04-09
EP3324585A1 (en) 2018-05-23
CA2910149A1 (en) 2014-10-30
HUE038567T2 (hu) 2018-10-29
SG11201508361XA (en) 2015-11-27
KR102156964B1 (ko) 2020-09-16
BR112015026779A2 (pt) 2017-07-25
US9497074B2 (en) 2016-11-15
EP2989762A1 (en) 2016-03-02
MX2015014821A (es) 2016-07-26
CN105308912A (zh) 2016-02-03
AU2014259015A1 (en) 2015-12-03
US9461880B2 (en) 2016-10-04
US9660861B2 (en) 2017-05-23
US20140314097A1 (en) 2014-10-23
MA38596A1 (fr) 2016-04-29
JP6064085B2 (ja) 2017-01-18
MX351201B (es) 2017-10-05
CN110266588A (zh) 2019-09-20
US20170063726A1 (en) 2017-03-02
CN105379200B (zh) 2019-06-11
MA38597B1 (fr) 2016-11-30
PH12015502296A1 (en) 2016-02-10
SG11201508359VA (en) 2015-11-27
JP2016523022A (ja) 2016-08-04
WO2014174443A1 (en) 2014-10-30
CN105379200A (zh) 2016-03-02
US20140313932A1 (en) 2014-10-23
CA2910159C (en) 2019-03-19
PH12015502296B1 (en) 2016-02-10
RU2620995C2 (ru) 2017-05-30
RU2635288C2 (ru) 2017-11-09
HK1221096A1 (zh) 2017-05-19
ES2641231T3 (es) 2017-11-08
KR20160003009A (ko) 2016-01-08
ZA201507972B (en) 2018-06-27
MA38597A1 (fr) 2016-04-29
CL2015003149A1 (es) 2016-07-08
RU2015149980A (ru) 2017-05-26
US9509556B2 (en) 2016-11-29
EP2989762B1 (en) 2017-12-27
JP2017098989A (ja) 2017-06-01
US20140313938A1 (en) 2014-10-23
US20170141956A1 (en) 2017-05-18
TR201802416T4 (tr) 2018-03-21
US20140317250A1 (en) 2014-10-23
CA2910171A1 (en) 2014-10-30
CN105308914A (zh) 2016-02-03
KR20160003011A (ko) 2016-01-08
AU2014259016A1 (en) 2015-11-12
US11811605B2 (en) 2023-11-07
US20190207816A1 (en) 2019-07-04
CN105308915A (zh) 2016-02-03
JP6388675B2 (ja) 2018-09-12
BR112015026664A2 (pt) 2017-07-25
BR112015026673A2 (pt) 2017-07-25
CN105308912B (zh) 2019-06-28
MX350401B (es) 2017-09-06
EP2989758A1 (en) 2016-03-02
DK2989759T3 (en) 2017-06-06
JP2016521065A (ja) 2016-07-14
US11025492B2 (en) 2021-06-01

Similar Documents

Publication Publication Date Title
US11811605B2 (en) Packet data unit (PDU) structure for supporting distributed relay control protocol (DRCP)
US9813290B2 (en) Method and system for supporting distributed relay control protocol (DRCP) operations upon misconfiguration

Legal Events

Date Code Title Description
B25D Requested change of name of applicant approved

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) (SE)

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B350 Update of information on the portal [chapter 15.35 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 22/04/2014, OBSERVADAS AS CONDICOES LEGAIS