CCNA TUTOR: Encapsulation

Go down

CCNA TUTOR: Encapsulation

Post  Admin on Thu Apr 10, 2008 1:42 pm

CCNA TUTOR: Encapsulation
Như đă nói ở bài trên, OSI có 7 lớp để dễ dàng phát triển. Vậy dữ liệu truyền trong 7 lớp đó như thế nào?

-Nói chung, dữ liệu khi ở nguồn (source) sẽ đi từ lớp cao xuống lớp thấp(encapsulation). Sau đó được truyền trên đường truyền(media) rồi đến đích cần gửi. Tại đích đến, dữ liệu sẽ lại được đưa ngược từ lớp thấp lên lớp cao(de-encapsulation).

-Data Encapsulation:

+Do chúng ta đang bàn về Cisco Certified, nên đi theo quan điểm của Cisco. Theo Cisco th́ ở từng lớp sẽ có một cách gọi dữ liệu riêng, và gọi đó là 1 đơn vị dữ liệu (PDU-Protocol Data Unit) tại lớp đó.

+Dữ liệu do người dùng gửi đi lúc đầu sẽ được chuyển qua 3 lớp Application, Presentation, Transport và sẽ được gọi là DATA. Cisco gom lai do họ không mặn mà lắm về 3 lớp trên này.

+Data sau đó được chuyển xuống lớp Transport, được gắn thêm header và được gọi là SEGMENT. Header ở lớp Transport chủ yếu gồm source port và dest port. Port dùng để chỉ ra 2 host đang dùng loại application nào.

+Segment lại được đưa xuống lớp Network, tiếp tục được gắn thêm header và được gọi là PACKET. Header ở lớp Network chủ yếu là địa chỉ luận lí của source & dest., chỉ ra protocol của lớp Transport. Do dùng service của layer ngay bên dưới nó nên phải biết lớp trên nó dùng ǵ.

+Packet lại tiếp tục đi xuống lớp Data link, ở đây packet được gắn thêm header & trailer, biến thành FRAME. Do Datalink có 2 lớp nhỏ, nên được gắn 2 lần Header và trailer như sau:

-Ở LLC(chuẩn 802.2): header chủ yếu là source & dest. Service Access Point (SAP). SAP chỉ ra protocol mà lớp Network đang dùng(IP= 06, IPX= E0). Ngày nay do càng nhiều giao thức lớp 3 được ra đời, nên IEEE (tổ chức chuyên lo về điện và điện tử) đă đưa ra tiếp khái niệm Subnetwork Access Protocol (SNAP). SNAP là tương tự như SAP, nhưng cho nhiều số hơn thôi. SNAP có khi SourceSAP và Dest.SAP được gán giá trị AA.

-Ở MAC sublayer (chuẩn 802.3 cho Ethernet, 802.5 cho Token Ring): header chủ yếu là source và dest. MAC address, ngoài ra c̣n có Preamble để máy tính nhận biết sự bắt đầu của frame, trailer ở đây là Frame Check Sequence (FCS) dùng để kiểm tra lỗi có xảy ra với frame hay không.

+Frame sau đó được gắn thêm header ở lớp Physical, rồi chuyển hoá ra dạng BIT truyền đi. Thật ra header ở đây chỉ là chuỗi bit, xác định xem đang truyền trên loại cable nào mà thôi. Sau đó bit được truyền đến dest.

Đó là quy tŕnh encapsulation của dữ liệu. Các PDU nói ở trên c̣n có tên gọi khác dễ nhớ hơn nhưng không được khuyến khích cho lắm đó là LxPDU (VD: Packet: L3PDU, Frame: L2PDU)

-Data De-encapsulation: khi được chuyển đến dest. th́ PDU được chuyển từ dưới lên, ở lớp nào th́ lớp đó sẽ gỡ header (và trailer nếu có) ra và xử lí. Rồi gửi phần ruột bên trong lên lớp trên nó.

Tham khảo: CCDA Certification Guide, ICDN course của NetG, RFC1700 về Assigned Number. Các bạn có thể t́m thông tin về RFC tại http://www.rfc-editor.org/rfcsearch.html.
avatar
Admin
Admin

Posts : 72
Join date : 2008-04-06

View user profile http://tinspdn.5forum.net

Back to top Go down

mot so khai niem co ban ve rfc

