Giải pháp CUNG Cấp chất lượng dịch vụ trên INTERNET

Giải pháp CUNG Cấp chất lượng dịch vụ trên INTERNET

G iải p háp C UNG C ấp c hất l ượng d ịch

Bộ môn Kỹ Thuật Thông Tin

Khoa Điện Tử Viễn Thông

Đại Học Bách Khoa Hà Nội

Đồ án tốt nghiệp cao học

Tháng 9, năm 2001

Tóm tắt

Cung cấp chất lượng dịch vụ trên Internet

tác giả

Nguyễn Tài Hưng

Đồ án này trình bày các cơ chế nhằm đảm bảo chất lượng dịch vụ (QoS) cho các

dịch vụ trên mạng Internet Các cơ chế đó bao gồm: định hướng lưu lượng và

cân bằng tải ở lớp ứng dụng, phân loại dịch vụ (Diffserv) ở lớp vận chuyển, kỹ thuật lưu lượng và định tuyến lại ở lớp mạng Định hướng lưu lượng là nhằm tận

dụng các phần mạng hiệu suất cao và tránh sử dụng các phần mạng hiệu suất thấp Cân bằng tải là phép phân phối các yêu cầu từ máy trạm đến nhiều máy chủ khác nhau nhằm tăng tính sẵn sàng của dịch vụ và giảm thời gian đáp ứng

Đồ án mô tả tóm tắt một số phương pháp tiếp cận nhằm định hướng lưu lượng

và cân bằng tải Diffserv là mô hình cho phép phân chia lưu lượng trong mạng thành các loại khác nhau và có các xử lý khác nhau đối với chúng, đặc biệt trong trường hợp tài nguyên của mạng hạn chế Đồ án cũng trình bày các cơ chế thực hiện mô hình Diffserv này ở 2 phần, phần ngoài (edge) và phần chính (core) của mạng Mục đích của các cơ chế này là để đạt được các phép xử lý khác nhau đối với từng chặng (PHBs) trên dọc tuyến đường đi của lưu lượng Bằng cách kết hợp tất cả các PHBs đó với nhau, có thể cung cấp được một mức chất lượng dịch vụ (QoS) nào đó trên phạm vi từ thiết bị đầu cuối đến thiết bị đầu cuối Ngoài ra đồ án cũng mô tả các xung đột xảy ra giữa mô hình Diffserv và giao thức TCP và đưa ra các giải pháp giải quyết các xung đột đó

Kỹ thuật lưu lượng là thuật ngữ mô tả quá trình lặp đi lặp lại công việc lập kế hoạch và tối ưu hoá mạng Lập kế hoạch mạng là nhằm cải tiến kiến trúc (cấu hình và dung lượng kết nối) của mạng về mặt hệ thống để dễ dàng vận hành mạng và làm cho mạng trở nên đơn giản và có thể hiệu chỉnh Tối ưu hoá mạng

là nhằm điều khiển việc ánh xạ và phân phối lưu lượng trên cơ sở hạ tầng mạng hiện có để tránh hoặc giảm bớt hiện tượng tắc nghẽn và do đó tối ưu hoá hiệu suất sử dụng tài nguyên mạng Đồ án này mô tả tóm tắt các hệ thống kỹ thuật lưu lượng đang được nghiên cứu và áp dụng hiện nay sau đó trình bày chi tiết

hệ thống kỹ thuật lưu lượng sử dụng giao thức chuyển mạch nhãn đa giao thức

(MPLS) và đánh giá hiệu suất của nó Dựa trên các kết quả nghiên cứu và thực

hiện hệ thống này, đồ án sau đó đưa ra một thủ tục chung cho các hệ thống kỹ thuật lưu lượng ở mức mạng lớn (phạm vi quốc gia, quốc tế) Sau đó đồ án mô

tả việc thực hiện kỹ thuật lưu lượng giữa các miền (domain) với nhau dưới dạng định lượng Trong đồ án tôi cũng đưa ra một thuật toán định tuyến cưỡng bức (constraint-based routing) để tính toán các đường LSPs cho hệ thống MPLS, và

mô tả phương pháp thực hiện mô hình Diffserv trong môi trường MPLS Cuối cùng đồ án trình bày 2 công nghệ nổi bật liên quan đến kỹ thuật lưu lượng là,

giao thức định tuyến lambda đa giao thức (MPLmS) và giao thức định tuyến lại nhanh (fast reroute)

Định tuyến cưỡng bức là một trong các công cụ quan trong nhất đối với kỹ thuật lưu lượng Do đó đồ án trình bày một cách chi tiết các vấn đề liên quan đến định tuyến cưỡng bức bao gồm các phép toán lặp để tính toán các tuyến đường đi với một độ trễ cho trước và để thực hiện định tuyến chất lượng dịch vụ trên các mạng ảo được xây dựng trong quá trình kỹ thuật lưu lượng Để giảm độ phức tạp tính toán trong phép định tuyến cưỡng bức, đồ án đưa ra một thuật toán nhằm giảm "chi phí" tính toán bảng định tuyến cho thuật toán OSPF

Tóm lại, đồ án này không chỉ thảo luận tất cả các vấn đề liên quan đến chất lượng dịch vụ mà còn trình bày một cách tiếp cận có hệ thống nhằm cung cấp chất lượng dịch vụ cho các dịch vụ trên Internet

Tháng 9, 2001

Tác giả Nguyễn Tài Hưng

Lời Tựa

Trong qúa trình thực hiện luận văn này tôi đã nhận được sự hướng dẫn, giúp đỡ

và hổ trợ từ rất nhiều người Đầu tiên, tôi xin trân trọng nói lời cảm ơn tới người hướng dẫn đồ án của tôi, PGS TS Phạm Minh Hà, người luôn luôn chú ý, hướng dẫn và đưa ra những lời khuyên bất cứ khi nào tôi cần Cô Hà là người

đã giúp đỡ và dẫn dắt tôi khi tôi mới bắt đầu tham gia vào lĩnh vực nghiên cứu các kỹ thuật và công nghệ truyền thông với dự án "Nghiên cứu thiết kế phần mềm lập kế hoạch và tối ưu hoá mạng đường trục ATM" Không có sự hướng dẫn và dìu dắt của cô tôi không thể nào hoàn thành được dự án nghiên cứu nêu trên và càng không thể trưởng thành trong công tác nghiên cứu khoa học như ngày hôm nay Khi tôi đã có được những kỹ năng cơ bản trong việc nghiên cứu, Tiến sĩ Hà đã để tôi tự do làm việc trong môi trường thực tế tại các công ty sản xuất thiết bị viễn thông và các nhà khai thác mạng trong quá trình hoàn thành luận văn cao học này Trong môi trường thực tế của nghành công nghiệp thông tin và viễn thông, tôi đã cố gắng nghiên cứu và triển khai các cơ chế cung cấp chất lượng dịch vụ, và thử nghiệm một hệ thống MPLS cở nhỏ trong phòng thí nghiệm Với những kinh nghiệm thực tế này, luận văn cao học của tôi sẽ mang tính chuyên sâu và thuyết phục hơn

Tôi cũng bày tỏ lòng cảm ơn sâu sắc tới các nghiên cứu sinh: Nguyễn Hữu Thanh (nghiên cứu sinh tiến sĩ ở Đức), Nguyễn Chấn Hùng (nghiên cứu sinh tiến

sĩ ở Tây Ban Nha), các khoa viện và các giảng viên, cán bộ của trường

ĐHBK-HN đã có những lời khuyên, giúp đỡ hết sức quý báu cũng như cung cấp cho tôi rất nhiều các tài liệu tham khảo quan trọng giúp tôi phát triển kiến thức và kỹ năng nghiên cứu của mình

Ngoài ra tôi cũng xin chân thành cảm ơn anh Vũ Thanh Hải (văn phòng đại diện Siemens tại Việt nam), kỹ sư Nguyễn Xuân Phương (công ty Điện Toán và Truyền Số Liệu), ông SHMUEL WIDER (công ty ECI Telecom/Israel) và anh Anuchit Vasinonta (Tom) (văn phòng châu á thái bình dương của Redback Networks tại Thái lan) Họ đã cố vấn, tin tưởng cho phép tôi thực hiện các thử nghiệm một hệ thống MPLS nhỏ trên các thiết bị của ECI Telecom và Redback Networks Họ cũng đã hướng dẫn và giúp sữa bản thảo luận văn trong suốt quá trình hoàn thành luận văn

Cuối cùng nhưng không kém phần quan trọng, tôi muốn nói lời cảm ơn chân thành tới tất cả bạn bè, đồng nghiệp của tôi, đặc biệt anh Phạm Văn Tiến (người bạn tốt và cũng là đồng nghiệp của tôi tại bộ môn kỹ thuật thông tin, khoa điện tử viễn thông, trường ĐHBK-HN) đã giúp đỡ và hổ trợ tôi rất nhiều với tinh thần bạn

bè trong sáng và vô tư

Xin chân thành cảm ơn tất cả!

C hương 1 G iới t hiệu : N hững x u h ướng p hát t riển v à

v ấn đ ề t ồn t ại c ủa m ạng I nternet.

Không có gì làm thay đổi thế giới này nhanh như Internet [1] Ngày nay Internet

đã trở thành một trong các công cụ vẩn chuyển thông tin quan trọng nhất Con người bắt đầu sử dụng Internet để học tập, nghiên cứu, mua bán hàng hoá và thực hiện các giao dịch ngân hàng và thị trường chứng khoán Vì Internet ngày càng trở nên quan trọng nên các yêu cầu đối với nó cũng ngày càng đòi hỏi cao hơn Bị thúc ép bởi các yêu cầu về băng thông, chất lượng dịch vụ (QoS) và tính bảo mật, mạng Internet ngày càng được nghiên cứu phát triển để trở nên tinh vi hơn, thông minh hơn và an toàn hơn [2][3] Chương này sẽ trình bày tóm tắt một

số xu hướng phát triển và các vấn đề liên quan của mạng Internet

CRs (Core Router) kết nối tới các POP khác Lưu lượng từ các ARs, BRs và HRs trước hết phải được gửi tới CR CR sau đó sẽ chuyển tiếp lưu lượng tới các

CR khác, cho đến khi tới POP cuối cùng (điểm đích)

Kiến trúc của các POP thường là đối xứng (như trong hình 1-1) Các POP khác nhau thường được kết nôi theo cấu hình vòng để tăng độ tin cậy Một mạng ISP lớn có thể có trên 50 POPs (mạng của VDC hiện có khoảng 28-30 POPs tại Hà nội, TP HCM và các tỉnh)

Có 2 yếu tốc dẫn đến việc phát triển các kết nối tốc độ cao trong mạng Internet đường trục Thứ nhất là sự gia tăng đến chóng mặt lưu lượng trên mạng Internet, mà theo các số liệu thông kế thì tỉ lệ tăng là gấp đôi mỗi sáu tháng Với

xu thế áp dụng các công nghệ đường thuê bao băng rộng như xDSL, cáp đồng trục kết nối thuê bao với nhà cung cấp dịch vụ và ngày càng xuất hiện nhiều các ứng dụng đa phương tiện (multi-media) trên Web, thì lưu lượng trên Internet được dự báo là sẽ còn gia tăng mạnh trong tương lai Do đó, các ISP phải cung cấp đủ băng thông để đáp ứng các yêu cầu gia tăng về lưu lượng đó Yếu tố thứ

2 dẫn đến việc phát triển các liên kết cao tốc liên quan đến chi phí và tính hiệu quả Ví dụ, chi phí cho một kết nối OC-12c (622Mbps) sẽ không lớn gấp 4 lần chi phí cho một kết nối OC-3c (155Mbps) Nói cách chi phí trên một đơn vị băng thông của các kết nối tốc độ cao thấp hơn của các kết nối tốc độ thấp Ngoài ra, xét về mặt vận hành và bảo dưỡng mạng thì việc quản lý một đường OC-12c sẽ đơn giản hơn quản lý 4 đường OC-3c

Các vấn đề liên quan đến các kết nối tốc độ cao bao gồm:

 Trễ truyền lan trở nên một vấn đề trọng yếu: Trễ truyền lan là thời gian

cần thiết để tín hiệu di chuyển từ nguồn tới đích, thường là với tốc độ ánh sáng Tuỳ thuộc vào phương tiện truyền dẫn, tuy nhiên nói chung ánh sáng cần khoảng 8ms để truyền trên một khoảng cách 1000 dặm (1852km) Điều này có nghĩa là trễ truyền lan một chiều giữa Hà nội và TP HCM (2000 km) khoảng 11ms Với các bộ chuyển mạch / bộ định tuyến

và các kết nối tốc độ cao, trễ hàng đợi trong các bộ chuyển mạch / bộ định tuyến trong trường hợp bình thường thường dưới 1ms Giả sử lưu lượng phải được chuyển qua 10 bộ định tuyến / bộ chuyển mạch, thì trễ truyền lan xấp xĩ 2/3 lượng trễ tổng cộng Điều này có ảnh hưởng trực tiếp đến phương pháp cung cấp chất lượng dịch vụ trên Internet Điều này có nghĩa là khi đó các cơ chế phức tạp để giảm trễ hàng đợi không còn quan trọng lắm, trừ khi mạng có tắc nghẽn xảy ra làm cho trễ hàng đợi trở nên rất lớn Mà khi đó việc điều khiển phân chia lưu lượng để tránh tắc nghẽn xảy ra trở nên hiệu quả hơn Vì trễ truyền lan đối với một kết nối là không đổi nên các kết nối có tốc độ cao hơn thì có lượng dữ liệu đang trên đường truyền (data on-the-fly) lớn hơn Ví dụ, lượng dữ liệu đang trên

đường truyền của một kết nối OC-3c từ Hà nội vào TP HCM là 155Mbps x 11ms = 0,213 MB Còn với kết nối OC-192c thì lượng dữ liệu trên đường truyền là 13,75MB Điều này tự bản thân nó thì không có vấn đề gì, nhưng nếu trường hợp có sự cố xảy ra đối với kết nối thì lượng dữ liệu cần phải nhớ đệm sẽ nhiều hơn, nếu không sẽ mất dữ liệu Điều này cần được xem xét khi thiết kế các hệ thống nhớ đệm trong các bộ chuyển mạch và định tuyến tốc độ cao.

 Tính sẵn sàng của mạng trở nên rất quan trọng: Độ sẵn sàng là khả năng

của mạng để tiếp tục hoạt động với một mức chất lượng nhất định khi đường truyền hoặc các bộ định tuyến có sự cố xảy ra Với trường hợp tốc

