PT2338257E

PT2338257E - Pedidos múltiplos numa rede de pontes da rede estruturante de fornecedor

Info

Publication number: PT2338257E
Application number: PT97955736T
Authority: PT
Inventors: Panagiotis Saltsidis; Mickael Fontaine
Original assignee: Ericsson Telefon Ab L M
Priority date: 2008-12-08
Filing date: 2009-12-08
Publication date: 2013-11-13
Also published as: WO2010068166A1; CN102246470A; US20140119369A1; US9264244B2; EP2338257B1; US8594088B2; EP2338257A1; US20110228774A1; DK2338257T3; CN102246470B

Description

ΡΕ2338257 - 1 -

DESCRIÇÃO

"PEDIDOS MÚLTIPLOS NUMA REDE DE PONTES DA REDE ESTRUTURANTE DE FORNECEDOR"

DOMÍNIO TÉCNICO A presente invenção diz genericamente respeito a redes de comunicações e, em particular, a um método e a um nó numa rede de comunicações para pedidos múltiplos, numa Rede de Pontes da Rede Estruturante de Fornecedor ("Provider Backbone Bridge Network - PBBN").

ANTECEDENTES 0 método de pedidos múltiplos é o método preferido para a distribuição de Televisão por Protocolo Internet ("Internet Protocol Television - IPTV") para utilizadores residenciais. 0 Protocolo de Gestão de Grupo Internet ("Internet Group Management Protocol - IGMP") é um protocolo de controlo baseado em IP, gue é usado para sinalizar a adesão de uma estação terminal a um grupo de pedidos múltiplos (canal de TV) numa rede de pontes. No sentido de colher os benefícios associados com os pedidos múltiplos, pode ser usada investigação ("snooping") de IGMP por nós intermediários para suprimir hierarguias ("prune trees") de pedidos múltiplos numa rede, a fim de fazer um eficiente uso de recursos limitados. - 2- ΡΕ2338257 A investigação de IGMP está concebida de maneira a impedir que os hospedeiros ("hosts") de uma rede local recebam tráfego para um grupo de pedidos múltiplos a que eles não tenham explicitamente aderido. A investigação de IGMP é um recurso que permite que um comutador ("switch") de camada 2 possa "entrar em escuta" sobre a conversação de IGMP entre hospedeiros e encaminhadores ("routers"), através do processamento de pacotes de IGMP da camada 3 enviados numa rede de pedidos múltiplos. Quando é disponibilizada capacidade de investigação de IGMP num comutador, o comutador analisa todos os pacotes de IGMP entre hospedeiros ligados ao comutador e encaminhadores de pedidos múltiplos na rede. Quando um comutador ouve um relatório de IGMP proveniente de um hospedeiro para um dado grupo de pedidos múltiplos, o comutador acrescenta o número da porta do hospedeiro à lista de pedidos múltiplos para aquele grupo. Da mesma forma, quando o comutador ouve uma Autorização ("Leave") IGMP, ele remove das entradas na tabela a porta do hospedeiro. Nestas circunstâncias, a investigação de IGMP proporciona aos comutadores um mecanismo para suprimir hierarquias em tráfego de pedidos múltiplos relativamente a links que não contenham um ouvinte de pedidos múltiplos (ou seja, o cliente de IGMP).