Post  nguyenhoanganh on Thu Apr 10, 2008 2:46 pm

Trong kỹ nghệ liên mạng và mạng máy tính, các tài liệu RFC (tiếng Anh: Request for Comments - Đề nghị duyệt thảo và b́nh luận) là một chuỗi các bản ghi nhớ chứa đựng những nghiên cứu mới, những đổi mới, và những phương pháp luận ứng dụng cho công nghệ Internet.
Thông qua Đoàn thể Internet (Internet Society), các kỹ sư và các nhà khoa học máy tính có thể công bố luận văn dưới h́nh thức là một bản ghi nhớ RFC, hoặc là để cho những người đồng nghiệp phê b́nh (peer review), hoặc chỉ đơn thuần thông báo những quan điểm mới, tin tức, hoặc (thỉnh thoảng) hài hước về kỹ thuật. Tổ chức Lực lượng chuyên trách về kỹ thuật liên mạng (Internet Engineering Task Force - IETF) chấp nhận một số những lư thuyết thông tin đă ứng dụng được công bố trong các bản RFC như những tiêu chuẩn về liên mạng (Internet standards).


LỊCH SỬ PHÁT TRIỂN CỦA RFC

Mẫu h́nh RFC được khởi đầu vào năm 1969, khi nó là một phần trong hội thảo của dự án ARPANET. Hiện nay, nó là tuyến công bố chính thức của IETF, của Ủy ban kiến trúc liên kết mạng (Internet Architecture Board - viết tắ là IAB)), và tới một mức độ nào đó, của cộng đồng những kỹ sư nghiên cứu về mạng lưới truyền thông vi tính toàn cầu.
Những bản RFC đầu tiên được tác giả của chúng đánh bằng máy chữ và truyền tay các bản in giữa nhóm những kỹ sư nghiên cứu tại ARPA. Tháng 12 năm 1969, các kỹ sư nghiên cứu phân phát các bản RFC mới được viết thông qua mạng lưới truyền thông, vốn là ARPANET, mà hiện nay đang hoạt động. Bản RFC số 1, với đề tài "Phần mềm dành cho máy chủ" (Host Software), được Steve Crocker sinh viên trường đại học California (University of California, Los Angeles - viết tắt là UCLA) viết, và được công bố vào ngày 7 tháng 4, năm 1969. Crocker đă thảo bản dự thảo này trong pḥng tắm để tránh đánh thức bạn cùng pḥng của ḿnh.
Trong phiên bản RFC số 3, khai điểm của chuỗi các bản RFC, Steve Crocker đặt các bản RFC đưới quyền của "Nhóm điều hành liên mạng" (Network Working Group). Nhóm này h́nh như chưa bao giờ tồn tại một cách chính thức, chỉ được định nghĩa là "nhóm người này", song sự ủy quyền vẫn c̣n tồn tại trong các RFC cho đến ngày nay.
Trường đại học UCLA tiếp tục cho ra nhiều các bản RFC trong những năm của thập niên kỷ 1970, không những v́ chất lượng uyên thâm, song c̣n là v́ UCLA là những Bộ điều hành giao diện thông điệp (Interface Message Processor) (nút kết nối mạng) đầu tiên trên mạng ARPANET.
Trung tâm nghiên cứu phát triển (Augmentation Research Center - viết tắt là ARC) của ông Douglas Engelbart tại Học viện nghiên cứu Stanford (Stanford Research Institute) - là một trong bốn nút mạng đầu tiên của mạng ARPANET. Nó cũng đồng thời là Trung tâm tin tức liên mạng (Network Information Centre) đầu tiên, đồng thời nó c̣n là (như đă được nhà xă hội học Thierry Bardini ghi chú) nguồn gốc của một số lớn những RFC ở thời kỳ đầu.
Từ năm 1969 đến năm 1998, ông Jon Postel làm chủ biên tập RFC. Sau khi hợp đồng ủng hộ tài chính của chính phủ Mỹ hết hạn, Hội đồng Internet (thay mặt cho IETF) kư hợp đồng với Chi nhánh điều hành liên mạng (Networking Division) của trường đại học miền Nam California (University of Southern California - viết tắt là USC) đứng ra làm quyền biên tập và chịu trách nhiệm về việc xuất bản (dưới sự chỉ đạo của IAB). Jon Postel tiếp tục giữ chức chủ biên tập cho đến khi ông mất; sau này, Bob Braden lănh chức chủ nhiệm đề án, trong khi Joyce Reynolds tiếp tục làm một thành viên của nhóm.
Arrow các bạn chờ chút hoàng anh t́m thêm nha Shocked
avatar
nguyenhoanganh