độ cao điều này càng quan trọng Phương pháp truyền thống đảm bảo tính sẵn sàng cao là cung cấp các bộ định tuyến và kết nối dự phòng, ví

dụ phương thức APS (automatic protection switching) trong thông tin

quang (SONET/SDH) và trong các mạng ATM [4] Trong đó nếu một bộ định tuyến hoặc kết nối xảy ra sự cố thì lưu lượng sẽ được chuyển sang

bộ định tuyến hoặc kết nối dự phòng trong vòng 50ms ở đây APS là phương thức cung cấp độ sẵn sàng cao cho mạng ở lớp vật lý (lớp 1) Độ sẵn sàng cũng có thể được cung cấp ở lớp mạng Vì các bộ định tuyến được kết nối theo cấu hình vòng nên sẽ có nhiều đường đi giữa mỗi cặp nguồn và đích Do đó, nếu có bất kỳ sự cố nào xảy ra đối với bộ định tuyến / kết nối trên tuyến đường đang hoạt động thì lưu lượng có thể được chuyển sang các đường đi khác Tuy nhiên phương pháp tiếp cận cung cấp độ sẵn sàng cao cho mạng theo kiểu này có một vấn đề là khi có

sự cố xảy ra các giao thức định tuyến IGPs (Interior Gateway Protocols)

như OSPF hay IS-IS để truyền thông tin về sự cố cho các bộ định tuyến khác để tính toán lại các tuyến đường của chúng Tuỳ thuộc vào kích thước của mạng mà việc định tuyến lại này sẽ cần từ vài giây đến vài phút Trong khoảng thời gian này, lưu lượng gửi qua tuyến đường bị ảnh hưởng này có thể bị mất do các bộ định tuyến trung gian không thể nhớ đệm một số lượng lớn số liệu như vậy Để giải quyết vấn đề này, cần phải

có một cơ chế định tuyến lại mới để giảm bớt thời gian tính toán lại các bảng định tuyến khi có sự cố xảy ra, một trong các cơ chế được đưa ra đó

là cơ chế định tuyến lại nhanh (Fast Reroute) Cơ chế này sẽ thực hiện

việc khắc phục tạm thời tuyến đường bị ảnh hưởng bởi sự cố để nó có thể tiếp tục vận chuyển dữ liệu, và đồng thời thông báo cho các nguồn bị ảnh hưởng để tính toán lại các tuyến đường mới để chuyển tiếp lưu lượng của chúng Cơ chế định tuyến lại nhanh sẽ được thảo luận chi tiết ở chương 4.

1.2.2 Chất lượng dịch vụ - QoS

Từ trước tới nay, mạng Internet chỉ có thể cung cấp các dịch vụ dạng

“best-effort” Trong đó, lưu lượng được xử lý (chuyển tiếp) với tốc độ nhanh có thể

nhưng không có bất kỳ sự đảm bảo nào về thưòi gian xử lý cũng như độ tin cậy của việc vận chuyển lưu lượng đến đích Tuy nhiên, ngày nay với sự phát triển ồ

ạt các dịch vụ thương mại điện tử (e-commerce), vấn đề đảm bảo chất lượng

dịch vụ cho các ứng dụng trên mạng Internet trở nên cần thiết hơn bao giờ hết Nhìn chung có 2 nhân tố cơ bản dẫn đến yêu cầu về chất lượng dịch vụ Thứ nhất, với các công ty thực hiện việc kinh doanh trên Web, họ cần chất lượng dịch

vụ để cải thiện và nâng cao chất lượng vận chuyển các thông tin và dịch vụ của

họ đến khánh hàng như một yếu tố để thu hút ngày càng nhiều khách hàng Thứ

2 các nhà cung cấp dịch vụ Internet - ISPs cần thêm nhiều các dịch vụ giá trị gia tăng trên mạng của họ để tăng lợi nhuận Hiện nay có hai mô hình cho phép

cung cấp chất lượng dịch vụ cho các ứng dụng trên mạng Internet là Mô hình

tích hợp dịch vụ – Intserv (Integrated services) và Mô hình phân chia dịch vụ –

Diffserv (Differentiated services) Thực chất của mô hình Intserv là nó thực hiện

việc dành trước các tài nguyên (băng thông đường truyền và không gian bộ đệm) cho mỗi phiên làm việc để có thể đảm bảo chất lượng cho các dịch vụ khi cần thiết Còn đối với Diffserv thì nó thực hiện việc phân chia lưu lượng thành các loại khác nhau cung cấp cho chúng các xử lý khác nhau [2]

Để cung cấp chất lượng dịch vụ cho các ứng dụng trên Internet, cần phải sử dụng một số cơ chế có thể ở lớp vận chuyển (lớp 4) hoặc lớp mạng (lớp 3) Phương pháp và cách thức cung cấp chất lượng dịch vụ trên Internet là chủ đề của luận văn này Gần đây có một số viện nghiên cứu, trường đại học và các công ty công nghệ đưa ra một số cơ chế cung cấp QoS ở lớp ứng dụng, do đó luận văn dành một phần nhỏ để trình bày vắn tắt các cơ chế đó Bên cạnh các

cơ chế (thuật toán) cung cấp QoS thì việc điều khiển (monitoring), quản lý và tính

cước (accounting & billing) cũng là các vấn đề quan trọng liên quan đến QoS Cả

khắch hàng lẫn nhà cung cấp chất lượng đều cần phải biết được liệu chất lượng dịch vụ đã thoả thuận giữa họ có được đảm bảo hay không, và đồng thời các nhà cung cấp dịch vụ Internet (ISPs) cũng cần có phương pháp để tính toán hoá đơn mới cho khách hàng Để thực hiện thêm các chức năng này, các thiết bị biên (edge devices) sau này cần phải có các tính năng phần mềm phong phú và tiên tiến và khả năng đo lường lưu lượng để cho phép các ứng dụng tính cước tạo các báo cáo dựa trên các số liệu thu thập được bởi các thiết bị biên đó [23].

1.2.3 Kỹ thuật lưu lượng với các mạng IP

Ban đầu và suốt một thời gian dài mạng Internet đường trục chỉ bao gồm các bộ định tuyến chạy giao thức IP Tuy nhiên, vài năm gần đây, một số nhà cung cấp dịch vụ (ISPs) trên thế giới đã đưa các bộ chuyển mạch ATM vào phần mạng đường trục của họ Theo cách đó các bộ định tuyến IP được sử dụng ở biên của mạng và được kết nối tới các chuyển mạch ATM (được nối từng đôi một) ở phần

trung tâm của mạng Thông qua các ATM PVCs (Permanent virtual circuits), các

bộ định tuyến có thể được coi là được kết nối một cách đầy đủ từng đôi một [6][7] Sau đây là những lý do mà người ta đã sử dụng các bộ chuyển mạch ATM trong phần chính của mạng:

các bộ định tuyến IP

 Hai là các mạng ATM tự nó đã có khả năng cung cấp chất lượng dịch vụ

và kỹ thuật lưu lượng

Tuy nhiên ATM cũng tồn tại một số các nhược điểm như:

 Chức năng SAR (Segmentation and reassembly) rất khó thực hiện ở tốc

cao; Do đơn vị truyền dẫn trong mạng ATM là các tế bào có kích thước 53 bytes, nên các gói IP phải được chia nhỏ thành các tế bảo ở đầu vào của mạng ATM Và tất nhiên ở đầu ra của mạng ATM, các tế bảo lại phải được ghép lại thành các gói IP ban đầu Vì các tế bào được ghép một cách luân phiên nên SAR phải thực hiện nhớ đệm (queuing) và lập lịch (scheduling) cho một số lượng lớn các VCs Do đó rất khó thực hiện SAR

ở tốc độ OC-48 hoặc cao hơn

 Thứ 2 là công nghệ ATM có phần thông tin tiêu đề (vô ích) khá cao; Trong tổng số 53 bytes của một tế bào ATM có 5 bytes được sử dụng cho phần

tiêu đề Điều này làm cho phần trăm thông tin tiêu đề của mạng ATM tương đối cao

Vì hai nhược điểm trên và cũng vì các bộ định tuyến IP ngày nay đã có thể đạt được tốc độ của các bộ chuyển mạch ATM và thậm chí còn cao hơn, nên các ISPs có xu hướng chuyển các mạng của họ từ ATM trở lại thành IP Tuy nhiên, bất kể là trong mạng ATM hay mạng IP, các kỹ thuật lưu lượng vẫn rất hữu ích Trong các mạng IP thông thường, lưu lượng luôn luôn được chuyển đi trên các tuyến đường ngắn nhất Điều này có thể gây ra tắc nghẽn trên một số kết nối trong khi một số kết nối khác lại có lượng tải qúa thấp Kỹ thuật lưu lượng là việc thực hiện một cách lặp đi lặp lại quá trình lập kế hoạch và tối ưu hoá mạng Mục đích của kỹ thuật lưu lượng là nhằm tối ưu hoá hiệu quả sử dụng tài nguyên và hiệu suất mạng [8][9][10]

Để có thể thực hiện kỹ thuật lưu lượng một cách hiệu quả trong các mạng IP, người quản trị mạng phải có thể điều khiển được đường đi của các gói Điều này làm nảy sinh một cái gì đó tương tự một kết nối trong các mạng IP hoạt động theo phương thức không kết nối (phát quảng bá).Giao thức chuyển mạch nhãn

đa giao thức, MPLS (Multi-protocol lable switching)[11] có thể cung cấp các kết nối như vậy bằng các LSPs (label switched paths) của nó Đó là một trong những

lý do làm cho MPLS trở nên rất hữu ích cho các mạng IP

1.2.4 Bảo mật

Do ngày càng nhiều các công ty tiến hành công việc kinh doanh của họ trên mạng Internet, cũng như ngày càng nhiều các dữ liệu quan trọng được truyền qua mạng Internet, vấn đề bảo mật thông tin đã trở nên hết sức quan trọng Bảo mật thông tin trên Internet là thực hiện việc mã hoá/giải mã dữ liệu cần truyền, lọc gói, nhận thực người dùng và quản lý các nguồn tài nguyên [12]

1.2.5 Chuyển mạch quang

Ngày nay, lưu lượng đang được truyền dưới dạng sóng ánh sáng bên trong các kết nối vật lý Tuy nhiên tại các nút trung gian tín hiệu ánh sáng phải được chuyển đổi thành tín hiệu số, sau đó mới được định tuyến và chuyển mạch Đối

với những lưu lượng còn phải đi tiếp (transit trafffic) thì tín hiệu số lại được

chuyển đổi thành tín hiệu quang trước khi truyền đi Phương thức này có 2 nhược điểm Thứ nhất, nếu chức năng định tuyến và chuyển mạch của nút

không hoạt động, thì dữ liệu chuyển tiếp sẽ bị ảnh hưởng Thứ 2, thiết bị chuyển đổi từ quang sang điện rồi lại từ điện sang quang (O-E-O) rất phức tạp và nó cuối cùng lại trở thành điểm gây ra tắc nghẽn trong mạng Do đó, cần thiết phải thực hiện việc chuyển mạch các kênh thông tin trưch tiếp dưới dạng quang, bỏ qua quá trình chuyển đổi O - E - O Phương thức đó gọi là kỹ thuật chuyển mạch quang Thiết bị thực hiện việc chuyển mạch quang gọi là các bộ đấu chéo quang (OXCs) Trong đó, chỉ những lưu lượng dành cho bộ định tuyến / hay bộ chuyển mạch này mới được chuyển thành tín hiệu số và được xử lý Xu hướng trong những năm tới là tích hợp chặt chẽ các OXCs vào các bộ định tuyến Và chúng sẽ trở thành phần trung tâm của mạng Internet [13][14][15].

Chương 4 sẽ trình bày chi tiết hơn về vấn đề chuyển mạch quang

1.3Tổ chức của luận văn

Luận văn này thảo luận các giải pháp và cơ chế cung cấp chất lượng dịch vụ cho các ứng dụng trên Internet Trong đó tập trung vào các phương pháp tiếp cận và

cơ chế tương ứng cần để thực hiện các cách tiếp cận đó trong các mạng đường trục Internet, tức các mạng ISP Các phương pháp tiếp cận được nhóm lại thành một số nhóm dựa trên lớp (trong mô hình phân lớp OSI) mà chúng được thực hiện Và các phương pháp tiếp cận trong luận văn này chỉ tập trung chủ yếu ở 2 lớp là lớp mạng và lớp vận chuyển Tuy nhiên để mang tính tổng thể luận văn cũng đề cập đến một số phương pháp tiếp cận nhằm cung cấp QoS ở lớp ứng dụng Chương 2 của luận văn trình bày một đoạn giới thiệu ngắn về QoS và đưa

ra danh sách những việc cần thực hiện để cung cấp QoS trong mạng Internet

Chương 3 trình bày hai mô hình cung cấp QoS phổ biến là mô hình tích hợp dịch

vụ Intserv và mô hình phân chia dịch vụ Diffserv, và tập trung vào các cơ chế cần

thiết trong mô hình Diffserv Chương 4 nghiên cứu phương pháp tiếp cận quan trọng nhất để cung cấp QoS là kỹ thuật lưu lượng và trình bày một số các kỹ

thuật lưu lượng là kỹ thuật định tuyến có điều kiện (constraint-based routing),

MPLS, IS-IS cải tiến, và giao thức báo hiệu RSVP Một ví dụ về việc thiết kế và

thực hiện kỹ thuật lưu lượng cho hệ thống mạng của VDC cũng được trình bày trong chương này Mặc dù luận văn này chủ yếu tập trung vào kỹ thuật lưu lượng cho các mạng quản lý độc lập (intra-domain), nó cũng trình một số khía cạnh hệ thống của kỹ thuật lưu lượng giữa các mạng với nhau (inter-domain) Hai công

nghệ mới liên quan chặt chẽ đến kỹ thuật lưu lượng là kỹ thuật chuyển mạch

lambda đa giao thức (multi-protocol lambda switching) và kỹ thuật định tuyến lại nhanh (fast reroute) cũng được thảo luận trong chương này Chương 5 dành để

mô tả kỹ thuật định tuyến có điều kiện vì đây là công cụ rất quan trọng để thực hiện các kỹ thuật lưu lượng Vì định tuyến có điều kiện thường có độ phức tạp tính toán rất cao nên trong chương này cũng dành một phần để thảo luận việc giảm chi phí tính toán bằng định tuyến cho giao thức tìm đường ngắn nhất OSPF Chương 6 trình bày các cách tiếp cận nhằm cung cấp chất lượng dịch vụ