Diversas Normas IEEE incidem nos pedidos múltiplos de IPTV sobre Redes de Pontes da Rede Estruturante de Fornecedor ("Provider Backbone Bridge Networks - PBBN's") e Redes de Pontes de Fornecedores ("Provider Bridge Networks - PBN's"). As Normas aplicáveis -3- ΡΕ2338257 são a Norma IEEE 802 . lad (Pontes de Fornecedores), a Norma IEEE 802.lah (Pontes da Rede Estruturante de Fornecedores) e a Norma IEEE 802 .lak (Protocolo de Registos Múltiplos). A Norma IEEE 802.lah (2008-08-14) define uma arquitectura e protocolos de pontes para interligação de múltiplas Redes de Pontes de Fornecedores. A Secção 6 descreve o suporte para o serviço de MAC em Redes de Área Local Virtual (Virtual Local Area Networks - VLAN's"). A Secção 8 descreve o funcionamento de pontes e a utilização de um connection_identifier armazenado numa Base de dados de Filtragem e transmitido através do Serviço Melhorado de Subcamada Interna ("Enhanced Internai Sublayer Service -EISS") sob a forma de um parâmetro num EM_UNITDATA.request ou numa EM_UNITDATA.indication. A Secção 26 descreve os princípios de funcionamento da PBBN. O Pedido de Patente Europeia com o N° EP 1 950 907 AI descreve um método para implementação de uma capacidade de pedidos múltiplos numa rede de Controlo de Acesso a Meios de Comunicação ("Media Access Control - MAC") . No entanto, o método requer que seja construída uma relação entre endereços de pedidos múltiplos públicos e endereços de pedidos múltiplos privados, antes do funcionamento dos mecanismos sugeridos. Esta relação não será vantajosa, porque ela é construída por uma operação complexa do protocolo IGMP. A Ethernet é L2 e o IP é L3, mas ambos os protocolos realizam comutação de pacotes; ambos podem estar -4- ΡΕ2338257 à escala mundial; ambos utilizam protocolos de topologia dinâmica; e ambos podem proporcionar protecção, Qualidade de Serviço ("Quality of Service - QoS") e engenharia de tráfego. A diferença fundamental está na conectividade: o IP pode proporcionar conectividade global de qualquer um para qualquer um, ao passo que o Fornecedor Ethernet pode proporcionar conectividade global entre conjuntos provisionados de interfaces de rede. A investigação de IGMP executa uma violação de camada entre a camada 3 (IP) e a camada 2 (Ethernet), porque é um protocolo IP quem controla o comportamento de fluxos de pedidos múltiplos em pontes de Ethernet. Isso pode causar problemas em PBBN^s (802.1ah), dado que as Unidades de Dados em Pacotes ("Packet Data Units - PDU's") de IGMP são encapsuladas em tramas de rede estruturante. A Figura 1 é um diagrama de blocos simplificado de uma PBBN 11 que estabelece interface com duas PBN's 12, 13 para distribuir um serviço de pedidos múltiplos. Neste exemplo, é estabelecido na PBBN um serviço de VLAN de rede estruturante ponto-a-ponto, para distribuir o serviço de pedidos múltiplos para as PBN's. São encapsuladas tramas Ethernet de ingresso, provenientes das PBN's, com novos campos de cabeçalho incluindo os endereços de Controlo de Acesso a Meios de Comunicação (MAC) de origem e destino na Rede Estruturante, etiqueta B, e etiqueta I. No essencial, isto oculta completamente mensagens de IGMP na PBBN e torna impossível a investigação de IGMP. -5- ΡΕ2338257

Neste cenário, serão insuficientes mesmo os protocolos de pedidos múltiplos L2 - como, por exemplo, o Protocolo de Registo de Múltiplos Endereços de MAC ("MAC Address Multiple Registration Protocol - MMRP"). 0 problema está associado com a forma com que são encapsuladas as tramas de clientes de PBN pelas Pontes de extremidade de Rede Estruturante ("Backbone Edge Bridges - BEB's") nos extremos da PBBN. De acordo com a Norma IEEE 802 . lah de 2008, as tramas de clientes normalizadas que tenham um endereço de MAC em Grupo como seu endereço de destino são encapsuladas dentro de tramas de Rede Estruturante que têm permanentemente o endereço de Destino de Rede Estruturante por Defeito como seu endereço de MAC de destino de Rede Estruturante. 0 endereço de Destino de Rede Estruturante por Defeito é um endereço especial construído pela concatenação do Identificador Exclusivo Organizacional ("Organizationally Unique Identifier - OUI") (00-1E-83) de Pontes da Rede Estruturante de Fornecedor com o valor de Identificador de Instância de Serviço ("Service Instance Identifier - I-SID") que identifica a instância de serviço de cliente no rede estruturante. Isso não permite diferenciação dos serviços de pedidos múltiplos de cliente no rede estruturante, e limita severamente a capacidade para supressão de hierarquias a exercer sobre esses serviços. As tramas de pedidos múltiplos de cliente associadas com o mesmo I-SID de rede estruturante são sempre mapeadas para o mesmo serviço de pedidos múltiplos de rede estruturante e, consequentemente, fica perdida a -6- ΡΕ2338257 capacidade para controlar individualmente cada um desses serviços de pedidos múltiplos no rede estruturante.

RESUMO

Nestas circunstâncias, existe uma necessidade para um método e nó melhorados para pedidos múltiplos numa Rede de Pontes da Rede Estruturante de Fornecedores (PBBN). A presente invenção proporciona uma nova maneira para tratar tramas de pedidos múltiplos de cliente que são recebidas pela Porta de Rede de Cliente ("Client NetWork Port - CNP") ou pela Porta de Rede de Fornecedor ("Provider Network Port - PNP") sobre um componente I de uma Ponte de Rede Estruturante de Fornecedor ("Provider Backbone Bridge - PBB"). Em vez de encapsular estas tramas com um Endereço de Destino de Rede Estruturante ("Backbone Destination Address - B-DA") que seja igual ao endereço de Destino de Rede Estruturante por Defeito, as tramas de pedidos múltiplos de cliente que são encaminhadas para uma Porta de Instância Virtual ("Virtual Instance Port - VIP") sobre o componente I serão, num dado modelo de realização, encapsuladas com um B-DA igual ao original Endereço de Destino de Cliente ("Client Destination Address - C-DA") da trama de pedidos múltiplos de cliente recebida. Esta capacidade pode ser controlada por um parâmetro de "Permissão de Pedidos Múltiplos de Cliente" ("EnableCustomerMulticast") possibilitando que o comportamento atrás mencionado seja ajustado de forma independente para cada VIP sobre um componente I. Quando o -7- ΡΕ2338257 parâmetro estiver ajustado, o B-DA de rede estruturante a ser utilizado para as tramas de rede estruturante encapsuladas é o C-DA de pedidos múltiplos recebido. 0 valor por defeito para o parâmetro pode ser estabelecido em zero (0), que corresponde ao comportamento tradicional de encapsular tramas de pedidos múltiplos de cliente com o endereço de Destino de Rede Estruturante por Defeito. A presente invenção permite que sejam ajustados serviços de pedidos múltiplos de cliente através de uma PBBN. Isto pode ser conseguido utilizando o protocolo MMRP, que agora pode ser executado entre os domínios de PBN e de PBBN como se eles fossem um domínio único. Alternativamente, a invenção pode utilizar uma função de interoperabilidade IGMP-MMRP, se o domínio de pedidos múltiplos de cliente estiver sobre L3, enquanto o MMRP é suportado no domínio de rede estruturante. Se o MMRP não for suportado, é utilizado um algoritmo por todos os componentes de ponte intermédios, a fim de identificar tramas de IGMP e executar inspecção de IGMP.

Assim sendo, um modelo de realização para a presente invenção está direccionado para um método de propagação de tramas de pedidos múltiplos que são recebidas por um componente I de uma Ponte de Rede Estruturante de Fornecedor. O método inclui as seguintes etapas: (i) encapsulamento das tramas de pedidos múltiplos de cliente recebidas com um B-DA igual a um C-DA original; e (ii) propagação das tramas encapsuladas em direcção ao C-DA, - 8- ΡΕ2338257 utilizando os métodos proporcionados pelo funcionamento de MMRP ou investigação de IGMP.

Noutro modelo de realização, a presente invenção está direccionada para uma Ponte de Rede Estruturante de Fornecedor (PBB) possuindo um componente I. Ela inclui: (i) uma porta de entrada do componente I para receber tramas de cliente; (ii) um analisador de tramas para determinação de que as tramas recebidas consistem em tramas de pedidos múltiplos; (iii) uma unidade de encapsulamento de trama para encapsular as tramas recebidas com um B-DA igual a um C-DA original das tramas de pedidos múltiplos de cliente recebidas; e (iv) uma porta de saída para propagação das tramas encapsuladas em direcção ao C-DA.

Num outro modelo de realização, a presente invenção está direccionada para um método de propagação de tramas de pedidos múltiplos numa PBBN. 0 método inclui as seguintes etapas: (i) recepção de tramas de clientes por uma porta de entrada de um componente I de uma Ponte de Rede Estruturante de Fornecedor; (ii) análise das tramas de pedidos múltiplos de cliente para determinar se um connection_identifier não é nulo, e se o connection_identifier referencia um endereço retido por uma Porta de Instância de Fornecedor; e (iii) no caso de se determinar que o connection_identifier não é nulo e que o connection_identifier referencia um endereço retido pela Porta de Instância de Fornecedor, ajustamento de um B-DA igual a um endereço referenciado pelo -9- ΡΕ2338257 connection_identifier. No caso de se determinar que o connection_identifier é nulo, o método determina se o C-DA recebido nas tramas de cliente consiste num endereço de MAC em Grupo, e se um parâmetro de Permissão de Pedidos Múltiplos de Cliente de uma VIP sobre o componente I está ajustado para um valor predefinido. No caso de se determinar que o C-DA recebido é um endereço de MAC em Grupo e que o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP está ajustado para o valor predefinido, o B-DA é ajustado para ficar igual ao C-DA recebido. Quando o C-DA recebido não for um endereço de MAC em Grupo, e/ou o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP não estiver ajustado para o valor predefinido, o B-DA é ajustado para ficar igual ao conteúdo de um parâmetro de Destino de Rede Estruturante por Defeito da VIP.

Num outro modelo de realização, a presente invenção está direccionada para um método implementado por computador num componente de ponte, para determinar se deve ou não executar investigação de IGMP sobre uma trama Ethernet recebida. 0 método inclui as seguintes etapas: a) deixar passar pelo componente os primeiros doze bytes da trama Ethernet que identificam um DA de MAC e SA de MAC, e analisar os subsequentes bytes que identificam um primeiro campo Ethertype; b) determinar, através do componente, se os dois bytes seguintes são iguais a 81-00 ou 88-A8; c) no caso de se determinar que os dois bytes seguintes são iguais a 81-00 ou 88-A8, ignorar os próximos dois bytes subsequentes e repetir as etapas b) e c) até que os - 10- ΡΕ2338257 próximos dois bytes não sejam iguais a 81-00 ou 88-A8; d) quando os próximos dois bytes não forem iguais a 81-00 ou 88-A8, determinar, através do componente, se os dois bytes seguintes são iguais a 88-e7; e) no caso de se determinar que os dois bytes seguintes são iguais a 88-e7, deixar passar pelo componente os próximos 16 bytes subsequentes e repetir as etapas b) a e) até que os próximos dois bytes não sejam iguais a 88-e7; f) quando os próximos dois bytes não forem iguais a 88-e7, determinar, através do componente, se os dois bytes seguintes identificam uma trama de IGMP; g) no caso de se determinar que os dois bytes seguintes identificam uma trama de IGMP, executar investigação de IGMP sobre a trama; e h) no caso de se determinar que os dois bytes seguintes não identificam uma trama de IGMP, desistir de executar investigação de IGMP sobre a trama.

