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

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 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. Nguyên tắc vượt nhanh: 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. 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. 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 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 Protocol Port(s) Used 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à 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) Match any Class Map match-all Voice-Bearer (id 2) Match ip rtp 16383 16383 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 ? 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 ! 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 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 ? 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. 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 đó 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) Liên kết phân mảnh và xen kẻ Phương pháp: phân nhỏ (chia packet thành các mảnh nhỏ), vượt nhanh (đưa packet chứa voice lên hàng đợi ưu tiên) Voice và video traffic rất nhạy cảm với sự chậm trễ và chập chờn. Mục tiêu chậm trễ cho voice là 150 ms, và cho jitter là 30 ms. LLQ, như mô tả trong phần trước, là một cách để cắt giảm sự chậm trễ và jitter. Khi traffic thoại được đặt vào một LLQ, nó được gửi ra trước các traffic khác. Tuy nhiên, giả sử một voice packet nhỏ đến interface chỉ sau khi một packet data lớn đã bắt đầu được truyền (hoặc truyền nhiều đợt). Ngay cả khi các voice packet được đặt trong LLQ ưu tiên, truyền dẫn của các packet data sẽ không dừng lại. Các voice packet phải chờ đến lượt. Điều này có thể là một nguyên nhân của sự chậm trễ và jitter. Thời gian cần cho một packet để được đặt lên dây truyền được biết đến như là delay tuần tự. Giá trị này thay đổi theo tốc độ của liên kết và kích thước của packet. Đương nhiên, với một packet kích thước bất kỳ mất nhiều thời gian để truyền đi trên một interface tốc độ chậm so với một interface khác nhanh hơn. Và càng nhiều bit được truyền trên một interface thì lại càng mất nhiều thời gian hơn. Để đáp ứng các yêu cầu voice, mỗi interface dọc theo con đường có delay tuần tự cho phép không quá 10 ms. Trong mạng LAN, các liên kết đủ nhanh để delay tuần tự không phải là một yếu tố. Nhưng trên các liên kết mạng WAN, nó có thể là cả một vấn đề. Một cách để giải quyết là chia các gói dữ liệu lớn thành nhiều mảnh nhỏ hơn mà không nhiều hơn 10ms để truyền nhiều lần, được biết đến như là phân mảnh. Sau đó, các voice packet có thể được truyền giữa mỗi phần của gói dữ liệu, được biết đến như là kỹ thuật đan xen. Khi kết hợp, kỹ thuật này được gọi là liên kết phân mảnh và đan xen. Có thể tính toán một giá trị gần đúng cho sự delay tuần tự sử dụng công thức sau: ([packet-size * 8]/link-speed) Kích thước packet là byte, do đó, nhân 8 để chuyển đổi sang bit. Sau đó, phân chia kết quả đó cho tốc độ đường truyền là kbps. Ví dụ, công thức cho một packet 1500-byte gửi ra interface T1 (1544 kbps) sẽ giống như thế này: ([1500 * 8]/1544 kbps) = 7.8 ms delay Như thấy, 1500 byte mất ít hơn 10 ms để truyền liên tiếp trên một interface T1. Tuy nhiên, cùng một lượng byte mất 15,6 ms trên một interface 768-kbps. Như một quy tắc chung, không nên phân mảnh trên inerface của tốc độ T1 hoặc cao hơn. Nó có thể hữu ích trên interface tốc độ thấp hơn, nếu họ có xu hướng thực hiện các packet data lớn cùng với voice. Điều này dẫn đến câu hỏi kích thước các mảnh nên là bao nhiêu. Các bảng có sẵn trong các tài liệu QoS có đề cập chi tiết này, nhưng cũng có thể ước tính kích thước phân mảnh chính xác. Tại 64 kbps, phải mất khoảng 10 ms để serialize 80 byte. có thể sử dụng cơ sở này để tính toán kích thước cho phân mảnh, một liên kết 256-kbps là bốn lần một liên kết 64 kbps. Vì vậy, kích cỡ gói dữ liệu có thể gấp bốn lần 80 byte là 320 byte. Phân mảnh được cấu hình theo những cách khác nhau tùy thuộc vào loại interface. Có thể làm điều đó trên một đường lease line bằng cách sử dụng Multilink PPP (MLP), trên một mạch Frame Relay bằng cách sử dụng FRF.12, trên một mạch Frame Relay bằng cách sử dụng Multilink PPP qua Frame Relay (MLPoFR), và với các máy ATM bằng cách sử dụng Multilink PPP trên máy ATM (MLPoATM). (Một sự thay thế cho cả Frame Relay và ATM là sử dụng PVC riêng biệt cho giọng nói.) Tổng kết: Trên đây chỉ là mộ