Využití mechanismu ENUM pro přenositelnost čísla

Mechanismus ENUM (tElephony NUmber Mapping, E.164 NUmber Mapping) slouží pro převod mezi jmennými prostory a je popsán v sekci ENUM a ve standardu IETF RFC 3761.

Přenositelnost čísla je telekomunikační službou, která umožňuje uživatelům měnit operátora, typ služby nebo místo připojení při zachování stávajícího telefonního čísla. Výhodou jsou ušetřené náklady související s oznámením nového čísla a také výhodnější podmínky, kvůli kterým změna proběhla.

Z technického pohledu přináší přenositelnost čísla zásadní změnu ve směrování v síti. Telefonní číslo nejprve používané jako směrovací adresa v telefonní síti, se se zavedením přenositelnosti mění ze směrovací adresy na virtuální identifikátor označující uživatele. Pro směrování jsou tedy nutné mechanismy překladu čísla na cílovou adresu uživatele.

Přenositelnost čísla v pevných a mobilních sítích

Většina současných telekomunikačních systémů využívá k identifikaci uživatele telefonní číslo (ITU-T E.164). Přidělování čísel jednotlivým operátorům a tím i uživatelům řídí ITU ve spolupráci s národními telekomunikačními regulátory. Telefonní čísla jsou předmětem služby přenositelnosti čísla, která je také zavedena regulačním opatřením (vyjímečně dohodou operátorů).

Technicky je přenositelnost čísla realizována databází telefonních čísel s informací kdy, od kterého operátora a kam bylo číslo přeneseno. Přístup k této databázi bývá nejčastěji navržen pomocí Inteligentní sítě (IN), která doplňuje současné telekomunikační sítě pracují na principu přepojování okruhů (TDM) a využívající SS7 signalizaci. Při zpracování hovoru na přenesené číslo proběhne dotaz z ústředny s podporou IN (SSP) přes SCP do lokální databáze přenesených čísel (LNPDB). Získaná směrovací informace je využita pro spojení k operátorovi, kam bylo číslo přeneseno (viz obrázek).

Realizace přenositelnosti čísla architekturou IN

Data v LNPDB jsou získána z centrální databáze RNPDB, do které jednotliví operátoři zadávají data o portacích. Rozhraní mezi databázemi není standardizováno a bývá realizováno technologií CORBA nebo s pomocí Webových služeb a protokolu SOAP.

Souvislost s mechanismem ENUM

Architektura systému přenositelnosti čísla je hierarchická. Informace zde uložená odpovídá převodu z telefonního čísla na směrovací informaci (obecně na textový řetězec). Tento systém je navíc realizován v IP síti. Všechny tyto parametry odpovídají mechanismu ENUM realizovanému v systému DNS. ENUM navíc umožňuje spolupráci tradičních telekomunikačních sítí a IP telefonie (obecněji Sítí příští generace - NGN).

V následujícím textu se zaměříme na parametry systému přenositelnosti čísla realizovaného ENUMem a jejich porovnání s existujícími systémy.

Návrh realizace

První otázkou je způsob uložení směrovací informace pro přenesená čísla. V článku ENUM based Number Portability in VoIP and IMS Networks (Ivcek, M.) navrhuje autor způsob spolupráce softswitche obsluhujícího čísla v pevné a VoIP síti s databází založené na ENUM obsahující záznamy o přenesených číslech. Jako způsob uložení směrovací informace jsou využity NAPTR záznamy (s tel: URI) ve formátu definovaném v RFC 4694

  • Not ported number
$ORIGIN 4.3.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:1234;npdi!".
  • PSTN-PSTN number portability
$ORIGIN 4.3.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:1234;npdi;rn=2234!".
  • PSTN-VoIP number portability
$ORIGIN 4.3.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:1234;npdi;rn=2234@sip.com;user=phone!".
SIP: INVITE sip:1234;rn=2234@sip.com;user=phone;npdi=yes SIP/2.0
  • VoIP-VoIP number portability
SIP: INVITE sip:1234@sip-A.com;user=phone SIP/2.0
$ORIGIN 4.3.2.1.e164.arpa.
NAPTR 10 100 "u" "E2U+pstn:tel" "!^.*$!tel:1234;npdi;rn=2234@sip-B.com;user=phone!".
SIP: INVITE sip:1234;rn=2234@sip-B.com;user=phone;npdi=yes SIP/2.0

