CIR và DE

[phieudu]

theo em hiểu CIR la` bandwidth mà nhà cung cấp dịch vụ phải đảm bảo cho mình ko được nhỏ hơn CIR mà chỉ có lớn hơn hoặc bằng, còn DE là nó sẽ đánh dấu khi mà lưu lượng đường truyền lớn hơn cái nhà cung cấp dịch vụ cấp cho bạn để khi mà xảy ra congestion nó sẽ được giảm xuống.Cách em hiểu thế có đúng ko.

[Present]

Về CIR thì đúng là bănng thôg mà nhà cung cấp dịch vụ phải đảm bảo đối với thuê bao đầu cuối.
Còn về bít DE thì: bít này được thiết bị phát sử dụng đề chỉ rõ khung đó được chọn để xoá khi mạng bị tắc nghẽn (tương đương việc giảm lưu lượng)
Còn việc giảm lưu lượng thực sự khi bị tắc nghẽn thì dựa trên bít FECN và BECN.

[LetItBe]

Cũng về chuyện Bit DE: mình và bạn cua mình có tranh cãi với nhau như sau:
Mình thì cho rằng biet DE do source bật lên khi gửi vì chỉ có source mới biết đ][cj gói tinm đó là quan trong hay không, để ưu tiên không bị xoá khi xảy ra tác nghẽn trên mạng.
Còn bạn của mình thi cho rằng: Bit DE là do FrSwitch bật lên.
Các bạn hãy giúp mình.

[1'hpSky]

Chào bạn LetItBe!
Công nghệ FR có khả năng điều khiển luồng rất hay, cho phép tận dụng băng thông rỗi của các kênh khác trên mạng. Và như thế có lúc tốc độ thực tế vượt qua tốc độ cam kết CIR.
Theo mình bạn là người đúng khi nói DE do source bật lên khi gửi dữ liệu. Nếu tắc nghẽn xảy ra thì những khung có bit DE được bật sẽ bị discard trước tiên.
"The DE bit is set on the oversubscribed traffic" Tạm dịch DE được đặt ở những frame vượt qua tốc độ cam kết . Thực sự source không biết gói tin nào là quan trọng hơn gói tin nào. FR hoạt động ở tầng 1, 2. Nó phải dựa vào tầng 4 để kiểm tra lỗi (TCP). nếu mất packet nào đó thì tầng 4 ở router đích sẽ phát hiện ra và yêu cầu source gửi lại.

[1''hpSky]

Công nghệ FR có khả năng điều khiển luồng rất hay, cho phép tận dụng băng thông rỗi của các kênh khác trên mạng. Và như thế có lúc tốc độ thực tế vượt qua tốc độ cam kết CIR.

Ồ, một phẩy Sky thiệt là đáng khen, đáng khen. Dưng cứ theo thiển ý của bần lão, thì điều này chỉ đúng mà không đủ!! Về bản chất, công nghệ FR là một biến thể của công nghệ HDLC, sử dụng LABF để truyền thông tin trong mạng WAN. HDLC được thiết kế rất tốt (dưng vẫn không có bằng được PPP). Lão nhớ không nhầm thì nó có cơ chế điều khiển luồng bằng Sliding-Window hoặc Xon-Xoff, điều khiển lỗi bằng ARQ, thêm vào các bít SN để đảm bảo tính tin cậy...

Và thực tế các tổ chức chuẩn cũng định nghĩa điều khiển luồng là: "controlling the rate of trasmission of characters or frames on a link so that the receiver always has sufficient buffer storage resource to accept them prior to process them",

...vậy chớ điều khiển luồng có thể khác với việc dồn kênh thống kê như 1 phẩy nêu ở trên đó.



Thực sự source không biết gói tin nào là quan trọng hơn gói tin nào...

Câu này cũng thiệt là đáng khen, đáng khen !!! nhưng mà cứ khen kiểu này thiệt là "xoa đầu trẻ"

Bần lão có một vài thiển nghĩ, mong bà con suy xét !!!

[halh]

ha_lh xin góp ý một vài điều:

Thứ nhất, việc điều khiển luồng của công nghệ FR được thừa hưởng các kỹ thuật có trong HDLC, nên có thể nói là khá hoàn hảo. Tuy nhiên, vấn đề này, đứng trên quan điểm triển khai thì không có gì để mà nói, còn đứng trên quan điểm kỹ thuật thực hiện, lại rất phức tạp dài dòng, nên có lẽ không nên bàn cãi nhau nhiều.

Thứ hai, 1'hpSky nói do có khả năng dồn kênh "thống kê" nên có thể tốc độ của thuê bao FR vượt quá CIR là không chính xác. Thực tế, khoa học lưu lượng chứng minh rằng thông tin người sử dụng thường xuất hiện dưới dạng "burst", hay theo nhóm, mà không liên tục hay cố định như trong một số ứng dụng truyền hình, thoại. Thông tin dạng burst sẽ tạo ra những thăng giáng trong base line của tốc độ truyền thông tin, dẫn đến có thể xảy ra trường hợp vượt quá Committed Infor Rate, mà FR chỉ là một ví dụ nhỏ.

Còn, 1''hpSky hơi quá khi cho rằng câu nói của 1'hpSky về vấn đề đặt bít DE. Thực ra, trên công nghệ FR, điều 1'hpSky nói là hoàn toàn đúng. Node nguồn không thể phân biệt được sự khác nhau về QoS hay quyền ưu tiên giữa các gói tin. Tuy nhiên, xét một các tổng quan, điều này có thể không chính xác bởi xu hướng sử dụng các kỹ thuật đảm bảo chất lượng dịch vụ trên mạng IP, mà mô hình MPLS/FR đang rất phổ biến trên thế giới. Chúng ta nên đặt công nghệ FR trong một bối cảnh sử dụng cụ thể nào đó. Chứ nếu xét riêng về nó, rất không chặt chẽ khi bàn luận về các đặc trưng mà nó có thể hỗ trợ. Điều này cũng là một trong các tiêu chí của mô hình tham chiếu OSI mà các công nghệ này sử dụng.

Thiển nghĩ,

[sinhvienngheo]

xin chào,

SVN rất vui vì chất lượng các bài trong box CCNA hiện nay còn cao hơn cả box CCIE. Đã lâu không quay lại box này, SVN thật sự là choáng ngợp bởi hàm lượng công nghệ trong các bài viết ở box CCNA.

Do SVN đã cấu hình FR và FRTS khoảng vài ngàn lần (;-)) nên SVN tạm post một đoạn config để set bit DE.

Bit DE được set bởi node nguồn giống như ý kiến của 1'hpsky. Khi một frame có bit DE bị set, frame này sẽ bị drop trước tiên nếu FR Switch bị nghẽn.

Đặc điểm này yêu cầu là mạng FR phải có khả năng dịch (interpret) được bit DE. Thực tế là một vài mạng không làm gì cả khi bit DE này được set.


Anh có thể định nghĩa de list để chi ra đặc điểm của packet mà packet đó là hợp lệ để discard. Anh cũng có thể chỉ ra dlci bị ảnh hưởng.

Dùng lệnh sau trong global config mode:

# frame-relay de-list list-number {protocol protocol | interface interface-type interface-number} characteristic

ta có thể định nghĩa DE list dựa trên: the protocol, the interface, and on characteristics such as fragmentation of the packet, a specific TCP or User Datagram Protocol (UDP) port, an access list number, or a packet size. Nói cách khác, có thể lọc ra bất kỳ traffic nào và set DE.


Apply trong interface mode bằng lệnh

frame-relay de-group group-number dlci

Vậy, DE được set trên node nguồn.

Còn về quan điểm của halh "Node nguồn không thể phân biệt được sự khác nhau về QoS hay quyền ưu tiên giữa các gói tin", mình nghĩ đó là sai. Nói cách khác, mình cùng quan điểm với 1''hpsky.

Có rất nhiều công cụ Q0S trên FR, ha-lh có chắc chắn rằng đã khảo sát hết các công nghệ trên chưa?

[1''hpSky]

Thực ra, 1''hp Sky đã check lại và cho rằng ha_lh rất đúng khi nói cần phải quan sát FR trong sự phối hợp với các công nghệ khác, như MPLS hay IP với DiffSev và InSev chẳng hạn. Lão nghĩ chẳng ai có thể đọc được hết công nghệ, và phần nhấn mạnh về FR của ha_lh (bold) có thể tham chiếu đến mạng FR ở thời điểm được đưa ra như một dịch vụ trên ISDN (có Frame Relay và Frame Switching).

QoS là một vấn đề phức tạp, rất phức tạp, khi mà môi trường mạng chuyển từ hỗ trợ các dịch vụ data thông thường sang multimedia (văn bản nhúng video, sound hay special image chẳng hạn). Bản thân FR, khi phát triển trên nền HDLC nhằm khắc phục các nhược điểm của X25, không đề cập nhiều đến vấn đề đó, có chăng chỉ được phát triển sau này, cùng với sự thống nhất và cho ra đời một số giao thức trong LMI nhằm mở rộng công nghệ FR.

1''hpSky đồng ý quan điểm về việc thực hiện QoS trong FR phải gắn liền với một số công nghệ khác. Lão không cẩn thận khi post bài, bà con xá tội :((

Không biết sinhvienngheo có thể nói một chút về QoS trong FR được không??

Lão xin đa tạ !!!

[cubithongminh]

Có thể nói rằng dịch vụ Frame Relay có ưu điểm là có thể truyền tại một thời điểm với tốc độ cao hơn so với CIR mà doanh nghiệp mua ban đầu (phần Be).
Dịch vụ FR của VDC không nêu rõ trong trường hợp vượt quá thì tính tiền như thế nào. Có bạn nào biêt các nhà ISP trên thế giới tính tiến phần Be này như thế nào không? Và có thể cấu hình cho Be mỗi tháng không vượt quá bao nhiêu đó được không?

[trung tam kn]

thông thường các nhà cung cấp dịch vụ không tính tiền phần vượt qúa be này.

Về phần cấu hình be, theo mình chỉ có thể cấu hình trong các tổng đài frame-relay thôi. Chứ các thuê bao framerelay sẽ không đủ để thực hiện tính năng này.

[cubithongminh]

uh. Mình cũng đã xem trên website của AT&T. Dịch vụ FR của họ cũng kô tính tiền thêm phần Be. Họ cũng tính y như VDC nhà minh.
Mình đã có dịp học và cấu hình cái IGX để tạo nên 1 mạng FR.
Khi thiết lập 1 PVC, ngòai CỈ ra còn có 1 thông số quan trong khác là Utilization. Ví dụ khi tốc độ của đường truyền là 64kbps. Nếu đặt CIR=64; Utilization=40% thì có thể đặt được 2 PVC trên 1 đường vật lý đo. Nhưng nếu đặt Utilization=80% thì chỉ đặt được 1 PVC. Set Utilization=100% trong khi CIR=64kpbs kô đươc.
Ông thầy giải thích rằng Utilization là 1 thông số tương tự như policy. Nếu đờớng thuyền bị nghẽ thì PVC nào có Utilization thấp sẽ bị rớt gói nhiêu. Nhưng mình vẫn còn lờ mờ chưa rõ lắm.

[robedan]

trong tình huống này, thông số utilization nhất định không liên quan gì đến các thông số traffic-shaping của frame-relay ở cấp người dùng cuối.

chào thân ái,

[sskkb]

Nếu nhà cung cấp đánh dấu tất cả những gói tin nào vượt quá 32kbps là DE thì như vậy giá trị Cir sẽ là 32000 phải ko?
Hay là giá trị Bc sẽ là 32000???

[robedan]

chào sskkb

CIR: tốc độ trung bình nhà cung cấp dịch vụ cam kết.
Bc: lượng dữ liệu truyền trong một chu kỳ
Be: lượng dữ liệu bùng nổ trong 1 giây.

Thông thường Bc=CIR/8

FR cho phép thuê bao truyền qua khỏi mức CIR một lượng là Be. Quá khỏi mức CIR+Be, một số frame hợp lệ sẽ bị DISCARD.

Trong ví dụ của sskkb, con số 32000 có nghĩa là CIR+Be. Nếu Be=0, CIR mới bằng 32000.

Thân

[sskkb]

Thanks robedan, như vậy trong trường hợp này, nếu chỉ được cấu hình giá trị Bc, chúng ta sẽ cấu hình Bc = 4000 phải không?

[robedan]

chào sskkb,

Giá trị Bc=4000.

bạn sskkb lưu ý:
Nếu đây là một tình huống thi CCIE Lab thật sự, bạn nên cầm câu hỏi này lên hỏi proctor nhé. Neu bạn hỏi khéo léo, proctor sẽ confirm cho bạn

ASK the proctor, DONT assume ANYTHING.

[kimlong]

Nếu lượng thông tin được lên kế hoạch một cách chính xác và nhà cung cấp dịch vụ có hỗ trợ tính năng này ( dĩ nhiên là có thêm phí) thì áp dụng CiR có thể điều chỉnh là rất hiệu quả . Tính năng này còn được biết đến với thuật ngữ băng thông theo yêu cầu . Những thông số liên quan đến tính năng này là :

"EIR:

là một thông số được đo bằng bps hoặc kbps , thông số này xác định số bits được truyền đi trong một giây trong khoảng thời gian Tc.
"Offered Lord : là lượng dữ liệu được đo bằng bit mà người dùng yêu cầu gửi đến một địa chỉ đã chọn trước ( DLCI) .
" Explicit congestion notificatiion: thuật ngữ này chỉ đến một tiến trình cảnh báo cho người sử dụng biết về tình trạng tắc nghẽn mạng . Có ba trạng thái về tình trạng là : Bình thường , tắc nghẽn ở mức trung bình , tắc nghẽn trầm trọng .
" Implicit congestion notification : thuật ngữ này chỉ đến vai trò của những giao thức ở lớp cao trong mạng Frame Relay , ở đó lỗi và hoạt động kiểm soát dòng dữ liệu phụ thuộc vào điều kiện tắc nghẽn frame trong mạng .


Bằng các ghép CiR , là đồng nghĩa với thuê nhiều kênh hơn , là kĩ thhuật rất lợi khi có bùng phát thông tin xảy ra trên các mạch ảo vĩnh viễn khác nhau .
Ví dụ như ta có một đường T1 ở bộ định tuyến chính và bốn người dùng mỗi người được cấu hình dùng 4 khe 64 kbps ( 64*4=384 kbps) với 2 đường cơ sở trong điều kiện thiết kế mạch ảo vĩnh viễn là : nhàn rỗi và hoạt động . Nếu chỉ 2 người dùng sử dụng dịch vụ còn 2 người kia thì không hoạt động thì 2 người đầu tiên có thể sử dụng toàn bộ tốc độ có được lên đến 1544 kbps và do mỗi người dùng được dành cho 384 kbps nên những frame vượt quá số này sẽ bị có DE=1.