ở lớp ứng dụng Cuối cùng chương 7 là phần kết luận của luận văn

1.4Tóm tắt một số kết quả đạt được của luận văn

Kết quả lớn nhất của luận văn này là đã cung cấp được một giải pháp tổng hợp cung cấo chất lượng dịch vụ trên Internet Giải pháp bao gồm các mô hình và cơ chế như: Diffserv, kỹ thuật lưu lượng, định hướng lưu lượng và cân bằng tải Đối với mô hình Diffserv, luận văn đã mô tả một cách chi tiết và đầy đủ các cơ chế thực hiện ở phân biên (edge) và phần chính (core) của mạng Các cơ chế

đó cũng được sử dụng để đạt được các PHB (per-hop behavior) mong muốn Do

đó có thể cung cấp được một mức chất lượng dịch vụ nhất định từ đầu cuối đến đầu cuối bằng cách kết hợp tất cả các PHB đó lại với nhau Luận văn cũng đã đề cập và đưa ra giải pháp cho các xung đột xảy ra giữa Diffserv và TCP Điều này giải quyết được vấn đề chủ yếu của Internet Giải pháp ở đây dựa trên giải pháp

đã được đưa ra của IETF [59]

Đối với kỹ thuật lưu lượng thì luận văn trước hết thảo luận các vấn đề thiết kế Sau đó trình bày việc thực hiện hệ thống MPLS cho mạng của VDC trên phạm vi toàn quốc và đánh giá hiệu suất của nó Luận văn cũng đã mô tả một cách định lượng phương pháp tiếp cận thực hiện kỹ thuật lưu lượng liên mạng (inter-domain) Đồng thời luận văn cũng đưa ra một thực hiện thuật toán định tuyến có điều kiện để tính toán các LSP, và mô tả phương pháp thực hiện mô hình Diffserv trong một trường MPLS Sau đó là thuật toán định tuyến lại nhanh và kỹ thuật chuyển mạch lambda đa giao thức

Như đã nói ở trên định tuyến có điều kiện (constraint-based routing) là một trong các công cụ quan trọng nhất để thực hiện một hệ thống kỹ thuật lưu lượng Do

đó luận văn đã trình bày rất chi tiết các vấn đề có liên quan đến định tuyến có điều kiện Sau đó đưa ra các phương pháp lặp (heuristics) để tính toán các tuyến đường với điều kiện ràng buộc là giá trị trễ truyền cho trước, và thuật toán lặp cho định tuyến QoS trên các mạng ảo được xây dựng trong quá trình thực hiện

hệ thống kỹ thuật lưu lượng Luận văn cũng đưa ra một thuật toán giảm chi phí tính toán bảng định tuyến của thuật toán định tuyến OSPF nhằm làm giảm độ phức tạp tính toán Hai kỹ thuật rất hữu ích trong việc cải thiện hiệu suất của lưu lượng Web là định hướng lưu lượng và cân bằng tải cũng đã được mô tả vắn tắt

Tóm lại luận văn đã không chỉ trình bày một phân tính tổng hợp về tất cả những vấn đề chính liên quan đến QoS mà còn đưa ra giải pháp cung cấp chất lượng dịch vụ cho các ứng dụng trên Internet Ngoài ra còn đưa ra thiết kế và thực hiện

hệ thống kỹ thuật lưu lượng cho mạng Internet quốc gia của VDC

C hương 2 N hững N hiệm V ụ C hính N hằm C ung

C ấp C hất L ượng D ịch V ụ T rên I nternet

Chất lượng dịch vụ của một mạng thông tin nói chung và mạng Internet nói riêng được phản ánh bởi mức độ hài lòng của các thuê bao của nó Mặc dù còn phụ thuộc vào kiểu dịch vụ và mức độ chấp nhận của người dùng, mức chất lượng dịch vụ QoS thường được đo lường bởi độ trễ của gói, biến thiên trễ (jitter), xác suất mất gói và độ khả thông (throughput) của ứng dụng [6]

Phần đầu chương này chúng tôi dành mô tả hai mô hình cung cấp QoS trên

Internet Đó là mô hình tích hợp dịch vụ (Intserv) với giao thức báo hiệu RSVP

(resource reservation protocol) và mô hình phân chia dịch vụ (Diffserv) Chúng là

các phương pháp tiếp cận truyền thống để cung cấp chất lượng dịch vụ cho các ứng dụng trên Internet Phần tiếp theo trình bày các phân tích để chứng minh rằng Intserv/Diffserv không thể giải quyết tất cả mọi vấn đề, và rõ ràng cần thiết phải có các cách tiếp cận khác Sau đó trình bày một sườn gồm các công việc chính cần thực hiện để cung cấp QoS bao gồm nhiều cơ chế như định hướng dữ liệu (traffic directing) và cân bằng tải (load balancing) ở lớp ứng dụng, Diffserv ở lớp vận chuyển (lớp 4) và lớp mạng (lớp 3), kỹ thuật lưu lượng (traffic engineering) và định tuyến lại nhanh (fast rerouting) ở lớp mạng

2.1 Giới thiệu

Chúng ta đều biết mạng Internet ngày nay chỉ có thể cung cấp các dịch với chất lượng tốt nhất có thể (best effort service) Tuy nhiên với sự chuyển biến nhanh chóng của mạng Internet trở thành cơ sở hạ tầng cho các giao dịch thương mại, thì yêu cầu về chất lượng dịch vụ ngày càng cấp thiết Khi đó mạng Internet phải

có thể cung cấp được một số loại dịch vụ thay vì chỉ một loại như hiện nay Một trong các kiểu dịch vụ đó là phải có thể xác định trước được chất lượng dịch vụ nhằm cho phép các công ty thực hiện công việc kinh doanh trên Web Những công ty đó họ sẽ phải trả một mức giá nhất định cho độ tin cậy của dịch vụ mà họ

có được Kiểu dịch vụ này có thể chỉ là một lớp dịch vụ đơn, hoặc nó có thể bao

gồm nhiều lớp như dịch vụ chất lượng vàng và dịch vụ chất lượng bạc với mức

chất lượng giảm dần

Một kiểu dịch vụ khác sẽ cung cấp các dịch vụ có độ trễ và Jitter thấp cho các ứng dụng thời gian thực Cuối cùng dịch vụ chất lượng tốt nhất có thể vẫn được duy trì cho những khách hàng chỉ cần kết nối [2]

Mặc dù vẫn còn có những tranh cải về tính cần thiết của các cơ chế cung cấp chất lượng dịch vụ mà một trong các ý kiến phản bác việc đưa ra các cơ chế đó cho rằng với các cải tiến vượt bậc trong công nghệ cáp sợi quang và kỹ thuật ghép bước sóng (DWDM) sẽ làm cho lượng băng tần trở nên dồi dào và chi phí trên một đơn vị băng thông thấp do đó chất lượng dịch vụ tự nhiên đã được đảm bảo Lại có ý kiến khác cho rằng cho dù với các công nghệ tiên tiến trên thì các ứng dụng mới với yêu cầu băng thông cao cũng phát triển với tốc độ rất nhanh nên băng tần không bao giờ là thừa Tuy nhiên đồ án này không có ý định bàn luận về vấn đề này, mà ở đây tác giả chỉ muốn lưu ý một điều rằng cho dù cuối

cùng băng tần cũng được tạo ra một cách dư thừa và chi phí thấp thì điều đó vẫn chưa thể xảy ra bây giờ Do đó tại thời điểm hiện nay và trong một tương lai gần việc nghiên cứu, phát triển một số cơ chế nhằm cung cấp chất lượng dịch vụ cho các ứng dụng trên Internet là rất cần thiết Và trên thực tế phần lớn các nhà cung cấp các bộ định tuyến và chuyển mạch Internet đều hổ trợ quan điểm này bằng cách phát triển các cơ chế đó trong các sản phẩm của họ [17][18][19][20][21].

Tổ chức chuẩn hoá IETF (Internet Engineering Task Force) đã đưa ra nhiều các

mô hình dịch vụ và giao thức nhằm cung cấp QoS trên Internet Đáng lưu ý trong

đó là hai mô hình: mô hình dịch vụ tích hợp với giao thức bào hiệu RSVP (Intserv) và mô hình phân chia dịch vụ (Diffserv) Chúng sẽ được mô tả tóm tắt trong các phần tiếp theo

2.2 Mô hình dịch vụ tích hợp và giao thức

báo hiệu RSVP

Mô hình dịch vụ tích hợp (Intserv) [24] đề xuất hai lớp dịch vụ thêm vào cho dịch

vụ chất lượng tốt nhất có thể Đó là: 1) dịch vụ bảo đảm [26] cho ứng dụng yêu cầu giới hạn trễ cố định; và 2) dịch vụ tải điều khiển [27] cho các ứng dụng yêu cầu độ tin cậy cao Thực chất của mô hình này là “có một yêu cầu không thể tránh khỏi đối với các bộ định tuyến phải có thể dành trước nguồn tài nguyên của

nó (RAM, CPU, vv ) để cung cấp các mức chất lượng dịch vụ cụ thể cho dòng các gói mang lưu lượng người dùng Điều này yêu cầu các bộ định tuyến phải có khả năng quản lý các luồng lưu lượng (tương tự các kết nối trong chuyển mạch kênh)

Giao thức phục vụ nguồn-RSVP được sáng chế như là giao thức báo hiệu cho các ứng dụng

để dự trữ các nguồn [28] Quá trình báo hiệu được minh hoạ trong hình 2-1 Người gửi gửi một bản tin PATH tới người nhận xác định rõ tính chất của lưu lượng Mọi bộ định tuyến trung gian dọc theo đường hướng đi của bản tin PATH tới bước tiếp theo được xác định bởi giao thức định tuyến Đến khi nhận được bản tin PATH, người nhận trả lời với bản tin RESV để yêu cầu nguồn cho luồng xác định Mọi bộ định tuyến trung gian dọc theo đường dẫn có thể loạI bỏ hoặc chấp nhận yêu cầu của bản tin RESV Nếu yêu cầu này bị loại bỏ, thì bộ định tuyến sẽ gửi một bản thông báo lỗi tới người nhận, và quá trình báo hiệu sẽ kết thúc Nếu yêu cầu được chấp nhận, băng thông kết nối và độ không gian bộ đệm được cấp cho luồng lưu lượng và thông tin trạng thái liên quan đến luồng lưu lượng sẽ được cài đặt trong bộ định tuyến

Hình 2-1: Báo hiệu RSVP

Dịch vụ tích hợp-Intserv được thực hiện bởi bốn thành phần: giao thức báo hiệu (ví dụ RSVP), sự đIều khiển định tuyến, cấu hình phân lớp và cấu hình gói Dịch vụ đảm bảo yêu cầu các ứng dụng hoặc dịch vụ tải điều khiển phải được cài đặt các đường dẫn và dự trữ các tài nguyên trước khi truyền dữ liệu của họ Sự điều khiển định tuyến sẽ quyết định cho việc cấp nguồn cho yêu cầu hay không Khi bộ định tuyến nhận được gói, bộ phân lớp sẽ thực hiện sự phân lớp đa trường (MF) và đưa gói vào hàng đợi đặc biệt dựa trên kết quả của sự phân lớp Cấu hình gói sau đó sẽ lên lịch trình cho gói để đạt được yêu cầu chất lượng dịch vụ của nó.

Kiến trúc dịch vụ tích hợp-Intserv/giao thức phục vụ nguồn-RSVP bị ảnh hưởng bởi công việc của Ferrari [29] Nó thể hiện sự thay đổi cơ bản sang kiến trúc Internet truyền thống, có thể thấy được dựa trên khái niệm là tất cả các thông tin trạng thái liên kết luồng nên ở trong các hệ thống cuối [32] Các vấn đề với kiến trúc Intserv là: 1) tổng số trạng thái thông tin tăng một cách tỷ lệ với số luồng Điều này sắp xếp một bộ chứa lớn và quá trình

sử lý mào đầu trên các bộ định tuyến xương sống Do đó cấu trúc này không tỷ lệ trong Internet; 2) yêu cầu trên bộ định tuyến là cao Tất cả các bộ định tuyến phải được cung cấp RSVP, thêm phần điều khiển, sự phân lớp MF và lịch trình đóng gói; 3) đồng thời sự triển khai được yêu cầu cho dịch vụ bảo đảm Sự triển khai gia tăng của dịch vụ tải điều khiển

có thể được triển khai dịch vụ tải điều khiển và tính năng RSVP tại nút nghẽn cổ trai của một phạm vi và truyền các bản tin RSVP qua phần khác của phạm vi này

2.3 Các dịch vụ khác biệt

Bởi vì sự khó khăn trong việc thực hiện và triển khai dịch vụ tích hợp-Intserv và giao thức phục vụ nguồn-RSVP, các dịch vụ khác biệt (Diffserv) [38][39] được giới thiệu Thực chất của các dịch vụ khác biệt-Diffserv là để chia lưu lượng thành nhiều lớp, và điều khiển chúng khác nhau, đặc biệt khi tài nguyên hạn chế

Phần mào đầu Ipv4 chứa byte kiểu dịch vụ (TOS) ý nghĩa của nó đã được định nghĩa trước trong phần [33] Các ứng dụng có thể đặt ở 3 bit trái trong byte TOS để chỉ ra được

sự cần thiết cho độ trễ thấp hoặc dữ liệu truyền qua cao hoặc dịch vụ tốc độ mất gói thấp Tuy nhiên, các sự lựa chọn là có giới hạn Các dịch vụ khác biệt-Diffserv đổi tên octet TOS thành trường dịch vụ khác biệt (trường DS) [43] và sử dụng nó để chỉ ra cách sử lý gói nên nhận Các dịch vụ khác biệt-Diffserv cũng chuẩn hoá số của các nhóm chế độ bước nhảy (PHB) [44][45] Sử dụng sự phân lớp khác nhau, điều lệ, hình dạng và các luật lịch trình, một vài lớp dịch vụ có thể được cung cấp

Để khách hàng nhận được các dịch vụ khác biệt từ ISP của nó, sự thoả thuận lớp dịch

