1. Trang chủ
  2. » Luận Văn - Báo Cáo

Luận văn Phương pháp luận sáng tạo khoa học

14 868 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Phương Pháp Luận Sáng Tạo Khoa Học
Trường học Trường Đại Học Công Nghệ Thông Tin
Chuyên ngành Công Nghệ Thoại IP
Thể loại Luận văn
Định dạng
Số trang 14
Dung lượng 103 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

Luận văn Phương pháp luận sáng tạo khoa học

Trang 1

MỤC LỤC

MỤC LỤC 1

Nêu vấn đề và hướng khắc phục 2

Chất lượng phục vụ 3

Sử dụng bản đồ lớp để phân loại traffic 3

Phân loại tại Layer 4 4

Phân loại tại Layer 3 6

Phân loại tại Layer 2 7

Sử dụng policy maps 8

Liên kết phân mảnh và xen kẽ 10

Tổng kết 12

Trang 2

I Nêu vấn đề và hướng khắc phục:

Vấn đề cần giải quyết:

Thông thường, data và traffic voice đi qua cùng một liên kết WAN Đây có thể là một vấn

đề, vì data có xu hướng chiếm đầy đường truyền và có thể sử dụng hết bandwidth, điều đó sẽ khiến cho voice không thể truyền đi

Khắc phục:

Kỹ thuật QoS giúp bảo vệ voice (hoặc video) khỏi sự xâm chiếm đường truyền của data Trong bài viết này sẽ phân tích một số nguyên tắc sáng tạo trong kỹ thuật QoS Vì đây là một

phần tự dịch trích từ sách Cisco Voice Gateways and Gatekeepers, đồng thời là đề tài thuyết

trình cùng nhóm trong môn Công nghệ thoại IP nên không tránh khỏi những thiếu sót hay những đoạn dịch chưa chính xác, nên rất mong nhận được những nhận xét, góp ý từ các thầy để em có thể hoàn thiện hơn kỹ năng dịch, trình bày, phân tích, sáng tạo

Một số phương pháp nguyên tắc sáng tạo nhận biết được trong kỹ thuật QoS nhằm giải quyết vấn đề nêu trên:

Nguyên tắc thực hiện sơ bộ:

- Thực hiện trước sự thay đổi, tác động cần có, hoàn toàn hoặc từng phần, đối với đối tượng

- Cần sắp xếp các đối tượng trước, sao cho chúng có thể hoạt động từ vị trí thuận lợi nhất và không mất thời gian dịch chuyển

Nguyên tắc tách khỏi:

Tách phần gây “phiền phức” (tính chất “phiền phức”) hay ngược lại, tách phần duy nhất

“cần thiết” (tính chất “cần thiết”) ra khỏi đối tượng

Nguyên tắc linh động:

- Cần thay đổi các đặc trưng của đối tượng hay môi trường bên ngoài sao cho chúng tối

ưu trong từng giai đoạn làm việc

- Phân chia đối tượng thành từng phần có khả năng dịch chuyển đối với nhau

- Nếu đối tượng nhìn chung bất động, làm nó di động được

Nguyên tắc kết hợp:

- Kết hợp các đối tượng đồng nhất hoặc các đối tượng dùng cho các hoạt động kế cận

- Kết hợp về mặt thời gian các hoạt động đồng nhất hoặc kế cận

Nguyên tắc vạn năng:

Đối tượng thực hiện một số chức năng khác nhau, do đó không cần sự tham gia của đối tượng khác

Trang 3

- Vượt qua các giai đoạn có hại hoặc nguy hiểm với vận tốc lớn.

- Vượt nhanh để có được hiệu ứng cần thiết

Trang 4

II Chất lượng dịch vụ

Một trong những nhiệm vụ đầu tiên của là xác định từng ứng dụng sử dụng mạng Voice rất nhạy cảm với delay, jitter và drops Voice chất lượng tốt và video tương tác phải theo các yêu cầu sau:

 Tối đa delay 1 chiều là 150ms

 Tối đa jitter là 30ms

 Cho phép mất mát tối đa 1% packet

Một lý do của sự delay là các voice packet nhỏ phải chờ sau các packet data lớn để được gửi

ra khỏi interface Jitter, là một dạng biến đổi của delay, là kết quả của các voice packet khi được gửi nhanh và một số phải chờ Drops xảy ra khi hàng đợi interface đã đầy tràn, rất thường xảy ra nếu voice phải chia sẻ hàng đợi với data Như vậy, khi gửi voice và data thông qua một mạng WAN thì đặc biệt quan trọng trong việc đặt kế hoạch và bổ sung phạm vi SoS để mở rộng đường cho voice luôn có đủ bandwidth nó cần