Num outro modelo de realização, a presente invenção está direccionada para um método implementado por computador para propagação de uma unidade de dados em pacotes (PDU) de Protocolo de Registo de Múltiplos Endereços de MAC (MMRP) iniciada no cliente, no domínio de rede estruturante, em que a PDU de MMRP é recebida por uma Porta de Rede de Cliente ou por uma Porta de Rede de Fornecedor sobre um componente I de uma Ponte de Rede Estruturante de Fornecedor (PBB), e é propagada para outras portas de Ponte dentro de um contexto de VLAN. O método é caracterizado pelo encapsulamento das PDU's de MMRP propagadas de acordo com as seguintes etapas, quando uma - 11 - ΡΕ2338257 VIP fizer parte do contexto de VLAN: (i) quando um connection_identifier associado com a PDU recebida não for nulo, ajustamento do B-DA para ficar igual a um endereço referenciado pelo connection_identifier; (ii) quando o

connection_identifier for nulo, determinar se o C-DA recebido na PDU consiste num endereço de MAC em Grupo, e se um parâmetro de Permissão de Pedidos Múltiplos de Cliente da Porta de Instância Virtual está ajustado para um valor predefinido; (iii) quando o C-DA recebido for um endereço de MAC em Grupo e o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP estiver ajustado para o valor predefinido, ajustar o B-DA para ficar igual ao C-DA recebido; e (iv) quando o C-DA recebido não for um endereço de MAC em Grupo, e/ou o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP não estiver ajustado para o valor predefinido, ajustar o B-DA para ficar igual ao conteúdo de um parâmetro de Destino de Rede Estruturante por Defeito da VIP. 0 método também inclui as etapas seguintes: (i) recepção de uma das propagadas PDU's de MMRP numa Porta de Rede Estruturante de Cliente sobre um componente B que implementa o protocolo MMRP; (ii) determinação, através da Porta de Rede Estruturante do Cliente que recebe, se a PDU recebida consiste numa PDU de MMRP; e (iii) propagação de todas as PDU's de MMRP identificadas dentro do contexto de VLAN correspondendo a um valor de Identificador de VLAN de Rede Estruturante ("Backbone VLAN Identifier - B-VID") associado à PDU recebida. - 12- ΡΕ2338257

