3.3.2.1. Đặt vấn đề
Tuy hiện tại mạng VNPT có thể đáp ứng hết các dịch vụ hiện có nhưng không vì thế mà coi nhẹ thiết kế QoS cũng như việc quản lý các vấn đề QoS do chất lượng của mạng sẽ bị biến động do các tác động khác nhau nhất là tải của mạng.
Việc triển khai các cơ chế QoS phức tạp có thể chưa cần gấp ở giai đoạn này nhưng về lâu dài cần hết sức chú ý nhất là mong muốn hướng đến việc cung cấp chất lượng dịch vụ theo thoả thuận chất lượng (SLA).
Việc xác định khả năng của mạng trong việc hỗ trợ QoS nhằm đưa ra giải pháp có tính lâu dài cho vấn đề này.
Từ phần phân tích công nghệ triển khai trên mạng NGN của VNPT hiện tại có thể thấy giải pháp QoS trên mạng dạng này sẽ sử dụng kết hợp giữa MPLS,
Diffserv và kỹ thuật lưu lượng (TE). Hướng tìm kiếm giải pháp về QoS đối với mạng VNPT sẽ trong khoảng từ Diffserv đến H-QoS.
Hình 3.8. Thiết kế QoS với mạng VNPT
Diffserv được sử dụng trên nền MPLS là mặc định, các kỹ thuật bổ trợ như TE sẽ giúp cải thiện QoS.
3.3.2.2. Khuyến nghị
Để giải quyết vấn đề QoS end-to-end , khuyến nghị:
− Toàn mạng nên có chung các Profile QoS
Hình 3.9. Toàn mạng nên sử dụng chung các Profile QoS
− Do tính độc lập của mỗi miền mạng metro/core nên trong nội miền
(MAN-E hoặc core) hãng cung cấp có thể sử dụng các biện pháp kỹ thuật riêng để tạo ra các Profile QoS. Tại biên giới các miền Core/MEN cần thống nhất việc sử dụng các mã DSCP của Diffserv.
Việc ánh xạ DSCP(Diffserv) sang EXP (MPLS) và các cơ chế tránh/quản lý tắc nghẽn Hãng chủ động đề xuất .
Hình 3.10. Các đối tượng và chức năng thực hiện
− Việc ánh xạ từ dịch vụ/ứng dụng cụ thể sang các QoS profile do bản thân các nhà tổ chức dịch vụ (SP) thực hiện (có thể tham khảo khuyến nghị của các Hãng và tổ chức). Các SP này có thể thuộc hoặc không thuộc VNPT.
− Sẽ sử dụng TE một cách linh hoạt (FRR, Load sharing, Band width
guarantee..)
3.3.2.3. Xây dựng các Profile QoS cơ bản và quy ước sử dụng DSCP
Trên mạng có thể tạo ra vô vàn các đối tượng (các kết nối) giữa các điểm, sự phân biệt các đối tượng này không chỉ ở vị trí kết nối, số điểm mà còn bao gồm cả các thuộc tính. Hai khía cạnh đối tượng và thuộc tính kết hợp với nhau theo dạng ma trận 2 chiều.
Đối tượng được tạo ra dưới yêu cầu từ khách hàng còn các thuộc tính có sẵn của mạng do tổ chức mà có (thể hiện bởi các Profile).
Xác định đối tượng là vấn đề đầu tiên cần làm trước khi áp QoS cho chúng. Đối tượng có thể là các flow, các trunk, các path, VPN... Miền biên mạng phải có cơ chế phân biệt được các đối tượng khác nhau (Classification), số đối tượng này phụ thuộc năng lực của mạng
Khuyến nghị trên mạng VNPT nên tổ chức thành một số Profile cơ bản sau:
3.3.2.4. Network control profile
Network control profile được dùng cho lưu lượng báo hiệu giữa các nút mạng sinh ra bởi các giao thức báo hiệu/điều khiển như OSPF, ISIS, RSVP, BGP, LDP... Các giao thức này có nhiệm vụ duy trì cấu trúc logic của mạng và là các giao thức quan trọng nhất trong của mạng, quan trọng hơn cả lưu lượng thời gian thực của khách hàng. Nếu các giao thức này bị ảnh hưởng thì nó có thể ảnh hưởng tới tất cả các lưu lượng của người sử dụng đi qua node mạng. Profile này phải được cấu hình một lượng băng thông tối thiểu để phân phát dữ liệu trong mọi điều kiện và
yêu cầu mất gói rất nhỏ [3.2-RFC 4594]
3.3.2.5. Reatime Voice profile
Reatime Voice profile được áp dụng cho các ứng dụng có yêu cầu rất nhỏ về độ trễ, jitter và mất gói để giữ cho nguồn lưu lượng có tốc độ phát sinh đều (constant bit rate)
Ứng dụng cho các yêu cầu chuyển tiếp các gói gần-thời-gian-thực với nguồn lưu lượng ổn định và tỷ lệ mất gói rất thấp. Các ứng dụng bao gồm broadcast TV, truyền phát trực tiếp video và audio, một số ứng dụng VoD và giám sát video
3.3.2.7. Data 1 Profile (Crictical)
Sử dụng cho các ứng dụng yêu cầu mất gói thấp và tương đối nhạy cảm với độ trễ ví dụ như các giao thức OAM (Operations, Administration, and Management): SNMP (Simple Network Management Protocol), FTP/SCP và SSH.
3.3.2.8. Data 2 Profile
Sử dụng cho các ứng dụng có các nguồn phát sinh lưu lượng có sự biến đổi, hay các luồng TCP long-lived (ví dụ các ứng dụng: lưu trữ và chuyển tiếp, truyền file, Email.. ) và thường có yêu cầu High-Throughput
3.3.2.9. Standard Profile
Standard Profile này được áp cho lưu lượng thông tin “best-effort” chẳng hạn các ứng dụng DNS, DHCP, BootP hay bất kỳ một luồng ứng dụng/ gói chưa được phân biệt nào được truyền qua mạng Diffserv.
3.3.3. Các phép ánh xạ QoS
3.3.3.1. Ánh xạ các QoS profile vào DSCP code
Hình 3-11 là việc ánh xạ các QoS Profile sang DSCP code được sử dụng làm chuẩn chung. Huawei và Cisco sẽ cần thống nhất theo quy ước này
Hình 3.11. Thống nhất việc ánh xạ các QoS Profile sang DSCP
Chi tiết theo như bảng 3-5:
Bảng 3-5. Bảng ánh xạ QoS Profile sang DSCP
QoS Profile DiffServ
Codepoint
Value
Network Control CS-6 48
REALTIME-VOICE EF 46
REALTIME-VIDEO AF41
DATA1 (CRICTICAL) AF31
DATA2 (ASSURED ELASTIC) AF32
STANDARD (ELASTIC) BE
Phần này khuyến nghị trong việc triển khai cho các dịch vụ ứng dụng (VoIP, IPTV, HSI..)
Profile A Profile B Profile C Profile …n
VPN VoIP HIS IPTV
3.3.3.3. Ánh xạ từ Diffserv code sang MPLS EXP code
Sử dụng bảng ánh xạ
Bảng 3-6 Bảng ánh xạ từ Diffserv sang MPLS EXP
DSCP PHB EXP value CS7(111000) 111 CS6(110000) 110 EF(101110) 101 AF4X(100xx0) 100 AF3X(011xx0) 011 AF2X(010xx0) 010 AF1X(001xx0) 001 Best Effort 000
3.3.4. Cấu hình QoS trong MAN-E
Để đảm bảo dịch vụ, khuyến nghị cấu hình QoS trên 2 loại interface:
• Interface kết nối đến các thiết bị khác trong mạng MAN
Hình 3.12. Mô hình kết nối end-to-end
Trên các interface kết nối đến các thiết bị khác trong mạng MAN-E, các cơ chế QoS được cấu hình như hình vẽ 3-13:
Hình 3.13. Cơ chế QoS trong MAN-E
Congestion Advoice (Chống tắc nghẽn)
Phương pháp chống tắc nghẽn WRED và Tail Drop sẽ được sử dụng để chống tắc nghẽn trong mạng MAN-E của VNPT.
WRED cung cấp giải pháp để chống tắc nghẽn. Công nghệ này cho phép theo dõi tải lưu lượng để chống lại tắc nghẽn xảy ra tại điểm nút chai. Chống tắc
nghẽn được thực hiện trước khi tắc nghẽn xảy ra, ngược lại với quản lí tắc nghẽn thực hiện điều khiển tắc nghẽn khi có tắc nghẽn xảy ra
WRED được thiết kế để chống tắc nghẽn trong mạng trước khi nó có vấn đề. Nó kế thừa khả năng theo dõi lưu lượng của giao thức TCP. WRED theo dõi tải lưu lượng tại một điểm trong mạng và discard gói tin nếu tắc nghẽn bắt đầu xuất hiện. Kết quả là bên gửi nhận thấy lưu lượng bị drop và bắt đầu giảm tốc độ truyền. WRED tương tác với các phương pháp QoS khác để xác định loại dịch vụ trong luồng lưu lượng. Nó thực hiện drop gói tin từ thứ tự ưu tiên thấp tới ưu tiên cao, đảm bảo rằng các gói tin ưu tiên cao tránh ảnh hưởng do tắc nghẽn
Lúc một gói tin tới, WRED áp dụng các quá trình sau:
• Dung lượng hàng đợi trung bình của gói tin được tính toán
• Nếu dung lượng hàng đợi trung bình của gói tin bé hơn dung lượng giới hạn (queue threshold), gói tin được đưa vào hàng đợi
• Nếu dung lượng hàng đợi trung bình của gói tin nằm giữa dung lượng giới hạn bé nhất cho loại lưu lượng và dung lượng giới hạn tối đa của giao diện, gói tin bị drop hoặc đưa vào hàng đợi tùy thuộc vào “drop probability”
(thông số phản ảnh khả năng bị drop) của lớp lưu lượng đó
• Nếu dung lượng hàng đợi trung bình lớn hơn dung lượng giới hạn tối đa, gói tin bị drop
Hình 3.14. Mô hình WRED
Hủy bỏ gói cuối hàng đợi -Tail drop xuất hiện khi một datagram vào hàng đợi, nhưng lúc này hàng đợi đầy. Các routerr sẽ hủy bỏ các datagram sau đó tức các router sẽ hủy bỏ phần đuôi của chuỗi dữ liệu.
Congestion Management (Quản lí tắc nghẽn)
Thông thường, khi một giao diện mạng bị tắc nghẽn thì các kỹ thuật hàng đợi là cần thiết để đảm bảo răng lưu lượng các ứng dụng quan trọng có thể được chuyển tiếp phù hợp. Ví dụ, các ứng dụng thời gian thực như VoIP đòi hỏi được chuyển tiếp với thông số loss và delay bé nhất. Các kỹ thuật hàng đợi bao gồm CBWFQ, priority, policed
3.4. Kết luận
Việc triển khai các giải pháp nâng cao chất lượng dịch vụ là việc rất cần thiết, tuy nhiên phải cân đối giữa chi phí triển khai và nhu cầu của khách hàng. Luận văn đã đưa ra bước đầu triển khai để nâng cao chất lượng dịch vụ. Chất lượng dịch vụ là một vấn đề rất phức tạp, chi phí lớn do đó cần có nhiều thời gian nghiên cứu để đưa ra từng bước triển khai cho phù hợp với thực tế.
TÀI LIỆU THAM KHẢO Tiếng Việt
1. Đề tài “Quản lý chất lượng dịch vụ 2009” CDiT.
2. Bộ Thông tin Truyền thông (2007, 2008): Tạp chí Công nghệ Thông tin Truyền thông.
3. Hoàng văn Bình, Vũ Long Oanh (2006): Lựa chọn công nghệ phù hợp cho mạng truy nhập cố định NGN.
4. Ts. Phạm Đức Thuỷ: Xây dựng mạng MAN, một số vấn đề cần quan tâm. Báo cáo tại hội nghị khoa học lần thứ 6. Học viện CN BC-VT.
5. Đề tài “Nghiên cứu ứng dụng công nghệ MAN triển khai trên nền mạng viễn thông Bưu điện Nghệ An” – Luận văn thạc sỹ Hồ Trung Chính Cao học 7 – Học viện Công nghệ BC-VT.
6. Tài liệu thiết kế LLD của Cisco 7. Tài liệu thiết kế LLD của Huawei
Tiếng Anh [1]. www.ietf.org. [2]. http://Metroethernetforum.org/index.php. [3]. http://ieee.org/index.html. [4]. http://www.cisco.com/en/US/docs/internetworking/technology/handbook/QoS.html. [5]. http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/CAR.html. [6]. http://www.cisco.com/en/US/docs/ios/11_1/feature/guide/CAR.html.
[7]. Nguyen Hong Son, Le Huu Lap, “A method for performing connection admission control
in Diffserv network”, IEEE International Conference ICACT’ 2009, Korea, 15-18th Feb.2009,
pp.227-232.
[8]. G.Huston (2000) “next Steps for IP QoS Architecture”, IETF RFC 2990. [9]. E.Brent Kelly, “Quality of Service in IP Network”, Wainhouse Research.
[10]. John William Evans, Clarence Filsfils. Deploying IP and MPLS QoS for Multiservice Networks : Theory & Practice
[11]. Metro Ethernet Forum.
[12]. Tim Szigeti, Christina Hattingh. End-to-End QoS Network Design Quality of Service in LANs, WANs, VPNs
[13]. Chris Hellberg, Dylan Greene, Truman Boye ”Broadband network architecture”, Designing and Deploying Triple Play Servic; Boston,USA may 2007.
2009.
[15]. Advanced Servuecs’ Deploying and Maintaining Carrier Ethernet Services of Cisco System, Inc.