1 / 17

Multiple Encapsulation Methods

Multiple Encapsulation Methods. Draft-iab-link-encaps-05.txt Bernard Aboba IETF 67 San Diego, CA. Outline. History Questions for 16ng. History. Ethernet vs. IEEE 802 Encapsulation IPv4 over Ethernet: RFC 894 IPv4 over IEEE 802: RFC 1042 Ethernet Trailer Encapsulation: RFC 893 PPP

jrenae
Télécharger la présentation

Multiple Encapsulation Methods

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multiple Encapsulation Methods Draft-iab-link-encaps-05.txt Bernard Aboba IETF 67 San Diego, CA

  2. Outline • History • Questions for 16ng

  3. History • Ethernet vs. IEEE 802 Encapsulation • IPv4 over Ethernet: RFC 894 • IPv4 over IEEE 802: RFC 1042 • Ethernet Trailer Encapsulation: RFC 893 • PPP • IPCP: RFC 1332, IPv6CP: RFC 2472 • Bridging Control Protocol: RFC 3518 • ATM • MPOA: RFC 1483 • Classical IP over ATM: RFC 1577

  4. PPP • Possible to negotiate both layer 3 (IPCP, IPv6CP) and layer 2 (BCP) encapsulations • In practice, this rarely happens • Hosts rarely implement BCP • Bridges typically do not also negotiate IPCP/IPv6CP

  5. Implications of Mixed Environments (From RFC 1042) • A host can potentially receive both Ethernet and IEEE 802.3 frames • If it does, it must keep track of which link protocol was used with each host and send using the right encapsulation. • Link layer broadcasts will not reach all hosts, just those who can receive the encapsulation used in the broadcast. • To enable hosts reading and sending only one encapsulation to communicate with each other, an IP gateway is recommended. • The MTU of Ethernet (1500) is different from the IEEE 802.3 MTU (1492).

  6. Recommendations from RFC 1122 • It is not useful or even possible for a dual-format host to discover automatically which format to send, because of the link-layer broadcast issue. • Every host: • MUST be able to send and receive using RFC 894 encapsulation (Ethernet) • SHOULD be able to receive RFC 1042 (IEEE 802) packets intermixed with RFC 894 packets • MAY be able to send packets using RFC 1042 encapsulation • A host that implements sending both RFC 894 and 1042 encapsulation MUST provide a configuration switch to select which is sent, and this switch MUST default to RFC 894.

  7. What We Learn From History • Multiple encapsulations should be avoided wherever possible • After effects of DIX vs. IEEE 802 are still with us today • Mitigating approaches are not completely satisfactory • Automated discovery of link encapsulation is complex and inefficient • Best done at the link layer • Requires keeping state for each destination (not a shopstopper) • Results in higher bandwidth overhead and latency plus implementation complexity • IP gateways are not a panacea • IP gateways need to support separate virtual interface for each encapsulation. • Separate prefixes needed for each encapsulation so that hosts can avoid keeping state.

  8. Questions for 16ng • Roaming • What if an MS supporting only Ethernet CS roams to a network supporting only IPv4 or IPv6 CS? • Interoperability • What if the Mobile Station (MS) and Base Station (BS) CS negotiate more than one way to send a given packet? • Example: Ethernet CS + IPv4 CS • What if MS and BS do not have any CSes in common?

  9. Feedback?

  10. Background

  11. Ethernet Header • The 7 byte Preamble and 1 byte Start Frame Delimiter are not shown. • Data field is at least 46 bytes, to bring the minimum frame size to 64 bytes. • Ethernet Jumbo frames can be as large ~9000 bytes • 802.1Q adds an additional 4 bytes of header (2 for EtherType=0x8100, 2 for Tag Control Information). • With 1500 bytes of data this brings the total frame size to 1522.

  12. IEEE 802 Header • Data and FCS omitted for brevity • How is IEEE 802 Length distinguished from Ethernet Type? • If the value of the field is less than or equal to 1500, then it indicates the Length in bytes of the subsequent MAC Client Data field (IEEE 802 encapsulation) • If the value of the field is greater than or equal to 1536, then it indicates the EtherType (Ethernet encapsulation). • IEEE 802.3 and Ethernet have different MTUs! • IEEE 802.3 MTU is 1492 (1518 – 18 (MAC header + FCS) – 8 (LLC + SNAP header), not including IP headers)

  13. EtherTypes http://standards.ieee.org/regauth/ethertype/eth.txt http://www.iana.org/assignments/ethernet-numbers

  14. Comparison of 1042 & 1122 • Send & Receiving • 1024: It is assumed that most computers will read and send using only one protocol • 1122: Sending and receiving RFC 894 a MUST implement • 1122: Receiving RFC 1042 a SHOULD implement, sending a MAY implement • 1122: RFC 894 a MUST use by default • Format discovery • 1024: a host receiving both 894 & 1024 must keep track and send using the right encapsulation • 1122: Automatic discovery is not useful or even possible • 1122 guarantees that a host can receive RFC 894, so no need to keep track or send using the right encapsulation

  15. Trailer Encapsulation (RFC 893) • Enabled to minimize memory-to-memory copy operations performed by a receiving host • Done by moving variable length headers (e.g. IP + TCP) after the data segment • Enables reception on a page aligned boundary • Packets using trailers utilize a distinct EtherType [RFC893]. • Type is calculated as 0x1000 plus the number of 512-byte pages of data (maximum of 16 pages or 8192 bytes) • Packet formulation • L2 header as normal • Data minus IP and TCP header always a multiple of 512 bytes • Trailer: Original Type (2) + Header Length (2) + IP and TCP headers • Frame Check Sequence

  16. Negotiation • Potential for four encapsulations! • IEEE 802 w or w/o trailers • Ethernet w or w/o trailers • Trailer negotiation • ARP exchange completed using the IP protocol type • Host that wants to speak trailers will send an additional “trailer ARP reply” • Receiver can add the host to the list of machines that understand trailers (e.g. marking the ARP cache entry). • Receiving host replies to “trailer ARP reply” with a “trailer ARP reply” • 4.2 BSD implementation • Did not implement trailer negotiation • Configured trailers at boot time, assumed that all hosts either did or did not implement it.

  17. RFC 1122 on Trailers • “The trailer protocol for link-layer encapsulation MAY be used, but only when it has been verified that both systems (host or gateway) involved in the link-layer communication implement trailers. If the system does not dynamically negotiate use of the trailer protocol on a per-destination basis, the default configuration MUST disable the protocol.”

More Related