vụ (SLA) với ISP của nó Một sự đồng ý lớp dịch vụ có thể được xác định một cách tường minh hay ngầm định một sự đồng ý điều kiện lưu lượng (TCA) các luật phân lớp được định nghĩa như là luật đo, luật chính sách, luật đánh dấu và luật định dạng [38] Một sự đồng ý lớp dịch vụ SLA có thể là tĩnh hay động Các SLA tĩnh được thương lượng trên một nguyên tắc chung, ví dụ hàng tháng, hàng năm Các khách hàng với các SLA động sử dụng một giao thức báo hiệu như là RSVP để hỏi dịch vụ theo yêu cầu Các khách hàng có thể đánh dấu các trường DS của các gói của họ để chỉ ra được dịch vụ yêu cầu hoặc đánh dấu cho họ bằng bộ định tuyến lề dựa trên sự phân lớp MF Tại quyền được vào mạng ISP, các gói được phân lớp, chế độ và định dạng phù hợp Sự phân lớp, các luật định dạng và chính sách đã sử dụng tại bộ định tuyến cho quyền được vào đã được chỉ rõ trong TCA Tổng số không gian bộ đệm yêu cầu thường không được xác định cụ thể Khi một gói đi vào một phạm vi này từ một phạm vi khác, trường DS của nó có thể được đánh dấu lại, được xác định bởi SLA giữa hai phạm vi Các dịch vụ khác biệt-Diffserv chỉ định nghĩa các trường

DS và các PHB Đó là trách nhiệm của ISP để quyết định dịch vụ nào cung cấp Sử dụng

sự phân lớp, chính sách, định dạng và các cơ cấu lịch trình, rất nhiều dịch vụ có thể được

cung cấp Ví dụ, 1 Dịch vụ tiền lương với độ tin cậy, độ trễ thấp và phân giải jitter thấp; 2 Các dịch vụ vàng bạc với sự phân giải đúng thời gian và đảm bảo Các dịch vụ khác biệt-Diffserv có ý nghĩa khác so với dịch vụ tích hợp-Intserv Thứ nhất, chỉ có một số hạn chế các lớp dịch vụ được chỉ ra bởi trường DS Từ tài nguyên được cấp trong chi tiết của lớp, tổng số thông tin trạng thái tỷ lệ với số lớp hơn là tỷ lệ với số luồng Do đó các dịch vụ khác biệt-Diffserv có tính mở rộng cấp độ hơn Thứ hai, sự phân lớp tinh tế, các quá trình đánh dấu, chính sách và quá trình định dạng chỉ được cần đến tại cuối của mạng Các lõi bộ định tuyến ISP chỉ cần thực hiện sự phân lớp tập hợp tương tác hợp nhất (BA) Do đó nó

dễ dàng hơn để thực hiện các dịch vụ khác biệt-Diffserv Trong mô hình Diffserv, sự triển khai gia tăng có thể cho các dịch vụ vàng bạc Các bộ định tuyến không có Diffserv thường

bỏ qua các trường DS của các gói và mang tới các gói một dịch vụ tốt nhất Thậm chí trong trường hợp, vì các gói vàng và bạc thường ít bị mất bởi các bộ định tuyến có Diffserv, sự thực hiện của luồng lưu lượng vàng và bạc sẽ vẫn tốt hơn luồng lưu lượng tốt nhất

2.4 Hệ thống cơ sở cho việc cung cấp chất lượng dịch vụ trên Internet

Nhiều người quan tâm đến các dịch vụ khác biệt-Diffserv như là một kế hoạch cho việc cung cấp chất lượng dịch vụ trên Internet Luồng lưu lượng cơ khí, định tuyến cơ sở hạn chế, MPLS, và định tuyến nhanh được xem như là một vấn đề độc lập Trong bản luận văn cao học này, chúng ta thấy rằng một mình Diffserv thì không đầy đủ cho việc cung cấp chất lượng dịch vụ trên Internet, và đề xuất hệ thống cơ sở để làm việc đó Hệ thống cơ sở này bao gồm luồng lưu lượng trực tuyến và tải cân bằng tại lớp ứng dụng, Diffserv tại lớp mạng và lớp truyền dẫn, và luồng lưu lượng cơ khí và định tuyến nhanh tại lớp mạng ở đây chúng ta giải thích một cách ngắn gọn các cấu hình thêm vào lại cần đến Diffserv nhất thiết phải cung cấp một sự suy giảm thực hiện khác biệt (hoặc không suy giảm) cho các luồng lưu lượng khác nhau khi mạng tắc nghẽn Nếu sự tắc nghẽn có thể tránh được, quá trình thực hiện của tất cả các luồng lưu lượng sẽ tốt thậm chí không cần Diffserv Luồng lưu lượng cơ khí có thể tránh được tắc nghẽn nguyên nhân gây ra bởi không có sự phân tán luồng lưu lượng ĐIều đó cho biết tại sao luồng lưu lượng cơ khí là có ích trong việc cung cấp chất lượng dịch vụ Đó cũng là vấn đề Diffserv không giải thích Điều đó thậm chí thông qua chính sách và dạng thức đã được làm tại bên lề, vấn đề không phân tải lưu lượng trên mạng có thể vẫn là nguyên nhân tình trạng tập trung cao luồng lưu lượng tại một vài

bộ định tuyến Vấn đề này phải được giải thích bằng luồng lưu lượng cơ khí Do đó luồng lưu lượng cơ khí cũng cần thiết cho việc cung cấp chất lượng dịch vụ trên Internet Các dịch vụ khác biệt-Diffserv chỉ liên quan đến mạng trong điều kiện thông thường Nó không định địa chỉ một cách đầy đủ về mặt số lượng tạo ra do nguyên nhân bởi lỗi kết nối hoặc lỗi của bộ định tuyến Khi một bộ định tuyến hoặc một kết nối bị lỗi, luồng lưu lượng gửi theo đường dẫn sẽ bị mất Do đó, nó bớt lỗi để sửa tạm thời đường dẫn có liên quan do đó

nó có thể tiếp tục thực hiện truyền lưu lượng Đó là nhiệm vụ của bộ định tuyến nhanh [51][52][53]

Luồng lưư lượng trực tuyến cũng sử dụng phần tắc nghẽn của mạng bằng cách chọn các tài nguyên lưu lượng từ các sự lựa chọn đa phân phối về mặt địa lý dựa trên một vài thống kê đo đạc một cách thường xuyên Đó là thành phần hỗ trợ cho Diffserv Tải cân bằng sử dụng đa máy chủ (có khoảng cách gần về mặt địa lý) và phân giải các yêu cầu giữa chúng

Mục đích để tăng chất lượng dịch vụ và để giảm tải của mỗi máy chủ Hệ thống cơ sở cho việc cung cấp chất lượng dịch vụ trên Internet được tổng kết ở bảng 2.1

Bảng 2-1 hệ thống cơ sở cho việc cung cấp chất lượng dịch vụ

tuyến và tải cân bằng

URL trực tuyến lại, tải cân bằng

Định tuyến trực tiếp luồng lưu lượng từ tắc nghẽn của mạng

và máy chủ Lớp truyền dẫn/lớp

mạng Các dịch vụ khác biệt-Diffserv Sự phân lớp, chính sách, đánh dấu, hàng

đợi và mô hình lớp

cơ bản, Sự dò tìm ngẫu nhiên sớm (RED)

Cung cấp các dịch

vụ khác biệt cho các lớp khác nhau của luồng, đặc biệt là trong suốt quá trình tắc nghẽn của mạng

khí MPLS, định tuyến cơ bản hạn chế, báo

hiệu đường dẫn LSP,

và các trạng thái tăng cường kết nối IGP

Tránh tắc nghẽn trên mạng

Định tuyến lại nhanh Sửa chữa nội hạt Tránh mất gói trong

quá trình lỗi kết nối và/hoặc lỗi bộ định tuyến

Chương 3 Các dịch vụ khác biệt

Trong chương này, chúng ta sẽ thảo luận cách thức cung cấp các dịch vụ khác biệt-Diffserv như thế nào trên các mạng IP Đồng thời đề xuất các giải pháp giải quyết xung đột giữa Diffserv và TCP

3.1 Giới thiệu dịch vụ bảo đảm (assured service) và dịch vụ bảo hiểm (premium service)

Phần này trình bày một mô hình kiến trúc cho các dịch vụ khác biệt (Diffserv)[5] Kiến trúc này cung cấp 3 lớp dịch vụ:

- lớp các dịch vụ với chất lượng tốt nhất có thể (best effort service)

- dịch vụ bảo đảm (assured service), và

- dịch vụ bảo hiểm (premium service)

Trong đó dịch vụ có chất lượng tốt nhất có thể là dịch vụ Internet truyền thống Sau đây chỉ

mô tả hai dịch vụ bảo đảm và bảo hiểm

3.1.1 Dịch vụ bảo đảm

Dịch vụ bải đảm cho phép phân phối các gói một cách tin cậy và có thể xác định trước Kiểu dịch vụ này được đưa ra nhằm phục vụ cho các ứng dụng tương tác không yêu cầu thời gian thực như duyệt Web Lưu lượng của lớp dịch vụ bảo đảm thể hiện một phương

thực chuyển tiếp bảo đảm trên từng chặng (assured-forwarding (AF) per-hop behavior)

[44] Dịch vụ bảo đảm lại có thể chia thành các lớp con khác là dịch vụ chất lượng vàng (gold) và dịch vụ chất lượng bạc (silver)

Các khách hàng thuê bao nếu cần được cung cấp dịch vụ bảo đảm sẽ phải có một bản ghi

nhớ với nhà cung cấp dịch vụ (ISP) của họ gọi là thoả thuận về mức chất lượng dịch vụ

(SLA-service level agreements) Sau đó khách hàng sẽ chịu trách nhiệm trong việc quyết

định phân chia lượng băng thông đó cho các ứng dụng của họ Mục 3.2.2 mô tả một quá trình phân chia dịch vụ như thế Các SLA cho các dịch vụ đảm bảo thường là tỉnh, có nghĩa khánh hàng có thể truyền dữ liệu bất cứ khi nào họ muốn mà không cần các thủ tục báo hiệu với ISP

3.1.2 Dịch vụ bảo hiểm - Premium Service

Dịch vụ boả hiểm cung cấp các dịch vụ tin cậy, trễ thấp và jitter thấp như dịch vụ thuê kênh ảo (VLL - virtual lease line) Nó được sử dụng cho các ứng dụng thời gian thực hoặc cho lưu lượng mang các thông tin cực kỳ quan trọng như các thông tin điều khiển mạng

Lưu lượng của lớp dịch vụ bảo hiểm sẽ thể hiện cơ chế chuyển tiếp liên tiếp (EF -

expedited forwarding)[45].

Khách hàng khi thuê bao dịch vụ bảo hiểm cũng sẽ phải có một SLA với nhà cung cấp dịch

dụ (ISP) của họ SLA qui định tốc độ bit cao nhất mà khách hàng được phép phát lưu lượng vào mạng và mạng sẽ đảm bảo cung cấp cho khách hàng lượng băng thông bằng tốc

độ đó Khách hàng phải đảm bảo không được phát lưu lượng với tốc độ vượt quá tốc độ đỉnh trên, nếu không lượng lưu lượng vượt quá đó có thể bị huỷ bỏ Tuy nhiên, không phải lúc nào mạng cũng sẽ huỷ bỏ lượng lưu lượng vượt quá này mà nếu ISP chắc chắn rằng mạng có đủ tài nguyên để vận chuyển lượng lưu lượng dư ra này nó sẽ truyền chúng bình thường Xác suất xảy ra trường hợp thứ hai cao hơn vì các mạng ISP thường được thiết kế với độ dự phòng cao

Vì dịch vụ bảo hiểm thường đắt hơn dịch vụ bảo đảm, nên các ISP thường phải hổ trợ cả các SLA tĩnh và động SLA động cho phép khách hàng yêu cầu dịch vụ bảo hiểm bất cứ khi nào họ cần mà không cần phải thuê bao trước Tuy nhiên cần thiết phải có các thủ tục báo hiệu và điều khiển chấp nhận yêu cầu đối với các SLA động [40]

3.1.3 Các thuật ngữ

Bảng 3-1 dưới đây định nghĩa các thuật ngữ thường xuyên được sử dụng trong chương này

Bảng 3-1 Các thuật ngữ thường xuyên được sử dụng trong mô hình các dịch vụ khác Diffserv

biệt-Flow (Luồng) Dòng các gói có cùng địa chỉ IP nguồn, số cổng nguồn, địa chỉ IP đích, số

cổng đích, và Id của giao thứcThoả thuận

mức dịch

vụ-SLA

Dịch vụ liên hệ giữa khách hàng và nhà cung cấp dịch vụ chỉ rõ xu hướng của dịch vụ khách hàng nên nhận Khách hàng có thể là một tổ chức người sử dụng hoặc phạm vi nhà cung cấp (phạm vi đi ngược dòng)

tiên Toàn bộ ba bit trái đầu tiên trong octet TOS của mào đầu IPv4 Nhớ rằng trong các dịch vụ khác các dịch vụ khác các dịch vụ khác

biệt-Diffserv, ba bit này có thể hoặc không thể được sử dụng biểu thị sự ưu tiên của gói IP

Trường TOS Bit 3-6 trong octet TOS của mào đầu IPv4 [34]

Nhận thức ngoài xu hướng sử lý lớp của gói tại nút Diffserv lỗi

Cơ cấu Một thuật toán riêng hoặc quá trình vận hành (ví dụ trật tự hàng đợi) được

thực hiện trong bộ định tuyến để thực hiện một hoặc nhiều mỗi tương tác bước nhảy

Đánh dấu Quá trình thiết lập các trường DS của các gói

Chính sách Quá trình sử lý các dạng lưu lượng, ví dụ loại bỏ các gói vượt quá

Định dạng Quá trình trễ của các gói trong luồng lưu lượng tạo cho nó tương thích

ứng với dạng luồng đã định nghĩa

Sơ đồ Quá trình quyết định gói gửi trước trong một hệ thống đa hàng đợi

Quản lý hàng

đợi Điều khiển chiều dài của các gói hàng đợi bằng cách bỏ các gói khi cần thiết hoặc cho phù hợpCấu trúc của octet TOS được miêu tả dưới đây:

Trường MBZ: Must Be Zero, các bit bên phải trong octet TOS.

Cấu trúc của trường DS được miêu tả như sau:

DSCP: Differentiated Service Code Point, 6 bits bên trái trong trường DS.

CU: currently unused.

3.2 Một giải pháp cho việc cung cấp dịch vụ bảo đảm và dịch

vụ “Premium”

Trong phần này chúng ta miêu tả cách cung cấp các dịch vụ bảo đảm và dịch vụ