BREVE DESCRIÇÃO DOS DESENHOS A Figura 1 é um diagrama de blocos simplificado de uma PBBN que estabelece interface com duas PBN's para distribuir um serviço de pedidos múltiplos; a Figura 2 é um fluxograma que ilustra as etapas de um modelo de realização para o método da presente invenção, no qual o B-DA é ajustado para uma trama emitida por uma Porta de Instância de Fornecedor ("Provider Instance Port - PIP"); a Figura 3 é um fluxograma que ilustra as etapas de um modelo de realização para o método da presente invenção para propagação de uma PDU de MMRP iniciada no cliente, no domínio da rede estruturante; a Figura 4 é um fluxograma ilustrando as etapas de um algoritmo implementado por todos os componentes de ponte para investigar a informação de IGMP, sempre que o protocolo de MMRP não for implementado pelas Pontes no domínio do Fornecedor; e a Figura 5 é um diagrama de blocos simplificado de uma PBB, num modelo de realização exemplificativo da presente invenção.

DESCRIÇÃO DETALHADA A presente invenção introduz um novo parâmetro, o qual pode ser por exemplo um parâmetro binário, aqui referido como o parâmetro de "Permissão de Pedidos Múltiplos de Cliente", sobre cada porta VIP sobre um componente I. Por defeito, todas as portas VIP têm esse parâmetro ajustado em zero (0). Se o parâmetro for ajustado - 13 - ΡΕ2338257 no valor um (1), cada trama de pedidos múltiplos de cliente que seja encaminhada para essa VIP é encapsulada com um Endereço de Destino MAC de Rede Estruturante o qual é igual ao endereço C-DA de pedidos múltiplos. Todas as outras funções da Porta de Instância de Fornecedor (PIP) permanecem as mesmas, conforme descrito na Norma IEEE 802.lah de 2008. A Figura 2 é um fluxograma que ilustra as etapas de um modelo de realização para o método da presente invenção, no qual o B-DA é ajustado para uma trama emitida por uma PIP. Na etapa 21, uma Porta de Rede de Cliente (CNP) sobre um componente I recebe uma trama que é encaminhada para uma Porta de Instância Virtual (VIP) sobre o mesmo componente. Na etapa 22, o componente I analisa a trama recebida. Na etapa 23, determina-se se o connection_identifier para a trama recebida é nulo. Se o connection_identifier não for nulo, ele irá conter um endereço retido pela PIP. Nestas circunstâncias, o método prossegue para a etapa 24, onde o valor para o B-DA é ajustado como sendo o endereço referenciado pelo connection_identifier. Se o connection_identifier for nulo, o método prossegue para a etapa 25, onde é determinado se o C-DA recebido é um endereço de MAC em Grupo e se o parâmetro de Permissão de Pedidos Múltiplos de Cliente da Porta de Instância Virtual está ajustado no valor um (1). Se assim for, o método prossegue para a etapa 26, onde o valor para o B-DA é ajustado como sendo igual ao C-DA recebido. Se assim não for, o método prossegue para a etapa - 14- ΡΕ2338257 27, onde o valor do B-DA é ajustado como sendo o conteúdo do parâmetro de Destino de Rede Estruturante por Defeito da Porta de Instância Virtual. Na etapa 28, as tramas são encapsuladas utilizando o B-DA seleccionado e propagadas através da rede em direcção ao destino.

