16ng M. Riegel Internet-Draft Siemens Expires: December 21, 2006 June 19, 2006 Transmission of IP Packets over Ethernet over IEEE802.16 draft-riegel-16ng-ip-over-eth-over-80216-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the special behavior of the Ethernet emulation on top of IEEE802.16 to efficiently support the transmission of IPv4 as well as IPv6 packets over IEEE802.16 radio links. Due to resource constraints of radio transmission systems and the limitations of the IEEE802.16 MAC layer for the emulation of Ethernet, the transmission of IP over an emulated LAN on top of IEEE802.16 may considerably benefit by adding IP specific support functions within the Ethernet emulation on top of IEEE802.16. Riegel Expires December 21, 2006 [Page 1] Internet-Draft IPoETH over IEEE802.16 June 2006 Contributors: The following have contributed to this document: ### more contributors kindly appreciated ### Changes from the last revision: - Initial version mainly providing the outline of the document - ### much more work to be done ### Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transmission of IP over Ethernet . . . . . . . . . . . . . . . 3 2.1. IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 3 2.2. IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 4 3. The IEEE802.16 Link Model . . . . . . . . . . . . . . . . . . 4 3.1. Connection Oriented Air Interface . . . . . . . . . . . . 4 3.2. IP over Ethernet Link Model . . . . . . . . . . . . . . . 5 3.3. Convergence Sublayers . . . . . . . . . . . . . . . . . . 5 3.4. Multicast and Broadcast Support . . . . . . . . . . . . . 6 3.5. Wireless Particularities . . . . . . . . . . . . . . . . . 6 4. Support of IP over Ethernet over IEEE802.16 . . . . . . . . . 7 4.1. IEEE802.16 without multicast support . . . . . . . . . . . 7 4.1.1. Default Processing of Ethernet Frames (for information) . . . . . . . . . . . . . . . . . . . . . 7 4.1.2. Packet Filtering . . . . . . . . . . . . . . . . . . . 8 4.1.3. IPv4 specific Packet Processing . . . . . . . . . . . 8 4.1.4. IPv6 specific Packet Processing . . . . . . . . . . . 9 4.2. IEEE802.16 with multicast support . . . . . . . . . . . . 9 4.2.1. ### TBD ### . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Riegel Expires December 21, 2006 [Page 2] Internet-Draft IPoETH over IEEE802.16 June 2006 1. Introduction [IEEE802.16] defines a point-to-multipoint radio transmission system connecting a Base Station (BS) with multiple Subscriber Stations (SSs). The MAC layer of IEEE802.16 provides one or more data link connections between each of the SS and the BS assigned by a 16 bit Connection IDentifier (CID). [IEEE802.16e] ammends the base specification with PHY and MAC functions for supporting mobile terminals adopting the same data link principles also for mobile network systems. While each of the SS and the BS are uniquely identified by a 48 bit value (MAC address), packets transmitted over the air only contain the 16 bit CID value for specifying the destination of the packet. To differentiate between different service flows and to determine the particular CID the IEEE802.16 MAC provides multiple convergence sublayers, one for each of the supported packet formats. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Base Station (BS) A generalized equipment sets providing connectivity, management, and control of the subscriber station (SS) Subscriber Station (SS): A generalized equipment set providing connectivity between subscriber equipment and a base station (BS) 2. Transmission of IP over Ethernet 2.1. IPv4 over Ethernet [RFC0894] defines the transmission of IP packets over Ethernet networks. It contains the specification of the encapsulation of the IP packets into Ethernet frames as well as rules for mapping of IP addresses onto Ethernet MAC addresses. Recommended is the use of ARP [RFC0826] for dynamic address resolution. ARP is the process by which nodes determine the link layer address of a destination node by broadcasting a query on the local link and expecting a response from the destination node. Ethernet broadcast Riegel Expires December 21, 2006 [Page 3] Internet-Draft IPoETH over IEEE802.16 June 2006 is used to transfer the query to all the nodes attached to the local link. Another important protocol deploying Ethernet broadcasts for determination of a particular service on the local link is DHCP [RFC2131]. The SS broadcasts a DHCPDISCOVER message on its local link. After eventually receiving multiple DHCPOFFER messages, the SS broadcasts a DHCPREQUEST message for initiating the provisioning of the desired host configuration information. 2.2. IPv6 over Ethernet Transmission of IPv6 Packets over Ethernet Networks is defined by [RFC2464] providing the frame format for encapsulation of IPv6 packets into Ethernet frames as well as the methods of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. Transmission of IPv6 Packets over Ethernet over IEEE802.16 has a couple of issues as listed in [I-D.jee-16ng-ps-goals]. 3. The IEEE802.16 Link Model 3.1. Connection Oriented Air Interface The IEEE802.16 MAC provides connections between the BS and its associated SSs. Each of these connections is identified by a 16bit CID number and has defined QoS capabilities. Multiple links can be established between a BS and a SS, each with its particular QoS class and direction. | | | | +--+--+ -+--+ +--+--+ +--+-+-+--+ | MAC | | MAC | | MAC | | MAC | +-----+ +-----+ +-----+ +---------+ | PHY | | PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | +-------|-+-------|-+----CID#w--<-+ | | | | | +------CID#x------+ | | | +----------------CID#y--------+ | +--------------------------CID#z----------+ SS#1 SS#2 SS#3 BS Basic IEEE802.16 Link Model While uplink connections provide only unicast transmission Riegel Expires December 21, 2006 [Page 4] Internet-Draft IPoETH over IEEE802.16 June 2006 capabilities from a particular SS to the BS, downlink connections can be used for unicast transmission from the BS to a particular SS as well as for multicast transmissions to a group of SSs. 3.2. IP over Ethernet Link Model According to [I-D.ietf-ipv6-2461bis] an IP Link is defined as a communication facility or medium over which nodes can communicate at the link layer, i.e. the layer immediately below IP. A well known example is Ethernet. IEEE802.16 provides point-to-point connections between SSs and the BS without enabling any direct SS to SS connectivity. Ethernet is realized on top of IEEE802.16 by implementing bridging between all BSs with IEEE802.16 providing the links between the hosts and the bridge on top of the BS like the twisted pair wires used in today's switched Ethernet. ------------ IP Link -------------------- | | | | ETH ETH ETH ETH | | | | | | | +----+----+ | | | | Bridge | | | | +-+-+-+-+-+ | | | | | | | +--+--+ -+--+ +--+--+ +-+-+-+-+-+ | MAC | | MAC | | MAC | | MAC | +-----+ +-----+ +-----+ +---------+ | PHY | | PHY | | PHY | | PHY | +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+ | | | | | | | | | | | +-------|-+-------|-+----CID#w--<-+ | | | | | +------CID#x------+ | | | +----------------CID#y--------+ | +--------------------------CID#z----------+ SS#1 SS#2 SS#3 BS IPoETH Link Model It is possible to control the size and coverage of IP links by segmenting the Ethernet and grouping particular links into VLANs. Such segmentation is mostly done between BSs, but it is also possible to extend the segmentation over IEEE802.16 links when multiple hosts are attached to a bridge at the SS. 3.3. Convergence Sublayers The assignment of higher layer packets to particular service flows Riegel Expires December 21, 2006 [Page 5] Internet-Draft IPoETH over IEEE802.16 June 2006 and the related CIDs is performed within the IEEE802.16 convergence sublayer by classifying the packets according to particular header fields. To enable the transmission of different kind of payloads over IEEE802.16, multiple types of classification types are defined, each specific for one kind of upper layer protocol, like Ethernet, IPv4, IPv6 or even for encapsulated payload, like IPv4 over Ethernet or IPv6 over Ethernet. Optionally the convergence sublayer performs a packet header suppression reducing static parts of the classified header fields to a single byte value. With the application of the packet header suppression function there is mostly no difference in header overhead over the air for Ethernet encapsulated IP packets in comparison to plain IP packets. 3.4. Multicast and Broadcast Support Downlink connections can be shared among multiple SSs, enabling multicast channels with multiple SSs receiving the same information from the BS. Multicast is not enabled in the uplink but must be realized by an entity on top the IEEE802.16 MAC sending packets received on a unicast uplink downstream on a multicast channel. 3.5. Wireless Particularities The need for special care for transmission of IP packets over IEEE802.16 originates out of the particularities of wireless links and mobile communication systems. As shown above, full Ethernet functionality can be implemented on top of IEEE802.16 point-to-point links between bridges. Two characteristics of wireless links discourage the deployment of a plain Ethernet link model on base of IEEE802.16: wasting radio resources and wasting battery power of SSs by transmitting broadcast and multicast packets to all stations. Without implementation of the special multicast and broadcast channels in IEEE802.16 all multicast and broadcast packets have to be transferred over unicast connections to each SS causing radio resources redundantly be used for transmission of the same information. Usage of dedicated multicast and broadcast channels in the downlink reduce the overhead but still requires the radio resources for the weakest link. With multiple stations receiving the same downlink channel, the channel has to be encoded in the most robust way to ensure that each of the stations successfully decodes the transmitted information. Unicast channels can often transfer the same amount of information with much less radio resources by applying higher grade modulation schemes on better links. Multicast transmission does not only consume more radio resources than usually needed for unicast transmission but also causes the SSs to receive and process the packets regardless of the necessity. Riegel Expires December 21, 2006 [Page 6] Internet-Draft IPoETH over IEEE802.16 June 2006 Especially in mobile networks with many stations staying for long periods in idle modes and power down modes this causes a considerable consumption of scarce battery power. 4. Support of IP over Ethernet over IEEE802.16 As outlined before, special support is desirable for preserving radio resources as well as battery power when transmitting IP packets over IEEE802.16 radio links. While Ethernet encapsulation of the IP packets over the air hardly does not cause any overhead, Ethernet provides a well known and widely deployed link model for IPv4 as well as IPv6. Enhancing the Ethernet emulation on top of IEEE802.16 with functions to reduce the transmission of multicast and broadcast messages over the radio link preserves scare resources without impacting the implementation of IP protocols in the mobile host as well as in corresponding hosts in the Internet. 4.1. IEEE802.16 without multicast support The first release of the mobile WiMAX network specification created by the Networking WG within the WiMAX Forum does not contain support for the native multicast capability of IEEE802.16. All data is transferred on unicast CIDs and multicast has to be emulated by multiple transmissions of the same information to each of the SSs. To increase the efficiency of transmission of IP packets over the IEEE802.16 radio link, a couple of IP specific support functions are provided within the bridging function on top of the IEEE802.16 MAC to prevent multicast of IP packets whenever feasible. Nevertheless the broadcast and multicast functionality of the standard learning bridge function and standard Ethernet emulation remains available for all cases when no IP specific support functions are intercepting the packets. This ensures that the link beneath the IP stack always behave like standard Ethernet and no modifications are necessary in the implementation of the IP stack. 4.1.1. Default Processing of Ethernet Frames (for information) If the SS has multiple LAN ports then it SHALL support Standard Learned Bridging between all its LAN ports and the airlink. The BS SHALL support Standard Learned Bridging between all its radio connections and the interfaces towards the network side. When performing Standard Learned Bridging, the SS or BS shall learn all source MAC addresses originating from a port up to MAXMSIP individual learned addresses. The accumulation of all learned MAC to Riegel Expires December 21, 2006 [Page 7] Internet-Draft IPoETH over IEEE802.16 June 2006 port associations constitutes the Learned Bridge Table. The Standard Learning Bridge shall automatically unlearn a MAC to port relationship after BRIDGETIMEOUT seconds have expired without any traffic from that MAC address. Information for the Learned Bridge Table MAY be transferred during handover of a mobile IEEE802.16e station to the target BS. The particular protocol for transfer of information for the Learned Bridge Table is out of scope of this specification. When performing Standard Learned Bridging any packets destined for one of the addresses in the Learned Bridge Table SHALL be forwarded directly to that port. When performing Standard Learned Bridging all packets received from a port, for which the packet's destination MAC address is also an entry for that port in the Learned Bridge Table SHALL be dicarded silently. When performing Standard Learned Bridging, the BS SHALL forward all packets received from any radio connection to a network side port. (Peer-to-peer communication is not supported by the Standard Learned Bridging in the BS.) When performing Standard Learned Bridging, the BS SHOULD flood any packet received from a network side port destined for a MAC broadcast or multicast address to all its radio connection interfaces. This flooding MAY be prevented by one of the filtering rules given in the sections below. 4.1.2. Packet Filtering The BS SHALL have the ability to enable or disable any filtering functionality defined herein. If a packet is filtered it SHALL be silently discarded. When performing Standard Learned Bridging, the ASN SHALL support filtering of all packets received from a network side port to a destination MAC address not existing in the Learning Bridge Table. When performing Standard Learned Bridging, the ASN SHALL support filtering of all packets received from a network side port to a broadcast or multicast MAC address. If filtering is enabled the ASN SHALL permit all Address Resolution Protocol messages to pass to the ARP Proxy Agent. 4.1.3. IPv4 specific Packet Processing 4.1.3.1. Proxy Address Resolution Protocol (Proxy-ARP) The BS SHALL support Proxy-ARP. The BS SHALL have the ability to enable or disable Proxy ARP. If Proxy ARP is disabled, the ARP Proxy Agent shall pass all ARP Riegel Expires December 21, 2006 [Page 8] Internet-Draft IPoETH over IEEE802.16 June 2006 packets without discrimination or modification using Standard Learned Bridging. Upon receiving an ARP Request from a network side interface, the ARP Proxy Agent shall unicast an ARP Response back to that interface, provided that the target address matches an entry in the Proxy ARP table. If no match is found in the Proxy ARP table, the ARP Proxy Agent SHALL support silently discarding the Request or flooding the Request to all radio connection interfaces based upon configuration option. The ARP Proxy Agent shall pass all ARP Response packets without discrimination or modification using Standard Learned Bridging. Upon receiving an ARP Request from an radio connection interface, the ARP Proxy Agent shall unicast an ARP Response back to the interface provided that the target address matches an entry in the Proxy ARP table. Otherwise, the ARP Proxy Agent shall flood the Request to all network side interfaces. The ARP Proxy Agent shall silently discard any received self-ARP Requests. Those are requests for a target IP address, that when queried in the Proxy ARP table results in a response MAC equal to the Request's source MAC address. The ARP Proxy Agent shall issue a gratuitous ARP on the network side interfaces for any new addition to the Proxy ARP table. An unsolicited broadcast ARP Response constitutes a gratuitous ARP. The Proxy ARP table MAY be established out of other IPv4 specific information available in the BS, e.g. DHCP Proxy or MIPv4 FA. The particular procedures are implementation dependent. Information for the Proxy ARP Table MAY be transferred during handover of a mobile IEEE802.16e station to the target BS. The particular protocol for transfer of information for the Learned Bridge Table is out of scope of this specification. 4.1.3.2. ### TBD ### ### TBD ### 4.1.4. IPv6 specific Packet Processing ### TBD ### 4.2. IEEE802.16 with multicast support 4.2.1. ### TBD ### ### TBD ### Riegel Expires December 21, 2006 [Page 9] Internet-Draft IPoETH over IEEE802.16 June 2006 5. Security Considerations ### TBD ### 6. References [IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [IEEE802.16e] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 2005. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-05 (work in progress), October 2005. [I-D.jee-16ng-ps-goals] Jee, j., "IP over 802.16 Problem Statements and Goals", draft-jee-16ng-ps-goals-00 (work in progress), February 2006. Riegel Expires December 21, 2006 [Page 10] Internet-Draft IPoETH over IEEE802.16 June 2006 Author's Address Max Riegel Siemens St-Martin-Str 76 Munich 81541 Germany Phone: +49-89-636-75194 Email: maximilian.riegel@siemens.com Riegel Expires December 21, 2006 [Page 11] Internet-Draft IPoETH over IEEE802.16 June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Riegel Expires December 21, 2006 [Page 12]