Tento způsob není jediným a v regulárním výrazu NAPTR záznamu, případě v řetězci pro nahrazení se mohou vyskytnout data vhodná pro realizaci v konkrétní zemi/systému.

Druhou otázkou je místo uložení těchto záznamů. Existuje několik návrhů na uložení operátorských záznamů do stromu e164.arpa společně se záznamy uživatelského ENUMu A Combined User/Carrier ENUM, Combined User and Infrastructure ENUM in the e164.arpa tree. Nicméně podle kritiky jsou tyto návrhy technicky složité a čelí politickým otázkám (národní regulátoři různých zemí nebudou chtít uvádět své záznamy v databázi spravované vládou Spojených států). Jako reálná možnost realizace se v současné době nabízí využití privátního ENUMu. Skupina operátorů se dohodne na využití určité domény, pravidel pro přístup a úpravy záznamů a tato slouží jako zdroj informace o přenesených číslech.

Poslední otázkou jsou parametry reálného systému pro přenositelnost čísla realizovaného s pomocí ENUMu. V následující sekci se zaměříme na měření doby odezvy systému a na porovnání s ostatními způsoby realizace.

Experiment: Porovnání systémů s využitím Webových služeb a s mechanismem ENUM

Z pohledu protokolového modelu přenáší ENUM data ve formátu DNS zpráv (DNS/UDP[TCP]/IP). Ty jsou v binární podobě a mohou komprimovat opakující se záznamy. Webová služba naproti tomu přenáší data s pomocí XML formátu v textové podobě. Přenos je navíc zatížen další vrstvou v podobě HTTP protokolu. Výhodou ENUM řešení je tak zkrácení doby zpracování o komunikaci HTTP. Je potřeba prozkoumat efektivitu přenosu DNS dat a porovnat ji s přenosem XML dat. Předpokladem je, že DNS by mohl být efektivnější, jelikož jde o binární přenos s kompresí a bez HTTP záhlaví.

K porovnání využijeme metodu experiment, která realizuje dvě databáze a jejich rozhranní. Referenční národní databáze se záznamy o všech přenesených číslech (RNPDB) je propojena s lokální operátorskou databázi s kopií RNPDB dat. V prvním případě budou propojeny pomocí protokolu SOAP pro XML transport (Webová služba). V druhém případě jsou databáze realizovány s pomocí DNS jako primární a sekundární DNS server.

Realizace: Webová služba

Pro implementaci SOAP protokolu využijeme open-source řešení Apache-Axis 1.2 (instalace popsána v příloze). Samotnou databázi přenositelnosti čísla budeme realizovat jako Webovou službu ve spojení s MySQL databází (nastavení v příloze).

  • Výběr Webové služby
  1. jws: potřeba zdojového kódu, kompilace při zavolání zabírá čas
  2. wsdd (web service deployment description): stačí classes
  • Tvorba Webové služby s využitím MySQL
vytvořit classes  - NpdbServer.java (v příloze)
instalovat jdbc (spoluprace s MySQL)
zkompilovat classes (javac -classpath /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/ext/:$CLASSPATH:. NpdbServer.java)
vložit do webapps/axis/WEB-INF/classes (jar do /lib)
vytvořit deployment descriptor *.wsdd (deploy-npdbserver.wsdd)
registrovat (java org.apache.axis.client.AdminClient deploy-npdbserver.wsdd)
(re)start Tomcatu (/usr/sbin/tomcat6 (re)start, nesmi byt nastavena CLASSPATH)
start MySQL (/usr/bin/mysqld_safe --user=mysql --log &)
test: http://test.com:8080/axis/services/NpdbServer?method=query

Realizace: ENUM

Nejprve využijeme open-source řešení BIND, jako nejrozšířenější implementaci DNS serveru. Instalace a konfigurace serveru je uvedena v příloze. Přidáme NAPTR záznamy se směrovací informací do definice domény:

  • 1.blue.comtel.cz. NAPTR 10 100 U E2U+pstn:tel “!^.*$!tel:1;npdi!“ . ; Not ported
  • 2 NAPTR 10 100 U E2U+pstn:tel “!^.*$!tel:2;npdi;rn=1234!“. ; PSTN-PSTN
  • 3 NAPTR 10 100 U E2U+pstn:tel “!^.*$!tel:3;npdi;rn=1234@sip.com;user=phone!“. ; PSTN-VoIP ported
  • 4 NAPTR 10 100 U E2U+pstn:tel “!^.*$!tel:4;npdi;rn=1234@sip-B.com;user=phone!“. ; VoIP-VoIP ported