As modificações atrás mencionadas permitem que fiquem visíveis endereços de pedidos múltiplos de Cliente na Rede Estruturante e, consequentemente, permitem controlar os serviços de pedidos múltiplos de cliente numa PBBN. Em particular, se a rede de cliente está a executar o Protocolo de Registo de Múltiplos Endereços de MAC (MMRP), as PDU's de MMRP de clientes podem ser propagadas na Rede Estruturante, com o fim de estabelecer serviços de pedidos múltiplos da Rede Estruturante com base nos serviços de pedidos múltiplos de cliente. A Figura 3 é um fluxograma que ilustra as etapas de um modelo de realização para o método da presente invenção, para propagação de uma PDU de MMRP iniciada no Cliente no domínio da Rede Estruturante. Na etapa 31, é recebida uma PDU de MMRP por uma porta CNP ou PNP sobre um componente I. Na etapa 32, a PDU é propagada para as outras portas de Ponte dentro de um contexto de VLAN, conforme descrito na Secção 10.11 da Norma IEEE 802.lak de 2008. Na etapa 33, se uma VIP fizer parte deste contexto de VLAN, as PDU's de MMRP propagadas são encapsuladas de acordo com as regras da Norma IEEE 802. lah conforme modificadas pelo método da Figura 2. Na etapa 34, uma Porta de Rede - 15- ΡΕ2338257

Estruturante do Cliente (CBP) sobre um componente B que implementa o protocolo MMRP verifica o endereço de Destino da trama e o campo "Ethertype", com o fim de determinar se a PDU recebida consiste numa PDU de MMRP. 0 campo "Ethertype" está ocultado debaixo da ETIQUETA I da trama, mas pode ser visível através da utilização da entidade de multiplexagem de instância de serviço da rede estruturante descrita na Secção 6.18 da Norma IEEE 802. lah de 2008. Na etapa 35, todas as PDU's de MMRP identificadas são propagadas dentro do contexto de VLAN correspondente ao valor do identificador de VLAN da Rede Estruturante (B-VID) associado com a trama recebida (ou seja, o valor na coluna B-VID da tabela de Instância de Serviço de Rede Estruturante associado com o I-SID recebido, ou então, se isso não for suportado, o valor do parâmetro PVID associado com esta porta CBP).

