GIÁM SÁT LƯU LƯỢNG 1. Khái niệm về giám sát và nắn dang lưu lượng: - Cả hai chức năng giám sát và nắn dạng lưu lượng đểu đo tốc độ truyền hoặc nhận dữ liệu. Giám sát loại bỏ gói dư thừa để đảm bảo tốc độ truyền không vượt quá tốc độ thoả thuận. Nắn dạng xếp các gói dư thừa này vào hàng đợi, và rồi đi ra khỏi hàng đợi ở tốc độ nắn dạng. Trường hợp còn lại thì cả giám sát và nắn dạng đều ngăn lưu lượng không được vượt quá tốc độ bit được định nghĩa bởi người thực hiện giám sát/nắn dạng. - Một lý do cổ điển để lựa chọn nắn dạng là khi thiết bị ở đầu kia của đường truyền đang thực hiện giám sát. Ví dụ: giả sử R1 thuộc một doanh nghiệp và R2 thuộc ISP. R1 gửi gói tới R2 và R2 thực hiện giám sát lưu lượng, loại bỏ những lưu lượng vượt quá tốc độ xbps. ISP có thể lựa chọn giám sát tại R2 để bảo vệ mạng tránh khỏi việc chấp nhận quá nhiều lưu lượng. R1 có thể được cấu hình đề nắn dạng lưu lượng gửi tới R2 sao cho lưu lượng này ở tốc độ bằng với tốc độ ở phía giám sát ở R2, thay vì để dữ liệu thừa bị R2 loại bỏ. 2. Giám sát lưu lượng: 2.1 Vi trí và thời điểm thực hiện giám sát lưu lượng: - Bất kể khi nào tốc độ xung vật lý vượt quá hợp đồng lưu lượng thì có thể cần đến giám sát. Ví dụ: giả sử ISP1 có 1000 khách hàng, như PB Tents. Mỗi khách hàng có một kết nối 100-Mbps và một hợp đồng hỗ trợ 2Mbps. Theo thời gian điều gì sẽ xảy ra? Nếu không có phương pháp nào ngăn chặn thì mỗi khách hàng sẽ gửi và nhận ngày càng nhiều lưu lượng. Các hàng đợi sẽ bị nghẽn thường xuyên, gây ra mất gói. Các lưu lượng đa phương tiên trở nên kém chất lượng do độ trễ và độ dao động cao. Các kết nối TCP liên tục giảm cửa số truyền do mất gói, gây ảnh hưởng đến đồng bộ bên trong ISP1. ISP1 có thể thêm dung lượng, nhưng điều đó có nghĩa là ISP1 bắt đầu tính cước tăng lên cho khách hàng của họ, và những người này có thể không vui lòng nâng cấp hợp đồng lưu lượng. - Trong các mạng ISP thực tế, các kỹ sư mạng thiết kế lõi mạng hy vọng một mức độ “oversubscription” nào đó, nghĩa là khách hàng gửi và nhận nhiều lưu lượng hơn thỏa thuận hay đăng ký. - Giám sát bảo vệ mạng không bị tràn lưu lượng. Nếu ISP1 chỉ giám sát lưu lượng từ mỗi khách hàng, loại bỏ gói vượt quá hợp đồng lưu lượng thì ISP1 đã tự bảo vệ chính nó không bị tràn lưu lượng. Tuy nhiên, việc quyết định thêm chức năng giám sát vào mạng có thể khá khó khăn. Ví dụ như đối với trường hợp ISP1 có 1000 khách hàng, mỗi khách hàng hợp đồng 2Mbps lưu lượng. Mỗi khách hàng gửi và nhận trung bình 10 Mbps, vì vậy mạng của ISP1 sẽ bị nghẽn. ISP1 lựa chọn thực hiện giám sát, sử dụng tốc độ thỏa thuận theo hợp đồng, loại bỏ các gói vượt 2Mbps. Và dĩ nhiên hầu hết các khách hàng sẽ không cảm thẩy hài lòng. - Giám sát cũng chỉ có thể đánh dấu lưu lượng thay vì loại bỏ. Để thực hiện điều này, các bộ giám sát đánh dấu thấp hơn các gói với trường ưu tiên IP hay DSCP khác nhau khi lưu lượng vượt quá tốc độ cho phép nhưng nó vẫn cho các gói đi qua. Các chức năng QoS sau này, bao gồm giám sát và các công cụ loại bỏ gói như WRED có thể loại bỏ những gói bị đánh dấu thấp xuống nhiều hơn so với những gói không được đánh dấu thấp xuống. Nói chung, khi giám sát đánh dấu gói xuống thấp hơn thì khi mạng không bị nghẽn các gói có thể đi qua mạng, còn ngược lại, khi mạng bị nghẽn các gói đó có thể bị loại bỏ trước. - Tóm lại,ISP thực hiện việc chọn lựa vị trí thương mại để giám sát.và làm cách nào để giám sát một cách linh hoạt. ISP đưa ra các tuỳ chọn để thực hiện việc việc giám sát: • Không giám sát. Để hỗ trợ các loại lưu lượng của khác hàng mà việc truyền và nhận dữ liệu theo tốc độ đường truyền truy cập. Từ quan điểm kinh doanh, các yêu cầu thoả thuận ở mức cao không thực hiện việc giám sát, nhưng khuyến khích khách hàng mở rộng hợp đồng để dành thêm băng thông. • Giám sát ở tốc độ thỏa thuận. Để hỗ trợ các mức lưu lượng này thì mạng chỉ cần được xây dụng để hỗ trợ tốc độ thỏa thuận, mặc dù mạng lõi xây quá lớn để hỗ trợ những khách hàng mới. Từ quan điểm kinh doanh, khuyến khích khách hàng bắt đầu truyền lưu lượng ở tốc độ vượt quá thỏa thuận nâng cấp hợp đồng. • Giám sát tại vị trí giữa tốc độ thỏa thuận và tốc độ đường truyền. 2.2 Hoạt động giám sát: - Nguyên tắc xử lý bên trong của IOS khi thực hiện CAR hơi khác so với trật tự dùng khi thực hiện giám sát theo lớp (CB). Bất kể quá trính xử lý bên trong, mỗi công cụ giám sát muốn phân loại gói liên quan đến việc nó có trong hợp đồng lưu lượng hay không. - Dựa theo sự phân loại đó, gói có thể được phép đi qua, bị loại bỏ hay được đánh dấu lại giá trị ưu tiên IP khác hay giá trị IP DSCP (mã điểm dịch vụ sai biệt). - Các mô hình đơn hay hai token-bucket được sử dụng để đánh giá đầy đủ xử lý bên trong của bộ giám sát. Kỹ thuật token-bucket được dùng để mô tả các khái niệm. Khi không cấu hình Be thì một bucket được sử dụng, dại diện cho Bc và khi Be được sử dụng thì bucket thứ hai được sử dụng, đại diện cho Be. 2.2.1 Giám sát dựa vào tốc độ truy cập thoả thuận nội bộ( Committed Access Rate Internal ): - CAR quyết định gói có tuân theo hay vượt quá hợp đồng lưu lượng. Sau đó, CAR thực hiện hành động trên gói dựa theo cấu hình (cho qua, hủy hay đánh dấu lại gói tuân thủ và không tuân thủ). - CAR sử dụng một hay hai token bucket để quyết định xem mỗi gói có tuân thủ hợp đồng lưu lượng hay không. CAR làm đầy các thùng bằng các token, mỗi token đại diện cho quyền được truyền hay nhận một byte. Khi một gói được giám sát, CAR kiểm tra các thùng để quyết định có đủ token để xem xét gói khi tuân thủ hay không. - Giám sát CAR và CB hơi khác nhau khi có xác định Be và khi không có. Phần sau đây giải thích CAR hoạt đ ộng như thế nào nếu không có Be và khi có Be. CAR không có Be - Trong thảo luận này, một thùng được gọi là bucket1 và một thùng là bucket2. Bucket1 bắt đầu với Bc token trong đó, và Bucket2 bắt đầu với Be token. Chỉ Bucket1 được sử dụng khi Be-0, nhưng cả Bucket1 và Bucket2 được sử dụng khi Be lớn hơn 0. Trong vài giải thích trước đây, bạn có thể thấy Bucket1 như Bc bucket hay chỉ là Bc. Tuy nhiên, do Bc là giá trị được cấu hình tĩnh và số token trong bucket thay đổi nên tài liệu này xem bucket như là bucket1 và Bucket2. - Đầu tiên, CAR làm đầy Bucket1 với Bc token. Mỗi token đại diện một byte và Bc được cấu hình bằng byte. Khi thời gian trôi qua, CAR lại đầy lại Bucket1 ở những khoảng cách đều đặn, sử dụng một giá trị Tc được tính cùng công thức với nắn dạng. Cấu hình thiết lập tốc độ giám sát và giá trị Bc, CAR tính toán Tc dựa trên công thức sau đây: Tc=Bc/tốc độ giám sát - CAR làm đầy lại Bucket1 sau thời gian Tc bằng cách thêm Bc token vào thùng. Do Bucket1 có dung lượng tối đa gồm Bc token và CAR làm đầy lại Bc token sau mỗi Tc nên CAR làm đầy lại Bucket1 một cách hiệu quả sau mỗi thời gian Tc. - CAR phân loại mỗi gói là tuân thủ hay vượt quá hợp đồng lưu lượng khi nó đến bộ giám sát. CAR so sánh số byte trong gói với số token trong Bucket1. ( Be=0, bộ giám sát không xem xét đến Bucket2 trong trường hợp này). Quyết định của CAR rất đơn giản: • Nếu số byte trong gói nhỏ hơn hoặc bằng số token trong Bucket1 thì gói tuân thủ hợp đồng. CAR xóa token ra khỏi Bucket1 bằng số byte trong gói và thực hiện hành động cho các gói tuân thủ hợp đồng. • Nếu số byte trong gói lớn hơn số token trong Bucket1 thì gói vi phạm hợp đồng. CAR không xoá token ra khỏi Bucket1 và thực hiện hành động cho gói vi phạm hợp đồng. - Vì vậy nếu không cấu hình Be thì nguyên tắc CAR khá đơn giản. Tất cả các gói được giám sát trong một khoảng Tc tuân thủ miễn là những gói có số byte tích luỹ không vượt quá Bc. Nếu cần truyền hơn Bc byte thì CAR quyết định những gói đó vi phạm hợp đồng. CAR có cấu hình Be: - CAR sử dụng một thuật toán khá phức tạp để xác định gói tuân thủ hay vi phạm hợp đồng lưu lượng. Thuật toán phức tạp hơn này có một mục đích đơn giản là làm dịu đi ảnh hưởng khi bộ giám sát loại bỏ gói. Thuật toán của CAR nhận ra khi nào các byte thừa được định nghĩa bởi Be đang được sử dụng và phân loại một số gói là vượt quá hợp đồng lưu lượng và tuân thủ hợp đồng lưu lượng trước khi toàn bộ Be được tiêu thụ hết. Bằng cách hủy vài gói trước khi tất cả Be được dùng hết thì bên gửi có thể giảm tốc độ truyền gói, dẫn đến giảm nghẽn và tránh trường hợp trong đó tất cả gói vượt tốc độ giám sát. - Để hiểu hoạt động CAR thì phải hiểu các thùng được làm đầy và cạn như thế nào. Ban đầu, CAR làm đầy Bucket1 bằng Bc token và Bucket2 băng Be token. Mỗi token đại diện cho một byte và Bc, Be được cấu hình bằng byte. - CAR làm đầy lại Bucket1 sau mỗi Tc bằng cách thêm Bc token vào thùng nhưng CAR không trực tiếp làm đầy lại Bucket2. Khi CAR thêm Bc token vào Bucket1mà nếu các token bị tràn thì sẽ dùng để làm đầy Bucket2. Nếu Bc=10,000 và Bucket1 có 2000 token sẵn trong đó khi CAR làm đầy lại Bucket1 thì 2000 token tràn sang Bucket2. Bucket1 có dung lượng tối đa là Bc token. Điều này có ý nghĩa là Bucket1 sẽ đầy lại (Bc) sau mỗi Tc. Bucket2 có dung lượng tối đa là Be token, nhưng nó có thể không đầy (Be) sau mỗi Tc. Điều đó còn phụ thuộc vào việc có bao nhiêu token tràn ra khỏi Bucket1 khi nó được làm đầy lại. Hình 5-1 mô tả lại quá trình. - Khi Bc và Be được cấu hình, CAR sử dụng hai thùng token, và thuật toán CAR trở nên phức tạp hơn. • Nếu số byte trong gói nhỏ hơn hoặc bằng số token trong Bucket1 thì gói này tuân thủ hợp đồng lưu lượng. CAR sẽ xóa các token ra khỏi Bucket1 bằng với số byte trong gói và thực hiện hành động cho các gói tuân thủ hợp đồng. • Nếu số byte trong gói lớn hơn số token trong Bucket1 thì CAR sử dụng tính toán “nợ” để quyết định gói tuân thủ hay không. CAR xóa các token ra khỏi Bucket2 với số lượng bằng số byte trong gói nếu gói tuân thủ theo quy luật sau: - Chú ý trong phần 2 của thuật toán, CAR sử dụng khái niệm “nợ”. Nghĩa là nếu kích thước của gói mới lớn hơn số token trong Bucket1, CAR có thể mượn từ Bucket2. CAR cần làm đầy lại hay trả lại những token đó sau một khoảng thời gian khi Bc không được sử dụng hoàn toàn. - Khái niệm “nợ thật” (Da) định nghĩa khái niệm rõ ràng nhất liên quan đến tính toán nợ. Tưởng tượng là Bucket1 giảm xuống 0 token và Bucket2 có 10,000 token trong đó. Một gói mới kích thước 1000 byte đến và cần được giám sát. CAR so sánh chiều dài gói với Bucket1 và quyết định rằng Bucket1 không có đủ token. Lúc đó, CAR nhìn vào Bucket2 có số token (10,000) nhiều hơn kích thước gói (1000). Vì vậy, CAR xem gói này là tuân thủ hợp đồng và nó giảm Bucket2 xuống 9000. CAR cũng coi Da là 1000-số token thực sự được mượn từ Be hay Bucket2. Những gói này cũng tuân thủ và CAR giảm Bucket2 xuống 8000 token sau khi gói thứ hai được truyền và xuống 7000 khi gói thứ 3 được truyền. Tương tự, Da tăng lên 2000 rồi đến 3000. - Dc là thành phần chính khác của thuật toán. Nợ ghép (Dc) là một biến cũng được CAR tính khi Be đang được sử dụng. Mỗi lần Da tăng lên thì Dc cũng tăng lên. Tuy nhiên, Dc tăng nhanh hơn Da do công thức dùng để tính Dc là Dc=Dc cũ + Da mới. Bảng V-1 liệt kê ba gói giống nhau mô tả trong phần giải thích Da, thêm hai gói 1000 byte nữa và các giá trị Da và Dc được tính toán. Trong trường hợp này, Be được thiết lập là 8000 byte. Hãy nhớ rằng việc tính toán Dc không bắt đầu cho đến khi Bc (Bucket1) được tiêu thụ trong một khoảng nào đó. - Dc tăng lên cho đến khi nó vượt quá Be. Khi Dc được tính và kết quả lớn hơn Be thì CAR xem gói không tuân thủ hợp đồng lưu lượng. Lúc này, CAR reset Dc về 0. Chú ý là gói 1000 byte thứ tư làm cho giá trị Dc vượt quá Be vì vậy, gói được xem như không tuân thủ hợp đồng lưu lượng và giá trị Dc được giảm về 0. - Nguyên tắc đầy đủ để xác định mỗi gói có tuân thủ hợp đồng hay không như sau: 1. Nếu số byte trong gói nhỏ hơn hay bằng số token trong Bucket1 thì gói tuân thủ hợp đồng lưu lượng. CAR xóa token ra khỏi Bucket1 một lượng bằng số byte trong gói và thực hiện hoạt động cho những gói tuân thủ hợp đồng. 2. Nếu số byte trong gói lớn hơn số token trong Bucket1 thì số byte trong gói nhỏ hơn hay bằng số token trong Bucket2, sử dụng công thức tính nợ sau: a. Nếu Dc nhỏ hơn hay bằng Be thì gói tuân thủ theo hợp đồng. CAR xóa các token ra khỏi Bucket2 bằng số byte trong gói và thực hiện hoạt động cho các gói tuân thủ hợp đồng. b. Nếu Dc lớn hơn Be thì gói không tuân thủ hợp đồng. CAR không xóa token ra khỏi một trong hai thùng và thực hiện hành động cho những gói vượt quá hợp đồng. CAR cũng reset Dc về 0. 3. Nếu số byte trong gói lớn hơn số token trong Bucket1 hay Bucket2 thì gói vượt quá hợp đồng. CAR không xóa token ra khỏi một trong hai thùng và thực hiện hoạt động cho các gói vượt quá hợp đồng. - Trong suốt khoảng thời gian nào đó miễn là có nhiều gói trong Bucket1 thì các gói tuân thủ (bước 1). Nếu không có đủ token trong Bucket1 hay Bucket2 thì gói vượt quá hợp đồng lưu lượng. Tuy nhiên, ở bước 2 khi tiêu thụ các token của Bucket2 thì một vài gói có thể vi phạm hợp đồng và những gói còn lại sẽ tuân thủ hợp đồng. 2.2.2 Giám sát dựa vào CB policing internal: - CB poliching internal hoạt động như CAR trước IOS 12.1(5)T, nhưng với IOS 12.1(5)T, nguyên tắc cơ bản thay đổi. CB policing không có Be: - Giám sát CB cũng sử dụng thùng token. Bucket1 là thùng token duy nhất được dùng khi Be=0; Bucket1 giữ các token dựa theo bùng nổ cam kết được cấu hình. Bucket2 được dùng khi Be lớn hơn 0, giữ các token Be. - Mỗi lần một gói được giám sát, giám sát CB đặt vài token vào Bucket1. Số token đặt trong Bucket1 được tính như sau: (Thời điểm đến của gói hiện tại - Thời điểm đến của gói trước đó)*Tốc độ giám sát/8 - Một số token được làm đầy lại trước khi một gói được giám sát, với kết quả cuối cùng là làm đầy lại token ở tốc độ giám sát. Giả sử, tốc độ giám sát là 128,000 bps (bằng với 16,000 byte/s). Nếu 1 giây trôi qua kể từ khi gói cuối cùng đến thì giám sát CB sẽ làm đầy lại thùng bằng 16,000 token. Nếu 0.1s trôi qua kể từ khi gói cuối cùng đến thì nó sẽ làm đầy thùng lại với 0.1s token hay 1600 token. Nếu 0.01 s trôi qua, nó sẽ làm đầy lại 160 token ở thời điểm đó. Bucket1 được làm đầy lại một lượng token theo tỉ lệ dựa vào việc lần cuối nó được làm đầy cách đây bao lâu. - Giám sát CB (không có Be) hoạt động như CAR (không có Be) liên quan đến việc lựa chọn gói có tuân thủ hay không. Giám sát CB so sánh số byte trong gói với số gói trong Bucket1 (Nên nhớ là Be=0 nghĩa là Bucket2 không được sử dụng). Quyết định của giám sát CB thì đơn giản: • Nếu số byte trong gói nhỏ hơn hay bằng số token trong Bucket thì gói tuân thủ hợp đồng. Giám sát CB xóa các token ra khỏi Bucket1 bằng với số byte trong gói và thực hiện hoạt động cho những gói tuân thủ. • Nếu số byte trong gói lớn hơn số token trong gói trong Bucket1 thì gói vi phạm hợp đồng. Giám sát CB không xóa các token ra khỏi Bucket1 và thực hiện hành động cho các gói vi phạm hợp đồng. - Vì vậy, nguyên tắc khi không có Be sử dụng khá đơn giản. Bucket1 đầy lại với các token. Nếu gói tuân thủ, giám sát CB hoặc là chuyển tiếp, hủy hay đánh dấu lại gói và một số token sau đó được xóa khỏi Bucket1. Nếu gói vi phạm, giám sát CB hoặc chuyển tiếp, hủy bỏ hay đánh dấu lại gói nhưng không có token nào bị xóa khỏi Bucket1. Giám sát CB có Be: - Giám sát CB sử dụng thuật toán đơn giản hơn CAR khi giá trị Be đã được cấu hình. Giám sát CB phân loại gói thành ba nhóm: tuân thủ, vượt quá và vi phạm. Khi sử dụng ba loại này, một thuật toán rất đơn giản và hữu dụng được sử dụng. - Giám sát CB tiếp tục làm đầy Bucket1 khi một gói đến. Nếu Bucket1 đầy, thì những token dư ra làm đầy Bucket2. Nếu bucket2 đầy thì các token dư thừa sẻ bị đổ ra ngoài và trở nên lãng phí. Hình 5-2 trình bày quá trình cơ bản sau: - Khi có cấu hình Bc và Be, giám sát CB sử dụng hai token bucket và thuật toán khá đơn giản: 1. Nếu số byte trong gói nhỏ hơn hoặc bằng số token trong Bucket1 thì gói tuân thủ. Giám sát CB xóa các token ra khỏi Bucket1 số lượng bằng với số byte trong gói và thực hiện hành động cho các gói tuân thủ hợp đồng. 2. Nếu gói không tuân thủ và số byte trong gói nhỏ hơn hoặc bằng số token trong Bucket2 thì gói vượt quá hợp đồng lưu lượng. Giám sát CB xóa số token ra khỏi Bucket2 bằng với số byte trong gói và thực hiện hành động đối với gói vượt quá hợp đồng lưu lượng. 3. Nếu gói không tuân thủ cũng không vượt quá hợp đồng thì nó vi phạm hợp đồng. Giám sát CB không xóa các token ra khỏi thùng nào và thực hiện hoạt động đối với các gói vi phạm hợp đồng. Giám sát nhưng không loại bỏ : - Bộ nắn dạng xếp hàng các gói dư thừa và bộ giám sát loại bỏ các gói dư thừa. Tuy nhiên, bộ giám sát cho phép một loại thỏa hiệp trong đó các gói không bị loại bỏ nhưng chúng được đánh dấu để mà nếu sau này khi có nghẽn xảy ra thì gói này có thể sẽ bị loại bỏ trước. Xem xét hình 5-3 và chức năng giám sát trên R1. - Trong hình, hai gói đi trên tuyến được đánh dấu là đường chấm chấm. Mỗi gói được đánh dấu DSCP AF11 khi đi vào R1. Bộ giám sát của R1 quyết định gói1 tuân thủ nhưng gói2 vượt quá tốc độ nắn dạng. Bộ giám sát của R1 đánh dấu lại gói2 là AF13. DiffServ đề nghị rằng AF13 nên ở cùng lớp hàng đợi với AF11, nhưng khả năng bị hủy cao hơn so với AF11. Nếu không có nghẽn xảy ra thì cả hai gói đều đi qua mạng. Nếu xảy ra nghẽn thì gói 2 có khả năng bị loại bỏ cao hơn. - Giám sát bằng cách đánh dấu nhỏ hơn cho gói cung cấp một sự thỏa hiệp. ISP có thể bảo vệ mạng không bị quá tải do hủy gói quá nhiều khi có nghẽn. Có thể tăng sự thỏa mãn của khách hàng nhờ cho khách hàng tận dụng được dung lượng khi có sẵn. - Khái niệm thứ hai có thể được áp dụng trong mạng Frame Relay và ATM. Header của Frame Relay chứa bit DE (có khả năng hủy) và header ATM chứa bit CLP(ưu tiên mất cell). Mỗi bit này có thể được sử dụng để ám chỉ rằng frame hay cell có khả năng bị nghẽn hơn khi có nghẽn. . GIÁM SÁT LƯU LƯỢNG 1. Khái niệm về giám sát và nắn dang lưu lượng: - Cả hai chức năng giám sát và nắn dạng lưu lượng đểu đo tốc độ truyền hoặc nhận dữ liệu. Giám sát loại bỏ gói. nhận nhiều lưu lượng hơn thỏa thuận hay đăng ký. - Giám sát bảo vệ mạng không bị tràn lưu lượng. Nếu ISP1 chỉ giám sát lưu lượng từ mỗi khách hàng, loại bỏ gói vượt quá hợp đồng lưu lượng thì. giám sát ở R2, thay vì để dữ liệu thừa bị R2 loại bỏ. 2. Giám sát lưu lượng: 2.1 Vi trí và thời điểm thực hiện giám sát lưu lượng: - Bất kể khi nào tốc độ xung vật lý vượt quá hợp đồng lưu lượng