QoS bao gồm 3 công đoạn:

 Phân loại traffic

 Đánh dấu traffic đã phân loại

 Cấu hình thiết bị mạng để chúng xử lý traffic theo các cách khác nhau dựa trên dấu đã đánh

Phương pháp: thực hiện sơ bộ Phân loại các traffic để đánh dấu, và các thiết bị mạng sẽ dựa vào dấu được đánh trên traffic để xử lý theo các cách khác nhau

1 Sử dụng bản đồ lớp để phân loại traffic

Phân loại traffic yêu cầu theo dõi và xác định tuỳ theo các đặc điểm, như port hay source address Sau khi đã phân loại traffic, có thể cấu hình router và switch để xử lý chúng theo các cách khác nhau với những traffic khác MQC sử dụng bản đồ lớp để phân loại traffic Việc phân loại có thể dựa trên nhiều thứ khác nhau, nhưng đặc trưng nhận biết của voice là xem xét thông tin headers OSI layer 4, layer 3, hoặc layer 2

Phương pháp: tách khỏi Tách phần traffic voice ra khỏi traffic data thông thường

Trang 5

1.1 Phân loại tại Layer 4

Có thể phân loại traffic dựa trên port TCP hay UDP trong header Mỗi ứng dụng voice sử dụng port được chỉ rõ Bảng 8-1 liệt kê các port default thường được sử dụng:

Table 8-1 Voice Protocols and Port Numbers

SCCP[1] TCP ports 20002002

MGCP[2] UDP 2427 and 2727; TCP 2428

H.323 UDP 1718 and 1719; TCP 1720 and 1721

RTP[3] UDP ports 16,38432,767

SIP[4] TCP and UDP port 5060 (Cisco implementation)

[1] SCCP = Skinny Client Control Protocol

[2] MGCP = Media Gateway Control Protocol

[3] RTP = Real-Time Transport Protocol

[4] SIP = Session Initiation Protocol

Có thể sử dụng một danh sách khác hoặc một bản đồ lớp khác để nhận dạng traffic dựa trên port Ví dụ 8-1 cho thấy làm thế nào để làm điều đó với một access list Access list được tạo và

có hiệu lực trong một bản đồ lớp Ví dụ này phân loại tín hiệu traffic SCCP tách biệt khỏi traffic RTP voice

Example 8-1 Configuring Access Lists and Class Maps

VGateway#conf t

VGateway(config)#ip access-list extended RTP

VGateway(config-ext-nacl)#permit udp any any range 16383 32767

!

VGateway(config-ext-nacl)#ip access-list extended SCCP

VGateway(config-ext-nacl)#permit tcp any any range 2000 2002

VGateway(config-ext-nacl)#exit

!

VGateway(config)#class-map match-all VOICE

VGateway(configs-cmap)#match access-group name RTP

!

VGateway(configs-cmap)#class-map match-all SIGNALING

VGateway(configs-cmap)#match access-group name SCCP

Cấu hình này cho thấy 2 bản đồ lớp mà 2 loại traffic sắp sử dụng, như được thực hiện trong

ví dụ 8-2 Bản đồ lớp VOICE nhận dạng traffic RTP được cho phép trong access list RTP, và

Trang 6

bản đồ lớp SIGNALING nhận dạng traffic SCCP được cho phép trong access list SCCP Vậy phần còn lại của dữ liệu đang truyền trên mạng sẽ thế nào? Mặc định có một lớp, và toàn bộ những gì không được nhận dạng sẽ xếp vào đó, ví dụ 8-2 cũng cho thấy điều này

Example 8-2 Verifying Class Map Configuration

VGateway#show class-map

Class Map match-any class-default (id 0)

Match any

Class Map match-all VOICE (id 2)

Match access-group name RTP

Class Map match-all SIGNALING (id 3)

Match access-group name SCCP

Ví dụ 8-3 cho thấy một bản đồ lớp phù hợp với traffic RTP Sử dụng lớp bản đồ này cho phép bỏ qua việc cấu hình access list cho RTP

Phương pháp: linh động Thay vì cấu hình access list cho RTP, ta sử dụng lớp bản đồ thích hợp sẽ nhanh và đơn giản hơn

Example 8-3 Using a Class Map to Identify RTP Traffic