“Premium” như thế nào Trước hết chúng ta miêu tả các cơ cấu cần thiết trong các mạng ISP Sau đó chúng ta sẽ miêu tả thích ứng cho khách hàng để cấp dịch vụ mà họ sẽ lấy từ các ISP cho các host/và các ứng dụng của họ, và tiếp cận ISP để cấp các tài nguyên trong mạng của họ do đó các dịch vụ liên hệ có thể được phân giải Các yêu cầu trên các bộ định tuyến, và sự mở rộng cấp độ của vấn đề này được thảo luận sau

Bởi vì chỉ có 3 lớp lưu lượng (hoặc 4 lớp nếu như dịch vụ đảm bảo được phân chia thành vàng và bạc), chỉ có 3 bit đầu tiên của DSCP, ví dụ , trường định dạng ưu tiên, được sử dụng để chỉ ra lớp lưu lượng rằng mỗi gói theo đó và sự đánh mất quyền ưu tiên của gói 3 bit khác của DSCP được thiết lập 0 Trong các từ khác, chỉ có bộ lựa chọn 8 lớp mã hoá điểm được sử dụng ứng với mỗi cổng đầu ra, một hàng đợi được sử dụng cho mỗi lớp Trong 3 bit được sử dụng, hai bit đầu tiên được sử dụng chỉ rõ các lớp lưu lượng (và do đó việc lựa chọn các hàng đợi gắn liền với các lớp này), bit thứ 3 được sử dụng để chỉ ra sự đánh mất quyền ưu tiên trong các mỗi lớp

3.2.1 Các cơ cấu cho việc cung cấp dịch vụ bảo đảm và dịch vụ

3.2.1.1 Sự phân lớp tại đầu vào

Sự phân lớp này chủ yếu dựa trên giao diện đầu vào Trong giao diện đầu vào này có thể về

mặt vật lý như là giao diện packet-over-SONET (POS), hoặc về mặt logic như là ATM VC

Quyền ưu tiên TOS MBZ

0 1 2 3 4 5 6 7

DSCP CU

0 1 2 3 4 5 6 7

hoặc là Ethernet virtual LAN (VLAN) Bên cạnh đó giao diện đầu vào, các địa chỉ IP nguồn

và đích, số các cổng nguồn và đích, giao thức ID và octet TOS có thể được sử dụng hơn nữa trong sự phân lớp Điều này được gọi là sự phân lớp đa trường (MF) Trước hết thông qua việc xem xét giao diện đầu vào, các luật phân lớp cho luồng lưu lượng từ một giao diện

có thể được tách ra từ các luật cho luồng lưu lượng từ các giao diện khác

Điều này giảm phần lớn số lượng các luật do đó cần được xem xét, và làm sự phân lớp đa trường MF nhanh hơn nữa Từ kết quả của sự phân lớp, các dạng lưu lượng và các luật định dạng, đánh dấu, chính sách tương ứng của các gói đến có thể được xác nhận từ nguồn đến Chính sách, đánh dấu và định dạng có thể sau đó được thực hiện trên luồng lưu lượng dựa trên sự thoả thuận lớp dịch vụ-SLA

3.2.1.2 Chính sách, đánh dấu, và sự định dạng tại đầu vào

Chính sách để xác định luồng lưu lượng nào từ một khách hàng phù hợp với dạng lưu lượng chỉ rõ trong sự thoả thuận lớp dịch vụ-sự thoả thuận lớp dịch vụ-SLA, và thực hiện hoạt động tương ứng Đánh dấu để xác định DSCP của các gói Chính sách và quá trình đánh dấu của luồng lưu lượng bảo đảm và luồng lưu lượng “premium” được miêu tả dưới đây

Đối với các khách hàng sử dụng dịch vụ bảo đảm, chính sách nên được thực hiện với một dấu hiệu xô “token bucket” do đó một vài loại “burst” được cho phép Khi các gói đến và

có các dấu hiệu trong xô, gói này được xem như trong dạng thức DSCP của gói được thiết lập đến 101000 thông qua quá trình đánh dấu Nếu như các gói đến và không có dấu hiệu trong xô, thì sau đó gói được xem như là ngoài dạng thức Quá trình đánh dấu sẽ thiết lập DSCP của gói đến 100000 Nhớ rằng hai bit đầu tiên cho cả các gói thuộc dạng thức và các gói không thuộc dạng thức là giống nhau, vì cả hai kiểu gói này có cùng lớp luồng lưu lượng Nhưng bit thứ ba là khác nhau, do đó các gói trong dạng thức và các gói ngoài dạng thức sẽ có quyền ưu tiên là khác nhau Thuật toán dò tìm ngẫu nhiên sớm (RED) sau đó quyết định thả gói riêng xuống hoặc cho nó xếp hàng đợi Không gói nào với DSCP

101000 được thả trước tất cả các gói 100000 Thuật toán dò tìm ngẫu nhiên sớm (RED) sẽ được chi tiết hơn trong phần tiếp theo Tất cả các gói không được thả, chúng thuộc dạng thức hoặc không thuộc dạng thức, được đẩy vào trong cùng một hàng đợi để tránh việc nằm ngoài sự phân tải Chúng ta gọi hàng đợi này là hàng đợi bảo đảm (AQ) Đối với các khách hàng với dịch vụ “premium” chính sách nên được thực hiện với gáo dò do đó sự bùng nổ sẽ không được giới thiệu, hoặc với một dấu hiệu của gáo cho phép chỉ có sự bùng

nổ nhỏ Khi gói đến và có dấu hiệu trong gói, gói này được xem như là phù hợp DSCP của gói được thiết lập 111000 Nếu như gói đến và không có dấu hiệu trong gáo, thì sau đó gói xem như là không phù hợp Tuỳ thuộc vào sự thoả thuận lớp dịch vụ-SLA giữa ISP và khách hàng (có thể là một ISP nữa), các gói không phù hợp có thể bị đánh mất ngay lập tức hoặc có thể được truyền và tính cước phí ngoài Nếu các gói không phù hợp được truyền, cácDSCP sẽ được thiết lập 111000 Tất cả các gói được đẩy vào một hàng được gọi là hàng đợi “premium” (PQ)

Luồng lưu lượng tốt nhất có thể cũng được thiết lập chính sách, tuỳ thuộc vào các sự thoả thuận lớp dịch vụ-SLA giữa các khách hàng và các nhà cung cấp dịch vụ Các gói trong dạng thức sẽ có DSCP 001000, và các gói ngoài dạng thức sẽ có DSCP 000000 Nói một cách khác, không một chính sách nào được thực hiện cho luồng lưu lượng tốt nhất và DSCP của tất cả các gói được thiết lập 000000 Thuật toán dò tìm ngẫu nhiên sớm (RED) được áp dụng, các gói không bị mất đưa vào hàng đợi gọi là hàng đợi mặc định (DQ).Bởi vì PQ, AQ, và DQ tất cả có cùng tốc độ đầu ra, “premium”, sự bảo đảm và các luồng lưu lượng tốt nhất được định dạng

3.2.1.3 Quản lý hàng đợi và sơ đồ gói tại đầu vào và phần chính

Sau khi các gói được đánh dấu, biện pháp của nó được quyết định một cách duy nhất bởi DSCP của nó, không có vấn đề tại bộ định tuyến cuối hoặc tại bộ định tuyến chính Quá trình sử lý mỗi gói được mô tả dưới đây Để bảo đảm và luồng lưu lượng tốt nhất, thuật toán dò tìm ngẫu nhiên sớm (RED) được ứng dụng đầu tiên để quyết định xem có thả gói hay không Thuật toán dò tìm ngẫu nhiên sớm (RED) là một sơ đồ quản lý bộ đệm Thuật toán dò tìm ngẫu nhiên sớm (RED) thả các gói một cách ngẫu nhiên dựa trên các DSCP của chúng và trung bình chiều dài hàng đợi Mục đích của Thuật toán dò tìm ngẫu nhiên sớm (RED) để tránh tràn hàng đợi và mất đuôi (khi hàng đợi tràn, tất cả các gói đến bị mất) tại mỗi bộ đệm Thông qua các gói mất một cách ngẫu nhiên, các gói của các kết nối TCP khác nhau dường như bị mất tại các thời gian khác nhau Do đó, cơ cấu điều khiển luồng TCP cho các kết nối này sẽ giảm tốc độ gửi của chúng tại thời gian khác nhau Điều này sẽ giúp để tránh tràn tại các hàng đợi ở các bộ định tuyến, và do đó tránh được sự cắt đuôi Ngoài ra, sự mất đuôi sẽ kích hoạt nhiều luồng TCP để giảm tăng chậm tốc độ đồng thời của chúng Nó gây ra tải lưu lượng dao động và có thể làm tổn hại tới ý nghĩa của việc thực hiện Thuật toán dò tìm ngẫu nhiên sớm (RED) được chứng tỏ là có ích

Thuật toán dò tìm ngẫu nhiên sớm (RED) vào và ra (RIO) là sơ đồ quản lý bộ đệm khá tiên tiến Nó duy trì cơ bản hai thuật toán RED, một cho bên trong gói và một cho bên ngoài các gói Có hai ngưỡng cho mỗi hàng đợi Khi chiều dài hàng đợi trung bình thấp hơn ngưỡng thứ nhất, thì không có gói nào bị mất Khi chiều dài hàng đợi ở giữa hai ngưỡng thì chỉ có các gói bên ngoài là bị mất một cách ngẫu nhiên Khi chiều dài hàng đợi vượt quá ngưỡng thứ hai, sự tắc nghẽn mạng có thể xảy ra, tất cả các gói bên ngoài bị mất, và sau đó một vài gói bên trong cũng có thể bị mất một cách ngẫu nhiên Gói đánh mất có thể là một bước chức năng hoặc là một chức năng tuyến tính của chiều dài hàng đợi

Thêm vào đó để ngăn cản sự đồng bộ điều khiển luồng TCP, ngăn cản thuật toán dò tìm ngẫu nhiên sớm vào và ra (RIO), tới một vài phạm vi, các nguồn tài nguyên mong muốn từ tổn hại việc thực hiện của luồng lưu lượng bảo đảm khác bằng cách đánh mất các gói ngoài nhiều tính đối nghịch Tuy nhiên, RED/RIO không có hiệu quả trong việc điều khiển các nguồn tài nguyên không tương ứng như các ứng dụng sử dụng UDP

Đối với lưu lượng “premium”, RED hay RIO được áp dụng, bởi vì nó không đáng có để đánh mất các gói “premium” Tất cả các gói được đưa vào bên trong PQ PQ, AQ và DQ được lập lịch trình bởi thuật toán gọi là hàng đợi trọng lượng vừa đủ (WFQ) hoặc một biến thể của nó Tốc độ của các hàng đợi này được thiết lập bởi các bộ quản trị mạng dựa trên các thống kê lưu lượng và phạm vi chính sách Nếu chúng ta định nghĩa hệ số của một hàng

đợi, pf(queue), như sự tỉ lệ giữa tốc độ cấu hình đầu ra và tốc độ lưu lượng đầu vào thực tế,

sau đó trật tự cho phép phải được duy trì:

pf(PQ) > pf(AQ) > pf(DQ) > 1.0.

Thiết lập hệ số cho các hàng đợi này như thế nào được miêu tả trong phần 3.2.3

3.2.1.4 Định dạng lại của luồng lưu lượng bảo hiểm tại lối ra

Tuỳ thuộc vào sự thoả thuận lớp dịch vụ-SLA giữa ISP và phạm vi dòng xuống của nó (có thể là ISP khác nữa), ISP hiện thời có thể cần được định dạng luồng lưu lượng bảo hiềm của nó đi đến phạm vi dòng xuống Phạm vi dòng tải xuống sẽ kiểm soát luồng lưu lượng bảo hiểm từ ISP hiện hành Luồng lưu lượng vượt quá có thể bị mất, hoặc có thể được truyền và được tính cước cho cước phí thêm Nói một cách khác, ISP hiện thời có thể gửi dòng lưu lượng bảo tải xuống của nó mà không cần định dạng nó, nếu sự thoả thuận lớp

dịch vụ-SLA cho phép nó làm điều đó Phạm vi dòng lưu lượng tải xuống sau đó sẽ định dạng luồng lưu lượng bảo hiểm từ ISP hiện thời.

3.2.1.5 Sự trình bày dịch vụ bảo đảm và dịch vụ bảo hiểm

Phần này giải thích các dịch vụ bảo đảm và dịch vụ bảo hiểm như thế nào và có thể được nhận thấy thông qua sự phân lớp, chính sách, đánh dấu, quản lý bộ đệm và các cơ cấu lịch trình gói đã miêu tả ở trên

Đối với luồng lưu lượng bảo đảm, bởi vì nó được tách ra từ luồng lưu lượng tốt nhất, các dạng gói bên trong sẽ có tốc độ mất gói thấp (hoặc không mất gói) và phân giải theo trình

tự thời gian, thậm chí khi mạng bị tắc nghẽn với luồng lưu lượng tốt nhất Do đó, các khách hàng sẽ cảm nhận sự bảo đảm và trách nhiệm của dịch vụ mạng nếu như họ giữ luồng lưu lượng của họ phù hợp với dạng thức luồng lưu lượng

Khi không có sự tắc nghẽn, các dạng gói ở ngoài cũng sẽ được phân giải Các tài nguyên mạng do đó được tận dụng tốt hơn

Dịch vụ bảo đảm có thể được thay thế bởi các dịch vụ vàng và bạc bằng nhiều lớp dịch vụ

Sự xử lý của các luồng lưu lượng vàng bạc thực tế sẽ giống như sự xử lý của luồng lưu lượng đảm bảo, trừ

 Các DSCP của các gói vàng bạc được đánh dấu khác nhau Các gói vàng sẽ có DSCP 10x000, các gói bạc sẽ có DSCP 01x000, ở đó x có thể là 1 hoặc 0, tuỳ thuộc xem gói đó có nằm trong dạng thức hoặc nằm ngoài dạng thức

 Các gói vàng sẽ đưa vào hàng đợi vàng (GQ) và các gói bạc đưa vào hàng đợi bạc (SQ) Theo như trật tự duy trì dưới đây:

pf(GQ) > pf(SQ) > pf(DQ) > 1.0.

Đối với luồng lưu lượng bảo hiểm, trước hết, luồng lưu lượng được định dạng hoặc bị đánh rơi tại các bộ định tuyến đầu vào của các mạng Các luồng lưu lượng không tương thích không thể thực hiện có hiệu quả như các luồng lưu lượng tương thích Thứ hai, tốc độ đầu

ra của PQ được cấu hình một cách có ý nghĩa hơn tốc độ đầu vào (nó thích hợp hơn khi có

pf(PQ) > 2.0) Do đó, các gói bảo đảm đến sẽ tìm PQ trống hoặc rất ngắn trong phần lớn