Se os serviços de pedidos múltiplos no domínio de cliente forem ajustados pela investigação de IGMP enquanto é implementado MMRP no domínio da rede estruturante, pode ser utilizada uma função de interoperabilidade IGMP-MMRP com vista a proporcionar perfeita interoperabilidade entre as redes baseadas em IGMP e em MMRP. A função de interoperabilidade pode ser implementada sobre as VIP's, e as CBP' s que recebem as PDU's de MMRP implementam as funções apresentadas nas etapas 34 e 35 atrás mencionadas. A Figura 4 é um fluxograma que ilustra as etapas de um algoritmo implementado por todos os componentes de - 16- ΡΕ2338257 ponte para investigação da informação de IGMP, sempre que o protocolo MMRP não for implementado pelas Pontes no domínio do Fornecedor. Como anteriormente mencionado, a investigação de IGMP é concebida para evitar que os hospedeiros numa rede recebam tráfego para um grupo de pedidos múltiplos a que eles nao tinham explicitamente aderido. A investigação de IGMP permite que um comutador de camada 2 "entre em escuta" na conversação de IGMP entre hospedeiros e encaminhadores através do processamento de pacotes de IGMP de camada 3 enviados numa rede de pedidos múltiplos. Para fazer uso eficiente de recursos limitados, a investigação de IGMP pode ser empregue por nós intermediários para suprimir hierarquias de pedidos múltiplos numa rede.

Na etapa 41, um componente recebe uma trama Ethernet. Na etapa 42, o componente deixa passar os primeiros 12 bytes da trama Ethernet que identificam o DA de MAC e SA de MAC, e analisa os bytes que identificam o primeiro campo Ethertype. Na etapa 43, é determinado se os dois bytes seguintes são iguais a 81-00 ou a 88-A8. Se assim for, o componente ignora os próximos dois bytes subsequentes na etapa 44 e repete a etapa 43. Se os dois bytes seguintes não forem iguais a 81-00 ou 88-A8, o método prossegue para a etapa 45, onde é determinado se os dois bytes seguintes são iguais a 88-e7. Se assim for, o componente deixa passar os próximos 16 bytes subsequentes na etapa 46 e regressa à etapa 43. Se assim não for, o método prossegue para a etapa 47, onde é determinado se os - 17- ΡΕ2338257 dois bytes seguintes estão a identificar uma trama de IGMP. Se for este o caso, o método prossegue para a etapa 48, onde é executada a investigação de IGMP. Não sendo esse o caso, o método prossegue para a etapa 49, onde não é executada qualquer investigação. A Figura 5 é um diagrama de blocos simplificado de uma PBB 50 num modelo de realização exemplificativo para a presente invenção. As tramas de Cliente são recebidas numa CNP ou PNP 51 de um componente 1. 0 C-DA das tramas recebidas é utilizado para consultar a Base de dados de Filtragem de Componentes I e identificar o conjunto de portas para onde a trama deve ser encaminhada. Se as tramas se destinam a ser encaminhadas para uma Rede de Pontes da Rede Estruturante de Fornecedor (PBBN), elas são direccionadas para uma Porta de Instância Virtual (VIP), a qual fica responsável pelo encapsulamento. Neste caso, a Base de dados de Filtragem 52 fornece um connection_identif ier 53 associado com o C-DA da trama recebida. 0 connection_identifier é encaminhado para um analisador de C-DA 57, o qual determina se o connection_identifier é nulo. Se o connection_identifier não for nulo, o connection_identifier referencia um endereço retido pela PIP. Os resultados da análise são enviados para um ajustador de B-DA 54. Em particular, quando o connection_identifier não for nulo, a unidade ajustadora de B-DA 54a ajusta o valor para o B-DA em conformidade com o endereço referenciado pelo connection identifier. - 18- ΡΕ2338257

Um ajustador de parâmetro de Permissão de Pedidos Múltiplos de Cliente 55 fornece ao analisador de C-DA 57 o parâmetro de Permissão de Pedidos Múltiplos de Cliente 56. 0 analisador de C-DA determina se o C-DA recebido consiste num endereço de MAC em Grupo, e determina se o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP está ajustado para o valor um (1) . Se não estiver, a unidade ajustadora de B-DA 54b ajusta o valor do B-DA como sendo o conteúdo do parâmetro de Destino de Rede Estruturante por Defeito da Porta de Instância Virtual. No entanto, quando o C-DA recebido for um endereço de MAC em Grupo, e o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP estiver ajustado para o valor um (1), a unidade ajustadora de B-DA 54c ajusta o valor para o B-DA como sendo o do C-DA recebido.

Em seguida, uma unidade de encapsulamento de trama 58, encapsula as tramas com o endereço de destino seleccionado, e a porta de saída 59 propaga as tramas encapsuladas em direcção ao destino. A presente invenção pode evidentemente ser realizada de outras maneiras específicas, diferentes daquelas aqui estabelecidas, sem nos afastarmos das características essenciais da invenção. Por conseguinte, os presentes modelos de realização deverão ser considerados em todos os aspectos como sendo ilustrativos mas não restritivos, e pretende-se que todas as alterações que ΡΕ2338257 - 19- ocorram reivindi Lisboa, no âmbito do significado e equivalência das cações anexas se considerem aqui englobadas. 7 de Novembro de 2013