[View full width]

VGateway(config)#class-map Voice-Bearer

VGateway(config-cmap)#match?

access-group Access group

any Any packets

class-map Class map

cos IEEE 802.1Q/ISL class of service/user priority

values

destination-address Destination address

fr-de Match on Frame-relay DE bit

input-interface Select an input interface to match

ip IP specific values

mpls Multi Protocol Label Switching specific values

not Negate this match result

protocol Protocol

qos-group Qos-group

source-address Source address

VGateway(config-cmap)#match ip ?

dscp Match IP DSCP (DiffServ CodePoints)

precedence Match IP precedence

rtp Match RTP port nos

VGateway(config-cmap)#match ip rtp 16383 16383

!

VGateway(config-cmap)#do show class-map

Class Map match-any class-default (id 0)

Trang 7

Example 8-3 Using a Class Map to Identify RTP Traffic

Match any

Class Map match-all Voice-Bearer (id 2)

Match ip rtp 16383 16383

1.2 Phân loại tại Layer 3

Một cách thứ hai để nhận biết traffic là theo dõi phạm vi kiểu phục vụ (ToS) tại Layer 3 IP header Sáu bit đầu của miền này được gọi là các bit điểm mã phân biệt các service khác nhau (the differentiated services code point - DSCP) Nó cấu hình đặc trưng với một giá trị thập phân

46 cho traffic voice-bearer Ngày trước, Cisco khuyến nghị thiết lập traffic tín hiệu voice là DSCP 31 Tuy nhiên, khuyến nghị hiện nay là thiết lập thành Class Selector (CS) 3 Có thể sử dụng một access list để nhận biết traffic với một giá trị DSCP nhất định trong packet Có thể thấy trong ví dụ việc có thể liệt kê DSCP khác như một giá trị thập phân hay giá trị DiffServ hoạt động mỗi bước truyền (DiffServ per-hop behavior PHB) Access list thứ hai, VOICE-SIG, cho phép cả CS3 và Assured Forwarding (AF) 31 đồng ý cho thiết bị mà chưa từng được chuyển đổi

để chỉ sử dụng CS3 cho tín hiệu Sau đó tạo access list, kết hợp chúng với các lớp bản đồ

Phương pháp có thể sử dụng: kết hợp, vạn năng (VOICE-SIG cho phép cả CS3 và AF31).

Example 8-4 Using an Access List to Match DSCP

VGateway(config)#ip access-list extended VOICE-BRR

VGateway(config-ext-nacl)#permit ip any any dscp ?

<0-63> Differentiated services codepoint value

af11 Match packets with AF11 dscp (001010)

af12 Match packets with AF12 dscp (001100)

af13 Match packets with AF13 dscp (001110)

af21 Match packets with AF21 dscp (010010)

af22 Match packets with AF22 dscp (010100)

af23 Match packets with AF23 dscp (010110)

af31 Match packets with AF31 dscp (011010)

af32 Match packets with AF32 dscp (011100)

af33 Match packets with AF33 dscp (011110)

af41 Match packets with AF41 dscp (100010)

af42 Match packets with AF42 dscp (100100)

af43 Match packets with AF43 dscp (100110)

cs1 Match packets with CS1(precedence 1) dscp (001000)

cs2 Match packets with CS2(precedence 2) dscp (010000)

cs3 Match packets with CS3(precedence 3) dscp (011000)

cs4 Match packets with CS4(precedence 4) dscp (100000)

cs5 Match packets with CS5(precedence 5) dscp (101000)

cs6 Match packets with CS6(precedence 6) dscp (110000)

cs7 Match packets with CS7(precedence 7) dscp (111000)

default Match packets with default dscp (000000)

ef Match packets with EF dscp (101110)

VGateway(config-ext-nacl)#permit ip any any dscp ef

!

Trang 8

Example 8-4 Using an Access List to Match DSCP

VGateway(config-ext-nacl)#ip access-list extended VOICE-SIG

VGateway(config-ext-nacl)#permit ip any any dscp cs3

VGateway(config-ext-nacl)#permit ip any any dscp af31

Trang 9

1.3 Phân loại tại layer2

Cách thức thứ ba để xác định luồng dữ liệu là dựa vào thẻ kết nối 802.1Q hoặc nhãn kết nối ISL 3 bits đầu gọi là lớp dịch vụ (COS), là những bits có thể ấn định để nhận biết những luồng

