Hello,
Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
reste un problème de base. Comment chaque opérateur va devoir
implémenter un composant liant BGP / Voix.
Cependant, comme évoqué à plusieurs reprises, pas de modifications
incessantes de la table de routage voix.
Pour la table de routage internationale, OSEF dans un IX. (ou alors,
c'est un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe).
Dans tous les cas, les changements sur les non-membres : on s'en fout.
(porta depuis / vers les membres à gérer uniquement). Exemple : porta
orange / sfr : quel impact vu qu'a moyen terme aucun des deux ne sera
dessus? Pire, belgacom / proxymus?
Pour moi, le plus simple, sur, rapide, fonctionnel reste :
Un IX dédié à la voix (qu'on peut multiplier à souhaits).
Sur cet IX :
- Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
- L'association fourni un ou plusieurs proxy SIP - en guise de voice
route server.
Coût pour l'association :
1 switch (1G/10G de préférence);
3 serveurs (db + proxy).
Le cheminement serai alors le suivant :
Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon
membre.
=> Si c'est pas sur un membre, alors plusieurs cas sont possibles :
A/ L'association renvoi un code retour temporaire ou permanent sur ce
numéro (pas routable sur l'IX);
B/ L'association étant un GIE, et disposant de contrat de terminaison
SIP peut router le numéro. ==> Quid de la facturation/re-facturation?
Par contre, économie d'échelle si les contrats sont mutualisés.
=> Si le membre ne réponds pas (SIP option réguliers) alors on réponds
une erreur temporaire. (ou on load balance sur moins d'IP si le membre a
plusieurs SBC)
Dans les deux cas, ralentissement de l'établissement de quelques
milli-secondes pour le SBC appelant, c'est largement acceptable pour
fall-back sur un autre fournisseur.
Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
l'asso.
Et pour la croissance me direz vous?
Là encore, deux options :
A/ On déploie un IX dans chaque DC, en se moquant complètement de
l'interco, c'est à dire que chaque POP est stand-alone; (coûts
multipliés par le nombre de POP)
B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC
des clients, c'est simple, ils mettent une interface en /28 sur le POP,
et une route vers la /22. (coût qui ne sont pas proportionnels au nombre
de POP, mais besoin d'équipement L3 pour gérer le backbone).
Point bonus de la solution B, le proxy peut être anycasté entre
plusieurs POP.
Dans tous les cas, l'asso ne gère pas de transcoding (les membres
envoient le RTP de pair à pair);
Tant que tous les membres respectent un critère simple, supporter au
moins le G.711, tout est inter-opérable;
Si deux membres veulent jouer avec de la visio, ou des codec de plus
haute qualité, ça n'a aucun impact sur les autres.
Les membres n'ont pas à avoir de connaissances BGP (je sais, on est sur
frnog, le BGP c'est simple)
Avec juste le proxy sur les invite (donc initiation d'appel), l'asso ne
peut pas influer sur la qualité de la voix (mono POP).
Celle-ci est garantie, vue que les SBC parlent entre eux sur le même
subnet. Dans le cas d'un réseau multi-pop, c'est plus complexe.
Côté revenus de l'association, les options seraient :
- coût au port d'interconnexion - fixe;
- coût à la BP réellement utilisée;
- coût d'initiation (ie par appel - mais complètement incohérent pour
moi).
Et pour moi, l'asso est gérée par ses membres, avec une évolution vers
un GIE à terme :
Besoin de quelques SBC propres à l'association, de contrats de transit
Orange / SFR / BICS / ... et LCR vers ces destinations
Cordialement,
Le 2018-05-16 09:48, David Ponzone a écrit :
Je balance une idée en l’air entre 2 tartines.
Si on prenait quelques octets en plus devant le numéro de téléphone
pour y mettre le préfixe de porta (celui de l’ARCEP si l’opérateur en
a un, sinon un attribué par l’association).
Ainsi, le SBC de l’opérateur a toutes les infos dans la route.
L’AS et le next-hop, c’est celui du RS de l’IX-Voix de toute façon,
car pour moi c’est un IX dont les membres peerent seuleement avec le
RS, qui est un tiers de confiance qui envoie une information
contrôlée.
Le SBC de l’opérateur peut alors récupérer le préfixe de porta dans la
route.
Si le prefixe de porta est 10000 par exemple, il cherche dans une
table interne ou alors il fait un lookup DNS pour avoir les champs TXT
par exemple de la zone 10000.domain.gtld, qui vont contenir les
différentes IP des SBC auxquels il faut envoyer l’appel (soit les SBC
de l’autre opérateur, soit ceux de l’IX, en fonction du modèle
technico-économique choisi).
On 16 mai 2018 09:08 +0200, Alexis Lameire <alexis.lame...@gmail.com>,
wrote:
Raphaël,
Ta remarque est pertinente sauf que ton plan de num est différent
selon le
pays, donc c'est 3digit + padding + num. On a besoin de mettre le
padding à
cette endroit pour que la notion de masque reste valide (et profiter
de
l’agrégation).
L'identification d'un opérateur ne peut se faire uniquement avec le
numéro
d'AS, il y a toujours/souvent un enregistrement local complémentaire
qui
est nécessaire à la vérification de la validité du plan de num
annoncé. Il
faut donc le recevoir dans l'annonce BGP. On pourrais utiliser le
vpnv6
mais utiliser la notion de vrf pour coder l'identification de
l'opérateur
c'est pas crédible. On souhaite isoler les plan de num par pays et non
par
opérateur (dont le numéro pourrait se recouvrir sur deux pays
différent)
On peut sinon concevoir de transférer l'information d'identification
ARCEP
via l'utilisation d'un bloc de communauté well know et rester dans les
clous. Comme ça on rajoute le moins de truc au protocole.
Le seul truc sur lequel il faut pas transiger, c'est l'utilisation
mémoire/tcam. Et donc il faut définir une extension pour router des
bloc de
64bit avec prefix.
Alexis
Le 16 mai 2018 à 08:46, Raphaël Jacquot <sxp...@sxpert.org> a écrit :
>
>
> On 15/05/2018 20:07, Alexis Lameire wrote:
>
> ainsi la EZABPQ 011234 se code avec :
> > un prefix binaire représenté en hexa : 01:12:34:00:00
> > un masque binaire représenté en hexa : FF:FF:FF:00:00
> >
> > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes
> > spécifique étant en /40
> >
>
> STOP right there...
>
> je pense qu'une solution est possible sans même ajouter d'extension a
> BGP...
>
> * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits.
> * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan
> un numéro de téléphone, au niveau mondial, a 15 caracteres BCD
>
> Il serait donc extremement simple, et le plus naturel du monde, de mapper
> tout ca sur un seul /64,
> * le code pays est sur 3 digits
> * le reste du numéro sur les 13 digits restants
>
> ce qui simplifierai grandement les tables de routages au niveau
> international
>
> Raphaël
>
>
>
>
>
>
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