thời gian Sự trễ hoặc jitter đã trải qua bởi các gói bảo hiểm sẽ là rất thấp Nhưng nên nhớ rằng dịch vụ bảo hiểm chỉ cung cấp sự bảo đảm có thể trong hạn định trễ hoặc jitter

Tuy nhiên, sự phân phối không đều của luồng lưu lượng bảo hiểm hoặc luồng lưu lượng bảo đảm có thể gây nên vấn đề cho các dịch vụ khác biệt-Diffserv Trong các mạng ISP, tổng số luồng lưu lượng từ các bộ định tuyến biên tới các bộ định tuyến chính, ví dụ CR1 trong hình 3-1, là không thể tránh được Nhưng đó không phải là vấn đề bởi vì kết nối đầu

ra đến lõi luôn nhanh hơn các kết nối đầu vào từ các khách hàng Tuy nhiên, tổng số luồng lưu lượng bảo hiểm và bảo đảm được gây ra bởi sự dịch chuyển lưu lượng không mong muốn, như chỉ ra tại CR4 trong hình 3-1, có thể mất hiệu lực giả thiết cần thiết rằng các tốc

độ đến của luồng lưu lượng bảo hiểm/bảo đảm là thấp hơn tốc độ dịch vụ, và gây ra việc thực hiện suy giảm luồng lưu lượng bảo hiểm/bảo đảm Một mình các dịch vụ khác biệt-Diffserv không thể tránh được vấn đề này Luồng lưu lượng cơ khí phải được sử dụng để tránh tắc nghẽn gây ra bởi sự phân phối lưu lượng không đều

Nó được thảo luận trong Chương 4

Hình 3-1 Sự phân bố luồng lưu lượng không đều

3.2.2 Sự phân bố dịch vụ trong các phạm vi khách hàng

Sự thoả thuận lớp dịch vụ-SLA được đưa ra, đó là trách nhiệm của khách hàng để quyết định các chủ của nó/các ứng dụng của nó chia sẻ dịch vụ như thế nào (ví dụ, 10 Mbps của luồng lưu lượng bảo hiểm) xác định trong sự thoả thuận lớp dịch vụ-SLA Quá trình này được gọi là sự định vị dịch vụ

Tại giai đoạn sớm của sự triển khai các dịch vụ khác biệt-Diffserv, các host trong các phạm

vi khách hàng sẽ gửi luồng lưu lượng của họ theo cách bình thường, ví dụ, không đánh dấu Tất cả luồng lưu lượng được xử lý công bằng trong phạm vi khách hàng, và bằng ISP trước chính sách, đánh dấu, sự xem xét của các host gửi và các ứng dụng Sự xử lý các gói từ các khách hàng sẽ nhận được quyết định bởi kết quả chính sách (ví dụ, vào ra của các dạng thức) tại bộ định tuyến đầu vào ISP Tại giai đoạn này, một khách hàng không có khả năng phân bố dịch vụ của nó một cách khác biệt đến các host/các ứng dụng khác nhau

Nếu một phạm vi khách hàng quyết định luồng lưu lượng khác nhau từ các host và các ứng dụng khác nhau, có hai sự lựa chọn cơ bản: 1) Mỗi ứng dụng tạo ra sự quyết định của riêng

nó trên mỗi dịch vụ để sử dụng, và thiết lập các DSCP của các gói của nó Không có bộ điều khiển trung tâm 2) Một bộ điều khiển tài nguyên phối hợp tài nguyên sử dụng của tất

cả các ứng dụng Một bộ điều khiển tài nguyên là một thiết bị cấp cho hoặc từ chối các yêu cầu cho các dịch vụ dựa trên các chính sách phạm vi Bộ điều khiển tài nguyên trong một phạm vi khách hàng giống như là bản thân bộ định tuyến lối ra (CPE)

Các chính sách phạm vi có thể được lưu trữ trong bản thân bộ định tuyến tài nguyên, hoặc chúng có thể được lưu trữ trong thành phần máy chủ tách biệt Trong trường hợp thứ hai,

bộ điều khiển tài nguyên sẽ sử dụng giao thức truy cập thành phần trọng lượng nhẹ-LDAP [55] để lấy lại các chính sách một cách có chu kỳ Từ đó tất cả các host phải cùng hoạt động để chia sẻ dịch vụ xác định trong sự thoả thuận lớp dịch vụ-SLA, đó là kỹ thuật tốt hơn để có bộ điều khiển tài nguyên Một lịch trình phân bố được miêu tả dưới đây Mỗi người sử dụng/mỗi ứng dụng sẽ quyết định dịch vụ nào để sử dụng và thiết lập các DSCP của các gói của nó Từ đó rất nhiều các ứng dụng có thể cần khả năng của việc thiết lập các DSCP của các gói của chúng, nó được giới thiệu là hệ thống vận hành (OS) của các host cung cấp giao diện chương trình ứng dụng-API tới tất cả các ứng dụng Nếu ứng dụng hoặc

hệ thống vận hành-OS không có khả năng thiết lập các DSCP của các gói của nó, sau đó bước này có thể được bỏ qua CPE sẽ phân lớp các gói và hoạt động như là bộ điều khiển tài nguyên để quyết định nên nhận luồng ứng dụng dịch vụ nào Các DSCP của các gói có thể được thiết lập lại đến một giá trị mới bằng CPE nếu cần thiết Sự thuận lợi của giải pháp này là đơn giản và dễ thực hiện Một chút không thuận lợi của giải pháp này là các

ứng dụng không biết CPE sẽ thiết lập các DSCP của các gói của chúng hay không Điều này có thể là một vấn đề cho các ứng dụng trong thời gian thực.

Để giải thích vấn đề ở trên, khả năng báo hiệu phải được thêm vào giữa các ứng dụng và

bộ điều khiển tài nguyên Bởi vì rất nhiều các ứng dụng có thể cần khả năng báo hiệu này,

nó được giới thiệu rằng hệ thống vận hành-OS cung cấp cơ cấu Giao thức báo hiệu có thể

là giao thức phục vụ nguồn-RSVP hoặc một vài giao thức khác Với khả năng báo hiệu, khi

bộ điều khiển tài nguyên quyết định để thiết lập lại các DSCP của các gói ứng dụng, nó có thể là ứng dụng báo hiệu Người sử dụng sau đó quyết định có dừng hay tiếp tục với dịch

vụ tốt nhất

Nói một cách khác, báo hiệu có thể được làm để quyết định ứng dụng dịch vụ nào có thể được sử dụng trước sự truyền dẫn dữ liệu thực tế Ví dụ, nếu một ứng dụng cần dịch vụ bảo hiểm, nó phải được yêu cầu dịch vụ bảo hiểm trước hết từ bộ điều khiển tài nguyên Bộ điều khiển tài nguyên sau đó có thể cấp cho hoặc từ chối yêu cầu Các báo hiệu có thể được cần đến trước sự truyền dẫn dữ liệu tuỳ thuộc vào bộ điều khiển tài nguyên nhanh như thế nào để tạo sự chấp nhận quyết định điều khiển Nếu sự chấp nhận quyết định điều khiển có thể được tạo rất nhanh, sau đó gói dữ liệu thứ nhất có thể phục vụ như là báo hiệu Ngoài

ra, báo hiệu có thể được làm trước sự truyền dẫn dữ liệu, hoặc một ít các gói dữ liệu đầu tiên có thể bị trễ đáng kể Từ triển vọng thực tế, bởi vì sự chấp nhận quyết định điều khiển được thực hiện bởi Card điều khiển trong CPE thay cho Card đường dây, nó thích hợp để thực hiện báo hiệu trước sự truyền dẫn dữ liệu

Nếu sự thoả thuận lớp dịch vụ-SLA giữa phạm vi khách hàng và ISP của nó là động, phạm

vi khách hàng phải báo hiệu ISP của nó cho dịch vụ Điều này có thể được thực hiện bởi giao tiếp giữa các bộ quản trị trong cả các phạm vi hoặc bởi một vài giao thức báo hiệu

3.2.3 Tài nguyên cung cấp trong các phạm vi ISP

Các sự thoả thuận lớp dịch vụ-SLA được đưa ra, một ISP phải được quyết định tạo cấu hình các bộ định tuyến của nó như thế nào do đó chúng có thể biết xử lý như thế nào luồng lưu lượng đến Một phần quan trọng của nhiệm vụ này là định hình tốc độ (dưới dạng tỷ lệ phần trăm khả năng kết nối) và kích cỡ cho PQ, AQ, DQ, và các tham số RIO cho AQ và

DQ Chúng ta gọi quá trình này là sự cung cấp tài nguyên

Trước hết chúng ta thảo luận sự cung cấp tài nguyên trong các ISP đó chỉ cung cấp các sự thoả thuận lớp dịch vụ-SLA tĩnh Đối với các bộ định tuyến lề, các luật phân lớp, chính sách, và các luật định dạng có thể được bắt nguồn từ các dạng lưu lượng trong các sự thoả thuận lớp dịch vụ-SLA Tuy nhiên, tốc độ và kích cỡ cho PQ, AQ, DQ và các tham số cho RIO theo cách phân tích không thể được bắt nguồn từ các dạng thức lưu lượng Lý do là bộ định tuyến lề có thể có đa dao diện tới các bộ định tuyến chính Do đó, mặc dù tổng số lưu lượng đến trong mỗi lớp có thể được bắt nguồn bằng cách cộng thêm tất cả các luồng lưu lượng khách hàng trong cùng lớp lại, sự phân phối luồng lưu lượng trong mỗi lớp giữa đa kết nối tới các bộ định tuyến chính là không biết Ví dụ, thậm chí nếu nó được biết là có một tổng số của luồng lưu lượng bảo hiểm 100 Mbps, nhìn chung không biết giá bao nhiêu cho 100 Mbps được dành cho Seattle và giá bao nhiêu được dành cho New York City Do

đó, tốc độ, kích cỡ, và các tham số RIO của các hàng đợi cho các giao diện đến các bộ định tuyến chính có thể phải được thiết lập dựa trên một vài phép đo thống kê Bởi vì điều này,

nó rất muốn các bộ định tuyến được trang bị với các lệnh cho việc chỉ ra tức thời hoặc trung bình (vượt trên chu kỳ định hình thời gian) tốc độ và chiều dài của các hàng đợi Khi

có một sự thay đổi topology trong mạng, sự phân phối của luồng lưu lượng giữa các giao diện này có thể thay đổi Thậm chí khi không có một sự thay đổi topology, sự phân phối luồng lưu lượng có thể thay đổi theo thời gian.Tất cả điều này làm nhiệm vụ thiết lập các tham số phức tạp

Đối với các bộ định tuyến chính, nhiệm vụ cung cấp tài nguyên có nhiều khó khăn, bởi vì thậm chí tổng số luồng lưu lượng đến trong mỗi lớp là không biết Một lần nữa, vấn đề lại đưa ra bởi vì sự phân phối luồng lưu lượng giữa các đích là không biết và có thể thay đổi theo thời gian Do đó, tốc độ và kích cỡ hàng đợi, và các tham số cho RIO, phải được định hình dựa trên một vài phép đo thống kê.

Một sự tiếp cận thiết lập tốc độ, kích cỡ và các tham số RIO là như sau Tốc độ đến của mỗi hàng được đưa đến thông qua giao thức quản lý mạng đơn giản (SNMP) từng khoảng

5 phút một Một trong nhóm thứ 95 của tất cả các phép đo tốc độ vượt quá 2 giờ, tăng lên

bởi sự cung cấp hệ số pf, và sau đó được sử dụng như là tốc độ đầu vào của hàng đợi Giá trị của pf được quyết định bởi lớp tương ứng và có thể cũng như bởi chính sách phạm vi

Ví dụ, pf có thể được thiết lập tới 2.0 cho PQ, 1.5 cho AQ, và 1.2 cho DQ Từ ba tốc độ

tăng mạnh r(q) của ba hàng đợi, phần trăm khả năng kết nối mỗi hàng đợi nên có có thể được tính toán như theo cách sau:

Phần trăm khả năng kết nối của hàng đợi q = r(q) / [ r(PQ) + r(AQ) + r(DQ) ], ở đó q là PQ

hoặc AQ hoặc DQ

Từ dạng thức luồng lưu lượng, tốc độ đầu ra của hàng đợi, và các yêu cầu khác như là sự ngầm định hàng đợi lớn nhất, kích cỡ cực đại của hàng đợi có thể sau đó được quyết định như sau:

Kích cỡ hàng đợi lớn nhất = tốc độ đầu ra của hàng đợi x sự ngầm định hàng đợi lớn nhất

Max queue size = output rate of the queue Max queueing latency

Từ kích cỡ hàng đợi lớn nhất và kích cỡ hàng đợi trung bình (biết từ các thống kê), các tham số có thể được bắt nguồn [124]

Các tham số ở trên có thể được thay đổi có chu kỳ, ví dụ: hàng giờ, để theo dõi sự thay đổi luân phiên luồng lưu lượng bình thường

Sự tổ chức cung cấp tài nguyên ở trên yêu cầu phép đo các tốc độ đến của các hàng đợi Nếu các tốc độ đến không đảm bảo nhưng tốc độ đầu ra hiện thời và chiều dài hàng đợi trung bình đảm bảo, sau đó tốc độ mới của hàng đợi có thể được quyết định theo cách sau.Nếu như chiều dài hàng đợi trung bình của một hàng đợi dài hơn chiều dài gốc, thì hệ số lớn hơn 1.0 nên được nhân với tốc độ đo đạc Giá trị của hệ số nên được quyết định xem giá trị là bao nhiêu để chúng ta tăng nhanh tốc độ của hàng đợi Nếu như chiều dài hàng đợi trung bình của một hàng đợi ngắn hơn chiều dài gốc, thì hệ số nhỏ hơn 1.0 có thể được

áp dụng Sau đó làm bình thường,

Phần trăm khả năng khả kết nối của hàng đợi q = r(q) / [ r(PQ) + r(AQ) + r(DQ) ], ở đó q là

PQ hoặc AQ hoặc DQ, và r(q) là tốc độ đầu ra bình thường của hàng đợi q

Cần ghi nhớ rằng không phải luôn luôn tốt để đưa ra PQ một phần trăm cao khả năng kết nối, bởi vì nó làm luồng lưu lượng bảo hiểm phá vỡ và cộng thêm gánh nặng cho các nút dòng tải xuống Nếu các sự thoả thuận lớp dịch vụ-SLA động cũng được cung cấp, sự cung cấp tài nguyên trở nên khá phức tạp