dữ liệu khác nhau Những bit này thường được ấn định dưới một giá trị thập phân của 5 cho âm thanh Chúng ta có thể kết hợp những bit này trong một bản đồ lớp Ví dụ 8-6 cho chúng ta thấy một bản đồ lớp nhận diện luồng dữ liệu tại layer 2 bằng giá trị CoS

Example 8-6 Using a Class Map to Match CoS

VGateway(config)#class-map COS-Voice

VGateway(config-cmap)#match cos ?

<0-7> Enter up to 4 class-of-service values separated by white-spaces

VGateway(config-cmap)#match cos 5

!

VGateway#show class-map

Class Map match-all COS-Voice (id 4)

Match cos 5

Các điện thoại IP của Cisco đặt một thẻ 802.1 trên luồng dữ liệu âm thanh chúng gửi CoS được ấn định 5 cho traffic thoại và 3 cho traffic truyền tín hiệu Switch nhìn vào giá trị CoS trước khi nó removes header ở layer 2, và nó biên dịch sang một giá trị DSCP mà gói tin đi qua switch Traffic không gắn thẻ PC được set giá trị DSCP mặc định là 0 Khi gói tin được gửi ra mặt ngoài switch, nó được đánh dấu tại layer 3 với một giá trị DSCP (Nó cũng có thể có giá trị CoS nếu mặt ngoài là một đường trunk) Xác lập switch để yêu cầu đặt giá trị DSCP trên bất kỳ gói tin nào muốn đánh dấu Header layer 2 thay đổi khi chúng được chuyển ra mạng, nhưng có thể kết hợp dựa vào giá trị không thay đổi DSCP ở layer3

Trang 10

2 Sử dụng Policy Maps

Sau khi nhận dạng traffic thường xuyên, có thể đánh dấu nó hoặc thiết lập policy cho nó Đánh dấu traffic bao gồm thiết lập DSCP bits hoặc CoS bits

MQC áp đặt policy trên traffic đã được phân loại bằng bản đồ policy Bản đồ policy tham khảo các bản đồ lớp đã được tạo trước đó và xác định những gì cần thực hiện với lưu lượng trong mỗi lớp Ví dụ, traffic có thể được đánh dấu, băng thông tối thiểu, giới hạn băng thông, được ưu tiên, hoặc ngay cả việc drop tất cả áp đặt bản đồ policy cho các interfaces Một hàng đợi riêng biệt được tạo ra tại interface cho mỗi bản đồ lớp, và traffic được nhận dạng bởi bản đồ lớp xếp vào hàng đợi của nó Điều này cho phép thực thi traffic ở các lớp theo cách khác nhau

Ví dụ 8-7 cho thấy traffic đánh dấu trong một bản đồ policy Bản đồ lớp CoS-Voice được tạo trong ví dụ 8-6 Nó nhận dạng traffic với một giá trị CoS là 5 trong thẻ trunking 802.1Q Ví dụ này tạo một bản đồ policy đánh dấu tất cả traffic được phân loại bằng CoS-Voice với giá trị DSCP là 46 (hay EF)

Example 8-7 Đánh dấu traffic bằng một bản đồ policy

VGateway (config) #policy-map COS-TO-DSCP

VGateway (config-pmap) #class COS-Voice

VGateway (config-pmap-c) #set dscp 46

!

VGateway (config-pmap-c) #class class-default

VGateway (config-pmap-c) #set dscp 0

!

VGateway#show policy-map

Policy Map COS-TO-DSVCP

Class COS-Voice

set dscp ef

Class class-default

set dscp default

Chú ý rằng trong ví dụ 8-7, tất cả traffic ngoại trừ được đánh dấu với Cos là 5 thì được đặt DSCP là 0 dưới lớp default Nếu có định tuyến traffic, đó là một ý kiến hay để phân tích tách biệt nhau trước khi phân loại tất cả những cái khác theo DSCP 0 Cũng lưu ý rằng một khi bản đồ policy được thiết lập sử dụng giá trị thập phân, khi trình diễn nó, tất cả sẽ được biên dịch thành giá trị PHB

Phải thường xuyên sử dụng bản đồ policy để chỉ rõ cách xử lý khác nhau cho traffic trong mỗi hàng đợi được tạo bởi bản đồ lớp Thiết lập policy và đánh dấu traffic không bị loại trừ nhau, có thể thực thi cả hai trên cùng một lớp Voice thường được đặt trong hàng đợi ưu tiên, gọi

là hàng đợi đường truyền nhanh (low-latency queue LLQ) Điều này rất quan trọng để nhận thức