Posts : 74
Join date : 2008-04-08
Age : 31

View user profile

Back to top Go down

phan thu hai ve rfc

Post  nguyenhoanganh on Thu Apr 10, 2008 2:58 pm

phần hai: các bản rfc có ở đâu? và phân cấp như thế nào?
Phương thức lấy các bản RFC

Địa chỉ chính thức của các RFC trên World Wide Web (Mạng lưới toàn cầu) là Chủ biên tập RFC. Chúng ta c̣n có thể lấy chúng từ những nguồn không chính thức khác, thông qua rất nhiều các máy chứa bản sao (mirror sites), truy cập dùng HTP (HyperText Transfer Protocol), dùng FTP nặc danh (anonymous FTP), dùng giao thức gopher (gopher protocol), hoặc những giao thức phổ biến của tầng ứng dụng.
Ai cũng có thể tiếp cận bất cứ một bản RFC nào đă từng được công bố, như RFC 3700, thông qua liên kết nối URL: http://www.rfc-editor.org/rfc/rfc3700.txt
Hầu hết các bản RFC đều hiện hữu ở dạng văn bản ASCII, song chúng cũng c̣n hiện hữu ở các dạng văn bản (file format) khác; Từ năm 2006 trở đi, những phiên bản chính thức của bất cứ đặc tả về tiêu chuẩn Internet nào, cũng đều ở dưới dạng văn bản ASCII. Xin lưu ư, bản RFC 1119 không tồn tại trong các bản RFC tiêu chuẩn được lưu trữ.

Để tiếp cận các chi tiết về dữ liệu (meta data) của một bản RFC, bao gồm lược tŕnh (abstract), những từ chủ chốt, tác giả, ngày xuất bản, đính chính, hiện trạng, và đặc biệt là sự cập nhật những thông tin mới, những thay đổi, ở dạng thức mà người dùng đọc được, một cách dễ dàng, các máy của chủ biên tập RFC cung cấp những bảng điền chi tiết cho những nhu cầu t́m kiếm, với nhiều chức năng khác nhau. Mỗi một lần chuyển hướng (đi lùng t́m văn bản) là một lần các tham số hiệu quả được thay đổi, chẳng hạn: http://purl.net/net/rfc/3700




Cấp bậc

Không phải bản RFC nào cũng là tiêu chuẩn. Chỉ có nhóm IETF đại diện cho Nhóm chỉ đạo kỹ thuật liên kết mạng (Internet Engineering Steering Group - viết tắt là IESG) là có quyền chuẩn y các bản RFC đang trên đà trở thành tiêu chuẩn. Cấp bậc của các bản RFC được chia ra thành những phần như đề cử (proposed) (PS), dự thảo (draft) (DS), và toàn phần (full) tiêu chuẩn Internet (Internet Standards (STD)). Mỗi một biên tập phụ, thuộc một tiêu chuẩn STD nào đó, đều có riêng một con số đặc thù; Kể từ năm 2006 trở đi, tiêu chuẩn số 1 là RFC 3700. Một số các STD tạo nên nhiều nhóm nhỏ, gồm nhiều những RFC liên quan.

Một bản RFC thử nghiệm có thể là một tài liệu của IETF, hoặc một bản đệ tŕnh cá nhân lên chủ biên tập RFC. Trên lư thuyết, thực trạng của các bản tài liệu như là cái tên của nó ám chỉ - chúng chỉ là các "Đề nghị duyệt thảo và b́nh luận". Trên thực tế một số bản tài liệu không được nâng đỡ trên đà tiêu chuẩn v́ không có người t́nh nguyện thi hành những chi tiết cụ thể trong thủ tục. Một số tài liệu quan trọng cũng chỉ tổn tại như một Bản thảo Internet, trong khi đó lại có những bản RFC chính quy hầu như trở nên lỗi thời (historic). Kể từ năm 2006 trở đi, so sánh bản TAObis I-D với bản RFC 3160, c̣n được gọi là "The Tao of IETF" (Bản chất Tao trong IETF).

