Luận văn Nghiên cứu các vấn đề kỹ thuật công nghệ bản chất của ENUM - Hệ thống đánh số điện tử

p thuận, TSB sẽ yêu cầu RIPE NCC thực hiện chuyển giao. Danh sách các yêu cầu chuyển giao đã được RIPE NCC xử lý có ở I.4.2. Các quốc gia đã và đang triển khai ENUM I.4.2.1. CHÂU ÂU Châu Âu hiện nay là khu vực có nhiều quốc gia nhất được ITU chấp nhận chuyển giao cho quyền quản lý tên miền ENUM tương ứng mã viễn thông quốc gia. Rất nhiều quốc gia Châu Âu đã xây dựng hệ thống thử nghiệm ENUM. Trong đó có những quốc gia đang tiến gần đến giai đoạn cung cấp dịch vụ ENUM thương mại Anh: Bộ Thương mại và Công nghiệp Anh thành lập UKEG (UK ENUM Group), có trách nhiệm nghiên cứu và triển khai thử nghiệm ENUM dưới mã quốc gia +44. UKEG đã thực hiện một dự án thử nghiệm ENUM (từ 6/2002 đến 6/2003) và giao cho UKETG (UK Enum Trial Group) phụ trách. Dự án thử nghiệm xây dựng bao gồm các đối tượng: - Tổ chức quản lý cấp một (Tier 1) tên miền ENUM quốc gia. - Nhà cung cấp dịch vụ DNS ENUM (hosting zone mức thấp nhất và khai báo bản ghi NAPTR cho khách hàng) - ENUM Registrar (cung cấp dịch vụ đăng ký) - Nhà cung cấp dịch vụ ứng dụng (Application Service Provider) - Tổ chức cung cấp dịch vụ xác thực (Authentication Agency) - Người sử dụng. Hiện nay, dự án thử nghiệm đã hoàn tất và có sản phẩm từ tháng 3 năm 2009. Từ các kết quả do UKETG báo cáo, UKEG đang hoạch định hướng phát triển ENUM trong không gian mã quốc gia +44 và chiến lược cho giai đoạn cung cấp thương mại. E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 18 Áo Áo là một trong những quốc gia Châu Âu đầu tiên thử nghiệm ENUM. Việc thử nghiệm ENUM tại Áo được giám sát bởi tổ chức quản lý viễn thông Áo (Austrian Regulatory Authority for Telecommunications and Broadcasting – RTR GmbH) Hiện tại, Áo đã thực hiện thành công một hệ thống quản lý đăng ký ENUM hoàn chỉnh gồm các Registry Tier1, Tier2, Registrar, hệ thống đăng ký hỗ trợ thủ tục EPP, công bố các chính sách về quá trình đăng ký, kế hoạch đánh số và phân bổ cho ENUM,VoIP (ENUM and VoIP Numbering Plan) và đang bước sang giai đoạn cung cấp dịch vụ. Tổ chức quản lý ccTLD (NIC.at) được chỉ định là Tier 1. Để thực hiện giai đoạn thương mại, RTR ký kết hợp tác với NIC.at để hệ thống hoá toàn bộ: - Các khung chính sách quốc gia cho ENUM - Mọi vấn đề liên quan đến tên miền 3.4.e164.arpa - Hướng dẫn cho Registrar - Mọi yêu cầu cho quản lý, vận hành, kỹ thuật. Vào quý 2/2004, Áo sẽ triển khai dịch vụ thương mại ENUM (cho cả số điện thoại cố định và di động) trong phạm vi mã code +43780 Pháp Để phục vụ cho nghiên cứu và thử nghiệm ENUM, Pháp đã thành lập tổ chức nghiên cứu cấp quốc gia về ENUM và thực hiện dự án Numerobis (từ 2/2003 đến 9/2004), thử nghiệm ENUM dưới mã quốc gia đã được chuyển giao cho Pháp là 3.3.e164. arpa. Tham gia dự án gồm: Học viện IRT, nhà cung cấp viễn thông cố định đồng thời cung cấp dịch vụ ISP - France Telecom, nhà cung cấp dịch vụ di động: SFR, Orange, tổ chức quản lý tên miền ccTLD của Pháp - AFNIC. I.4.2.2. CHÂU MỸ Hiện nay, Mỹ, Canada và 16 quốc gia khác trong khu vực Bắc Mỹ có chung mã cc +1 và hệ thống đánh số NANP (North American Numbering Plan) với 10 số NXX NXX XXXX. Tháng 10/2000, NTIA (National Telecommunications and Information Administration) - một cơ quan thuộc Bộ thương mại Mỹ đã tổ chức hội thảo về giải pháp thực hiện ENUM, không triển khai hệ thống thử nghiệm mà hướng tới ứng dụng thương mại thực tế. E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 19 Tháng 2/2001 nhóm nghiên cứu thử nghiệm ENUM (Study Group A Ad Hoc on ENUM) được thành lập, đã tư vấn cho Bộ Ngoại giao Mỹ thiết lập ENUM forum với nhiệm vụ nghiên cứu về các vấn đề chính sách, công nghệ trong phát triển ENUM. Do mã coutry code của Mỹ là mã dùng chung, Mỹ đã chính thức yêu cầu ITU không chấp nhận chuyển giao toàn bộ hoặc một phần mã +1 cho bất cứ tổ chức nào và hiện nay đang nghiên cứu để có giải pháp cho các vấn đề chính sách : - Chính sách trong việc chuyển giao tên miền ENUM tương ứng mã code +1: Sẽ tìm kiếm sự hợp tác giữa 18 nước Bắc Mỹ để có một tổ chức độc lập phụ trách chung cho mã code +1 của Bắc Mỹ hay RIPE NCC chỉ chuyển giao độc lập cho Mỹ các mã thuộc phạm vi USA. - Sẽ duy trì duy nhất một nhà quản lý Tier 1 hay duy trì một số nhà quản lý cấp Tier 1. (Trong trường hợp nhiều tổ chức Tier 1 thì thực hiện phân chia phạm vi quản lý và thực hiện đồng nhất trong chính sách giữa các nhà quản lý Tier1 như thế nào). I.4.2.3. CHÂU Á - THÁI BÌNH DƯƠNG Trong khu vực Châu Á – Thái Bình Dương, ENUM đang được thử nghiệm ở phạm vi quốc gia tại Nhật Bản, Hàn Quốc, Trung Quốc, Đài Loan, Singapore, Úc. Trong đó Trung Quốc và Singapore đã được ITU và RIPE NCC chuyển giao quản lý tên miền ENUM tương ứng mã quốc gia Mới đây, CNNIC, JPRS (quản lý ccTLD .jp của Nhật), KRNIC, SGNIC, TWNIC đã thành lập APEET (Asian Pacific Enum Engineering Team), giới hạn thành viên là các tổ chức quản lý ccTLD tại khu vực Châu Á – Thái Bình Dương. Mục đích: - Chia sẻ kinh nghiệm trong triển khai thử nghiệm ENUM, trao đổi phần mềm và source code về ENUM. - Dự định APETF sẽ tổ chức một track về ENUM/SIP tại APRICOT 2005 và cung cấp dịch vụ điện thoại ENUM/SIP phone tại APRICOT 2005. Trung quốc Tổ chức đầu tiên thử nghiệm ENUM tại Trung Quốc là CNNIC (tổ chức quản lý tên miền ccTLD của Trung Quốc). CNNIC hoạt động dưới sự quản lý của Bộ Công nghiệp thông tin Trung Quốc (Ministry of Information Industry of China – MII ). E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 20 Tháng 2/2002 MII đã quyết định thử nghiệm ENUM và thành lập China MII-ENUM study group dưới sự quản lý của MII, trong đó CNNIC là thành viên chủ chốt. Nhóm nghiên cứu có các thành phần: Các nhà cung cấp dịch vụ viễn thông, các học viện, ISP…lập thành các nhóm làm việc Tháng 9/2002 Trung Quốc đã thành công trong việc yêu cầu ITU chuyển giao tên miền +86 về Trung Quốc. Tháng 10/2002, Trung Quốc thiết lập máy chủ thứ cấp cho tên miền e164.arpa Từ 7/2003 đến 9/2003, Trung Quốc nâng cấp hệ thống thử nghiệm ENUM và mở rộng dịch vụ thử nghiệm ENUM như một dịch vụ miễn phí công cộng dưới tên miền 6.8.e164. arpa và có 520 số ENUM đăng ký. Hiện tại, Trung Quốc đang tiếp tục triển khai giai đoạn hai của thử nghiệm cung cấp dịch vụ, đồng thời nghiên cứu để đưa ra một hệ thống quản lý phân cấp (Tier 2 ) phù hợp với Trung Quốc. Đồng thời, Bộ Công nghiệp thông tin Trung Quốc - MII đang tư vấn cho chính phủ Trung Quốc về việc mở một hệ thống cung cấp dịch vụ thương mại thử nghiệm (dự kiến là thực hiện áp dụng công nghệ ENUM cho dịch vụ SIP) và dự kiến triển khai thử nghiệm công cộng với một số ISP và nhà cung cấp dịch vụ. Hàn quốc Hàn Quốc là một trong những quốc gia rất tích cực trong triển khai dịch vụ ENUM Từ tháng 10/2000: tham gia các diễn đàn và hoạt động quốc tế về ENUM: ITU, IETF, US ENUM Forum… Đầu 2003, chính phủ (Bộ Thông tin và Truyền thông - MIC) đã đầu tư 300.000 USD cho dự án thử nghiệm (từ 3/2003 đến 12/2003), thiết lập hệ thống thử nghiệm và cung cấp thử nghiệm ENUM như một dịch vụ công cộng (đăng ký qua một Website riêng). Hiện nay dự án thử nghiệm đã hoàn tất, cung cấp dịch vụ cho 1495 đăng ký. Hàn Quốc đang tiếp tục làm việc với ITU để chuyển giao tên miền ENUM tương ứng mã quốc gia +82 và đặt kế hoạch cung cấp dịch vụ thương mại vào đầu 2005. Đài Loan Bắt đầu nghiên cứu ENUM từ 2001. Năm 2002 bắt đầu thử nghiệm thực tế cùng các ISP, nhà cung cấp viễn thông, các đơn vị đăng ký (PSTN, VoIP) E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 21 Tháng 7/2003 thành lập diễn đàn ENUM (hội tụ cả Hội đồng khoa học quốc gia, Tổng cục viễn thông, Mạng khoa học quốc gia, Mạng chính phủ, TWNIC, hiệp hội máy tính quốc gia và các nhà sản xuất, cung cấp dịch vụ...): chuẩn bị khung chính sách, xúc tiến thử nghiệm thực tế, chuẩn bị cho triển khai thực tế dịch vụ SIP/ENUM, tìm hiểu thực tế sử dụng của người dùng Đã hoàn thành quy hoạch cho mã số 0944xxxxxx (cho phép gọi từ PSTN tới IP phone) Tiếp tục thử nghiệm rộng rãi với 5 khu vực thử nghiệm công cộng. Trong thử nghiệm công cộng gọi PSTN – IP -> hạn chế các đích gọi và giới hạn thời lượng cuộc gọi trong 25 phút/người/tháng Đã hoàn thành thử nghiệm hiệu năng, chất lượng dịch vụ ENUM Tháng 10/2003 thành lập trung tâm chuyển mạch mở cho IP phone (IPOX – IPPhone open exchange). Quy hoạch cho 070xxxxxxx. Chưa được chuyển giao mã ENUM từ ITU. Tạm sử dụng e164.tw Singapore Triển khai bởi iDA (Infocomm developement authority – kết hợp của Telecom Authority of Singapore và National Computer Board). Được chuyển giao mã quốc gia 65 từ ITU tháng 6/2003. Đã thành lập ENUM working group, thành lập SIG (special interest group) thuộc SingAREN. Thử nghiệm diện rộng kết hợp cùng Đại học kỹ thuật Nanyang và Trường Bách khoa Singapore; Thử nghiệm chuyển giao ENUM cho các nhà cung cấp; Thiết lập kết nối hạn chế giữa IP và PSTN. Ngoài ra còn rất nhiều nước vẫn đang trong quá trình nghiên cứu và thử nghiệm. E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 22 Tình hình triển khai ENUM trên thế giới: (Nguồn: E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 23 E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 24 Hình 7: Dữ liệu về tình hình triển khai ENUM các nước E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 25 CHƯƠNG II. CƠ SỞ KỸ THUẬT CỦA ENUM II.1. Số điện thoại E.164 ITU-T E.164 ra đời vào tháng 5 năm 1997, thuộc vào seri E: "Hoạt động chung của mạng, dịch vụ điện thoại, hoạt động dịch vụ và các tác nhân con người", quy định các "Hoạt động, đánh số, định tuyến và các dịch vụ di động - Hoạt động quốc tế - Quy hoạch đánh số cho dịch vụ điện thoại quốc tế". Trong đó E.164 quy định "Quy hoạch đánh số viễn thông công cộng quốc tế" E.164 tập trung quy định cấu trúc số và chức năng của 3 dạng cơ bản của số sử dụng trong viễn thông công cộng quốc tế là theo vùng, dịch vụ chung và theo mạng. E.164 quy định cụ thể mọi loại tiền tố cần thiết cho từng mục đích nhằm thống nhất việc đánh số toàn cầu cho mọi loại nhu cầu dịch vụ. Nó cũng cung cấp các quy ước dùng để định tuyến cuộc gọi giữa các số và nhóm số trên toàn hệ thống. Các nội dung chính của E.164 gồm: Cấu trúc số viễn thống công cộng quốc tế, gồm: - Số theo vùng địa lý: gồm có mã quốc gia/mã vùng địa lý (CC), mã đích quốc gia (NDC), số thuê bao Hình 8. Cấu trúc số theo vùng địa lý - Số theo dịch vụ toàn cầu: gồm mã quốc gia CC và số thuê bao dịch vụ toàn cầu GSN CC NDC SN 15 số Số viễn thông quốc tế theo vùng địa lý 1 đến 3 số Số quốc gia N(S)N (15 – n) số n số E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 26 Hình 9. Cấu trúc số theo dịch vụ toàn cầu - Số theo mạng: gồm mã quốc gia CC, mã nhận dạng mạng IC và mã thuê bao Hình 10. Cấu trúc số theo mạng Các quy định về việc cấp phát mã quốc gia, mã nhận dạng mạng, mã dịch vụ toàn cầu , cũng như quy định cụ thể cho từng loại mã về độ dài, cấu trúc tiền tố, mã thoát (escape code), cũng như các khuyến nghị cho cấu trúc đánh số quốc gia được mô tả rất kỹ trong tài liệu E.164. Định dạng 1 số viễn thông công cộng quốc tế theo E.164 sẽ có dạng VD: + 84 - 8 - 3847 - 1104 Ở đây số viễn thông được đánh theo cấu trúc phân theo vùng địa lý: Trong đó : + là tiền tố cho biết số viễn thông là đầy đủ 84 là mã quốc gia của Việt Nam CC GSN 15 số Số viễn thông quốc tế cho dịch vụ toàn cầu 3 số 12 số CC NDC SN 15 số Số viễn thông quốc tế cho các mạng 3 số 12 số (12 – x) số 1 đến 4 số x E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 27 8 là mã nhận dạng viễn thông cố định khu vực thành phố Hồ Chí Minh 38471104 là số thuê bao trong mạng Số viễn thông đầy đủ như mô tả ở trên có thể được sử dụng để truy vấn ENUM. Chi tiết về E.164, và kế hoạch đánh số ở Việt Nam có ở Phụ lục II.2. Kỹ thuật ánh xạ số điện thoại - DNS Ánh xạ số điện thoại E.164 vào hệ thống DNS là nền tảng của ENUM, nó cho phép sử dụng hệ thống quản lý phân cấp của DNS, các thủ tục truy vấn Internet đã phát triển để mở rộng nội dung thông tin chứa trong cùng 1 số điện thoại, vốn vẫn được coi là duy nhất, và thường được coi là tương ứng gần nhất đối với 1 chủ thể. Với 1 số điện thoại ứng với một cá nhân nào đó, thông qua các phép truy vấn (giống như tra cứu danh bạ, trang vàng) có thể tìm được rất nhiều các thông tin liên quan. Ở đây chỉ khác là hệ thống lưu trữ thông tin là hệ thống DNS được sửa đổi, phép truy vấn là thủ tục DNS đã rất phát triển. Với thế mạnh của dịch vụ Internet, các truy vấn dựa trên DNS được coi là rất dễ triển khai và ứng dụng. Như vậy với ENUM, có thể thấy viễn thông và Internet đã có điểm hội tụ. Trong tài liệu này còn có thể tìm thấy rất nhiều điểm hội tụ khác nữa giữa 2 lĩnh vực này. Một cách vắn tắt, để tìm được tên miền tương ứng với một số E.164 nào đó, các bước sau sẽ được thực hiện: II.2.1. Các bước định dạng truy vấn ENUM 1. Số E.164 phải được viết dưới dạng đầy đủ theo quy định của ITU, bao gồm cả các mã quốc gia IDDD11, theo dạng (VD): +84-4-8226115 2. Bỏ đi các ký tự không phải số, trừ dấu "+": +8448226115 3. Bỏ nốt dấu "+": 8448226115 4. Bỏ dấu chấm "." vào giữa các chữ số: 8.4.4.8.2.2.6.1.1.5 5. Đảo ngược thứ tự: 5.1.1.6.2.2.8.4.4.8 6. Thêm chuỗi "e164.arpa" vào cuối: 5.1.1.6.2.2.8.4.4.8.e164.arpa 11 International Direct Dialing Digits E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 28 Trong hệ thống tên miền, người ta sử dụng một trường dữ liệu đặc biệt là trường NAPTR để chỉ ra các cách khác nhau khi kết nối tới 1 trạm có định danh nào đó. Nói một cách khác, nó chỉ ra các dịch vụ mà trạm đó có. Việc xử lý các trường NAPTR được thực hiện thông qua một thuật toán gọi là thuật toán NAPTR, đầu vào của thuật toán này là chuỗi thể hiện số E.164 theo định dạng như định nghĩa trong bước 2 của quá trình chuyển đổi nói trên, tức là chuỗi đầu vào có dạng: "+8448226115" II.2.2. Cấu trúc của trường NAPTR ENUM-Domain IN NAPTR order preference flag service regexp replacement Tên miền IN NAPTR thứ tự mức ưu tiên cờ dịch vụ biểu thức thay thế Ví dụ 1 $ORIGIN 5.1.1.6.2.2.8.4.4.8.e164.arpa. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:minhhung@hutech.edu.vn!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto: minhhung@hutech.edu.vn!" . IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+8448226115!" . IN NAPTR 100 10 "u" "ldap+E2U" "!^+84(.*)$!ldap://ldap.hutech.edu.vn/cn=01!" . Cú pháp và các loại hình dịch vụ được bàn đến ở phần sau. II.2.3. Ý nghĩa của các trường trong cấu trúc NAPTR Trường "thứ tự" (order) là một số nguyên không dấu 16 bit, được bắt buộc sử dụng khi có nhiều bản ghi NAPTR được trả về trong cùng 1 dữ liệu phản hồi. Khi đó bản ghi NAPTR có thứ thự nhỏ hơn sẽ được sử dụng. Trường "độ ưu tiên" (preference) là một số nguyên không dấu 16 bit, được sử dụng (nên) khi nhiều bản ghi NAPTR được trả về, có cả thứ tự giống nhau. Trường này tương tự như trường độ ưu tiên trong bản nghi MX của DNS, và được các nhà quản trị sử dụng để lái dịch vụ tới các máy chủ khác có khả năng xử lý tốt hơn. E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 29 Trường "cờ": (flag) là một chuỗi ký tự, chứa tham số ảnh hưởng tới lần truy vấn tiếp theo, thường được dùng để tối ưu hoá quá trình truy vấn. Cờ "u" được hiểu là luật này là luật áp dụng để kết thúc chu trình, và dữ liệu trả về là một URI. Trường "dịch vụ" (service) là một chuỗi ký tự, chỉ ra thủ tục phân giải và dịch vụ phân giải sẽ sẵn sàng khi việc viết lại được thực hiện thông qua các trường "biểu thức" và "thay thế". Trường "biểu thức" (regexp - regular expression) chứa một chuỗi biểu thức thay thế mà khi áp dụng vào chuỗi nguyên thuỷ sẽ tìm ra được tên miền nào sẽ được truy vấn tiếp theo. Cú pháp của trường này sẽ được bàn đến sau, thông qua các thuật toán của thủ tục DDDS12. Trường "thay thế" (replacement) có thể là một tên miền mới để truy vấn tuỳ theo các giá trị có thể của trường "cờ". Trường này được sử dụng khi trường "biểu thức" là một phép thay thế đơn giản. Bất kỳ giá trị nào của trường này cũng phải là một tên miền đầy đủ (full qualified domain name). Một lưu ý là tất cả các quá trình xử lý thay thế và truy vấn đều được ứng dụng thực hiện, bản thân hệ thống DNS không thực hiện tính toán xử lý nào. Đầu vào của thuật toán là một chuỗi số E.164 được mã hoá theo định dạng quy định ở trên, đầu ra của thuật toán là một chuỗi định danh tài nguyên thống nhất URI13 trong dạng thức tuyệt đối của nó theo [RFC2396] Dịch vụ hỗ trợ cuộc gọi là E2U14. Xem xét lại Ví dụ 1, ở đây chỉ dùng cờ "u" để chỉ ra kết quả là các URI, một số các dịch vụ được sử dụng là : - Dịch vụ SIP15 (thủ tục tra cứu SIP URI được định nghĩa trong [RFC2543]), dịch vụ phân giải sử dụng là "sip+E2U", trường regexp chỉ ra rằng số E.164 đầu vào sẽ được thay thế hoàn toàn bằng một chuối SIP URI là "sip:minhhung@hutech.edu.vn", và như vậy ứng dụng SIP sẽ có thể thực hiện các truy vấn tiếp theo để kết nối tới đầu cuối SIP tương ứng 12 Dynamic Delegation Discovery System - DDDS 13 Uniform Resource Identifier 14 ENUM to URI 15 Session Initiation Protocol - Thủ tục thường được sử dụng cho khởi tạo phiên làm việc của VoIP E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 30 - Dịch vụ email sử dụng dịch vụ phân giải "mailto+E2U", trả về chuỗi URI của dịch vụ mail là: "mailto: minhhung@hutech.edu.vn ", và như vậy ứng dụng thư điện tử sẽ có được một URI mới để thực hiện các truy vấn tiếp theo (trong trường hợp này ứng dụng sẽ thực hiện truy vấn DNS thông thường để tìm bản ghi MX tương ứng với tên miền "hutech.edu.vn", và thực hiện việc chuyển email...) - Dịch vụ telephone sử dụng dịch vụ phân giải "tel+E2U", nói chung có thể trả về một số điện thoại bất kỳ ứng với khả năng kết nối của đầu cuối bị gọi (Ví dụ có thể trả lại số ISDN thay vì số telephone thông thường). Tuy nhiên có trường hợp trả về đúng với số đầu vào (ở đây là 8448226115) thì có thể bị lặp (tức là có thể sẽ lại bắt đầu chu trình truy vấn từ số này, sử dụng tất cả các chu trình nói trên một cách vô định). Ứng dụng đầu cuối có trách nhiệm xử lý các trường hợp lặp này. - Dịch vụ thư mục (directory) dùng để tìm kiếm thông tin kiểu trang vàng, sử dụng thủ tục LDAP với dịch vụ phân giải là "ldap+E2U". Trong trường hợp này, thuật toán trả về chuỗi URI cho phép sử dụng LDAP để truy vấn thông tin. Với các số E.164 có mã quốc gia là 84 thì ứng dụng có thể sử dụng truy vấn tiếp theo là truy vấn LDAP tới máy chủ thư mục có địa chỉ là "ldap.hutech.edu.vn" với URI là "ldap://ldap.hutech.edu.vn/cn=01" II.3. Hệ thống DDDS Hệ thống dò tìm đại diện tự động (Dynamic Delegation Discovery System - DDDS) là một thành phần cơ bản quan trọng của ENUM. Nó được đưa vào ENUM để giải quyết các vấn đề gặp phải khi thể hiện các tài nguyên gắn kết với số ENUM một cách tối ưu nhất, và hỗ trợ các giải pháp dữ liệu động tốt nhất. DDDS được sinh ra như kết quả của một hướng nghiên cứu mới của nhóm làm việc chuyên trách về "tên tài nguyên thống nhất" URN16 do khi nhóm nghiên cứu về vấn đề URN gặp phải vấn đề: làm thế nào để có thể tìm kiếm được thông tin về một URN nếu trong URN không chứa các thông tin định vị dịch vụ mạng (chẳng hạn không chứa tên hoặc địa chỉ máy chủ truy 16 Uniform Resouce Name E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 31 vấn). Một hệ thống được đưa ra có thể sử dụng một cơ sở dữ liệu luật dùng để áp đặt lên URN nhằm tìm ra thông tin trên từng đoạn của URN. Đầu tiên, hệ thống này được gọi là dịch vụ dò tìm thiết bị truy vấn RDS (Resolver Discovery Service), chỉ dùng được với các URN. Sau này, phương pháp tương tự được áp dụng trên các chuỗi không phải URN và trở thành DDDS. DDDS được mô tả bởi một hệ thống các tài liệu chuẩn của IETF, gồm 5 phần với các RFC số 3401, 3402, 3403, 3404, 3405. DDDS được định nghĩa đơn giản là một thuật toán tổng quát nhằm áp dụng một luật chuyển đổi chuỗi thu nhận được một cách động lên một chuỗi đơn của ứng dụng. Nói cách khác, DDDS là phương pháp dùng để chuyển đổi chuỗi thành dữ liệu một cách động, sử dụng để hỗ trợ cấu hình động cho các hệ thống uỷ quyền (delegation). Để làm được việc này, DDDS đơn giản là sử dụng các luật chuyển đổi chuỗi áp đặt tuần tự và lặp lại lên các chuỗi đầu vào cho tới khi điều kiện kết thúc đạt được, và ánh xạ kết quả vào các dữ liệu chứa trong cơ sở dữ liệu DDDS. II.3.1. Cách thực hiện DDDS Luật bắt đầu (First well known rule) Tìm khóa trong CSDL DDDS Áp dụng các luật lên các chuỗi duy nhất cho tới khi kết quả không rỗng nhận được thỏa mãn yêu cầu của ứng dụng Đầu ra của luật cuối cùng chính là kết quả cần tìm của ứng dụng Kết thúc luật cuối cùng chưa ? Chuỗi đầu vào duy nhất của ứng dụng Khóa đầu tiên Khóa Tập hợp luật Tập hợp luật Khóa Sai Đúng CSDL DDDS luôn nhận 1 khóa và trả về 1 luật Đầu vào là luật và chuỗi ứng dụng Đầu ra là khóa hoặc kết quả Nếu luật chưa kết thúc thì đầu ra của nó là khóa mới để áp dụng tiếp tìm các tập hợp luật khác Hình 131. Thuật toán DDDS E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 32 Đầu tiên, chuỗi đơn đầu vào của ứng dụng được áp đặt một luật gọi là luật bắt đầu (First Well Known Rule). Luật này do ứng dụng định ra, chứ không phải lấy từ cơ sở dữ liệu. Luật này nhằm tìm ra khoá đầu tiên dùng để truy vấn cơ sở dữ liệu DDDS. Với khoá tìm được, truy vấn cơ sở dữ liệu DDDS sẽ tìm được luật áp dụng tiếp theo. Luật này áp dụng lên chuỗi đầu vào sẽ cho khoá mới, hoặc cuối cùng là kết quả đầu ra mong muốn. Để thấy được sự phức tạp của các biểu thức áp dụng trong DDDS, ta xem xét ví dụ sau: Xem xét 1 URN có định dạng lấy từ MIME17 "Content-Ids" như sau: urn:cid:199606121851.1@bar.example.com Để truy vấn thông tin về URN này, ứng dụng thực hiện theo quy ước, ở đây việc đầu tiên là tìm thông tin về dạng dữ liệu MIME, bằng cách tìm chuỗi dữ liệu giữa 2 dấu ":" đầu tiên. Kết quả thu được là "cid" Ứng dụng cũng được quy ước trước là với chuỗi thu được, nó phải thêm vào một đuôi "urn.arpa" để có được một khoá tìm kiếm đầy đủ. Khoá ở đây là "cid.urn.arpa" Với truy vấn tên miền "cid.urn.arpa", ứng dụng thu được một bản ghi NAPTR như sau: cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" . Do ở đây chỉ có 1 trường NAPTR trả về nên không có vấn đề sắp xếp thứ tự ưu tiên. Áp dụng luật thu được trên chuỗi URN ban đầu ta thu được chuỗi "example.com" (thành phần thứ 2 theo như biểu thức thay thế chỉ ra, giữa 2 dấu "!") Truy vấn tiếp tên miền "example.com" ta thu được: example.com. ;; order pref flags service regexp replacement IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com. 17 Multimedia Internet Mail Extension E164 - ENUM GVHD: Ths.Nguyễn Đức Quang Nguyễn Minh Hưng - 106102046 Trang 33 Chi tiết thêm về thuật toán DDDS tham khảo [RFC3402]18. II.3.2. Phân bố các luật DDDS qua DNS Để có thể phân bố các luật DDDS một cách hiệu quả và đơn giản, DDDS sử dụng cơ sở dữ liệu DNS như một cơ sở dữ liệu phân bố luật, định nghĩa theo [RFC3403]19. Các khoá ở đây là các tên miền, và các luật được mã hoá bằng các trường NAPTR. Một truy vấn khoá sẽ có dạng một truy vấn tên miền thông thường, và kết quả trả về sẽ là một loạt các bản ghi NAPTR chứa các luật cần truy vấn. RFC3403 cũng đồng thời thay thế cho RFC2915, và được coi là định nghĩa chính thức của NAPTR. Các mô tả chính như sau: Bộ mã được sử dụng trong các trường của NAPTR là UTF-8. Do đó nếu đầu vào/ đầu ra của các biểu thức có chứa các mã nằm ngoài bộ mã UTF-8 thì phải được biểu diễn bằng các tham chiếu theo kiểu một chuỗi byte để có thể thoả mãn được. Điều này là do các biểu thức thường được sử dụng là dạng mở rộng của biểu thức dùng trong hệ POSIX. Điều này cần được đặc biệt quan tâm khi áp dụng ở Việt Nam khi các trường NAPTR được sử dụng có chứa mã tiếng Việt. Tuy nhiên trong khuôn khổ tài liệu này sẽ không bàn đến vấn đề mã đa ngữ trong các bản ghi NAPTR. Tất cả các bản ghi DNS đều được gán một thời gian sống (time-to-live) tính bằng giây. Sau khi bản ghi được lấy về thì nó chỉ có giá trị trong khoảng thời gian bằng time-to-live. Sau thời gian đó bản ghi coi như không còn giá trị, và phải được truy vấn lại. Điều này cũng ảnh hưởng tới việc lưu trữ các luật DDDS, vì ứng dụng phải đảm bảo là chỉ áp dụng các luật chưa bị quá hạn time-to-live. Nếu luật được áp dụng bị quá hạn, ứng dụng phả