Trang 11

đó là hàng đợi ưu tiên nghiêm ngặt Nếu có bất kỳ traffic nào khác trong hàng đợi, nó sẽ được đưa lên trước các traffic đó Có thể giới hạn số lượng bandwidth được dùng cho hàng đợi ưu tiên,

vì thế các traffic khác sẽ không bị chiếm hết bandwidth

Phương pháp: vượt nhanh Đưa packet voice lên đầu, ưu tiên để truyền đi trước

Bandwidth bao nhiêu dành cho hàng đợi ưu tiên? Lập kế hoạch nhu cầu bandwidth, đưa vào tài khoản tải dữ liệu dự đoán cộng với nạp thoại Tổng lượng bandwidth được cấp cho mỗi cuộc gọi thay đổi dựa trên mã hoá / giải mã (codec) sử dụng Codec mô tả phương thức của việc nén

âm thanh Thường sử dụng nhất là G.711 cho âm thanh chưa nén, và G.729, dạng nén của âm thanh G.711 thường dùng trong mạng LAN với bandwidth dồi dào G.729 thường dùng trong mạng WAN, với các đường truyền bandwidth thấp Với một cuộc gọi G711, sử dụng 64kbps, dung lượng tải 160 bytes Cuộc gọi G.729 sử dụng 8kbps, tải trọng dung lượng ở mức 20 bytes

IP, UDP, và RTP headers được thêm vào trên mỗi packet IP header chiếm 20 bytes, UDP chiếm 8 bytes, và RTP chiếm 12 bytes, tổng cộng 40 bytes được thêm vào trên mỗi gói tin VoIP

có tuỳ chọn nén Ip, UDP, và RTP headers, giúp giảm bớt header 2 tới 4 bytes, theo đó giảm toàn

bộ dung lượng packet và sủ dụng ít bandwidth hơn

Khi lập kế hoạch cấp bandwidth, cũng nên cân nhắc việc sử dụng layer 2 headers Ví dụ, Ethernet thêm 18-byte vào header, trong khi Frame Relay chỉ them 6 bytes Multilink PPP cũng thêm 6-byte vào header ATM header thì 5 bytes Nếu dùng MPLS trong mạng WAN của , MPLS router ngoài cùng sẽ thêm vào 4-byte header Nếu gửi voice qua mạng Internet, nên mã hoá với Ipsec để bảo mật Ipsec sẽ thêm vào từ 50 đến 57 bytes trện cùng.Giao thức truyền tải theo thời gian bảo mật (SRTP) mã hoá trọng tải gói tin IP voice và thêm 4 bytes vào gói tin Như một quy luật, 21 tới 320 kbps của bandwidth được yêu cầu cho mỗi cuộc thoại, tuỳ vào

bộ giải mã và chi phí hoạt động Khuyến cáo khi truyền âm thanh và dữ liệu trên cùng một interface thì nên giới hạn LLQ khoảng 1/3 bandwidth Việc này cho phép vẫn còn đủ bandwidth phân chia giữa các lớp dữ liệu

Hội nghị truyền hình IP (IP/VC) thêm vào cân nhắc cho thiết kế QoS của Hình ảnh tương tác

có cùng yêu cầu như mạng âm thanh, độ trễ tối đa 150ms, độ rung 30ms hoặc thấp hơn, và mất mát ít hơn 1%, vì thế nó cũng được đặt vào LLQ Tuy nhiên, traffic video biến đổi lớn trong kích thước gói tin và tốc độ truyền tải Một hội thoại hình trung bình cần khoảng 384kbps Cisco khuyến cáo nên cung cấp hơn 20%, nghĩa là nâng lên 460kbps mỗi luồng IP/VC LLQ cho phép bursts lên đến 200ms, là mức thường đáp ứng đủ cho một luồng video.Nếu gửi nhiều luồng thông qua một interface, sẽ cần điều chỉnh lại kích thước burst có thể chỉ rõ giới hạn burst khi tạo LLQ trong bản đồ policy, như một phần của lệnh ưu tiên, việc này được biểu diễn trong ví dụ 8-8 Không có bất kỳ nguyên tắc bất di bất dịch nào có sẵn về bao nhiêu để gia tăng giới hạn burst cần test nhiều lần luồng IP/VC được thêm vào

Phương pháp: dự phòng (cung cấp hơn mức yêu cầu 20% để đảm bảo đáp ứng nhu cầu)

Ngày đăng: 17/09/2012, 11:23

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w