Một bản RFC tin tức hầu như có thể là bất cứ một thứ ǵ, từ những bản RFC hài hước mùng 1 tháng Tư (April 1st jokes) về những giao thức sở hữu (proprietary protocols) cho đến những bản RFC chủ chốt, được đại đa số biết đến, như bản RFC 1591. Một số bản RFC tin tức được nhóm lại thành một loạt các bài "tin tức đáng để ư" (for your information - viết tắt là FYI). Tuy hiện nay ít ai đăng thêm, một số những FYI cũ vẫn c̣n rất thích thú, chẳng hạn FYI 18 c̣n được gọi là RFC 1983, bản "Từ vựng dành cho người dùng Internet". (Internet User's Glossary)

Một bản RFC tồn kho (historic) là một bản lỗi thời và đă có một phiên bản mới thay thế nó. Những bản này liệt tŕnh một giao thức không được coi là đáng để ư trong Internet hiện tại, hoặc đă bị mang ra khỏi đà tiêu chuẩn hóa v́ những lư do nào đó. Một số những bản RFC lỗi thời c̣n không được liệt kê vào hàng các bản tồn kho, v́ "Tiến tŕnh tiêu chuẩn hoá Internet" (Internet Standards Process) thường không cho phép những tham chiếu có tính quy chuẩn (normative references) đối với một bản RFC đang trên đà tiêu chuẩn hóa, từ một RFC có địa vị thấp hơn. Đồng thời, ít người chú ư đến việc giải quyết những chi tiết thủ tục yêu cầu, để những bản RFC được phân loại là tồn kho, và những thay đổi được đánh dấu vào tất cả các bản RFC phụ thuộc vào nó.

Dạng vô danh thường được đặt cho những bản RFC quá cũ, không rơ cấp bậc của nó phải là ǵ nếu phải công bố. Trong một vài trường hợp, những bản RFC ấy c̣n hoàn toàn không được công bố. Những bản RFC cũ thường, như cái tên của nó ám chỉ, chỉ đơn thuần là những bản "Yêu cầu duyệt thảo và b́nh luận", không chủ tâm đặc tả một giao thức, một chu tŕnh quản lư, hoặc bất cứ một cái ǵ khác mà các RFC hiện nay đang được dùng để thực hiện.

Một loạt các bài những thực hành ưu ái (best common practice - viết tắt là BCP) thu thập các tài liệu về quản lư và những văn bản được công nhận là những luật lệ chính quy, và không thuộc dạng tin tức, song chúng không ảnh hưởng đến những dữ liệu được truyền thông qua đường dây. Danh giới giữa các bản trên đà tiêu chuẩn hóa và các bản BCP thường, là một danh giới rất khó phân định. Nếu một tài liệu chỉ ảnh hưởng đến Tiến tŕnh tiêu chuẩn hoá Internet (Internet Standards Process), c̣n được gọi là BCP 9 hoặc Sự quản lư IETF th́ nó rơ ràng là một bản BCP. Nếu bản RFC ấy chỉ định nghĩa những luật lệ và qui định cho những cơ quan đăng kư IANA (Internet Assigned Numbers Authority), th́ khó mà có thể phân định được nó là cái nào. Đa số những bản tài liệu này được liệt kê là các bản BCP, song cũng có một số đang trên đà được tiêu chuẩn hóa.

Loạt các bài BCP c̣n đồng thời nói đến những đề bạt kỹ thuật về phương pháp thực hành những tiêu chuẩn Internet, chẳng hạn đề bạt về cách dùng những bộ lọc nguồn (source filtering) làm cho những tấn công DoS (Denial of Service - Tấn công từ chối dịch vụ) trở nên khó khăn hơn như (RFC 2827: "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" - tạm dịch là "Thanh lọc nội mạng: Hủy diệt các tấn công từ chối dịch vụ dùng cách đóng địa chỉ IP giả") - là bản BCP 38.
thôi nhiêu đó đủ rồi .từ từ mà xem nha mấy bạn nếu bạn nào muốn t́m hiểu thêm th́ pm cho ha nha. bye cheers
avatar
nguyenhoanganh

Posts : 74
Join date : 2008-04-08
Age : 31

View user profile

Back to top Go down

Re: CCNA TUTOR: Encapsulation

Post  Sponsored content


Sponsored content


Back to top Go down

Back to top

- Similar topics

 
Permissions in this forum:
You cannot reply to topics in this forum