Claims

ΡΕ2338257 - 1 - REIVINDICAÇÕES 1. Um método de propagação de tramas de pedidos múltiplos dentro de uma Rede de Pontes da Rede Estruturante de Fornecedor ("Provider Backbone Bridge Networks - PBBN"), em que as tramas de pedidos múltiplos são recebidas por uma Porta de Rede de Cliente sobre um componente I de uma Ponte de Rede Estruturante de Fornecedor ("Provider Backbone Bridge - PBS") , e são encaminhadas para uma Porta de Instância Virtual sobre o componente I, sendo o referido método caracterizado pelas seguintes etapas: determinação (25) da hipótese de um parâmetro de Permissão de Pedidos Múltiplos de Cliente ("EnableCustomerMulticast") de uma Porta de Instância Virtual sobre o componente I estar ajustado para um valor predefinido, e da hipótese de as tramas recebidas consistirem em tramas de pedidos múltiplos, ao determinar (25) que um original Endereço de Destino de Cliente, ("Customer Destination Address - C-DA") das tramas recebidas consiste num endereço de Controlo de Acesso a Meios de Comunicação ( "Media Access Control - MAC") em Grupo; determinação da hipótese de o parâmetro de Permissão de Pedidos Múltiplos de Cliente estar ajustado para o valor predefinido, e de as tramas recebidas consistirem em tramas de pedidos múltiplos; encapsulamento (26) das tramas de pedidos múltiplos recebidas com um Endereço de Destino de Rede - 2- ΡΕ2338257 Estruturante igual ao C-DA original das tramas de pedidos múltiplos recebidas; e propagação (28) das tramas encapsuladas para o C- DA.
2. 0 método de acordo com a reivindicação 1, compreendendo ainda a etapa de encapsulamento (27) das tramas de pedidos múltiplos recebidas com o Endereço de Destino de Rede Estruturante igual a um endereço de Destino de Rede Estruturante por Defeito, se o parâmetro de Permissão de Pedidos Múltiplos de Cliente não estiver ajustado para o valor predefinido.
3. 0 método de acordo com a reivindicação 1, compreendendo ainda o ajustamento de forma independente do parâmetro de Permissão de Pedidos Múltiplos de Cliente para cada Porta de Instância Virtual sobre o componente I.
4. 0 método de acordo com a reivindicação 1, compreendendo ainda a utilização de investigação (48) do Protocolo de Gestão de Grupo Internet ("Internet Group Management Protocol - IGMP"), para suprimir hierarquias em tráfego de pedidos múltiplos relativamente a links que não contenham um ouvinte de pedidos múltiplos.
5. 0 método de acordo com a reivindicação 1, compreendendo ainda as etapas de: -3- ΡΕ2338257 análise (22, 23) de uma trama recebida para determinar a hipótese de ser nulo um connection_identifier associado; no caso de ter sido determinado que o connection_identifier não é nulo, ajustamento (24) do B-DA de modo a ficar igual a um endereço referenciado pelo connection_identifier; no caso de ter sido determinado que o connection_identifier é nulo, determinação (25) da hipótese de o C-DA recebido nas tramas de pedidos múltiplos de cliente consistir num endereço de MAC em Grupo, e de o parâmetro de Permissão de Pedidos Múltiplos de Cliente de uma VIP sobre o componente I estar ajustado para um valor predefinido; no caso de ter sido determinado que o C-DA recebido é um endereço de MAC em Grupo e que o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP está ajustado para o valor predefinido, realizaçao da etapa de encapsulamento (26); e no caso de ter sido determinado que o C-DA recebido não é um endereço de MAC em Grupo, e/ou que o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP não é o valor predefinido, ajustamento (27) do B-DA de modo a ficar igual ao conteúdo do parâmetro de Destino de Rede Estruturante por Defeito da VIP.
6. 0 método de acordo com a reivindicação 5, que compreende adicionalmente a etapa de ajustamento de forma independente do parâmetro de Permissão de Pedidos -4- ΡΕ2338257 Múltiplos de Cliente para cada Porta de Instância Virtual sobre o componente I.
7. 0 método de acordo com a reivindicação 1, em que a PBB recebe as Unidades de Dados em Pacotes ("Packet Data Units - PDU's") do Protocolo de Registo de Múltiplos Endereços de MAC ("MAC Address Multiple Registration Protocol - MMRP") iniciadas no cliente, sobre o componente I, e propaga as PDU's de MMRP para outras portas de Pontes dentro de um contexto de Rede de Área Local Virtual (Virtual Local Area Network - VLAN"), em que o método compreende ainda as seguintes etapas, quando uma Porta de Instância Virtual fizer parte do contexto de VLAN, ajustamento (33) do B-DA das PDU's de MMRP propagadas de acordo com as seguintes etapas: quando um connection_identifier associado com a PDU recebida não for nulo, ajustamento (24) do B-DA de modo a ficar igual a um endereço referenciado pelo connection_identifier; quando o connection_identifier for nulo, determinação (25) da hipótese de o C-DA recebido na PDU consistir num endereço de MAC em Grupo, e de o parâmetro de Permissão de Pedidos Múltiplos de Cliente da Porta de Instância Virtual estar ajustado para um valor predefinido; quando o C-DA recebido for um endereço de MAC em Grupo e o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP estiver ajustado para o valor predefinido, realização da etapa de encapsulamento (26); e -5- ΡΕ2338257 quando o C-DA recebido não for um endereço de MAC em Grupo, e/ou o parâmetro de Permissão de Pedidos Múltiplos de Cliente da VIP não estiver ajustado para o valor predefinido, ajustamento (27) do B-DA de modo a ficar igual ao conteúdo de um parâmetro de Destino de Rede Estruturante por Defeito da VIP; recepção de uma das PDU's de MMRP propagadas na Porta de Rede Estruturante de Cliente sobre um componente B que implementa o protocolo MMRP; determinação (34), através da Porta de Rede Estruturante de Cliente, da hipótese de a PDU recebida ser uma PDU de MMRP; e propagação (35) de todas as PDU's de MMRP identificadas dentro do contexto de VLAN correspondendo a um valor de Identificador de VLAN de Rede Estruturante ("Backbone VLAN Identifier - B-VID") associado com a PDU recebida.
8. Uma Ponte de Rede Estruturante de Fornecedor ("Provider Backbone Bridge - PBB") (50) dentro de uma Rede de Pontes da Rede Estruturante de Fornecedor ("Provider Backbone Bridge Network - PBBN") , em que a PBB compreende uma Porta de Rede de Cliente sobre um componente I, estando tal Porta de Rede de Cliente da PBB adaptada para receber tramas de pedidos múltiplos e encaminhar tramas de pedidos múltiplos para uma Porta de Instância Virtual sobre o componente I, e sendo a PBB caracterizada por: um analisador de C-DA (57) adaptado para determinar a hipótese de o parâmetro de Permissão de -6- ΡΕ2338257 Pedidos Múltiplos de Cliente de uma Porta de Instância Virtual sobre o componente I estar ajustado para um valor predefinido, e para determinar a hipótese de as tramas recebidas consistirem em tramas de pedidos múltiplos, ao determinar que um original Endereço de Destino de Cliente, C-DA, das tramas recebidas consiste num endereço de Controlo de Acesso a Meios de Comunicação, MAC, em Grupo; uma unidade de encapsulamento da trama (58) adaptada para encapsular tramas de pedidos múltiplos recebidas com um Endereço de Destino de Rede Estruturante igual a um original C-DA das tramas de pedidos múltiplos recebidas, no caso de o parâmetro de Permissão de Pedidos Múltiplos de Cliente estar ajustado para o valor predefinido, e de as tramas recebidas serem tramas de pedidos múltiplos; e uma porta de saida (59) para propagação das tramas encapsuladas em direcção ao C-DA.
9. A PBB de acordo com a reivindicação 8, em que o analisador de C-DA inclui um leitor de endereços que determina se o C-DA das tramas recebidas consiste num endereço de Controlo de Acesso a Meios de Comunicação, MAC, em Grupo.
10. A PBB de acordo com a reivindicação 8, que compreende ainda: meios (55) para ajustar selectivamente para um valor predefinido, ou para um segundo valor, um parâmetro -7- ΡΕ2338257 de Permissão de Pedidos Múltiplos de Cliente de uma Porta de Instância Virtual sobre o componente I; e em que, quando o parâmetro de Permissão de Pedidos Múltiplos de Cliente estiver ajustado para o segundo valor, a unidade de encapsulamento de trama (58) é obrigada a encapsular as tramas recebidas com o Endereço de Destino de Rede Estruturante igual a um endereço de Destino de Rede Estruturante por Defeito.
11. A PBB de acordo com a reivindicação 10, em que os meios (55) para ajustar selectivamente o parâmetro de Permissão de Pedidos Múltiplos de Cliente estão adaptados para ajustar de forma independente o parâmetro de Permissão de Pedidos Múltiplos de Cliente para cada Porta de Instância Virtual sobre o componente I.
12. A PBB de acordo com a reivindicação 8, em que o analisador de C-DA está igualmente adaptado para determinar se é nulo um connection_identifier associado com o C-DA e, se não for nulo, obrigar a unidade de encapsulamento de trama (58) a encapsular as tramas recebidas com um endereço referenciado pelo connection_identifier. Lisboa, 7 de Novembro de 2013