Přestože je BIND jedním z nejrozšířenějších DNS serverů není vhodný pro implementaci přenositelnosti čísla. Z výsledků studie „Charles Shen and Henning Schulzrinne, Measurement and Evaluation of ENUM Server Performance, IEEE Communications Society, ICC 2007“ vyplývá, že řádově rychlejší odezvu poskytuje open-source řešení PowerDNS. Server spolupracuje s MySQL databází, která obsahuje veškeré DNS záznamy. Instalace a konfigurace serveru a databáze je srozumitelně popsána v manuálu dodávaném se zdrojovým kódem. Zde uvádíme pouze způsob vkládání NAPTR záznamů do MySQL databáze:

  • jednotlivý záznam:
 INSERT INTO records (domain_id, name, content, type,ttl,prio) VALUES (1,'0.0.1.test.com','100  50  "u"  "sip+E2U"     ""  _z3950._tcp.gatech.edu','NAPTR',3600,50);
  • více záznamů ze souboru (položky odděluje TAB):
 LOAD DATA LOCAL INFILE '/path-to/records' INTO TABLE records;

Reálná měření přenosu databáze přenositelnosti čísla

Přenos databáze přenositelnost čísla na rozhraní mezi centrální RNPDB a lokální LNPDB byl realizován jak v podobě Webové služby s pomocí protokolu SOAP, tak s pomocí ENUM mechanismu v podobě DNS serveru. Cílem je porovnat dobu mezi odesláním žádosti a doručením odpovědi v obou případech. Doba je měřena od začátku TCP spojení až po jeho ukončení. Měření proběhlo v sérii 1 000 pokusů s pravidelnými rozestupy.

Webová služba s databází v paměti:

ENUM/DNS server s databází v paměti:

  • DNSSEC: server - BIND, klient: dig (part of BIND)
  • Způsob: DNS SOA query (zone transfer)
  • Příkaz: dig @IP.ad.re.ss blue.comtel.cz AXFR
  • Průměrná doba trvání TCP spojení (SYN-FIN): 6 545 us

Webová služba s databází v MySQL:

ENUM/DNS server s databází v MySQL:

  • DNSSEC: server - PowerDNS + MySQL, klient: dig
  • Způsob: DNS SOA query (zone transfer)
  • Příkaz: dig @IP.ad.re.ss blue.comtel.cz AXFR
  • Průměrná doba trvání TCP spojení (SYN-FIN): 11 232 us

Zhodnocení:

Mechanismus ENUM umožňuje ukládat záznamy o přenesených číslech. S pomocí NAPTR záznamů lze uložit různé formáty směrovací informace a zajistit tak přenositelnost čísla pro různé telekomunikační prostředí. Řešením otázky místa uložení se pravděpodobně dočasně stává privátní ENUM. V budoucnu dojde k vytvoření celosvětového prostředí pro převody mezi telefonními čísly používanými v tradičních pevných a mobílních sítích a identifikátory URI používanými v IP telefonii, obecně v prostředí Internetu.

Z pohledu efektivity přenosu přínáší ENUM zkrácení doby zpracování a přenosu informace díky přímé spolupráci DNS protokolu s transportní vrstvou a tedy v porovnání s Webovou službou odpadá zpracování HTTP protokolu. Druhou výhodou je komprimace zpráv DNS protokolu.

V experimentálním přenosu databáze přenesených čísel mezi referenční a lokální databází bylo ověřeno, že přenos pomocí ENUM mechanismu je o 28,2%* rychlejší v případě dat uložených v paměti programu a o 34,8%* v případě dat uložených v MySQL databázi.

* Avšak doby odezvy DNS serveru byly změřeny pro dvě různé implementace, a tak nelze tato zrychlení mezi sebou porovnávat.

V současné době je v přípravě článek shrnující výše uvedená zjištění.

Přílohy