Thứ nhất, sự cung cấp tài nguyên trở nên liên quan đến quá trình báo hiệu Khi một yêu cầu cho các tài nguyên đến, bộ định tuyến ISP lề tạo một sự chấp nhận quyết định điều khiển dựa trên chính sách phạm vi và sự sẵn sàng tài nguyên Nếu các yêu cầu được cấp, các bộ định tuyến lề sẽ được định hình với các luật sự phân lớp, chính sách, sự đánh dấu và sự định dạng tương ứng.Tốc độ, kích cỡ và các tham số RED/RIO cho các hàng đợi có thể phải được thay đổi thường xuyên hơn, nhưng không phải hàng giờ cho một yêu cầu đến hoặc rời khỏi

Thứ hai, bởi vì các sự dịch chuyển luồng lưu lượng thêm vào được giới thiệu bởi các sự thoả thuận lớp dịch vụ-SLA động, ước lượng thực tế tổng số luồng lưu lượng trong mỗi lớp

trở nên khó khăn Tuy nhiên, các tham số cấu hình cho các bộ định tuyến chính vẫn nên dựa trên các phép đo thống kê, ví dụ một trong những nhóm thứ 95 của tốc độ phép đo vượt trên 2 giờ, và không nên thay đổi thường xuyên Một cách cụ thể, các bộ định tuyến chính không nên thay đổi các tham số cấu hình của nó với sự đến và đi của mỗi yêu cầu tài nguyên động.

Sự cung cấp tài nguyên là một nhiệm vụ sự khó khăn Từ các sự thảo luận ở trên, nó thật rõ ràng rằng các dịch vụ khác biệt-Diffserv không cung cấp các cơ cấu đầy đủ để ngăn cản các điểm nóng của luồng lưu lượng ưu tiên Do đó, nếu một mạng không bố trí và điều khiển cẩn thận, một mình các dịch vụ khác biệt-Diffserv không thể luôn luôn cho phép phân phối chất lượng dịch vụ thoả thuận cho luồng lưu lượng ưu tiên Quá trình này còn phức tạp hơn nếu như số lớp lưu lượng tăng

Nếu như một mạng có khả năng ưu tiên, thì thiết lập tốc độ hàng đợi, kích cỡ và các tham

số RED một cách chính xác trở nên ít quan trọng Bên cạnh đó, mạng có thể xử lý bùng nổ luồng lưu lượng bảo hiểm/bảo đảm và sự luân phiên luồng lưu lượng khá đơn giản Điều này làm sự hoạt động của mạng trở nên dễ dàng và giảm giá kết nối vận hành Hệ số này nên được xem xét trong quá trình lập sơ đồ mạng

3.2.4 Các yêu cầu trên các bộ định tuyến cho việc cung cấp các dịch vụ bảo hiểm và bảo đảm

Các yêu cầu trên các bộ định tuyến cho việc cung cấp các dịch vụ bảo hiểm và bảo đảm được tổng kết như sau

1 Các bộ định tuyến ISP lề (PEs) cần cung cấp sự phân lớp MF, chính sách, đánh dấu, và định dạng

2 Tất cả các bộ định tuyến ISP cần thực hiện sự phân lớp BA, RED/RIO, và tối thiểu 3 hàng với lịch trình hàng đợi trọng lượng vừa đủ-WFQ Một vài lệnh chỉ ra tốc độ đầu vào/đầu ra và chiều dài trung bình của các hàng đợi mong muốn cao Một cách tuỳ chọn,

3 Nếu các sự thoả thuận lớp dịch vụ-SLA động được cung cấp, các cơ cấu điều khiển sự chấp nhận và báo hiệu được cần đến Nếu dịch vụ bảo đảm được thay thế bởi các dịch

vụ vàng và bạc, thì AQ phải được thay thế bởi GQ và SQ Hàng đợi trọng lượng vừa đủ-WFQ được cần thiết để lập lịch trình cho PQ, GQ, SQ và DQ

3.2.5 Tính mở rộng cấp độ của các dịch vụ khác biệt-Diffserv trong trung tâm Internet

Cấu hình mô tả trong phần này về việc cung cấp dịch vụ bảo đảm và dịch vụ bảo hiểm là cấu hình mở rộng Đó là bởi vì:

1 Tổng số trạng thái thông tin mà bộ định tuyến chính cần để bảo dưỡng tỷ lệ với số lớp lưu lượng, mà không tỷ lệ với số các luồng ứng dụng;

2 Sự phân lớp phức tạp, chính sách, đánh dấu và định dạng chỉ xuất hiện tại lề của mạng;

3 Các bộ định tuyến chính chỉ cần để phân lớp các gói dựa trên các DSCP của chúng (sự phân lớp BA), thực hiện RED/RIO nếu cần thiết, và sử dụng hàng đợi trọng lượng vừa đủ-WFQ để lập lịch trình PQ, AQ và DQ

Tại lề của mạng, tốc độ kết nối thường là thấp Do đó các bộ định tuyến lề có thể sử dụng nhiều thời gian vào việc phân lớp phức tạp, chính sách, đánh dấu và định dạng Tại trung tâm mạng, tốc độ kết nối cao Các bộ định tuyến chính phải được giữ một cách đơn giản để

có thể chuyển các gói đi nhanh chóng Sơ đồ miêu tả trong phần này cho thấy được các yêu cầu đó.

3.2.6 Các ví dụ của sự phân phối dịch vụ từ đầu cuối đến đầu cuối

Ví dụ 1: sự phân phối dịch vụ bảo đảm với một sự thoả thuận lớp dịch vụ-SLA tĩnh

Trong hình 3-2, host S trong mạng khách hàng #1 (CN1) muốn sử dụng dịch vụ bảo đảm

để gửi dữ liệu đến host D trong mạng khách hàng #2 (CN2) CN1 có một sự thoả thuận lớp dịch vụ-SLA tĩnh với ISP1 Quá trình phân phối dịch vụ được miêu tả như dưới đây Một

số lượng bên trong mạch vòng là các số cho từng bước trong quá trình phân phối dịch vụ

Hình 3-2 Quá trình phân phối của dịch vụ bảo đảm với sự thoả thuận lớp dịch SLA tĩnh

vụ-1 Host S gửi các gói tới bộ định tuyến thoát ra nội hạt CPEvụ-1 Một cách tuỳ chọn, các DSCP của các gói có thể được thiết lập bởi Host S

2 CPE1 phân lớp các gói dựa trên các địa chỉ nguồn và các địa chỉ đích, các số cổng nguồn và đích, giao thức ID và có thể giao diện đầu vào Sau đó CPE1 kiểm tra các phạm vi chính sách để quyết định có nên thiết lập lại các DSCP của các gói trong dòng

đó tới giá trị mới không Nếu việc cấp dịch vụ không cần thiết, sau đó sự phân lớp và quá trình giải quyết có thể được bỏ qua, và PE1 sẽ cấp cho dịch vụ bảo đảm luồng lưu lượng CN1 đầu tiên của máy chủ đầu tiên cơ bản trong bước 3 CPE1 sau đó đưa các gói đến bộ định tuyến ISP PE1

3 PE1 thực hiện sự phân lớp MF dựa trên giao diện đầu vào, các DSCP, và có thể các lĩnh vực khác của các gói PE1 sau đó giải quyết dòng lưu lượng và đánh dấu lại các gói nếu cần thiết Các gói trong dạng thức sẽ có DSCP 101000, các gói ngoài dạng thức

1 Host S sends its packets to the local exit router CPE1 Optionally, the DSCPs of the packets can be set by Host S

2 CPE1 classifies the packets based on source and destination IP addresses, source and destination port numbers, protocol ID and possibly the incoming interface CPE1 then checks domain policies to decide whether to reset the DSCPs of the packets in that stream

to a new value If service allocation is not needed, then these classification and policing processes can be skipped, and PE1 will allocate the assured service to CN1’s traffic on a first come first serve basis in Step 3 CPE1 then forwards the packets to ISP edge router PE1

3 PE1 performs a MF classification based on the incoming interface, DSCPs, and possibly other fields of the packets PE1 then polices the traffic stream and re-marks the packets if necessary In-profile packets will have DSCP 101000, out-of-profile packets will have DSCP 100000 RIO is applied to the packets If the packets are not dropped by RIO, they are put into the AQ and scheduled accordingly PE1 also does the metering/accounting so that billing can be done later

4 All routers between PE1 (excluded) and PE2 (included) perform BA classifications, apply RIO, and perform WFQ on the queues.

5 CPE2 forwards the packets to host D

Example 2: Delivery of premium service with a dynamic SLA

In Fig 3-3, host S in customer network #1 (CN1) wants to use premium service to send

Figure 3-3 The delivery process of premium service with a dynamic SLA

data to host D in customer network #2 (CN2) CN1 has a dynamic SLA with ISP1

Phase 1: signaling

1 Either the administrator in CN1 communicates with the administrator in ISP1 to request for the service, or CPE1 (acting as the resource controller in CN1) sends a signaling message to PE1 to request for the service Theoretically, the request can be granted or denied If the request is granted, some policy rules will be added to CPE1 specifying which applications are allowed to use premium service Some rules will also be added to PE1 so that it knows how to police the premium traffic from CPE1 If the request is denied, the whole service process stops In reality, a dynamic request for premium service may never

be denied because this is an important profit source for ISPs The main purpose of signaling

is to notify the ISP to configure its edge router

Note that:

 It is assumed that static SLAs will always be used between ISPs Therefore, even if there are multiple ISPs between CN1 and CN2, there is no need for the signaling process to proceed end to end

 If the SLA between CN1 and ISP1 is static, then the signaling process is not needed

Phase 2: Data Transmission:

2 Host S sends its packets to the local exit router CPE1 Optionally, the DSCPs of the packets can be set by Host S

3 CPE1 classifies the packets based on source and destination IP addresses, source and destination port numbers, protocol ID and possibly the incoming interface

CPE1 then checks domain policies to decide whether to reset the DSCPs of the packets in that stream to new values CPE1 then forwards the packets to ISP edge router PE1

4 PE1 performs a MF classification based on the incoming interface, DSCPs, and possibly other fields of the packets, and polices the traffic If the premium traffic is non-conformant

to the profile, either the stream is shaped, or excess premium packets are dropped, or excess premium packets are sent and accounted for extra charge After that, all premium packets will have their DSCPs set to 111000, be put into the PQ, and be scheduled accordingly PE1 will also do the metering/accounting so that the information can be used for billing later.

5 All routers between PE1 (excluded) and PE2 (included) perform BA classifications and WFQ on the queues

6 PE2 forwards the packets to CPE2

7 CPE2 forwards the packets to host D

3.3 Resolving a Conflict between Diffserv and TCP

This section describes a conflict between TCP [56] and Diffserv on the use of the three leftmost bits in the TOS octet of an IPv4 header [57] In a network that contains Diffserv capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably A solution to this problem

is provided by modifying TCP to ignore the precedence field This solution has been published by the IETF as a proposed standard [59]

3.3.1 Introduction to the conflict between Diffserv and TCP

In TCP, each connection has a set of states associated with it Such states are reflected by a set of variables stored in the TCP control block (TCB) of both ends Such variables may include the local and remote socket number, precedence of the connection, security level and compartment, etc Both ends must agree on the setting of the precedence and security parameters in order to establish a connection and keep it open [60]

There is no field in the TCP header that indicates the precedence of a segment Instead, the precedence field in the header of the IP packet is used as the indication The security level and compartment are likewise carried in the IP header, but as IP options rather than a fixed header field Because of this difference, the problem with precedence discussed in this dissertation does not apply to them TCP requires that the precedence (and security parameters) of a connection must remain unchanged during the lifetime of the connection Therefore, for an established TCP connection with precedence, the receipt of a segment with different precedence indicates an error The connection must be reset [RFC793, page 37]

With the advent of Diffserv, intermediate nodes may modify the differentiated services code-point (DSCP) of the IP header to indicate the desired per-hop behavior (PHB) The DSCP includes the three bits formerly known as the precedence field

Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset

It should be noted that this conflict exists well before Diffserv is standardized, because it is

a common practice for routers to manipulate the precedence field to achieve some forwarding behavior before Diffserv was introduced [60]

3.3.2 Problem description

The manipulation of the DSCP to achieve the desired PHB by Diffserv-capable nodes may conflict with TCP's use of the precedence field This conflict can potentially cause problems for TCP implementations that conform to RFC 793 First, page 36 of RFC 793states:

“If the connection is in any non-synchronized state (LISTEN, SENT, RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or if an incoming segment has a security level or compartment which does not exactly match the level and compartment requested for the connection, a reset is sent If our SYN has not been acknowledged and the precedence level

SYN-of the incoming segment is higher than the precedence level requested then either raise the local precedence level (if allowed by the user and the system) or send a reset; or if the precedence level of the incoming segment is lower than the precedence level requested then continue as if the precedence matched exactly (if the remote TCP cannot raise the precedence level to match ours this will be detected in the next segment it sends, and the connection will be terminated then) If our SYN has been acknowledged (perhaps in this incoming segment) the precedence level of the incoming segment must match the local precedence level exactly, if it does not a reset must be sent.”

This leads to problem #1:

For a precedence-aware TCP module, if during TCP's synchronization process, the precedence fields of the SYN and/or ACK packets are modified by the intermediate nodes, resulting in the received ACK packet having a different precedence from the precedence picked by this TCP module, the TCP connection cannot be established, even if both modules actually agree on an identical precedence for the connection

Then, on page 37, RFC 793 states:

“If the connection is in a synchronized state (ESTABLISHED, 1,

FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), [unrelated statements snipped] If an incoming segment has a security level, or compartment, or precedence which does not exactly match the level, and compartment, and precedence requested for the connection, a reset is sent and connection goes to the CLOSED state.”

This leads to problem #2:

For a precedence-aware TCP module, if the precedence field of a received segment from an established TCP connection has been changed en route by the intermediate nodes so as to

be different from the precedence specified during the connection setup, the TCP connection will be reset

Each of problems #1 and #2 has a mirroring problem They cause TCP connections that must be reset according to RFC 793 not to be reset

Problem #3: A TCP connection may be established between two TCP modules that pick different precedence, because the precedence fields of the SYN and ACK packets are modified by intermediate nodes, resulting in both modules thinking that they are in agreement for the precedence of the connection

Problem #4: A TCP connection has been established normally by two TCP modules that pick the same precedence But in the middle of the data transmission, one of the TCP modules changes the precedence of its segments According to RFC 793, the TCP connection must be reset In a Diffserv-capable environment, if the precedence of the segments is altered by intermediate nodes such that it retains the expected value when arriving at the other TCP module, the connection will not be reset

3.3.3 Proposed modification to TCP

The proposed modification to TCP is that TCP must ignore the precedence of all received segments More specifically:

(1) In TCP's synchronization process, the TCP modules at both ends must ignore the precedence fields of the SYN and ACK packets The TCP connection will be established if all the conditions specified by RFC 793 are satisfied except the precedence of the connection

(2) After a connection is established, each end sends segments with its desired precedence The two ends' precedence may be the same or may be different (because precedence is ignored during connection setup time) The precedence fields may be changed by the intermediate nodes too They will be ignored by the other end The TCP connection will not

be reset

Problems #1 and #2 are solved by this proposed modification Problems #3 and #4 become non-issues because TCP must ignore the precedence In a Diffserv-capable environment, the two cases described in problems #3 and #4 should be allowed The proposed modification to TCP is in conformance with TCP's design philosophy In RFC 793, page

36, it is stated that:

“As a general rule, reset (RST) must be sent whenever a segment arrives which apparently

is not intended for the current connection A reset must not be sent if it is not clear that this

is the case.”

With the deployment of Diffserv, the precedence field can be modified by intermediate network nodes A change in the precedence of a received segment does not necessarily indicate that the segment is not intended for the connection Therefore, a RST must not be sent based solely on the change of the precedence of a received segment, no matter whether the TCP connection is in a non-synchronized state or synchronized state

3.3.4 Security impact of the proposed modification to TCP

The RST generation rules given on page 37 of RFC 793 appear to indicate that the reception of any segment with an incorrect precedence field terminates a connection If this

is true regardless of the correctness of the sequence numbers in the segment's header, then the RFC 793 rules present a serious denial-of-service threat, as all an attacker must do to terminate a connection is guess the port numbers and then send two segments with different precedence values; one of them is certain to terminate the connection Accordingly, the change to TCP processing proposed in this memo would yield a significant gain in terms of TCP resilience On the other hand, the stricter processing rules of RFC 793 in principle make TCP spoofing attacks more difficult, as the attacker must not only guess the victim TCP's initial sequence number, but also its precedence setting

3.4 Conclusion

In this chapter, we propose a framework for providing differentiated services in IP-based networks Three classes of services are provided, i.e., premium service, assured service and best effort service In this approach,

1 Customers negotiate SLAs with ISPs The SLAs specify what services the customers will receive SLAs can be static or dynamic For static SLAs, customers can transmit data at any time For dynamic SLAs, customers must request for the desired service before transmitting data

2 With service allocation, a customer domain decides how its hosts and applications share the services specified by the SLAs With resource provisioning, an ISP domain decides how its routers should be configured so that the contracted services can be delivered

3 Packets are classified and have their DSCPs set at the edge of a network Subsequent forwarding treatment is solely based on the DSCPs of the packets In order to deliver premium service and assured service, the following mechanisms are needed in ISP networks:

 At the ingress routers: classification, policing, marking and shaping;

 At all routers: BA classifications, RED/RIO and WFQ scheduling for the PQ, AQ and DQ

One of the most important tasks in providing Diffserv is to set the output rate and size for the queues Although the amount of ingress traffic in each class is known at the network edge, the distribution of the traffic in the network is generally unknown, unless some kinds

of statistics are available Besides, the traffic distribution can vary over time

Therefore, it is difficult to set the output rate for the queues, especially at the core In this dissertation, we propose that the output rate of the queues are set according to measured statistics, and updated periodically From the output rate, the input rate, and the desired queueing delay of the packets in each queue, the queue size can then be derived It is not advisable to set the service rate of a high priority queue much higher than its input rate, because this can introduce burst of high priority traffic for the downstream router

Another important task of providing Diffserv is to avoid hot spots of high priority traffic Since Diffserv has to provide preferable treatment for high priority traffic at the expense of low priority traffic during traffic congestion, the service quality of high priority traffic may

be affected if there is a hot spot of high priority traffic Diffserv does not provide sufficient mechanisms to avoid hot spots Therefore, traffic engineering is necessary for providing QoS in the Internet

Diffserv has a conflict with TCP on the use of the precedence field in the IP header Because Diffserv-capable routers may change the precedence fields of packets en route, TCP connections can be reset undesirably for TCP stacks that strictly implement RFC793

We describe the problem and propose a solution to resolve this conflict The solution is to modify TCP to ignore the checking of the precedence field

Chapter 4 TRAFFIC ENGINEERING AND

FAST REROUTE

This chapter discusses traffic engineering and fast reroute.

Traffic engineering is an iterative process of network planning and network optimization [8] The purpose of traffic engineering is to optimize resource efficiency and network performance Traffic engineering is important for providing QoS in the Internet because, Diffserv essentially provides differentiated performance degradation for different classes of traffic during network congestion When there is no congestion, network performance will

be good even without Diffserv This means that traffic engineering is very useful for providing QoS Traffic engineering is also needed to prevent concentration of high priority traffic If there is concentration of high priority traffic, when there is network congestion, Diffserv cannot provide high priority traffic graceful performance degradation (or no degradation) at the expense of low priority traffic Therefore, the contracted quality of high priority traffic may be violated [5]

Constraint-based routing, multi-protocol label switching (MPLS), an enhanced link state

IGP and a path signaling protocol are useful tools for traffic engineering [63] Fast reroute

is to temporarily repair an affected path so that it can continue to carry traffic before a more optimal path is computed and used to carry traffic Fast reroute is important for providing

QoS because, when a router or a link fails, it takes interior gateway protocols (IGPs) from

seconds to minutes to propagate information and re-compute paths During this time interval, traffic sent along an affected path will experience high latency because of buffering, or will be lost Higher link speed means more lost traffic Therefore, it is important that the affected path is temporarily repaired and used to carry traffic before a more optimal path is computed [51][52][53] This is especially important for providing QoS for real-time and other high priority traffic In this chapter, we first briefly review MPLS, constraint-based routing and enhanced link state IGPs to provide a background for traffic engineering We then discuss the general issues of designing an MPLS system for traffic engineering The design of GlobalCenter’s MPLS system is presented and its performance is evaluated Based on the experiences, a generic procedure for deploying MPLS system is proposed [9] We then discuss the importance of network planning [10]

and multi-protocol lambda switching (MPLmS) [16] The inter-domain issues of traffic

engineering are discussed, and an approach for systematic inter-domain traffic engineering

is described

Besides traffic engineering, an approach for providing fast reroute for high riority traffic is briefly discussed And an MPLS-based service architecture for roviding Diffserv is described

4.1 Introduction

Traffic engineering is an iterative process of network planning and network optimization o

as to optimize resource efficiency and network performance Network planning is to mprove the architecture (topology and link capacity) of a network in a systematic way so hat the network is robust, adaptive and easy to operate Network optimization is to control the mapping and distribution of traffic over the existing network infrastructure to void and/or relieve congestion, to assure satisfactory service delivery, and to optimize resource efficiency In the first four sections of this chapter, we focus on network optimization Network planning is discussed in Section 4.4

Network optimization is needed because, no matter how well a network is designed, random incidents such as fiber cuts or changes in traffic demand will occur When they occur, they can cause congestion and other problems to manifest in an operational network This is aggravated by the fact that current IGPs always use the shortest paths to forward traffic Using shortest paths conserves network resources, but it may also cause the following problems

1 If traffic from a source to a destination exceeds the capacity of the shortest path, the shortest path will become congested while a longer path between these two nodes is under-utilized;

2 At a link that multiple shortest paths from different sources overlap, if the total traffic from different sources exceeds the capacity of the link, congestion will occur.Such problems occur because traffic demand changes over time but network topology cannot be changed as rapidly, causing the network architecture to become sub-optimal over time

Traffic engineering is difficult to do with IGP in large networks because:

1 Among the equal-cost multi-paths (ECMPs) [81] from a source, every path will

have an equal share of load This equal ratio cannot be changed Therefore, one of the paths may end up carrying significantly more traffic than other paths because it also carries traffic from other sources

2 Load sharing cannot be done among multiple paths of different cost.

3 Modifying IGP metric to trigger some traffic shift tends to have side effects, and undesirable traffic shifts may also be triggered In order to do traffic engineering

effectively, the Internet engineering task force (IETF) introduces MPLS,

constraint-based routing and enhanced link state IGPs They are briefly reviewed in this section

4.1.1 MPLS

MPLS is an advanced forwarding scheme It extends routing with respect to packet forwarding and path controlling [11] Each MPLS packet has a header In a non-ATM

environment, the header contains a 20-bit label, a 3-bit experimental field (formerly known

as class of service, or CoS, field), a 1-bit label stack indicator and an 8-bit TTL field In an

ATM environment, the header contains only a label encoded in the VCI/VPI field An

MPLS capable router, termed label switching router (LSR), examines the label and

possibly the experimental field in forwarding the packet

Figure 4-1 MPLS

At the ingress LSRs of an MPLS-capable domain IP packets are classified and routed based

on a combination of the information carried in the IP header of the packets and the local routing information maintained by the LSRs An MPLS header is then inserted for each packet Within an MPLS-capable domain, each LSR will use the label as the index to look

up the forwarding table of the LSR The packet is processed as specified by the forwarding table entry The incoming label is replaced by the outgoing label and the packet is switched

to the next LSR This label-switching process is very similar to ATM's VCI/VPI processing Before a packet leaves a MPLS domain, its MPLS header is removed This whole process is showed in Fig 4-1 The paths between the ingress LSRs and the egress

LSRs are called label switched paths (LSPs) MPLS uses some signaling protocol like

RSVP [65][66], LDP [66] or CR-LDP [68] to set up LSPs

In order to control the path of LSPs effectively, each LSP can be assigned one or more attributes These attributes will be considered in computing the path for the LSP [63] The attributes are summarized in Table 4.1.

4.1.2 Constraint-based routing

Constraint-based routing computes routes that are subject to constraints such as bandwidth and administrative policy Because constraint-based routing considers more than network topology in computing routes, it may find a longer but lightly loaded path better than the heavily loaded shortest path Network traffic is hence distributed more evenly [83]

For example in Fig 4-2, the shortest path between router A and router C is through link

A-C with IGP metric m=1 But because the reservable bandwidth on the shortest path is only (622-600)=22 Mbps (see the figure), when constraint-based routing tries to find a path for

an LSP of 40 Mbps, it will select path A-B-C instead, because the shortest path does not meet the bandwidth constraint

Figure 4-2 Constraint-Based Routing

It should be noted that the reservable bandwidth of a link is equal to the maximum reservable bandwidth set by network administrators minus the total bandwidth reserved by LSPs traversing the link It does not depend on the actual amount of available bandwidth on that link For example, if the maximum reservable bandwidth of a link is 155 Mbps, and the total bandwidth reserved by LSPs is 100 Mbps, then the reservable bandwidth of the link is

55 Mbps, regardless of whether the link is actually carrying 100 Mbps of traffic or more or

less In other words, constraint-based routing does not compute LSP paths based on instantaneous residual bandwidth of links This reduces the probability of routing instability [5][83].

Constraint-based routing can be online or offline With online constraint-based routing, routers may compute paths for LSPs at any time With offline constraint-based routing, an offline server computes paths for LSPs periodically (hourly/daily) LSPs are then configured to take the computed paths

4.1.3 Enhanced link state IGPs

In order for constraint-based routing to compute LSP paths subject to constraints, an enhanced link state IGP must be used to propagate link attributes in addition to normal link state information [69][71] Common link attributes include:

1 reservable bandwidth, and

2 link affinity (color), that is, an administratively specified property of the link Enhanced link state IGPs will flood information more frequently than normal IGP This is because, even without topology changes and hence no normal IGP flooding, changes in reservable bandwidth or link color can trigger the enhanced IGP to flood information Therefore, a tradeoff must be made between the need for accurate information and the need for avoiding excessive flooding Change in reservable bandwidth is flooded only when it is significant And a timer should be used to set

an upper bound on flooding frequency When the enhanced IGP builds LSR's forwarding table, it will take into account

LSPs originated by the LSR, so that the LSPs can actually be used to carry traffic One of such approaches is described in [72] In a network with MPLS, constraint-based routing enhanced IGP and a path signaling protocol, the process of forwarding table construction is showed in Fig 4-3

Figure 4-3 Forwarding Table Construction

4.1.4 Summary

With MPLS, constraint-based routing and an enhanced link state IGP, traffic engineering can be done much more effectively The two problems discussed in the introduction can be solved

First, by setting the maximum reservable bandwidth of each link (e.g., to the physical bandwidth of the link), and by setting the bandwidth requirement for each LSP, constraint-based routing will automatically avoid placing too many LSPs on any link This solves the first problem For example in Fig 4-4, constraint-based routing will automatically place LSP B->E on a longer path to avoid congestion in link C->E Every link in the figure is an OC3 link with 155 Mbps of bandwidth and has IGP metric 2

Figure 4-4 Congestion AvoidanceSecond, if traffic from router C1 to router B1 exceeds the capacity of any single path from C1 to B1 (Fig 4-5), then multiple LSPs can be configured from C1 to B1, and load splitting ratio of these two LSPs can be specified as desired, so that load can be distributed optimally This solves the second problem For example in Fig 4-5, if the total traffic from router C1 to router B1 is 160 Mbps, and the traffic from C2 to B1 is 90 Mbps, then two LSPs can be configured from C1 to B1 Their load ratio is automatically derived from their bandwidth specification Here we clearly see that with MPLS, constraint-based routing, and enhanced IGP, not only can load sharing be done among multiple paths of different cost, but also load splitting ratio can be specified as desired With IGP shortest path routing and equal-cost multi-paths (ECMPs), the problem described in the example cannot be solved.

Figure 4-5 Load Sharing

In addition to the advantages mentioned above, MPLS also provides the followings:

1 Explicit routes (ERs) can be specified for LSPs Network administrators can use ERs to control traffic trajectory precisely

2 Per-LSP statistics can provide accurate end-to-end traffic matrix

3 Backup LSPs can be used to provide graceful degradation in the case of router or link failure

In particular, end-to-end traffic matrix makes network planning possible in an IP network without a dedicated connection-oriented network layer such as ATM or frame relay

4.2 Design of A National MPLS System

In this section, the generic design issues of an MPLS system are discussed, and the design

of GlobalCenter’s MPLS system is presented

4.2.1 Generic issues of designing an MPLS system for traffic

engineering

To build an MPLS system for traffic engineering, the following design parameters must be determined:

1 the geographical scope of the MPLS system;

2 the participating routers;