CCNA TUTOR: Encapsulation

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 gì.

+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 trì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.

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).

---

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 phòng tắm để tránh đánh thức bạn cùng phòng của mì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.
các bạn chờ chút hoàng anh tìm thêm nha

Đị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 trì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

---

---

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 đệ trì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ứ gì, 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 trì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 trì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à gì 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 trình quản lý, hoặc bất cứ một cái gì 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 trì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