Příloha - Apache-Axis 1.2 instalace:

  • Instalace aplikačního serveru:
	su -
	yum install tomcat6
	yum install tomcat6-webapps
	yum install tomcat6-admin-webapps
	vim /etc/tomcat6/tomcat-users.xml (tman, ttt)
  • Instalace SOAP serveru - Apache AXIS
	cd /path-to/axis-1_4
	wget http://ftp.sh.cvut.cz/MIRRORS/apache/ws/axis/1_4/axis-bin-1_4.tar.gz
	tar zxf axis-bin-1_4.tar.gz
	cp -R axis-1_4/webapps/axis/ /var/lib/tomcat6/webapps/
  • „Instalace“ SOAP klienta - Webový prohlížeč, wget
	SOAP test: http://ns.blue.comtel.cz:8080/axis/services/Version?method=getVersion
	- error: java.lang.RuntimeException: No compiler found in your classpath!
	(you may need to add 'tools.jar')
	- solution: yum install java-1.6.0-openjdk-devel -> OK
  • Nastavení prostředí
vi /root/.bash_profile
	AXIS_HOME=/var/lib/tomcat6/webapps/axis
	AXIS_LIB=$AXIS_HOME/WEB-INF/lib
	AXISCLASSPATH=$AXIS_LIB/axis.jar:$AXIS_LIB/commons-discovery-0.2.jar:$AXIS_LIB/commons-logging-1.0.4.jar:$AXIS_LIB/jaxrpc.jar:$AXIS_LIB/saaj.jar:$AXIS_LIB/log4j-1.2.8.jar
	CLASSPATH=$CLASSPATH:$AXISCLASSPATH
	export AXIS_HOME AXIS_LIB AXISCLASSPATH CLASSPATH

Příloha - MySQL instalace:

Fedora Linux:
	yum install mysql		# MySQL client inst.
	yum install mysql-server	# MySQL server inst.
	yum install mysql-bench		# for mysql benchm.
	yum install mysql-devel		# for mysql app.dev.
Post-installation steps:
	/usr/bin/mysql_install_db --user=mysql # initialize grant tables
	/usr/bin/mysql_secure_installation
	/usr/bin/mysqld_safe &		# start the server
	/usr/bin/mysqladmin version	# verify
Start:
	/usr/bin/mysqld_safe --user=mysql --log &
Stop:
	/usr/bin/mysqladmin -u root shutdown
Zabezpeceni uctu:
	mysql
	> SET PASSWORD FOR ''@'localhost' = PASSWORD('XyZ');
	> SET PASSWORD FOR ''@'ns.blue.comtel.cz' = PASSWORD('XyZ');
	> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('XyZ23');
	> SET PASSWORD FOR 'root'@'ns.blue.comtel.cz' = PASSWORD('XyZ23');

Příloha - NpdbServer.java:

import java.io.*; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.SQLException; import java.sql.Statement; public class NpdbServer {

/**
 * @param args
 */
public String query(String[] args) {
	Class driver_class=null;
	String Reply="";
	try {
		driver_class = Class.forName("com.mysql.jdbc.Driver");
	} catch (ClassNotFoundException e) {
		e.printStackTrace();
		return "Error 1 - jdbc.Driver";
	}
	System.out.println("Found driver " + driver_class);
	Connection connection=null;
	try {
		connection = DriverManager.getConnection("jdbc:mysql://localhost:3306/npdb","root","blue123");
	} catch (SQLException e) {
		e.printStackTrace();
		return "Error 2 - getConnection to MySQL";
	}
	try {
		System.out.println("Established connection to " + connection.getMetaData().getURL());
	} catch (SQLException e1) {
		e1.printStackTrace();
	}
	Statement statement=null;
	try {
		statement = connection.createStatement();
		statement.execute("SELECT * FROM npdbt");
		ResultSet resset = statement.getResultSet();
		System.out.println("Name RoutingNumber");
		while(resset.next())
		{
			Reply = Reply + resset.getString("number") + resset.getString("rn");
		}
		resset.close();
		return Reply;
	} catch (SQLException e) {
		e.printStackTrace();
	}
	finally {
		if (statement != null)
		{
			try {
				statement.close();
			} catch (SQLException e) {
				e.printStackTrace();
			}
		}
		if (connection != null)
		{
			try {
				connection.close();
			} catch (SQLException e) {
				e.printStackTrace();
			}
		}
	}
return "Reached end";
} 	

}

Příloha - BIND instalace:

- instalace

(verze: ISC BIND 9.5.0-P2)
download: https://www.isc.org/
configure (s parametrem "--with-openssl" pro DNSSEC)
make
make install

- konfigurace:

/usr/local/sbin/rndc-confgen -> /etc/rndc.conf /etc/named.conf
vi /etc/named.conf (+ "caching and authoritative name server" configuration)
mkdir /etc/namedb
vi /etc/namedb/localhost.rev
vi /etc/namedb/test.com.db
master:
	zone "test.com" {
	     type master;
	     file "test.com.db";
	};
slave:
	zone "test.com" {
	     type slave;
	     file "test.com.db";
	     masters { Ma.st.er.IP; };
	};

- test: named-checkzone test.com /etc/namedb/test.com.db - run: named (check iptables)

Z pohledu realizace přenositelnosti v České republice není toto řešení ideální. Způsob směrování v ČR závisí na operátorovi a nikde není formálně specifikován. Například dominantní operátor používá ve své síti způsob Query on Release (QoR) a mimo svoji síť All Call Query (ACQ), jiný operátor používá například ACQ (detail o způsobech v RFC 3482. V ČR platí, že formát směrovacího čísla (routing number) není jednotný a povinností operátora je zajistit předání čísla na rozhraní přijímajícího operátora. Samo číslo se předává úplně obyčejně, bez jakýchkoliv příznaků, že jde o portaci.

Příloha - Rozšíření systému doménových jmen (DNSSEC)

Systém doménových jmen navržený v RFC 1033, 1034 a 1035 a reprezentovaný DNS serverem poskytuje informace, jejichž původ není zaručen. Aby bylo možné ověřit identitu serveru poskytujícího informace a zajistit nenarušené doručení záznamů (během přenosu nedošlo ke změně) lze použít rozšíření DNSSEC podle RFC 4033, 4034 a 4035. Vychází z použití klíčů a přidává k existujícím DNS záznamům 4 nové záznamy:

  • DNSKEY - veřejný klíč pro ověření identity DNS serveru
  • RRSIG - podpis DNS záznamů
  • NSEC - „spojka“ DNS záznamů zamezující vložení cizího záznamu
  • DS - ověření veřejného klíče zamezující jeho podvržení

Příloha - Instalace a konfigurace DNS serveru s podporou DNSSEC

Pro realizaci DNS s podporou DNSSEC byla vybrána implementace Berkeley Internet Name Domain (BIND) verze 9.5.0-P2 od Internet System Consortium (ISC). BIND je hardwarově poměrně nenáročný. Zvolená konfigurace Intel(R) Core(TM)2 CPU @ 2.00GHz byla pro testovací účely naprosto dostatečná. Operačním systémem byl Linux Fedora Core 9.

  • BIND 9.5 Instalace
configure --with-openssl
make
make install
  • Konfigurace - „caching“ nebo „authoritative“ name server (BIND 9 Manual - kap.3)
vi /etc/named.conf
  • Utilita pro ovládání name severu - rndc
/usr/local/sbin/rndc-confgen		# výstup do /etc/rndc.conf, /etc/named.conf
  • Definice záznamů domény
mkdir /etc/namedb
vi /etc/namedb/localhost.rev		# reverzní mapování lokální IP adresy
vi /etc/namedb/example.cesnet.cz.db	# nepodepsané záznamy domény example.cesnet.cz
  • Vytvoření klíčů:
dnssec-keygen -a RSASHA1 -b 768 -n ZONE example.cesnet.cz.	#  výstup: Kexample.cesnet.cz.+005+27183.key - veřejný klíč, Kexample.cesnet.cz.+005+27183.private - privátní klíč
  • Podepsání zóny:
dnssec-signzone -o example.cesnet.cz /etc/namedb/example.cesnet.cz.db	#  výstup: example.cesnet.cz.db.signed, upravit cestu k v /etc/named.conf
  • Ověření konfigurace:
named-checkzone example.cesnet.cz /etc/namedb/example.cesnet.cz.db
  • Spuštění serveru:
named					# případné chyby v logu /var/log/messages
  • Klasický DNS dotaz:
dig @name_server_ip 1.0.2.4.example.cesnet.cz NAPTR
  • Dotaz s použitím DNSSEC:
dig @name_server_ip +dnssec ns.example.cesnet.cz

Příloha - Přenos zóny (DNS zone transfer) - Konfigurace Master a Slave serveru

Pro realizaci přenosu zóny nastavíme jeden DNS server jako „Master“ (primary) a druhý jako „Slave“ (secondary) úpravou named.conf (type, masters, allow-transfer). Zajistíme průchodnost Iptables pro TCP provoz na cílový port 53.

Zónový přenos mezi servery zabezpečíme mechanismem TSIG. Ten spočívá v přidání podpisu ke zprávám vyměněným mezi servery.

  • Generování klíče
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example1-example2.cesnet.cz.			# example1 - Master, example2 - slave, použijeme klíč z .private
  • Použití klíče v konfiguraci zdrojového serveru
vi /etc/named.conf
	server 212.24.135.15 (								# IP adresa cílového serveru
        	keys { example1-example2.cesnet.cz. ;};
	};
	key example1-example2.cesnet.cz. {
	        algorithm hmac-md5;
	        secret "AB5YvVRT/reiDgySIKAm4ew==";					# obsah key elementu z .private, klíč stejný pro obě strany
	};

…experiment…

Z pohledu rychlost odezvy je současný systém „offline“, tedy není přístupný v reálném čase. Z porovnání vychází lépe databáze založená na ENUM, která může být přístupná v reálném čase. Nespornou výhodou ENUM je kombinace NP záznamu s informací o směrování. NP databáze obsahuje pouze ID operátora, ke kterému bylo číslo přeneseno. ENUM by mohl umožnit nejen uložení takového identifikátoru, ale mohl by poskytnout i informaci o dostupnosti cíle po IP. Způsob zabezpečení přenosu v současném systému NP je pomocí certifikátů. ENUM (DNS) má možnost použití DNSSEC.

…porovnání obou zabezpečení - integrita, ověřování zdroje, šifrování dat, …

Příloha - Přenositelnost v České republice

Přenositelnost v ČR byla zavedena na konci roku 2002 zákonem, který nedefinoval technické podmínky a nepřidělil regulátorovi právo je stanovit. Operátoři veřejných telefonních sítí sdružení v asociaci APVTS (Asociace Provozovatelů Veřejných Telekomunikačních Systémů) iniciují spolu s regulátorem (ČTU) vznik společnosti CNPAC s.r.o. (Czech Number Portability Administrative Centre), správce celonárodní databáze přenositelnosti čísel. Technické řešení přenositelnosti čísla v pevných sítích bylo stanoveno formou celonárodní referenční databáze pro přenositelnost čísla (Reference Number Portability Database, RNPDB). Jedná se o jediný platný zdroj přenesených číslech v ČR poskytující informace pevným i mobilním operátorům do jejich lokálních databází (LNPDB). Databáze se skládá ze záznamů obsahujících:

  • přenesené číslo
  • identifikátor dárce (komu bylo číslo přiřazeno regulátorem)
  • identifikátor příjemce (kdo číslo obsluhoval)
  • datum převodu (dokdy příjemce číslo obsluhoval)

Přenositelnost mobilních telefonních čísel (pouze mezi mobilními sítěmi) byla v ČR zavedena na konci roku 2005. Vytvoření služby iniciují Asociace provozovatelů mobilních sítí (APMS) a národní regulátor. Správcem databáze se stává opět CNPAC. Technické řešení je opět formou referenční databáze (RNPDB-M) se záznamy přenesených čísel mobilních operátorů, poskytující informace pevným i mobilním operátorům.

+Z porovnání struktury české sítě NP a struktury ENUM vyplývá, že ENUM může realizovat Master-Slave architekturu napodobující RNPDB - LNPDB vztah nebo vytvořit nový, veřejný a škálovatelný systém. Ukládání záznamů NP je v současném NP systému založeno na databázi. V porovnání s ENUM, který uchovává data v textovém souboru (DNS Master file) se jedná o řešení efektivností ukládání srovnatelná. Přenos dat v současném systému i v systému založeném na ENUM je založený na IP. Zadávání a sledování změn v současném NP systému probíhá přes HTTP protokol (HTTP/TCP/IP) a je zabezpečeno certifikáty. Změny jsou zadávány v XML formátu.

+addOtherEUCountries

cs/protokoly/enumnp.txt · Poslední úprava: 2009/06/08 09:44 autor: rudinsj@cesnet.cz
Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0